Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Combien de temps pour une transition agile?

Publié par Philippe Tremblay le lundi 11 mai 2015 à 11:30

Infinite Paradise

Cette question est présente dans la bouche de bien des gens jonglant avec l’idée de se lancer dans l’évolution représentée par les principes et techniques agiles.  Le nombre de réponses possibles à cette question est probablement similaire à la quantité de contextes possibles.  Ce qui donne souvent des réponses ressemblant à ces exemples...

  • « Ça dépend »
  • « Le même temps que celui requis pour entrer et sortir d’un trou noir »
  • « Combien de temps avez-vous? »

Bien que ces réponses soient valides, elles risquent fort de laisser votre interlocuteur sur sa faim.  Sa question, pertinente à souhait, mérite après tout un peu plus de considération!  En ce qui me concerne, j’aime bien la réponse qui suit.  Elle vise à donner un ordre d’envergure tout en soulignant les principaux défis ou acquis essentiels à une réussite

5 ans.

Et retranchez une année pour chacun des points suivants si vous les possédez déjà:

  • Vous avez une équipe de leadership puissante qui communique un sentiment d'urgence du changement accompagné d'une vision claire et forte
  • Excellence technique et automatisation
  • Esprit d'équipe et motivation intrinsèque chez vos membres
  • Une stratégie d'affaires (vision, planification, priorités) claire et adaptative, découlant d'une relation étroite avec vos clients

 

D'autres billets qui pourraient vous intéresser

photo: Infinite (license)

Agile comme un enfant, 2eme partie

Publié par Marc Allard le mardi 5 mai 2015 à 12:39

Enfants

La Anderson School, à New York, est une école pour les enfants surdoués. Même pour être admis à la maternelle, les jeunes candidats doivent se farcir deux tests d’intelligence et l’institution ne retient que ceux qui se classent dans le top 4 %.

Il y a quelques années, j’ai lu un reportage qui s’amorçait avec l’histoire de Thomas, un élève de cinquième année de cette école ultra-compétitive. Thomas avait éclipsé la concurrence à l’épreuve d’admission. Même dans le top 1% des candidats, il avait obtenu un des meilleurs scores. 

Le gamin savait qu’il était intelligent. Question de renforcer son estime de soi, ses parents et son entourage lui avaient répété depuis tout jeune à quel point il était «smart». Avec un tel cerveau athlétique et des éloges à répétition, on se serait imaginé que Thomas allait déborder de confiance en soi, s’attaquant sans peur à la matière scolaire qui se trouverait sur son chemin.

Mais non. Son père observait le contraire : «Thomas ne voulait pas essayer des choses où il ne réussirait pas. Certaines choses lui venaient très rapidement, mais quand ce n’était pas le cas, il abandonnait presque aussitôt, se disant "je ne suis pas bon dans ça"».

Dans mon dernier billet, je vous parlais d’un groupe d’élèves de la maternelle qui avait réussi à battre des ingénieurs chevronnés à un défi de construction d’une tour de spaghettis. J'expliquais cet étonnant résultat en pointant, à l’image du livre de la journaliste Megan McCardle, le principal responsable : la peur de l’échec (et son meilleur ami, la peur du risque). Vous avez été plusieurs à réagir et à vous demander si cette peur n’avait pas quelque chose à voir avec notre système d’éducation?

L’histoire du petit Thomas est révélatrice à cet égard. Ce n’est pas tant le système d’éducation que les éloges constants à propos de son intelligence qui l’ont rendu aussi effrayé d’échouer.

Au Québec, les enfants reçoivent, comme leurs voisins américains, de constants éloges. La plupart des parents ont le réflexe du «Bravo, mon champion» très généreux, même quand ce n’est pas mérité. C’est la même chose à la garderie, à l’école ou dans l’équipe de soccer : il n’est pas rare que tout le monde ait droit à un collant ou à une médaille, peu importe le résultat.

