Le flux de valeur

La Definition of Done et la qualité

« C'est fini » est l'une des phrases les plus ambiguës du travail en équipe. La Definition of Done fixe à l'avance ce que ce mot veut dire pour tous. A Scrum Book l'entoure de quatre autres patterns : tenir le produit en ordre chaque jour, corriger les défauts dès qu'ils apparaissent, produire à chaque Sprint un incrément utilisable et, dans certains cas, le livrer sans attendre la fin du Sprint.

« C'est fini, il reste juste… »

Une équipe développe le logiciel de facturation d'un réseau de cabinets comptables. Pendant la Sprint Review, un développeur montre la nouvelle fonction d'export des factures.

« Les cabinets pourront s'en servir lundi ? » demande la Product Owner.

« La fonction est finie, répond le développeur. Il reste les tests sur les gros fichiers et la mise en production. »

« Et la page d'aide ? »

« Elle n'est pas écrite, mais ce n'était pas dans ma tâche. »

« Alors c'est fini quand ? »

Le pattern Definition of Done s'ouvre sur une scène très proche. Le même mot y prend trois sens : le code est écrit, le travail est vérifié, le client peut s'en servir. Tant que ces sens coexistent, la Product Owner ne peut rien promettre à personne.

Definition of Done : un seul sens pour le mot « fini »

Le pattern Definition of Done (définition de « fini », que le livre surnomme aussi Done-Done) formule ainsi le problème : chaque membre de l'équipe peut avoir sa propre idée de ce qu'est un travail terminé. Le Product Owner a pourtant besoin de connaître l'état réel du produit pour décider de la suite. Pour un développeur, « terminé » suppose une documentation, une relecture et aucun défaut connu, alors que pour son voisin il suffit que rien ne casse lors d'un essai rapide. La qualité varie donc d'un élément à l'autre. Quand elle est inférieure aux attentes, il faudrait du temps pour stabiliser le produit, mais le Sprint est fini, et les retards créent des tensions dans l'équipe.

Une dernière force est moins visible. Il est facile de passer sous silence une convention non respectée ou une vérification sautée. L'équipe contracte alors une dette technique : elle doit au produit un travail qu'il faudra fournir plus tard. Cette dette ne figure dans aucun backlog et ne se voit pas à la Sprint Review, qui ne montre que l'extérieur du produit.

La solution est que tout le travail de la Scrum Team respecte une liste de critères convenue entre les développeurs et le Product Owner. Un élément est Done quand les développeurs ont vérifié qu'il ne reste aucun travail connu au regard de ces critères. Dans le cas contraire, il n'est pas Done et ne peut pas être livré. Le livre y ajoute plusieurs précisions.

• La définition idéale couvre tout ce qu'il faut pour mettre le produit entre les mains du client. Une équipe part de ce qu'elle sait réellement tenir aujourd'hui et renforce sa définition avec le temps, par exemple lors de la Sprint Retrospective.
• Chaque critère est objectif et vérifiable. L'enfant qui répond « oui » à la question « as-tu rangé ta chambre ? » répond « non » quand on lui demande si les jouets sont rangés et le lit fait. Un critère décrit donc un état constaté et non une activité, ce qui permet de présenter la définition comme une liste de contrôle.
• La définition accueille les petites tâches répétitives qui encombreraient le Product Backlog, comme mettre à jour un document technique ou nettoyer le poste de travail.
• Un critère qui n'apporte de valeur à aucune partie prenante est un gaspillage.
• Plusieurs équipes qui travaillent au même produit partagent la même définition. Le livre admet en revanche qu'une même équipe tienne des définitions distinctes par type de travail (documentation, calculs, code) quand une liste unique les couvre mal.

Les auteurs en attendent des prévisions plus fiables, puisque ce qui est déclaré fini ne revient pas, et la disparition des « Sprints de stabilisation » consacrés à rattraper la qualité.

