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.

Quelques chiffres viennent appuyer les bonnes pratiques agiles

Publié par Philippe Tremblay le jeudi 5 septembre 2013 à 05:40

Agile est dans le paysage du développement logiciel depuis plus d’une décennie et l’expérience acquise par essais et erreurs durant ces années est inestimable.  Cette connaissance permet aux passionnés (telle l’équipe d’Elapse) de conseiller, d’accompagner les organisations et leurs membres dans la transformation agile de façon beaucoup plus efficiente.  Et bien que le cycle d’amélioration continue exercé par les adeptes des valeurs agiles amènera sans aucun doute une évolution des pratiques, il en existe déjà plusieurs n’étant pas partie intégrante de cadres tels Scrum, mais qui sont généralement acceptées comme de bonnes pratiques.

Récemment, Rally Software a émis une première série de chiffres extraits de l’utilisation faite de leur logiciel de la part de milliers d’utilisateurs afin de quantifier l’impact des pratiques agiles sur la qualité et la performance.  Plusieurs sondages (dont celui de VersionOne) ont déjà mis en évidence les avantages (et les embuches) d’une transition agile, mais à notre connaissance, très peu d’analyses statistiques ont permis de mettre en relation les pratiques agiles et ses bénéfices potentiels.  Vous trouverez un lien vers le rapport fait par Rally Software à la fin de cet article, mais pour l’instant, nous aimerions vous présenter quelques-uns des aspects discutés dans ce rapport.

Composition et stabilité des équipes

« Un nouveau projet?  Allez hop, formons une nouvelle équipe dédiée à ce nouveau projet! »

Tous ceux qui ont déjà vécu ou accompagné des équipes dans leurs différentes phases de développement ont assurément une baisse de pression à cette proposition très répandue de « gestion d’équipe par projet ».  Il est si difficile d’atteindre la formation d’une équipe de haute performance, que l’idée de détruire ces efforts et les énormes bénéfices en découlant semble pour le moins injustifiable.

Que dit le rapport?

Les équipes stables sont :

  • 60% plus productives
  • 40% plus prévisibles
  • 60% plus rapides pour répondre aux changements

La taille est importante

Une petite équipe est plus susceptible aux variations (imprévus), donc moins prévisible.  La créativité collective risque également d’être limitée par le nombre d’opinions et la composition de l’équipe.  Une trop grosse équipe et vous risquez de n’avoir aucun des bénéfices d’une équipe hautement performante où la communication informelle et le focus sont au centre de leurs interactions quotidiennes.

Que dit le rapport?