Or, il s’avère que ces éloges continuels nuisent plus aux enfants qu’ils ne les aident. Carol Dweck, psychologue à l’Université Stanford, aux États-Unis, a consacré l’essentiel de sa carrière à cette question. Dans une de ses expériences les plus célèbres, elle a testé l’effet de deux types d’éloge auprès de 400 élèves de 5e année d’une école primaire régulière de New York. Après avoir effectué un casse-tête plutôt facile, la moitié du groupe s’est fait complimenter sur son intelligence («you must be really smart at this») et l’autre s’est fait complimenter sur son effort («you must have worked really hard». Ensuite, l’équipe de Carol Dweck a demandé aux mêmes élèves de choisir entre deux nouveaux tests : un plus difficile, où ils auraient l’occasion d’apprendre, et un autre plus facile, comme le premier. Parmi le groupe qui s’était fait louanger pour son effort, 90% ont choisi le test difficile, et parmi le groupe louangé pour son intelligence, la majorité a choisi le test facile.

«Quand on félicite un enfant pour son intelligence, on lui dit que c’est comme ça que ça fonctionne dans la vie : aie l’air intelligent, ne risque pas de faire des erreurs», écrit Dweck dans le résumé de sa recherche

Dans son livre Mindset, traduit en français en 2010, la professeure explique qu’il y a deux façons de voir ses habiletés : avec un état d’esprit «fixe» (fixed mindset) ou un état d’esprit «de développement» ou «incrémental» (growth mindset). Thomas, qui avait un état d’esprit fixe, était convaincu qu’il y avait deux sortes de défis : ceux où il était naturellement bon, et ceux où il ne l’était pas — donc pas la peine d’essayer.  Les jeunes champions de la tour de spaghettis, eux, se disaient que chaque tour qui s’écroulait était une occasion d’apprendre à coiffer des ingénieurs. 

Je vous laisse deviner dans quel état d’esprit l’agilité peut fleurir... 

D'autres billets qui pourraient vous intéresser

Mots-Clés :

Standardiser ses activités de développement

Publié par David Beaumier, Jean-François Gilbert le mercredi 29 avril 2015 à 14:33

Pour ce 4ième billet de la série sur l’application de la méthode des 5S en développement logiciel nous aborderons l’aspect standardisation (ou Seiketsu en japonais). Ce principe vise principalement à :

  • Standardiser les meilleures pratiques;
  • S’assurer que chaque processus est appuyé sur une façon de faire éprouvée et connue;
  • Maintenir le niveau de qualité dans l’ensemble des activités;
  • Préserver l’ordre et la propreté (les 3 premiers s).

On ne parlera donc pas des normes telles que CMMI, Macroscope ou ITIL dans ce billet. La standardisation dont on parle est à un niveau beaucoup plus tactique et se trouvera complémentaire à vos processus.

Établir les règles

Clean CodePeu importe les conventions, normes et orientations que vous choisirez, l’important est qu’elles soient suivies. Certains membres de l’équipe pourraient préférer une approche différente et ils ont tout à fait le droit. Cela ne devrait toutefois pas les autoriser à contourner les règles communes. Pour favoriser l’adoption de ces règles et faire en sorte qu’elles soient accordées au « nous » il est toujours préférable de les choisir collectivement que de les imposer.

Un des bons points de départ peut être que chaque membre de l’équipe fasse la lecture (ou la relecture) du livre Clean Code de Bob Martin. Même s’il date d’un peu plus de 6 ans, ce livre demeure une référence incontournable pour qui veut produire du code de qualité. J’ai été agréablement surpris de voir qu’il était toujours dans le top 20 des meilleurs vendeurs en développement logiciel.

Adopter un standard de programmation

Bon nombre de ces standards ont déjà été écrits. Vous pourriez donc vous sauver bien du travail en adoptant une convention existante. Par exemple :

Si vous choisissez d’en bâtir un qui soit spécifique à votre équipe, essayez tout de même de respecter les conventions habituelles de votre langage (les nouveaux équipiers vous en seront très reconnaissants). Adoptez aussi un style concis : énoncez la règle et évitez les longues justifications.

N’oubliez pas le code qui tourne autour des bases de données. Sans standard les artéfacts peuvent devenir rapidement aussi différents les uns des autres que le sont les flocons de neige. Encore plus vrai si vous utilisez des artéfacts contenant de la logique (fonctions, procédures stockées, etc.). L'uniformisation de votre base de données viendra aussi vous simplifier la vie si vous souhaitez éventuellement intégrer un ORM car la conversion OO-SGBD s'appui sur une convention.

Au-delà des conventions

La standardisation va bien au-delà des simples conventions.  Ce souci d’uniformisation devrait transparaître dans l’ensemble de votre application.  Prenons l’exemple de Sonos, ce système intelligent de haut-parleurs sans-fil. Sonos propose une application servant à contrôler votre système sur les plateformes les plus répandues (Android, iOS, Mac et Windows). L'entreprise s'est efforcée de standardiser l'expérience utilisateur entre toutes ces plateformes, ce qui fait que vous bénéficierez d'un « look and feel » cohérent que vous utilisez la version iOS ou Windows. En plus, Sonos a réussi cette standardisation tout en tirant profit des capacités particulières à chaque plateforme.

Dans votre application, la standardisation devrait donc transparaître autant de l’intérieur (le code) que du point de vue du client. Voici quelques exemples de standardisation dans un applicatif :

  • Établir un vocabulaire uniforme du domaine d’affaire et s’y référer constamment;
  • Définir des abstractions-clé arrimées avec le domaine d’affaires et en promouvoir l’utilisation dans le vocabulaire autant que dans le code;
  • Favoriser la création de classes réutilisables;
  • Bâtir des mécanismes de déploiement automatisés;
  • Proposer une expérience utilisateur uniforme dans tous les modules.

Une équipe qui gère les dépendances entre les fichiers Javascript à l’aide d’une approche déclarative (telle que proposée par RequireJS) se trouve à standardiser ses façons de faire tout en améliorant la qualité du code et en offrant une meilleure vitesse d’exécution pour l'utilisateur.

Détecter les écarts

Si vous souhaitez maintenir le niveau de qualité à long terme, rien de mieux que de mettre en place des points de contrôle fréquents, idéalement automatisés. Dès que vous trouvez un écart par rapport à la cible, trouvez un moyen que cette situation ne se reproduise pas. Avec le temps vous bâtirez un solide harnais de sécurité.

Un plugiciel comme Checkstyle (pour Eclipse), Rubocop en Ruby ou FxCop (la fonctionnalité Static Code Analysis de Visual Studio) permet de vérifier si les standards de programmation sont respectés. Il est possible de choisir quelles règles doivent s’appliquer et même d’en développer des personnalisées, si besoin est.

Checkstyle

Il est même possible d’appliquer des vérifications automatisées au niveau du respect des principes d’architecture. Visual Studio offre la possibilité de valider que les dépendances entre les différents projets de votre solution respectent les choix que vous avez faits au niveau du diagramme d’architecture. Cette validation peut même être intégrée au processus d’intégration continue. Vous aurez rapidement une rétroaction si un équipier contourne le modèle établi. Beaucoup plus intéressant que de le réaliser quelques semaines plus tard!

Regarder le processus dans son ensemble

Le principe de standardisation aura avantage à s’appliquer au-delà des activités de « codage ». Si vous ne l’avez pas déjà fait, pourquoi ne pas illustrer votre processus de développement dans son ensemble. Cela vous permettra de voir les grandes activités qui le composent et creuser pour voir quels sont les standards existants pour chacune d’elles.

Par exemple, est-ce que la gestion du carnet est standardisée? Est-ce que la formule « En tant que <acteur> je veux <besoin> afin de <bénéfice d’affaires> » est systématiquement utilisée pour vos stories? Les critères d’acceptation sont-ils définis avant la cérémonie de planification? Est-ce que le carnet de produit est révisé (backlog grooming) sur une base régulière? Ce sont toutes des activités qui auront avantage à être standardisées selon votre réalité.

Il en sera de même pour les activités de déploiement (le fameux DevOps) ou de prise en charge des demandes des clients. En fait, standardiser ce type d’activités aura un double bénéfice en offrant à vos clients une expérience beaucoup plus uniforme et prévisible.

Enseigner et diffuser

Vous aurez beau établir les meilleurs standards, développer des procédures simples et précises et offrir des outils hors-pairs, si les membres de votre équipe ne savent pas qu’ils existent ou comment les utiliser, vous risquez de ne pas être plus avancés!

Il existe une foule d’outils disponibles pour consigner ce genre d’information. Peu importe l’outil que vous choisirez (tel qu’un wiki, par exemple), assurez-vous que l’outil en question offre un bon moteur de recherche et encouragez les gens à s’y référer et, surtout, à garder le contenu à jour.

Prévoyez aussi accompagner les gens de votre équipe. Il se peut que le p’tit nouveau oublie d’appliquer certaines des règles de conception (pourtant inscrites dans le wiki) et un rappel amical peut faire toute la différence. La programmation en paire ou les revues de conception sont des façons de guider les équipiers dans l’application des standards.

Contrôler et adapter

La standardisation n’est pas une activité dogmatique et elle ne vise pas à réduire la capacité d’innovation de votre équipe. Il ne faut pas hésiter à remettre en question les façons de faire afin de ne pas tomber dans le piège du « c'est de même que ça se fait depuis toujours ici ». On le sait, en informatique la technologie et les outils évoluent à vitesse grand V. Les façons de faire doivent s'adapter. Les rétrospectives d’équipe sont un bon moment de se questionner sur les standards existants et proposer des changements qui seraient bénéfiques.

D'autres billets qui pourraient vous intéresser

Une roche dans le soulier

Publié par Jean-Francois Gilbert le jeudi 23 avril 2015 à 00:00

Course

Vous courez depuis un bon moment déjà et vous avez atteint votre vitesse de croisière. L'endorphine et le vent chaud du printemps provoquent en vous une douce euphorie. Tout va bien, vous filez le parfait bonheur! Soudain, vous la sentez vous piquer. Une petite roche s'est glissée dans votre soulier, puis à l'intérieur de votre bas. Au début, vous la remarquez à peine. Mais après un moment, l'inconfort fait place à la douleur. Vous pourriez décider de l'endurer et de continuer à courir. Après tout, vous avez la moitié du chemin de parcouru. Mais vous savez que la roche risque de vous couper. En modifiant un peu votre foulée, vous vous rendez compte que la roche se fait plus discrète. Cependant, après quelques kilomètres de plus, votre démarche inhabituelle créé une douleur musculaire pire que celle causée par la roche ! Parfois, la seule idée de prendre une pause de 2 minutes pour détacher notre soulier, retirer le bas et enlever le caillou nous horripile. Le rythme est bon, il ne faut surtout pas s'arrêter de courir ! Pourtant, on risque une blessure qui va nous ralentir encore plus.

Je vois souvent le même comportement dans des équipes de développement logiciel. On accumule de la dette technique. Le build fonctionne une fois sur deux. Des tests intégrés sont instables et on commence à les ignorer sans essayer de comprendre la cause du problème. Comme le coureur, l'équipe risque d'en souffrir beaucoup plus à long terme. Les tests n'étant plus fiables, on ignorera des symptômes évidents et la stabilité du logiciel s'en ressentira. Parfois ce sont des problèmes humains : l'ambiance dans l'équipe n'est plus bonne ou encore on accepte sans rien dire des comportements néfastes.

Ce n'est pas toujours plaisant de faire une pause dans le développement. Parfois on subit beaucoup de pression de nos supérieurs pour soutenir la cadence. Mais il faut vraiment le faire lorsque ça devient nécessaire. Les problèmes se règlent rarement d'eux-mêmes et il ne faut pas attendre que ça fasse mal pour s'y attarder. La rétrospective du sprint est le moment tout indiqué pour mettre en lumière les problèmes à corriger. On a souvent tendance à faire cet exercice un peu vite et à la légère. Il n'y a pourtant pas de meilleur moment pour discuter des embûches, que lorsque toute l'équipe est présente. C'est l'occasion de se questionner en tant qu'équipe et de relever les points agaçants qui vous empêchent de bien travailler. 

Une fois les irritants énumérés, c'est le moment de passer à l'action afin de les éliminer. À mon avis, ces actions devraient se retrouver dans le carnet du sprint autant que possible. Il faut les rendre visibles, les prioriser et les attaquer rapidement. L'équipe devrait s'engager à régler les problèmes de la même façon qu'elle s'engage à livrer de la valeur au client. Autrement, après quelques sprints une vilaine roche risque de réduire la capacité de l'équipe à satisfaire le client.

D'autres billets qui pourraient vous intéresser

 

Nettoyer votre code pour le rendre 5 S

Publié par David Beaumier, Jean-François Gilbert le lundi 20 avril 2015 à 08:13

Nous voilà rendus au 3ième concept de la méthode 5S : nettoyer (ou seiso en japonais). Comment ce principe, pensé à la base pour éviter la détérioration de la machinerie et des équipements, peut-il s’appliquer en développement logiciel?

Revenons pour une seconde aux fondements de la méthode 5S : une fois l’espace de travail ordonné (le premier S) et rangé (le second S), il devient beaucoup plus simple de le nettoyer puisque ce qui a besoin de nettoyage devient dès lors visible.  En développement, on pourrait penser à ces bouts de codes qui ont mal vieilli et qui handicapent d’une façon ou d’une autre le système. La fameuse dette technique, quoi!

Évidemment, pas besoin d’avoir fait les étapes 1 et 2 dans l’ensemble du code pour pouvoir passer au nettoyage. En procédant ainsi vous risqueriez même de salir de nouveau certains coins si l’application est d’une certaine envergure. Pourquoi ne pas directement cibler les morceaux qui sont connus pour dégager une odeur (virtuelle, on s’entend) nauséabonde? Probablement qu’il faudrait très peu de temps à l’équipe pour les identifier!

Nous vous proposons dans ce billet quelques suggestions pour procéder au nettoyage de votre base de code.

La règle des scouts

La bonne vieille règle des scouts, soit celle de laisser le campement plus propre au départ qu’à l’arrivée, peut être une bonne façon de procéder à un nettoyer graduel de votre code. En effectuant ici et là une extraction de méthode, un renommage ou en révisant une condition en introduisant un guard clause (quelqu’un a une bonne traduction à proposer?) votre équipe en viendra à rehausser la maintenabilité de la base de code. Et cela, sans impacter de façon significative son rythme de livraison habituel.

L’important dans toute opération de nettoyage de cette envergure est de se donner des objectifs atteignables, de mesurer la progression régulièrement (tous les sprints, par exemple) et d’ajuster le tir en fonction de ce que vous découvrirez. C’est surprenant de voir ce qu’on peut accomplir lorsqu’on rend visible la crasse qui se cache dans certains recoins du code!

Réingénierie (refactoring)

La réingénierie logicielle est la technique qui revient le plus souvent lorsqu’on parle de nettoyer du code existant.

La réingénierie logicielle est un processus ayant pour objectif de transformer et améliorer un logiciel à partir du modèle existant sans toutefois modifier son comportement externe.

Livre RefactoringtopatternMême si elle est simple à comprendre, c’est une technique qui demande beaucoup de pratique pour développer les bons réflexes et savoir bien doser son utilisation. Si vous débutez avec cette pratique, la lecture du livre Refactoring: Improving the Design of Existing Code de Martin Fowler s’avère toujours un bon point de départ (même après plus de 15 ans). Un catalogue des différents types de réingénierie est aussi disponible en ligne.

Le livre de Kerievsky s’adressera quant à lui aux personnes qui ont déjà un peu d’expériences avec la réingénierie et qui souhaitent voir comment cette technique peut être combinée avec les patrons de conception.

Scott Ambler et Pramod Sadalage ont même appliqué les principes de la réingénierie logicielle aux bases de données relationnelles dans leur livre Refactoring Databases: Evolutionary Database Design.  Vous n’aurez dorénavant plus aucune excuse pour ne pas nettoyer votre schéma de base de données!

Outils disponibles

Il existe aujourd’hui des fonctionnalités de réingénierie dans pratiquement tous les IDEs. Sinon, des extensions plus avancées peuvent vous aider, tel que Resharper sous Visual Studio. Ces outils vous sauveront du temps, tout en évitant les erreurs typiques associées aux opérations manuelles de rechercher/remplacer.

Des outils spécialisés pour les SGBDR, tels que Liquibase ou SQL Server Data Tools vous aideront à produire les scripts de mise à jour requis pour offrir une cure de jeunesse à vos bases de données. La vidéo ci-dessous vous permettra d'avoir un aperçu de l'utilisation de Liquibase.

Identifier les candidats potentiels au nettoyage

Encore une fois, les techniques du management visuel peuvent venir à notre rescousse pour vous aider à identifier les bouts de code qui sont de bons candidats à la réingénierie. Par exemple, l'extension Microsoft CodeLens Code Health Indicator (pour Visual Studio Ultimate) permet d’obtenir plusieurs mesures sur la maintenabilité du code et l’indicateur visuel vous indiquera si vous êtes face à un bout de code qui rencontre les exigences (en tout cas, celles de Microsoft). On peut même voir si la modification courante améliore ou non le code et ajuster le tir au besoin. Ça réduit de beaucoup la boucle de rétroaction.

Codehealth

SourceMonitor est un autre outil qui peut aider à identifier les classes qui ont besoin d’un peu d’amour. Bien qu’il ne soit pas directement intégré à un IDE, SourceMonitor a l’avantage de supporter plusieurs langages de programmation, tels que C++, C, C#, VB.NET, Java et Delphi. Il permet de cibler un sous-ensemble plus ou moins grand de votre base de code et produit les métriques de différentes façons, tel que démontré ci-dessous. Il est aussi possible d'en automatiser l'utilisation de façon à prendre des mesures sur une base régulière.

Sourcemonitor

Et vous, quels sont les techniques et outils qui vous permettent de nettoyer votre code? Quels approches ont été les plus bénéfiques pour votre équipe?

D'autres billets qui pourraient vous intéresser

Archive