Definition of Done : Simple et pourtant complexe

La Definition of Done (DoD) est un outil agile essentiel qui aide les équipes à planifier et à réaliser leur travail. En principe, la Definition of Done n'est qu'un ensemble de critères que le produit doit remplir pour être considéré comme terminé. Mais bien que le concept soit simple, sa mise en œuvre n'est pas si évidente en réalité. Le contexte et les possibilités d'interprétation créent en effet une zone grise.

Contexte et critères d'acceptation

Le premier niveau de complexité réside dans le fait que la Definition of Done doit toujours être considérée dans le contexte de l'environnement, ce qui concerne la complétude technique et fonctionnelle ainsi que l'acceptation par le Product Owner . Le fait que le Product Owner accepte le produit représente la valeur du produit. Les critères d'acceptation – ou quel que soit leur nom – reflètent si le code peut résoudre un problème métier spécifique défini par la User Story ou une exigence. Les critères d'acceptation servent à confirmer que la story fait vraiment ce pour quoi elle a été conçue, et ils peuvent être utilisés pour créer des tests d'acceptation.

D'un point de vue formel, la Definition of Done est souvent un reflet des standards techniques et processuels d'une organisation. Par exemple, les organisations ont souvent des standards pour l'écriture de code et de tests unitaires, et donc la Definition of Done peut contenir des exigences concernant la structure du code, la documentation et les tests. Elle peut également inclure des composants liés à la fonctionnalité. Cependant, la fonctionnalité est fondamentalement couverte par les critères d'acceptation etc. dans la définition. Dans certains cas, j'ai déjà vu des mentions dans la Definition of Done indiquant que les critères d'acceptation doivent être respectés. Une fois le double obstacle de la Definition of Done et des critères d'acceptation franchi, le Product Owner doit donner son évaluation de la valeur livrée par la solution. Ensuite vient l'évaluation finale, où il accepte ou rejette la solution. Le résultat de ce processus est également décrit comme done-done ou même done-done-done.

Obstacles et questions importantes concernant la DoD

Pour mettre en œuvre le concept de « Done » de manière solide, il faut surmonter trois obstacles : les critères de la Definition of Done, les critères d'acceptation (faisant partie d'une User Story) et l'acceptation par le Product Owner. Cela implique également de peser certaines questions qui rendent ce processus, autrement relativement simple, un peu plus complexe. Parmi celles-ci :

1. Qui décide de ce que signifie Done ?
   Dans de nombreuses organisations, les critères Done sont souvent laissés à l'appréciation des équipes individuelles. Cela se fait généralement dans les limites des standards techniques et procéduraux définis par l'organisation. Il y a quelques années, par exemple, une équipe de développement soumise à des standards stricts en matière de codage et de tests unitaires m'a demandé si elle pouvait supprimer les exigences de tests unitaires pour son code. Les tests unitaires étaient un critère dans leur Definition of Done. Leur argument était que les testeurs découvriraient plus tard dans le processus si cela fonctionnait, et que le Product Owner n'aimait pas les tests des développeurs. Cependant, l'équipe devait respecter les standards définis par l'organisation et il n'était pas question de simplement supprimer les exigences relatives aux tests unitaires.

2. Est-il acceptable de ne pas remplir tous les critères ?
   Chaque équipe avec laquelle j'ai travaillé s'est tôt ou tard posé la question de savoir s'il serait acceptable d'interpréter différemment la Definition of Done pour la contourner. Souvent, la réponse est « Oui ». Cela implique toutefois généralement une discussion sur la zone grise, l'acceptation de la dette technique et le moment où cette dette devra être remboursée.

3. Les besoins de l'organisation peuvent-ils primer sur ceux du Product Owner ?
   C'est l'alter ego de la question précédente. Chaque membre de l'équipe, y compris le Product Owner, doit savoir quand et où les standards et/ou besoins de l'organisation priment sur l'acceptation par le Product Owner. La pression de livrer peut inciter les équipes et les Product Owners à faire avancer le code pour le retravailler lors de sprints ultérieurs, poussant ainsi les standards et l'architecture à leurs limites. La plupart des organisations plus matures fixent des limites claires, afin que chacun sache quand les besoins et standards de l'organisation doivent être respectés.

Conclusion sur la Definition of Done (DoD)

Toutes les définitions du mot « Done » contiennent un certain degré de finalité et de complétude. Dans le développement, l'amélioration et la maintenance de logiciels, le concept de Done peut être très complexe. Chacune de ces couches peut avoir ses propres nuances techniques, fonctionnelles et liées à la valeur. Les équipes apprennent rapidement qu'un travail doit vraiment être done, done et done pour être réellement terminé.

Ce texte provient du blog de SPaMCAST et a été traduit par nos soins en français.