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.

Souligner les succès…

Publié par Vincent Crépin le lundi 3 février 2014 à 20:11

J’ai récemment été appelé à effectuer une intervention à La Capitale et c’était la première fois que l’occasion se présentait à moi. J’avais eu de bons mots de plusieurs personnes ayant effectué des interventions auparavant mais rien de précis. Bien évidemment j’ai été impressionné par leur nouvel édifice vert qui vaut le détour à lui seul. Mais ce n’est pas le sujet de mon article…

Lors de rencontres avec les architectes d’affaires et organiques, j’ai pu prendre connaissance du niveau d’implantation des techniques agiles dans le département du développement et je dois dire que j’ai été impressionné. Je n’avais jamais vraiment entendu parler de cet aspect de La Capitale mais parmi les endroits que j’ai visités, ils sont au sommet de la liste selon ce que j’ai vu.

Salle de développement à La CapitaleJe parle surtout ici des pratiques de développement (TDD, refactoring, intégration continue). Ils utilisent TDD pour tous leurs développement qui utilisent la plateforme Ruby on Rails. Ils possèdent actuellement une base de tests qui se comptent en plusieurs milliers et dont la couverture frôle le 100%. Ils ont une salle de développement dans laquelle la première chose que l’on remarque, c’est la présence intimidante d’un écran géant qui donne en temps réel l’état des builds (il y avait une tuile rouge quand je suis passé ;-)). Voici d’ailleurs une photo de cela.

On sent dans cette salle la très grande complicité entre les développeurs et tous ces facteurs se matérialisent par des mises en production exemptes de défauts.

Il va sans dire que cet accomplissement est un travail acharné d’équipe, comme on le devine tous. Je félicite ces personnes qui se sont battues pour leurs idées et qui ont accompli quelque chose de bien et qui peut servir de modèle pour notre communauté.

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

À qui appartient la définition de Terminé

Publié par Louis-Philippe Carignan le mardi 9 avril 2013 à 12:10

Vous êtes dans une situation où vous démarrez une équipe Scrum. Lors de ce démarrage, l’une des étapes est de mettre en place la définition de Terminé pour que tous soit d’accord sur ce que représente une fonctionnalité terminée. Une fois en place, qui doit maintenir et respecter cette définition? À qui appartient-elle? Est-ce la responsabilité de l’équipe de la mettre à jour et de la respecter? Ou est-ce au propriétaire de produit de s’assurer qu’elle est respectée?

En regardant dans le guide Scrum écrit par les créateurs de Scrum, on ne retrouve pas d’informations pertinentes pour répondre à cette question. Bien que la définition soit bien expliquée pour démontrer son utilité, les auteurs ne précisent pas à qui appartient la définition.

Dans le livre « Choisir l’Agilité », les auteurs Mathieu Boisvert et Sylvie Trudel expliquent à la page 14 qu’ « Elle assure une qualité uniforme de la part de tous les membres de l’équipe de projet, car ils sont engagés à respecter cette définition ». Il est clair que pour eux, l’équipe doit respecter cette définition. Mais leur appartient-elle?

Pour trouver une réponse à cette question, voyons voir le contenu de la définition de Terminé.

Premièrement, nous avons des tâches techniques qui doivent être faites pour assurer la maintenance du produit sur le long terme. Des tâches comme le réusinage (refactoring), les plans de tests et les documents expliquant les choix de design sont quelques-uns des éléments que l’on retrouve dans la définition de Terminé pour l’équipe de réalisation. Par exemple, un projet est lancé dans une entreprise où l’on utilise une plate-forme logicielle qui est à la base de plusieurs logiciels. Puisque cette plate-forme doit vivre plus longtemps que le projet lancé, plusieurs tâches techniques devront être ajoutées à la définition de Terminé pour assurer la viabilité de la plate-forme même si le produit est périmé.

Deuxièmement, nous retrouvons aussi des tâches dans la définition de Terminé pour la mise en production d’une nouvelle version. Le guide utilisateur et les notes de livraison, bien que faîtes par l’équipe, ont plus d’intérêt pour les gens qui utiliseront ou supporteront le logiciel que ceux qui le développent.

Et finalement, on retrouvera les tâches qui se terminent par « ility » (Ex : Scalability, Security, Usability) dans la définition de Terminé. Le propriétaire de produit peut spécifier le niveau de qualité qu’il désire mais doit négocier avec son équipe lorsque ses demandes sont accompagnées de coûts trop élevés. Par exemple, l’équipe doit suivre des normes d’interface visuelle pour respecter l’image de marque de la compagnie. À certains moments, elle peut déroger si l’effort est trop coûteux. Dans le cas d’un stimulateur cardiaque, la définition de Terminé peut exiger une stabilité hors-pair à cause de la nature de l’appareil où l’équipe doit faire le nécessaire pour l’atteindre.

Nous avons donc 3 types de tâches dans la définition de Terminé :

  • Pérennité du logiciel
  • Support pour la mise en production
  • Requis par le monde Affaires

Bien que je sois d’accord que l’équipe doit respecter la définition de Terminé, certains éléments de la définition ne leur appartiennent pas. Par exemple, les requis du monde Affaires leur sont dictés. L’équipe peut suggérer ou améliorer mais à prime à bord, ce sont des contraintes provenant du monde Affaires qui viendront ajouter des tâches à la définition de Terminé.

À mon avis, la définition de Terminé est une entente entre le propriétaire de produit et l’équipe de réalisation. Le propriétaire de produit et l’équipe ont chacun le droit d’ajouter certains éléments à la définition de Terminé. Le propriétaire de produit identifie les éléments pour le monde Affaires tandis que l’équipe identifie les éléments techniques. Cependant, l’équipe est responsable de réaliser toutes les tâches pour la respecter.

  • Plus récents
  • 1
  • Plus anciens

Archive