Definition of done, comment ?

Le but de cette veille était de voir l’intérêt de cette definition of done (définition de terminé ou fait en français) et comment la mettre en place au sein du service si cela peut être intéressant.

Déjà d’où vient cette définition ? Sur ce point je me suis souvent trompé en pensant qu’elle venait du système Kanban. Et bien non elle provient de Scrum. Mais Kanban n’est pas en reste car il possède une notion similaire qui est la ou les règles de passage d’une colonne à l’autre. Scrum nous indique que la definition of done est la liste des critères que doit remplir un incrément pour être considéré comme terminé. Scrum indique aussi que si un des critères n’est pas rempli l’incrément n’est pas terminé donc pas compté dans la vélocité (nous on ne la calcule pas vraiment donc pas de souci). Cette définition doit être composée de différents types de critères : pérennité du logiciel, support de mise en production (doc si besoin, commit de git, merge si nécessaire, …), requis du monde des affaires (prévenir le PO, les utilisateurs, tracer les changements, …). Ces différents aspects permettent de couvrir les différents points de vues des acteurs de l’incrément.

Quelques erreurs à éviter selon Scrum :

  • Liste de critères trop importante -> contre productif
  • Liste implicite peu d’intérêt plutôt mettre par écrit les choses même triviales car il arrive à tout le monde d’oublier.
  • Éviter les incréments en suspend en se disant je reviendrais dessus plus tard.
  • Il faut que dans tous les cas on puisse checker la totalité des critères.

Pour notre part on ne va pas choisir entre l’un et l’autre nous allons prendre les deux. D’un côté comment déterminer qu’une tâche est terminée et de l’autre comment faire avancer ces tâches dans chacune des colonnes de notre Kanban. Voyons maintenant comment déterminer ces règles qu’il faut écrire, afficher et partager entre tous les membres de l’équipe, l’objectif est d’avoir une façon de travailler proche et de limiter les erreurs sur des choses que l’on ne fait pas régulièrement.

De mon point de vue, il faut partir du contexte dans lequel vous êtes, prendre toutes les bonnes pratiques de chacun en discuter avec tous les membres et se mettre d’accord sur les points qui peuvent poser problème.

Par exemple, je fais une branche, j’écris au moins un test qui échoue, j’écris le code de l’application, je lance tous les tests, ils passent tous puis je merge ma branche, je push mon code, je fais un test en prod et je préviens le PO.

Voilà, il est important de prendre conscience que ces règles ne peuvent être universelles, elles peuvent être proches mais pas universelles, chacun fonctionne à sa manière et le but n’est pas de standardiser cela mais bien d’améliorer cette manière de fonctionner.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.