Definition of Done (DOD)

definition of done
definition of done
En scrum, il est important que l’ensemble de l’équipe s’aligne sur ce qui est considéré comme « fini ». Pour cela, l’équipe va définir son Definition of Done. Nous l’appelons également Dod qui est tout simplement l’acronyme ! La definition of done est une pratique imposée par le scrum par l’intermédiaire de son guide scrum. Nous allons profiter de l’article pour bien comprendre ce concept et assimiler l’importance de ne pas le sous-estimer. Vous pouvez regarder la vidéo de la minute agile sur le sujet : Definition of done (dod)

La Definition of Done (Dod)

L’équipe de développement va définir ensemble l’ensemble des critères qui permettront d’affirmer qu’un item (user story par exemple) peut être considéré comme « done ». Ces critères auront pour objectif de s’imposer une qualité technique sur tous les éléments livrés. Souvent bien mal compris, en scrum, l’équipe de développement est 100% responsable des réalisations et ceci jusqu’à la mise en production des éléments. Le product owner n’est pas un validateur du travail de cette équipe. Ainsi, l’équipe de développement doit s’imposer des critères qui définiront le minimum requis pour s’autoriser de livrer les éléments en production. Et cette équipe le fait en toute autonomie.
definition of done
definition of done
Si le product owner peut être consulté, il n’a aucune responsabilité autour du definition of done. Il ne peut pas essayer d’imposer ses idées à l’équipe de développement. Il est essentiel que l’organisation comprenne que l’équipe de développement est 100% autonome sur la réalisation et ceci dans son intégralité. Sur les board visuels, cela est souvent représenté par le passage du post’it dans la colonne « done ».
Definition of Ready
Definition of Ready
Dans certaines équipes de développement, nous voyons d’ailleurs un des membres ayant des compétences de tests (ou d’homologation) qui aura la tâche de valider que l’item répond à 100% à cette Definition of Done. Cependant, rappelons que l’ensemble de l’équipe de développement restera responsable de la mise en « done » de chacun des éléments. Avoir un membre de l’équipe avec une expertise dédiée au testing, n’en enlève en aucun cas la responsabilité à l’ensemble de l’équipe de développement. Petite phrase intéressante du scrum guide pour montrer l’importance de cette pratique :
L’objectif de chaque Sprint est de fournir des Incréments de fonctionnalités potentiellement publiables qui adhèrent à la définition de « Fini » actuelle de l’équipe Scrum.

La mise en production incluse ?

L’équipe a la responsabilité de la réalisations des items jusqu’à la livraison de ceux-ci. Cependant cette livraison doit au minimum se faire sur un environnement stable ; celui-ci est souvent appelé vulgairement environnement de recette. La definition of done ne peut inclure la mise en production si le product owner valide la stratégie de livraison ou déploiement continu. Cela n’interdit pas d’inclure des concepts d’activations/désactivations de fonctionnalités en production. Si le product owner définie une stratégie de livraison par lot, alors la definition of done ne pourra pas inclure la mise en production !

La definition of done commune à toutes les tâches ?

L’équipe de développement ne va pas écrire une Dod pour chacun des items. Cela serait en effet trop chronophage. Cependant certains items peuvent se voir ajoutés des critères complémentaires de qualité. En effet, si chaque item impose de respecter à 100% l’ensemble des critères définis par la Dod, rien n’interdit l’équipe de développement d’ajouter parfois des critères complémentaires à certains items.

Le product owner participe à la Definition of Done (dod) ?

Par défaut, le product owner ne participe pas à la création de la Dod. L’équipe de développement est 100% autonome sur les items livrés (en environnement stable). Cependant, il peut être observateur de l’atelier de sa création ce qui permet d’avoir une équipe plus soudée. Mais si l’équipe en toute autonomie désire que le product owner soit un participant actif de sa création, rien ne l’interdit. Cependant en cas de désaccord, le dernier mot reviendra à l’équipe de développement.

La Definition of Done de plusieurs équipes

Si plusieurs équipes travaillent sur un produit commun (ou offre commune), il est fortement recommandé que celle-ci soit la même pour l’ensemble des équipes. D’ailleurs, le scrum guide impose d’avoir une même dod pour l’ensemble des équipes scrum travaillant autour d’un même produit. Ne pas le faire amènera des complexités supplémentaires inutiles voire parfois sera source de conflit entre les équipes.

Comment la mettre en place

L’équipe de développement va ensemble lors d’un atelier, définir la Definition of Done (Dod) sous plusieurs formes :
  • action à mener
  • critères de qualité
  • conformité attendue (de façon concrète)
Par exemple l’équipe pourrait définir un Dod de ce type : Definition of done - exemple Je vous recommande fortement d’afficher votre Definition of Done dans votre management visuel ou de la mettre de façon visible sur le logiciel  utilisé (en cas d’équipes dispersées).

La Dod doit évoluer

Au démarrage d’un produit, il n’est pas évident d’être stricte sur la Definition of Done. Il faudra alors alimenter la liste des critères au fur et à mesure de l’avancement afin d’amener le « done » a être un critère de qualité de plus en plus stricte. Cependant, au démarrage d’un produit, il ne faudra pas que la dod soit irréaliste au risque pour l’équipe de ne plus pouvoir livrer de la valeur aux clients/utilisateurs.

Conclusion definition of done (dod)

Le concept de la Dod est relativement simple à comprendre. Il sera par contre plus difficile de la mettre en application surtout au démarrage de produits. Les équipes de développement doivent accepter de ne pas être trop exigeantes au démarrage du produit ; en effet, cela permettra à l’équipe de développement d’avoir une phase d’apprentissage. Elle améliorera celle-ci tout au long de l’avancement du produit. Cependant, il ne faut pas oublier que la Dod est une pratique de l’équipe de développement ; elle seule est responsable de sa définition même si elle peut autoriser au product owner d’y participer.
[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 645 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]