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.

À 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 !

Comment identifier un Scrum Master potentiel

Publié par Louis-Philippe Carignan le lundi 3 décembre 2012 à 00:00

Lors d’un démarrage Agile où vous avez choisit Scrum comme approche, il est important de ne pas négliger le choix de votre Scrum Master.  Cette personne se verra confier des responsabilités importantes. Il faut donc identifier la personne apte à tenir ce rôle qui n’existe pas dans un projet informatique traditionnel.

À mon avis, la personne tenant le rôle du Scrum Master doit être une bonne communicatrice. Par communicatrice, je ne veux pas dire qu’elle est extravertie. Elle doit être en mesure de bien faire passer ses messages aux membres de l’équipe ainsi qu’aux parties prenantes qui gravitent autour de son équipe. Par ses messages clairs, elle établira une confiance initiale envers les parties prenantes tout en s’assurant que l’équipe de réalisation livrera les résultats à la fin de l’itération.

La créativité est aussi un point important chez la personne qui sera désignée Scrum Master. Puisque la personne sera appelée à animer des rencontres, son sens de la créativité lui sera utile pour dynamiser ces évènements. À cause de la nature itérative de Scrum, les cérémonies se répètent souvent et pour les dynamiser, un certain sens de la créativité peut aider l'équipe à sortir de la routine. Dans l'intérêt de renouveler ses techniques de facilitateur, on peut inviter le Scrum Master à suivre des formations d’animations. Par exemple, la conférence « Agile Games » est un bon endroit pour un Scrum Master qui désire s’outiller en termes de jeux.

Et pour organiser ces cérémonies, il faut que votre Scrum Master ait un sens de l'organisation. Il doit être en mesure de voir à l'avance les rencontres à planifier. Il doit se préparer pour chaque rencontre, préparer l'agenda, établir l'objectif ainsi que l'extrant obtenu à la fin de chaque rencontre. Il faut donc faire attention de ne pas retenir une personne qui est souvent désordonnée dans son travail.

Puisque le Scrum Master est un rôle de gestion sans pouvoir décisionnel, la personne doit comprendre ce qu’est le pouvoir d’influence et en faire bon usage. Le Scrum Master n’est pas imputable du résultat. Cette imputabilité revient au propriétaire de produit (Product Owner). Le Scrum Master doit donc guider l’équipe à répondre aux besoins du client sans imposer sa vision du travail à faire. Elle doit donc influencer l’équipe dans leurs décisions tout en se rappelant qu’elle est au service de l’équipe. 

Par mon expérience, je trouve que le Scrum Master est un « process manager ». C’est une personne qui doit comprendre le processus Scrum ainsi que son implication au sein de l’organisation. Par exemple, une personne qui voit et comprend tout le processus dans l’équipe, de la collecte des besoins jusqu’à sa livraison, sera avantagée si elle tient le rôle de Scrum Master puisqu’elle voit l’équipe dans son entier. Cela lui donnera la chance d’être un pas en avant de son équipe lorsque celle-ci semble vouloir apporter un changement à leurs façons de faire. En étant un pas en avant d’eux, cela lui permet de mieux guider son équipe sur les impacts que leur idée peut avoir sur le reste de l’organisation.

La personne identifiée doit aussi vivre les valeurs Scrum dont elle fera la promotion. Les trois valeurs de Scrum étant la transparence, l’inspection et l’adaptation, le Scrum Master doit démontrer qu’il vit ces valeurs. Elle doit se montrer transparente dans sa démarche puisqu’elle rappellera souvent à son équipe l’importance de la transparence. Elle doit aussi se montrer ouverte à se faire critiquer sur son approche pour montrer qu’elle n’a pas peur de s’améliorer elle-aussi. Il faut donc choisir une personne qui est en mesure de vivre ces valeurs. Il faut identifier une personne qui est capable de mettre « ses tripes sur la table » pour montrer l’exemple au lieu de dicter ce que l’équipe doit faire.

Je vous suggère aussi une personne qui est capable de s’oublier. Dans la littérature Scrum, on lit souvent le terme « servant-leadership ». Cette personne doit être en mesure de favoriser des interactions et la communication entre les membres de l'équipe. Par exemple, lorsque le Scrum Master anime des rencontres, il ne doit pas devenir le centre d'attention mais bien un catalyste entre les individus autour de la table. Il doit s'assurer que les intravertis ont autant leur mot à dire que les extravertis de l'équipe. On parlera aussi d’une personne qui est capable de générer des idées. Même si ses idées ont du sens, le Scrum Master doit favoriser l’apparition d’idées dans l’équipe. À l’aide de sa créativité mentionnée précédemment ainsi que la transparence, cette personne trouvera des moyens originaux d’exposer la situation actuelle à son équipe pour que celle-ci voit ce qui ne va pas. 

Au final, le choix de la personne qui tiendra le rôle du Scrum Master est important puisqu’elle est à la base de l'approche Scrum. Je crois que la citation de Lao Tzu, père du taoïsme, résume l’idée de l’apport d’un Scrum Master dans une équipe :

« A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say : we did it ourselves. »

 

« Juste assez » et la planification de sprint

Publié par Philippe Tremblay le vendredi 11 mai 2012 à 09:15

En tant qu’équipier ou Scrum Master, il est parfois difficile de définir le moment où les discussions d’une session de planification de sprint dépassent l’objectif du « juste assez ». Que ce soit les discussions relatives aux items du carnet de produit ou l’élaboration du plan de travail du sprint, la ligne est parfois mince entre ce qui est nécessaire à l’équipe pour acquérir une compréhension commune des éléments et ce qui constitue les détails de réalisation (le « comment »).

Bien que cette difficulté puisse se présenter dans toutes les équipes, elle l’est encore plus lorsque l’équipe est nouvellement formée ou qu’un nouveau membre y fait son entrée. Pour faciliter l’identification du moment où le « juste assez » se présente, l’équipe peut tenter de répondre aux questions suivantes.

« Est-il probable que notre discussion…

  • … change de façon significative l’estimation de l’item du carnet de produit?
  • … ait un impact sur la prévisibilité de l’état d’avancement de notre sprint?

Si la réponse à ces questions est « non », vous pouvez passer à autre chose! Vous avez probablement atteint l’objectif pour cet item du carnet de produit.

  • Plus récents
  • 1
  • Plus anciens

Archive