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 2 fois aujourd'hui ]
A propos Judicaël Paquet 647 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]

2 Commentaires

  1. Bonjour
    1.Ce que je ne comprends pas c’est a quel moment est validé la recette , avant le sprint review ou apres ?
    2. dans le cas ou la recette n’est pas concluante ou probleme d’environnement , que va t-on faire au sprint review dont la date est deja fixée ? il faudra corriger les anomalie et reteste pour livrer mais la date du sprint review est passé donc pas de deploiement du sprint en temps et en heure . C’est reparti pour un nouveau sprint avec les corrections à apporter ?
    merci

    • Bonjour dan,

      1/ En scrum, on privilégie de tester user story par user story pour éviter les phases de recette. Chaque user story a le droit à sa recette pour faire simple. Cela se fait directement à la fin du développement de la user story. Le fait de faire une « phase » recette sur un ensemble de user story vous amène à faire un mini cycle en V et vous perdez en efficacité.

      2/ En scrum, tu peux livrer à n’importe quel moment. Ce n’est pas lié à la sprint review. On présente en sprint review toutes les user stories « done » donc toutes celles qui sont intégralement terminées (tests inclus). Toute user story non validée par l’équipe scrum est alors potentiellement reportée au sprint suivant. Mais il ne faut pas attendre d’avoir un lot de user story pour lancer une phase de « recette » sinon ça rendra votre organisation plus complexe et moins efficace.

      Tu vois ce que je veux dire ?

11 Rétroliens / Pings

  1. Un format de user-story très efficace : le story A4 | Blog Myagile Partner
  2. Top 10 des articles de mars 2017 | Blog Myagile Partner
  3. Et si on faisait de la BDD (Behavior Driven Development) | Blog Myagile Partner
  4. Est-ce que le “Done” contient la mise en production ? | Blog Myagile Partner
  5. La Job Story à la place de la user story ? - Blog Myagile Partner
  6. Definition of Done (DOD) | Blog Myagile Partner
  7. Dod kards : co-construction de la Definition of Done - Blog Myagile Partner
  8. Faire son tableau kanban - Blog Myagile Partner
  9. La Definition of Ready (dor) - Blog Myagile Partner
  10. Scrum : le framework agile - My Agile Partner Scrum
  11. La vélocité à 0... Vraiment impossible ? - My Agile Partner Scrum

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.