Les équipes de moins de 4 membres sont :

  • 40% moins prévisibles
  • 17% moins de qualité
  • Mais, 17% plus productives [est-ce productif d'avoir moins de qualité?]

Agile et la planification

Pour certains, la planification agile est un oxymoron.  Pour d’autres, c’est beaucoup trop de rencontres et de perte de temps.  Mais pour la plupart de ceux ayant expérimenté la puissance et le juste assez d’une planification de sprint ou les possibilités d’adaptation offerte par une planification agile d’un plan de livraison, la planification est un levier essentiel à plusieurs bénéfices agiles.

Que dit le rapport?

  • Les équipes effectuant l’estimation relative et le découpage en tâches comme planification de sprint ont une qualité 250% meilleure que les équipes n’effectuant aucune estimation relative.
  • Les équipes utilisant l’estimation relative sans effectuer le découpage en tâches ont une meilleure performance globale.  Plus productive, plus prévisible et plus rapide à répondre aux changements.

À première vue, il peut paraître difficile de comprendre la corrélation entre l’estimation relative de la planification avec la qualité produite.  Pour ma part, je crois que cette qualité découle justement de ce qui est au cœur de l’estimation relative faite lors de la planification, soit les discussions entre les membres de l’équipe.  Les échanges et la confrontation respectueuse d’idées entre les membres permettent d’accéder à des aspects fondamentaux de la qualité telles la recherche de meilleure solution et l’appartenance commune du logiciel.

Je suis personnellement satisfait de constater que le découpage en tâches est une pratique qui, selon le rapport, ne permet pas aux équipes l’obtention de meilleurs résultats.  J’ai déjà établi mes arguments en ce sens lors d’un précédent billet.

En résumé

Le rapport appuie fortement ce que notre expérience a déjà permis de constater dans divers environnements.  Si vous désirez démarrer (ou poursuivre) votre transition agile du bon pied, je vous invite à explorer les principes et valeurs derrière ces pratiques afin de bénéficier de résultats à la hauteur de vos efforts.

  • Ayez des équipes stables
  • Composez vos équipes de 5 à 9 membres
  • Effectuez l’estimation relative (pour les discussions qui en découlent) et juste assez, juste à temps de planification en équipe
  • Limitez votre travail en cours (WIP)

Lien vers le « Agile Performance Metrics Whitepaper » de Rally Software.

Mots-Clés :

Agile Coach Competency Framework

Publié par Louis-Philippe Carignan le mercredi 3 juillet 2013 à 17:00

Lors d’une formation que j’ai suivi au Agile Coaching Institute (ACI), on nous a présenté le « Agile Coach Competency Framework » qui rassemble les différentes compétences qu’un coach Agile doit développer en lui. 

Pour bien le visualiser, les formateurs ont dessiné sur le tapis de la salle ce « framework ». Les images suivantes montre ce dessin :

 Frameworkup

 Frameworkdown

Je trouve ce "framework" extrêmement puissant. Premièrement, il définit clairement les champs de compétences d'un coach Agile, quelque chose qui était mal défini dans l'Agilité. Deuxièmement, ils guident les coachs pour qu'ils puissent identifier leurs points d'amélioration dans ce "framework". Et troisièmement, il informe les clients qui désirent engager un coach Agile. Ils seront maintenant mieux informés de ce que peut apporter un coach Agile lors d'une adoption Agile. 

Voyons voir en surface chaque volet de cette étoile :

Agile-Lean Practitioner

Ce volet est habituellement la porte d’entrée pour les gens qui s’intéressent à l’Agilité. Ils ont lu des livres, participés à des formations ou des évènements Agile qui ont contribué à leurs connaissances Agile. Ils ont senti des bénéfices à cette approche et continuent maintenant à creuser le sujet.

Teaching/Mentoring

Tel que défini par le ACI, un mentor est une personne qui fait bénéficier ses clients de son expérience. En mentorant quelqu’un, il leur partage son expérience et ses conseils. Ce volet est donc consacré à l’enseignement et donc, les compétences que le coach doit développer pour bien partager ses connaissances à ses clients.

Technical/Business/Transformation Mastery

Les fondateurs du ACI ont remarqué avec le temps que les coachs Agile sont originaires de trois endroits différents. Certaines personnes ont un passé technique, c’est-à-dire qu’ils étaient des chefs d’équipe, des architectes ou simplement des gens compétent techniquement parlant. Avec le temps, ces gens sont devenus des coachs Agile.

Il y a aussi des coachs qui arrivent du volet Affaires. Dans une ancienne vie, ils étaient des gestionnaires de produit où la valeur d’affaires était importante pour eux. Ils visaient le plus petit produit à livrer (Minimum Viable Product). Ils ont reconnu en l’Agilité une autre façon d’atteindre cet objectif qu’ils tenaient si cher dans leur ancienne vie.

Finalement, il y a des gens qui ont un passé où ils ont agit comme agent de transformation pour une organisation. Ces gens étaient des catalystes pour le changement en développement organisationnel.

Professional coaching/Facilitator

Ce dernier volet est le plus intéressant à mon avis puisqu’il est nouveau dans tout ce qui existe dans l’Agilité. Si on révise les classiques de Schwaber, Sutherland ou Cohn par exemple, on restait très flou sur le rôle de facilitateur et très peu précis sur ce qu’était un coach.

Grâce au ACI, on définit ce qu’est un facilitateur et les compétences qui lui sont requises. La même chose est vraie pour le coaching professionnel. Un facilitateur est une personne neutre qui tient le processus en place et qui aide les gens impliqués dans leurs recherches de solution. Schwaber affirmait souvent qu’un Scrum Master est comme un berger qui guide son troupeau. Les compétences du facilitateur identifiées dans le framework vont beaucoup plus loin et cela permettra aux coachs Agile de cibler leurs points d’amélioration dans leur travail. Puisque Michael Spayd, l'un des fondateurs du ACI, est un Certified Facilitator Practitioner (CFP), on comprend comment il vient enrichir ce volet dans l'Agilité. À mon avis, notre profession ne fait que gagner avec cette expérience extérieure qui s'intéresse à notre univers.

Le coaching, qui est un partenariat créatif entre un client et son coach, est la dernière facette que Lyssa apporte à l'Agilité En incluant des coachs professionnels dans le ACI, elle viendra bonifier ses cours. Une fois que la mécanique Scrum est en place, que reste-t-il à faire dans l'Agilité? Une partie de la réponse est dans le coaching professionnel et le ACI est en train de bien déterminer ce que peut apporter ce volet à notre profession.  

Conclusion

On retrouvera une courte définition de ces compétences ici dans une ancienne tentative de définir le Agile Coach Competency Framework. Lors de la présentation pendant le cours, on sentait vraiment dans la salle que la nouvelle figure était beaucoup plus représentative de ce qu’un coach est. Tous les participants étaient d’accord que le volet Agile-Lean Practitioner fut leur porte d’entrée dans l’Agilité. Ensuite, chaque personne savait si elle avait un passé technique, Affaires ou transformationnel.

Après plus de 10 ans en Agilité, il est intéressant de voir qu'il n'y aura peut-être pas une prochaine mode mais plutôt un approfondissement de l'Agilité pour qu'un jour, elle soit bien en place dans toutes les équipes de notre profession.

Mots-Clés :

Coach versus consultant

Publié par Louis-Philippe Carignan le mardi 2 juillet 2013 à 22:00

Lors d’une formation récemment, j’ai beaucoup aimé l’image suivante pour comparer un coach à un consultant.

Imaginer que vous êtes le client et que vous avez votre tasse devant vous. Votre tasse représente votre problème en entreprise. Tenez la tasse dans votre main. C’est présentement votre problème.

Lorsque vous engagez un consultant, vous lui donnez votre tasse en lui demandant de régler le problème. Cette façon de faire s’applique dans beaucoup de cas. Lorsqu’il faut fabriquer une solution logicielle et que vous n’avez pas les effectifs pour la produire dans les délais prescris, vous donnerez votre tasse à une firme de consultants pour qu’elle solutionne votre problème. En termes plus larges, le consultant va offrir plusieurs solutions au client.

L’approche est différente avec un coach. Lorsque vous engagez un coach, il vous demande plutôt de garder la tasse dans vos mains. Il est simplement là pour vous aider à résoudre votre problème puisque après tout, c’est votre tasse à café. Le coach assume que vous détenez la solution et qu’elle émergera par des questions fortes. Vous devenez alors partie prenante de la solution ainsi que de sa mise en place.

Mots-Clés :

Mon appréciation des cours du Agile Coaching Institute

Publié par Louis-Philippe Carignan le mardi 2 juillet 2013 à 18:00

Depuis les 2 dernières années, j’ai eu l’occasion de suivre deux cours du Agile Coaching Institute (ACI). Cet institut fût fondé par Lyssa Adkins et Michael Spayd. Lyssa est l’auteure du livre « Coaching Agile Teams » tandis que Michael est sur le point de publier son propre livre, « Coaching the Agile Enterprise ». Grosso modo, l’objectif du ACI est de coacher les coachs Agile.

En juin 2011, j’ai suivi le cours « Coaching Agile Teams » qui est un bon condensé du livre de Lyssa mais avec beaucoup d’interactions. Par exemple, le manuel du participant ne tient que sur une vingtaine de pages. À chaque segment du cours, on voit un peu de théorie pour ensuite mettre la théorie en pratique. On se sert donc du manuel pour prendre quelques notes à propos de la théorie ainsi que noter nos propres expériences lors des exercices. Lors de ce cours, j’ai pu mieux comprendre toutes les facettes d’un coach Agile. Par exemple, j’ai pu faire la différence entre un mentor, coach et facilitateur, trois des postures demandées par un coach Agile. Dans un autre segment du cours, nous avons pratiqué l’écoute active par des exercices et en étant jumelé avec différents individus, on identifie rapidement nos forces et nos faiblesses en ce comparant à nos coéquipiers.

En juin 2013, j’ai alors suivi le cours « The Coaching Stance » qui est la suite du cours que j’avais suivi en 2011. Je me compte chanceux d’avoir suivi ce cours lors de la rencontre annuelle des formateurs de Scrum.org puisque j’ai pu travailler avec des coachs d’expérience. Par exemple, lors d’un exercice, on devait donner du feedback à notre coéquipier. J’ai pu voir comment un coach sénior donnait du feedback et ainsi cibler des points d’amélioration en ma propre personne.

Un point fort de cette formation est le détail d’une conversation qu’un coach a avec son client. Chaque conversation débute en ciblant le sujet dont on veut parler suivi d’une période d’exploration où le client doit répondre à une série de questions fortes posées par le coach. Lorsque le client identifie des pistes de solutions, le coach ferme la conversation en lui offrant une demande ainsi qu’un geste d’imputabilité pour faire un suivi dans des délais raisonnables.

Encore une fois, ce second cours est accompagné d’un manuel d’une vingtaine de pages qui sera remplit de nos propres expériences et commenté d’un peu de théorie. Lors de ce cours, le segment à propos du « Design Alliance » est un vrai bijou. Sans rentrer dans les détails, Lyssa qualifie ce sujet comme étant « Team norms on steroids ». Et c’est exactement ça. En résumé, on voudra dresser un code de conduire lorsque l’équipe va dérailler. Comme exemple pour mieux apprécier le concept, on raconte comment il peut être important de discuter avec les passagers qui sont à côté de nous dans l’avion. Lorsqu’il sera temps d’aller au petit coin, que ferons-nous si la personne à côté de nous dort? Il faudra bien la déranger pour se rendre aux toilettes. Pourquoi ne pas en parler avant pour déterminer comment gérer cette situation. Il est donc préférable d'eéchanger auparavant pour que tout le monde soit d’accord lorsque cela arrivera. C’est le même concept avec son équipe Agile. On se définit des règles pour gérer des conflits qui ne sont pas encore arrivés, question que toute l'équipe soit d’accord sur les mesures à prendre lorsque ceux-ci auront lieux.

Lors des deux cours, je n’ai pas eu le temps de regarder ma montre et j’avais le sentiment de bien avoir investi mon argent. Les formateurs interviennent lorsqu'on se pratique pour qu'on identifie nos points faibles. Certains exercices sont en groupe pour que tous puissent apprendre en même temps avec le feedback des formateurs.

Je recommande ces deux cours aux Scrum Masters et coachs Agile qui désirent améliorer leurs aptitudes au travail. Mais je conseille aussi ce cours aux gestionnaires et chargés de projets qui aimeraient inclure cette dimension à leur carrière. Par exemple, l’écoute active est une habileté fort utile pour un gestionnaire et le temps passé à la pratiquer lors de ces deux cours lui sera certainement bénéfique à son retour au travail. À plusieurs occasions, j’entends des gestionnaires me confier qu’ils aiment bien aider leurs subordonnés identifier leur profil de carrière. Je crois que plusieurs éléments dans les cours du ACI peuvent aider les gestionnaires qui désirent accompagner leur personnel. L’écoute active. Poser des questions fortes. Ces thèmes ne font, qu'à mon avis, améliorer l'étoffe des gestionnaires.

Le ACI offrira bientôt le cours « The Agile Facilitator » qui, vous l’avez deviné, tourne autour du thème de facilitateur. Puisque Michael est un Certified Professional Facilitator (CPF), il a sûrement monté un cours à cet effet. J’invite les Scrum Masters qui lisent ce blogue à garder un œil pour ce cours.

J’ai aussi une opinion favorable envers Lyssa, Michael et leur initiative. Ils ont cerné un créneau dans l’Agilité, coacher les coachs, qui était absent mais nécessaire dans notre profession. Grâce à leur leadership, ils vont définir ce qu’est un coach Agile. Par exemple, ils visent utiliser les « learning objectives » du International Consortium for Agile (IC Agile) pour définir les trois types de coach : Scrum Master (ou Team Facilitator), Agile Coach (ou coach de Scrum Masters) et Enterprise Agile Coach. L’image suivante, prise de leur site, résume bien ces trois niveaux de coaching :

Icagile Coaching 

Finalement, les gens du ACI ne saisissent jamais l’occasion pour ridiculiser les autres experts en Agilité. Dans les dernières années, j’ai souvent lu des chicanes entre Scrum et Kanban, le ridicule envers l'absence de pratiques d’ingénierie sous Scrum ou des moqueries à l’égard des certifications Scrum. Le ACI ne se permet pas une telle critique et cela est tout à son honneur. Ils s’élèvent au-dessus de la mêlée pour le bien de notre profession et non celui de leur porte-feuille.

À deux, c'est mieux !

Publié par Jean-Francois Gilbert le mercredi 19 juin 2013 à 00:00

Tout le monde connait la programmation en binôme, plus souvent appelée « pair programming ». Ses bienfaits ont été empiriquement démontrés, mais sa popularité demeure relativement marginale dans les faits. Il est évident que l'apport de nos collègues ne devrait pas être négligé. Il y a plus d'une façon de collaborer avec les membres de notre équipe et de bénéficier de leur expertise. Dans l'équipe où j'œuvre présentement, cette collaboration porte le nom de "test par un pair". Il s'agit d'une validation de la part d'un collègue, du travail qui a été exécuté et fait partie intégrante de la définition de "terminé" des éléments du carnet de Sprint. Cette pratique s'est avérée très efficace et ses bénéfices sont multiples. Elle a été empruntée à une autre équipe qui avait eu cette brillante idée et nous l'avons bonifiée par la suite.

Fonctionnement

Lors du découpage des tâches des éléments du carnet par l'équipe Scrum, nous créons presqu'obligatoirement une tâche nommée "Test par un pair". C'est la dernière tâche effectuée et elle détermine si l'élément du carnet est terminé ou non. Le collègue qui fait la vérification procède à peu près de la façon suivante :

  • Prend connaissance de l'élément du carnet et des critères d'acceptation.
  • Exécute les tests fonctionnels, aidés par les critères d'acceptation.
  • Consulte le gestionnaire de sources (Team Foundation Server dans notre cas) afin de connaître les changements qui ont été effectués au niveau du code (ajout/suppression de fichiers, modification du code existant, etc.)
  • Valide la qualité du code, c'est-à-dire si celui-ci est conforme à l'architecture et aux normes prescrites par l'équipe, s'il suit les bonnes pratiques de développement, etc.
  • Au besoin, il peut effectuer des corrections ou améliorer le code. Si ces modifications sont non-triviales, il avertira l'auteur du code original pour s'assurer que le changement est sans risque (de plus, les tests unitaires font office de filet de sûreté).
  • Valide la documentation au besoin.

Bénéfices

Outre le fait que l'élément du carnet est testé, cette façon de faire comporte d'autres avantages :

  • Le code que vous écrivez sera presqu'assurément lu par vos collègues. Cela ajoute une saine pression qui incite à produire du code qui respecte les règles de l'art. C'est juste normal de vouloir bien paraître devant nos collègues.
  • Cela force l'équipe à définir des critères d'acceptation et souvent des scénarios de tests avant de commencer à coder.
  • Cela favorise l'échange d'informations. Si vous n'avez pas eu la chance de travailler sur un élément du carnet, le fait de le réviser vous permet de vous mettre au parfum autant au niveau fonctionnel que technique.
  • C'est un excellent moyen d'apprendre et d'enseigner. Si vous trouvez que le code n'est pas optimal, vous avez une excellente opportunité d'enseigner un nouveau design pattern, un nouvel outil, une nouvelle façon de faire à votre collègue.

Les qualités requises

Le test par un pair demande aux membres de l'équipe 2 qualités importantes. D'abord, il faut être en mesure d'accepter de voir son travail scruté et potentiellement critiqué par nos collègues. Parfois, ça fait un peu mal à l'égo, mais c'est une occasion de s'améliorer comme développeur. D'un autre côté, cela demande nécessairement de la diplomatie et du tact lorsque l'on critique le code d'un compère. Les deux parties doivent en tout temps garder en tête que c'est un exercise qui se veut constructif.

Un risque potentiel

Que se passe-t-il si le code révisé ne respecte clairement pas les exigences de qualité ? Si fonctionnellement ça répond au besoin mais que le code est mal écrit ? Après tout, si l'élément du carnet est à toute fin pratique terminé et que vous renvoyez votre collègue à la table à dessin. cela ne mettra-t-il pas le sprint en danger ?

Dans notre équipe, nous avons trouvé une façon d'éviter ce problème. Nous le traitons en amont. Lorsqu'un élément du carnet comporte un tant soit peu de difficulté technique ou d'inconnu, nous ajoutons une tâche qui s'appelle "Atelier de conception". Elle doit être faite avant d'entreprendre les autres tâches de cet élément du carnet. Avant de commencer le développement, 2 ou 3 membres de l'équipe sont sollicités afin de discuter de ce qui doit être fait et de s'entendre sur l'architecture ou l'orientation à prendre pour répondre aux critères d'acceptation. Ainsi, lors de la revue par un pair, la personne faisant le révision ne devrait pas avoir de surprise quant  à la solution technique choisie. En effet, il a soit pris part aux discussions initiales ou bien il sait que plusieurs personnes ont réfléchi à l'approche utilisée. Si jamais la solution venait à changer en cours de route, il suffit d'expliquer ce qui nous a fait prendre une autre approche. Cela n'élimine pas complètement la possibilité de s'égarer en chemin mais le risque est grandement diminué.

Voilà donc notre façon de renforcer la qualité du code que nous écrivons tout en transmettant les connaissances d'un coéquipier à l'autre. C'est tout simple, mais très efficace !

Archive