Good Housekeeping : ne pas laisser le désordre pour demain

Le pattern Good Housekeeping (la bonne tenue de la maison, aussi appelé Daily Clean Code) énonce son problème simplement : là où règne le désordre, on perd du temps et de l'énergie à trouver par où commencer. Celui qui doit nettoyer avant de travailler, ou refaire une tâche parce qu'il ignorait l'état du travail, gaspille son temps. Remettre le rangement à la fin du Sprint ne résout rien, car cette fin est toujours occupée par du travail jugé plus urgent.

La solution est de maintenir en permanence le produit et l'environnement de travail dans un état propre, ou de les y remettre à la fin de chaque journée. Le produit doit se trouver chaque soir dans un état conforme aux critères de la Definition of Done, même s'il ne constitue pas encore un incrément, de sorte que n'importe quel membre de l'équipe puisse reprendre le travail le lendemain sans risque. Dans une équipe logicielle, cela signifie par exemple que le code du soir s'assemble et passe ses tests.

Les auteurs mettent en garde contre l'excès inverse : un bureau vide cache l'état du travail autant qu'un bureau encombré. Ils rattachent le pattern aux 5S du système de production Toyota et à la consigne des scouts de laisser le campement plus propre qu'on ne l'a trouvé. Si le rangement quotidien paraît trop coûteux, ils y voient le signe d'un outil trop lent ou d'un défaut de conception, à traiter comme un obstacle.

Whack the Mole : corriger tout de suite

Le nom du pattern Whack the Mole vient du jeu de foire où l'on frappe d'un maillet les taupes qui sortent de leurs trous. Il traite de la tension entre faire avancer les fonctions du produit et élever sa qualité. Sous la pression commerciale, les défauts passent pour des distractions, et l'on reporte leur correction. Les auteurs opposent plusieurs arguments à ce report. Selon Steve McConnell (1996), les défauts ralentissent tout le développement en obligeant à des contournements. Un défaut coûte moins cher à corriger quand son contexte est encore frais. Une liste de défauts tenue à part est un stock qui empêche d'ordonner l'ensemble du travail, et un « Sprint de nettoyage » laisse le produit défectueux jusqu'à sa date.

Le livre rapporte l'histoire d'un client qui découvrit 2 000 défauts de première gravité dans son outil de suivi et lança un Sprint pour en réduire le nombre de 60 %. Les équipes atteignirent l'objectif en reclassant environ 60 % de ces défauts dans la catégorie inférieure.

La solution est de résoudre les problèmes du produit dès qu'ils apparaissent, petits ou grands, sans créer d'élément dans le Product Backlog. Réparer un produit qui fonctionne mal passe avant l'enrichir. Un ou deux développeurs s'en chargent pendant que les autres continuent, et ils rendent ce travail visible sur le tableau et au Daily Scrum. Ils y consacrent une durée maximale convenue d'avance, le livre donnant quatre heures à titre d'exemple. Passé ce délai, le Product Owner décide de poursuivre, au risque de ne pas finir un élément prévu, ou d'inscrire le problème au Product Backlog. La correction respecte elle-même la Definition of Done. Quant au processus qui a laissé passer le défaut, il se corrige en général plus tard, à la Sprint Retrospective.

Regular Product Increment : quelque chose d'utilisable à chaque Sprint

Le pattern Regular Product Increment (incrément de produit régulier) répond à une difficulté du Product Owner : comment s'assurer, Sprint après Sprint, que le produit gagne réellement en valeur ? Les indicateurs abstraits, comme la « valeur acquise » de la gestion de projet, mesurent un avancement détaché du produit lui-même. Des spécialistes issus de services différents peuvent avoir chacun terminé leur partie sans que l'ensemble fonctionne, alors que la valeur vient de l'assemblage.

