Qu'est-ce que la Definition of Done ?
Vous est-il déjà arrivé de livrer quelque chose pour découvrir ensuite que ce n'était pas vraiment fini ? La Definition of Done (DoD), ou « définition de terminé », est la liste de critères partagée par votre équipe, que chaque élément de travail doit remplir avant que quiconque le déclare terminé. Elle s'applique à chaque user story, fonctionnalité et incrément, pour que « terminé » ait le même sens, quelle que soit la personne qui a réalisé le travail. En Scrum, la Definition of Done fixe le niveau de qualité exigé pour chaque incrément. La mettre par écrit met fin aux débats du type « est-ce que c'est fini ? » au moment de la revue et empêche le travail caché, comme des tests ou une documentation manquants, de glisser vers le sprint suivant. Cette session réunit développeurs, testeurs, designers et product owners pour construire la liste ensemble, afin qu'elle couvre les étapes que chacun sait souvent oubliées. Le tableau comporte quatre colonnes : Critères de qualité, Documentation et communication, Tests et validation, et Déploiement et mise en production. Chacun ajoute des critères, puis l'équipe les regroupe et vote pour se mettre d'accord sur la liste. Considérez le résultat comme un document vivant et revenez-y à mesure que vos outils et vos standards évoluent. Pour aller plus loin, consultez le guide de Scrum.org sur la Definition of Done.
Format collaboratif Definition of Done
Critères de qualité
Quels standards de qualité le travail doit-il respecter ?
Listez les vérifications techniques et de qualité que chaque élément de travail doit passer : revue de code, couverture de tests, performance, standards de code. Demandez « Qu'est-ce qui nous rendrait confiants que ça ne cassera pas en production ? » pour faire émerger les attentes implicites et les rendre mesurables.
Documentation et communication
Que faut-il documenter ou partager avant de terminer ?
Abordez ce qui doit être mis par écrit, ou communiqué, avant que le travail compte comme terminé. Demandez qui doit être informé d'un changement et ce qui doit exister ensuite. Les équipes négligent souvent cette partie, alors interrogez-les sur les manques passés.
Tests et validation
Comment vérifier que le travail fonctionne vraiment ?
Mettez-vous d'accord sur les vérifications qui prouvent que le travail fait ce qu'il doit faire. Allez au-delà des tests automatisés : tests manuels, exploratoires et d'acceptation. Décidez aussi qui valide et dans quel environnement.
Déploiement et mise en production
Que faut-il réunir pour livrer le travail sans risque ?
Définissez ce qui doit être en place avant la mise en ligne. Parlez du déploiement, du monitoring, des plans de rollback et de qui assure le support une fois en production. C'est ce qui fait la différence entre du code terminé et une fonctionnalité réellement utilisable.
Dans quels cas recourir à cette étude rétrospective ?
- Quand une nouvelle équipe se forme et doit s'accorder sur ses standards de qualité dès le départ.
- Quand des tickets sont sans cesse rouverts ou que des bugs arrivent en production, signe que tout le monde n'a pas la même idée de ce qu'est un travail fini.
- Avant le lancement d'un nouveau projet, pour que l'équipe fixe le niveau d'exigence avant de commencer.
- Lors de l'intégration de nouveaux membres qui doivent découvrir les attentes de qualité de l'équipe.
- Quand une rétrospective révèle que les membres de l'équipe n'ont pas la même vision de ce qui est terminé.
Exemples de questions pour brise-glace
- Si « terminé » avait une personnalité, à quoi ressemblerait-elle : perfectionniste, pragmatique ou héros de dernière minute ?
- Quelle est la chose la plus surprenante que vous ayez découverte comme n'étant pas vraiment terminée ?
Vous souhaitez un exercice d'échauffement que votre équipe puisse pratiquer, et pas seulement répondre à voix haute ? Découvrez des brise-glaces gratuits →
Idées et conseils pour votre réunion de rétrospective
- Construisez la Definition of Done avec toute l'équipe pour que chacun se l'approprie. Ne laissez pas une seule personne la rédiger.
- Gardez des critères réalistes. Une DoD que l'équipe ne respecte jamais finit par être ignorée.
- Rendez chaque critère assez précis pour être vérifié, afin qu'il n'y ait pas de débat sur le fait qu'il soit rempli ou non.
- Revoyez-la tous les quelques sprints, à mesure que vos standards et vos outils évoluent.
- Laissez à chacun le temps d'ajouter ses idées seul avant la discussion de groupe, pour que les plus discrets contribuent aussi.
- Distinguez-la bien des critères d'acceptation. La DoD s'applique à tout le travail, alors que les critères d'acceptation sont propres à une story.
Foire aux questions
Qu'est-ce que la Definition of Done en agile ?
Quelle différence entre la Definition of Done et les critères d'acceptation ?
Qui doit participer à la création de la Definition of Done ?
À quelle fréquence mettre à jour notre Definition of Done ?
Combien de temps faut-il pour créer une Definition of Done ?
Modèles associés
Décidez en équipe ce qui doit être fait et ce qui peut attendre.
Rétrospective Prime Directive de Norm Kerth - Les quatre questions originales
Les quatre questions de Norm Kerth, en partant de la Prime Directive.
Rétrospective Rate of Improvement
Découvrez où les efforts de votre équipe ont vraiment payé.
Rétrospective Quoi ? Et alors ? Et maintenant ?
Passez de ce qui s'est passé à ce que vous allez faire.