Comment livrer de la qualité ?

Architecture en équipe

Notre équipe avait grandi rapidement. Nous devions apprendre la logique d’affaire du client et respecter des contraintes de temps. Dans ces circonstances, il fut facile d’accumuler une dette technologique. Avec le temps, on sentait que cela devenait un obstacle et que nous devions s'attaquer à ce problème avant qu’il ne devienne plus sérieux. Nous devions trouver un moyen pour coordonner plusieurs équipes pour les faire avancer dans une direction commune. C’est ainsi que débutèrent nos architecture grooming.

Cet atelier de travail se passe quelques jours avant le début d’un nouveau sprint. L’équipe de développeur se rassemble et regarde le contenu du prochain sprint en équipe. Chacune des stories sera lue et expliquée à l’équipe pour s’assurer qu’elle comprenne bien son objectif. Ensuite, l’équipe s’interroge sur les besoins architecturaux. Quels seront les défis techniques ? Quelle partie pourra être faite en une composante réutilisable ? Avons-nous le temps de retravailler le code pour effacer une dette technologique, et quelle solution pouvons-nous implémenter dans le temps disponible ? Une fois ces questions répondues, le travail à faire sera clair pour chaque membre de l’équipe. Les solutions techniques trouvées proviendront du savoir commun de l’équipe, ce qui donnera des solutions solides.

Pour que le travail soit bien coordonné entre les équipes, notre Architecture Owner participera à l’atelier de travail de chacune des équipes. Son rôle est de conseiller les équipes et de s’assurer que la vision architecturale du projet est respectée. Mais cela reste le rôle de l’équipe de trouver les solutions. L’Architecture Owner devra aussi faire le pont entre les équipes. Il devra communiquer et expliquer au besoin les solutions que les autres équipes mettront en place durant le prochain sprint.

Finalement, à la suite de la revue du sprint avec le Product Owner, nous faisons une revue architecturale. Le travail technique sera présenté à l’Architecture Owner et aux autres équipes. Nous présentons les composantes réutilisables qui ont été créées, les patterns qui ont été introduits et tous les autres renseignements techniques pertinents à transmettre.

Avec ces nouvelles ceremonies, l’équipe est plus consciente du travail architectural et des défis techniques du système; autant ceux qui ont été réalisés que ceux qui sont à venir.

Assurance qualité par les pairs

Il n’est jamais agréable qu’une story complétée soit rouverte par l’équipe d’assurance qualité, et nous trouvions problématique quand cela arrivait trop souvent. De plus la story rouverte pouvait dater d’un sprint précédent parce que l’équipe d’assurance qualité était débordée de travail jusque là. Notre solution à cette situation fut d’introduire l’assurance qualité par les pairs.

Quand un développeur a terminé sa story, que la revue de code a été acceptée et qu’il a fait les tests nécessaires, mais avant qu’il ne pousse ses changements dans le code source, il devra les donner à un autre développeur. Ce second développeur devra compiler les changements sur son poste. Cela évite que la compilation du code source ne soit brisée par les changements, que ce soit par un fichier qui ait été oublié d’être ajouté au code de développement, ou bien qu’une configuration du poste de développement ne soit pas conforme à celle de la machine de compilation. Une fois que la compilation a réussi, le second développeur teste la story pour s’assurer qu’il n’y a ni défectuosité ni oubli au niveau de la logique d’affaires. Quand le second développeur est satisfait, alors seulement la branche de développement pourra être versée au code source.

Avec cette étape supplémentaire, beaucoup des problèmes qui auraient été rendus visibles par la machine de compilation automatisée ou par l’équipe d’assurance qualité sont trouvés par le second développeur. Ces problèmes sont trouvés et réglés plus rapidement et la confiance de l’équipe face à une story terminée est accrue.

Séance d’assurance qualité en équipe

Il est difficile d’être satisfait, en tant qu’équipe, du travail livré lorsque la revue du sprint semble se transformer en séance de débogage. Mais une story livrée lors de la première semaine d’un sprint peut parfois être impactée par des modifications faites vers la fin de celui-ci. C’est pourquoi nous avons introduit les séances d’assurance qualité en équipe. 

Nous avions débuté ces séances de travail à la veille d’une livraison, pour tester de façon intensive tout ce qui avait été fait comme travail. À chaque fois qu’on faisait une telle séance durant un sprint, le nombre de défectuosités ou de règles d’affaires non respectées était en hausse par rapport aux autres sprints. En introduisant cette séance à la fin de chaque sprint, à deux jours de la revue, nous pouvons bien voir le travail accompli et les problèmes qui auraient pu nous échapper durant le sprint. Le jour suivant, nous prenons le temps de faire les correctifs que l’on peut faire. Si un problème majeur a été trouvé dans une story et que l’équipe considère inacceptable de la livrer telle quelle, la story peut être sortie du code source et les correctifs devront être apportés en début du prochain sprint. Cela peut retarder sa livraison, mais nous nous assurons que la qualité y soit.

Cela permet à l’équipe de ne pas avoir de mauvaise surprise durant la revue et aussi de hausser la confiance face au travail qui a été exécuté. Une séance en équipe permet aussi une meilleure communication et compréhension de ce que les autres développeurs ont exécuté comme travail dans le sprint.

Un processus lourd ?

Nous considérons que chacune de nos équipes est composée de personnes raisonnables et qui ont assez de jugement pour savoir quand il est possible de sauter une étape. Notre méthodologie est un guide et non une structure rigide. Corriger une faute de syntaxe ne demande pas le même effort que de réécrire la logique du coeur du système. Nos équipes sont dévouées dans leur travail et elles ne veulent pas remettre à nos clients un livrable de mauvaise qualité. Donc nous conservons une flexibilité au niveau du processus. Un membre de l’équipe peut en tout temps ne pas faire une étape s’il juge qu’il est raisonnable de l'omettre. Ceci évite de ralentir le développement inutilement.

Malgré cela, depuis la mise en place de ces étapes dans notre méthodologie de travail, nous nous sommes interrogés sur le temps que cela implique. Est-ce un processus trop lourd et trop coûteux ?

Ce que nous avons constaté est que la vélocité de chacune des équipes s’en trouve affectée et que le travail prend un peu plus de temps. Par contre, la qualité s’en trouve grandement améliorée. La période de stabilisation qui se passe avant une livraison a été de beaucoup raccourcie et les équipes ont un plus grand niveau de confiance face aux livrables.

Après la livraison, le client trouve moins de défectuosités, et la gravité et l’impact de ces problèmes sont moindres, évitant de devoir faire des livraisons rapides pour des correctifs d’urgence.

Il est plus facile de prédire l’effort nécessaire à faire pendant le développement de la livraison. Nous réduisons la quantité de travail à faire pour la livraison et l'après-livraison. Une plus grande qualité de code rend le travail plus facile, facilitant le travail des équipes et l’évaluation des nouvelles fonctionnalités.

Au final, l’équipe et le client sont confiants face au livrable qui est remis. Aussi les évaluations sont plus près de la réalité et il y aura moins d’effort de maintenance après une livraison.