La solution est que la Scrum Team s'efforce de livrer à chaque Sprint un incrément Done, utilisable et susceptible d'être mis en service. Cet incrément sert à vérifier si la valeur du produit a augmenté et à observer comment il se comporte auprès de ses utilisateurs. Rendre compte devient alors plus simple, puisqu'un élément est Done ou ne l'est pas.

Responsive Deployment : livrer sans attendre la fin du Sprint

Le pattern Responsive Deployment (déploiement réactif) examine une limite du rythme des Sprints. Un élément terminé le troisième jour attend la fin du Sprint dans ce que les auteurs appellent un stock. Il faudra un Sprint de plus pour savoir comment il est reçu et un troisième pour réagir. La correction d'un défaut attend de la même façon, pendant que les utilisateurs continuent d'en souffrir. En sens inverse, regrouper les livraisons réduit leur coût administratif.

La solution est de mettre en service certains éléments dès qu'ils sont Done et que le Product Owner les approuve, au cours même du Sprint, à condition que le coût de ces livraisons dispersées ne dépasse pas leur bénéfice. Une courte revue accompagne chaque livraison partielle, et les questions de fond restent pour la Sprint Review.

Les auteurs sont réservés sur leur propre pattern. Ils le destinent aux équipes mûres et disciplinées, surtout pour les corrections de défauts, les urgences et le service d'un client unique et proche, car rien n'agace davantage des utilisateurs que de voir leur outil changer sans cesse.

Ce que dit le Guide Scrum 2020

• Le Guide fait de la Definition of Done l'engagement attaché à l'Increment : une description formelle de l'état de l'Increment lorsqu'il satisfait aux mesures de qualité exigées pour le produit.
• Si une définition existe parmi les standards de l'organisation, toutes les Scrum Teams la suivent au minimum. Sinon, la Scrum Team crée la sienne. L'édition 2017 confiait cette tâche à l'équipe de développement, et le livre la décrit comme un accord entre les développeurs et le Product Owner.
• Un élément qui ne respecte pas la définition ne peut être ni mis en service ni même présenté à la Sprint Review. Il retourne dans le Product Backlog. Le Guide 2020 ne parle pas d'une « acceptation » des éléments par le Product Owner, alors que le livre lui fait approuver chaque élément.
• Le livre parle d'incrément « potentiellement livrable », comme le Guide 2017. Le Guide 2020 dit seulement que l'Increment doit être utilisable. Il précise que plusieurs Increments peuvent être créés pendant un Sprint, qu'un Increment peut être livré avant la fin du Sprint et que la Sprint Review ne doit jamais être considérée comme une porte à franchir pour livrer. Ce que le livre réserve aux équipes expérimentées est donc explicitement permis par le Guide.
• Le Guide rend les développeurs responsables d'insuffler la qualité en respectant la Definition of Done. Dans le livre, le Scrum Master veille à ce respect en rendant visible tout travail inachevé sur le point d'être livré.

Limites et pièges

Une Definition of Done peut échouer de deux façons. Trop faible, elle déclare fini un travail que personne ne peut utiliser. Trop ambitieuse pour les moyens de l'équipe, elle n'est jamais respectée, et l'on prend l'habitude de la contourner.

On confond souvent la Definition of Done avec les critères de vérification propres à un élément. La première vaut pour tout le travail de l'équipe. Les seconds décrivent ce qu'un élément particulier doit faire et relèvent de la spécification, traitée dans l'article sur l'affinage du backlog. Un élément doit satisfaire les deux.

La correction immédiate a ses propres risques. Elle peut absorber tout le Sprint : les auteurs y voient alors le symptôme d'un problème de qualité grave, qui justifie la procédure d'urgence. Elle ne réduit pas la dette technique déjà accumulée.

Plus largement, l'idée qu'une définition stricte fait disparaître les Sprints de stabilisation et contient la dette technique repose sur l'expérience des auteurs. Elle est plausible et cohérente, mais le livre n'apporte pas d'étude comparative à son appui. L'article critique du corpus fait le point sur ce que la recherche permet d'affirmer.