Les DoD et DoR supports essentiels à la qualité en Agile

Le cycle en V n’est jamais loin!

On ne va pas se le cacher, même si les développements logiciels sont de plus en plus fait avec des méthodes Agiles, l’influence des méthodes dites « traditionnelles » comme le cycle en V reste particulièrement prégnante.

Cette influence s’explique d’ailleurs assez simplement par le fait que ces méthodes ont été pendant des décennies et jusqu’à très récemment ultra majoritaires. Nous somme donc « formaté » au cycle en V comme on peut le constater avec le syllabus ISTQB fondation 2018 encore très axé sur ce cycle de développement. Le passage à l’Agile demande un changement d’état d’esprit et une transformation globale de l’ensemble des acteurs du logiciel ce qui ne se fait pas sans heurts. On voit alors apparaître de nombreuses « dérives » des méthodes agiles que j’attribue à cet état d’esprit Cycle en V. Je pense notamment à:

• rognier sur la qualité pour livrer plus vite: ce qui est une très mauvaise solution en Agile car les développements itératifs et modifications fréquentes font que l’on se doit de construire sur des bases solides… les bases étant le produit lui même!
• faire les tests en dehors du sprint (si Scrum) ou considérer qu’une US est finie avant les tests des testeurs: pour moi on n’est carrément plus sur de l’Agile à ce niveau
• Vouloir planifier et connaître le contenu des livraisons des mois voir 1 ou 2 ans à l’avance: on perd ici tout l’intérêt de l’Agile qui est l’adaptabilité au contexte et au changement
• Décaler la fin d’un sprint pour livrer l’ensemble de ce sprint: on est alors sur des minis cycles en V et non de l’Agile
• Vouloir absolument avoir une correspondance entre effort et jours homme: cela témoigne d’une forte incompréhension de l’Agile et élude le fait qu’une même tâche prend plus ou moins de temps en fonctions des personnes dans l’équipe!
• Charger le sprint car il faut livrer toute les fonctionnalités prévues: dans ce cas l’équipe n’est plus responsabilisée et forcée d’inclure des éléments qu’elle sait ne pas pouvoir faire dans de bonnes conditions ce qui crée énormément de dettes
• Des modifications de périmètres en cours de développements: avec une demande de modification de fonctionnalités (US) sur lesquelles on a commencé à travailler…

Il y a évidemment d’autres dérives mais le but n’est pas d’être exhaustif. Vous noterez cependant que pour l’ensemble des dérives ci-dessus on a bien un état d’esprit très lié au cycle en V avec une planification importante, une variable d’ajustement sur la qualité ou alors un silotage test/dev.

Afin de limiter en partie ces dérives il y a un outil qui me semble toujours plus important: la Definition of Ready (DoR) et la Definition of Done (DoD). Ce ne sont évidemment pas la solution à tout mais réussir à les sanctuariser permet d’éviter pas mal d’écueils.

DoR et DoD en bref

Pour faire simple la DoR et la DoD sont des « checklists ». Elles contiennent un ensemble de critères à remplir pour pouvoir considérer que l’on peut passer à la suite. Cet ensemble de critères doit être vérifié avant toute validation. Ce dernier point est important car je remarque régulièrement des DoR et DoD « fantômes » qui existent mais sont ignorées.

La DoR définit les critères nécessaires pour que l’on puisse commencer à travailler sur une US. Voici un exemple de DoR possible:

La DoD définit quant à elle, et comme son nom l’indique, les critères nécessaires pour que l’on puisse dire que le travail sur l’US est « fini » c’est à dire que l’on n’a plus à travailler dessus. Voici un exemple de DoD possible:

Ces outils, très stricts, sont un rempart contre certaines dérives énoncées en début d’article. Et cela s’explique finalement assez simplement.

DoR et DoD pour assurer la qualité

La DoR permet de s’assurer la stabilité des US sur lesquelles on va travailler. Une condition comme « les scénarios d’acceptation validés par le métier » permet de limiter considérablement les risques de modifications des demandes pendant les développements. De même cette DoR permet de s’assurer une synchronisation entre les parties prenantes et donc de livrer une meilleure qualité en livrant ce qui est souhaité.

La DoD a un impact encore plus important que la DoR. Certains la considère même comme la stratégie de test en Agile! Dans les faits on peut s’apercevoir que si la DoD de l’exemple est appliquée scrupuleusement alors:

• Il ne peut pas y avoir de renoncement sur la qualité car les US ne seront pas considérées comme finies
• Cela ne sert à rien de charger le sprint car au final les US en trop ne seront pas livrées
• Les tests sont effectués pendant le sprint
• Mieux évaluer la quantité de travail à faire

Conclusion

La DoR et la DoD sont souvent mis en place mais ont rarement la place qu’elles devraient avoir. Une utilisation poussée de ces éléments peut cependant aider à livrer une meilleure qualité tout en assurant que cette dernière soit durable.

Ces DoD et DoR se doivent cependant d’être vivante et d’évoluer… Mais cela doit se peut se faire en cours de sprint.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.