Définir une Definition of Done qui améliore vraiment la qualité
Définir une Definition of Done qui améliore vraiment la qualité
Je me souviens d'une équipe dans une grande organisation de retraite complémentaire. Ils avaient une DoD, une vraie, écrite, affichée dans la salle. Je leur ai demandé comment elle était utilisée. Le Scrum Master a répondu avec un sourire gêné : "En théorie, elle est vérifiée avant chaque merge. En pratique, en fin de sprint, on coche tout et on merge pour tenir le sprint." J'ai vérifié les métriques : 38% des bugs de prod de l'année précédente étaient apparus dans des stories "Done" selon la DoD de l'équipe. Ce n'était pas un problème de personnes. C'était un problème de contrat.
La DoD la plus fréquente que je rencontre dans les équipes : "Le code est mergé et testé." C'est une description, pas une Definition of Done. Et cette ambiguïté est directement responsable de 30 à 40% des bugs qui atteignent la production.
La Definition of Done est le contrat de qualité de l'équipe. Quand elle est vague, chaque développeur l'interprète différemment. Quand elle est absente, la qualité dépend de la conscience professionnelle individuelle, ce qui est insuffisant pour garantir la cohérence.
Avant de commencer : les prérequis
- L'équipe a déjà une DoD existante (même minimale ou informelle) à partir de laquelle progresser
- Le Product Owner et le Tech Lead sont impliqués dans la redéfinition
- L'équipe a accès aux métriques de base : taux de bugs de prod, lead time, incidents récents
Étape 1 : Auditer la DoD actuelle (ou son absence)
Durée estimée : 2 heures en atelier équipe Qui : Toute l'équipe de développement + PO + Scrum Master
Avant de construire une nouvelle DoD, comprendre pourquoi l'actuelle ne fonctionne pas.
Questions à poser en atelier :
- "Quand considérez-vous qu'une story est vraiment terminée ?" Recueillir les réponses individuelles avant la discussion.
- "Citez un bug récent de prod : quelle étape de la DoD aurait dû le détecter ?"
- "Y a-t-il des items de notre DoD actuelle que personne ne vérifie vraiment ?"
Le dernier exercice est le plus révélateur. Dans 80% des équipes que j'accompagne, il existe des items "fantômes" dans la DoD : des critères formellement présents mais systématiquement contournés, généralement par manque de temps en fin de sprint.
Résultat attendu : une liste de ce qui fonctionne, ce qui est contourné, et ce qui manque.
Étape 2 : Les 7 critères non-négociables d'une DoD solide
Durée estimée : 1 heure de discussion Qui : Tech Lead + PO
Ces 7 critères sont le minimum pour une DoD qui protège réellement la qualité. Adaptez le wording à votre contexte, mais ne supprimez pas les catégories.
1. Code reviewé par au moins un pair Pas "par le Tech Lead si disponible". Par n'importe quel pair, avec un retour documenté dans la PR. Spécifier le délai maximum : aucune PR ne reste sans review plus de 24 heures ouvrées.
2. Tests automatisés écrits ou mis à jour Spécifier le type : tests unitaires pour la logique, tests d'intégration pour les interactions avec les dépendances. Spécifier le seuil : la couverture du module ne descend pas en dessous du seuil de l'équipe.
3. Build CI vert sur la branche Évident mais souvent contourné "pour gagner du temps". Un build rouge = story non terminée, sans exception.
4. Critères d'acceptation vérifiés et documentés Chaque critère d'acceptation de la story doit avoir été testé manuellement ou automatiquement. Le résultat est documenté dans le ticket.
5. Pas de régression identifiée sur les scénarios existants Une suite de tests de régression tourne sur chaque PR. Si elle n'existe pas, c'est un déficit à combler progressivement, mais c'est un objectif de la DoD.
6. Documentation mise à jour si applicable Pas de documentation pour chaque story. Mais si la story modifie une API publique, un flux d'intégration, ou une règle métier documentée, la documentation est mise à jour dans la même PR.
7. Déployable en environnement de staging sans intervention manuelle La story doit pouvoir être déployée en staging en appuyant sur un bouton. Si un déploiement nécessite des étapes manuelles, c'est une dette technique à documenter et traiter.
Résultat attendu : une DoD de 7 items précis et actionnables.
Votre équipe merge du code que tout le monde sait incomplet faute d'une DoD claire ?
Vous voyez les patterns se répéter : les bugs arrivent en prod sur des stories "Done", les revues de code sont expéditives en fin de sprint, et personne n'ose vraiment bloquer un merge. Ce n'est pas de la mauvaise volonté, c'est l'absence d'un contrat clair. En 30 minutes, on identifie la vraie cause et on définit une DoD réaliste et tenue.
Étape 3 : L'intégrer dans le workflow sans friction
Une DoD que personne ne consulte n'existe pas. Elle doit être au bon endroit, au bon moment.
Dans Jira/Linear : ajouter la DoD comme checklist dans le template de story. Chaque item est coché (et non supprimé) avant de passer au statut "Done". L'outil garde une trace.
Dans GitHub/GitLab : créer un template de PR avec les items de la DoD comme checklist. Le développeur les coche au moment de la PR, pas après coup.
Dans le sprint review : le PO valide que les items de la DoD ont été respectés avant d'accepter la story. C'est le moment de fermeture du cycle qualité.
L'erreur à éviter : transformer la DoD en checklist bureaucratique que tout le monde coche sans vérifier. Pour éviter ça, j'inclus des items vérifiables de façon objective (build vert, coverage seuil) plutôt que subjectifs ("le code est de qualité").
Résultat attendu : la DoD est intégrée dans les templates Jira et GitHub. Elle est visible au bon moment dans le workflow.
Étape 4 : La faire évoluer chaque trimestre
Une DoD figée devient rapidement soit trop laxiste (l'équipe a progressé et la DoD ne reflète plus ses standards actuels) soit trop contraignante (les outils ont changé et certains items ne s'appliquent plus).
Rituel recommandé : une session de 1 heure par trimestre, en même temps que le trimestrial planning, pour réviser la DoD :
- Quels items sont systématiquement respectés ? (→ potentiellement automatisables dans la CI)
- Quels items sont régulièrement contournés ? (→ soit les supprimer, soit identifier pourquoi et lever le blocage)
- Quels items manquent compte tenu des problèmes rencontrés ce trimestre ?
L'objectif à 12-18 mois : une DoD qui contient des items d'un niveau 3 de maturité engineering : les standards de qualité sont ancrés dans les pratiques de l'équipe, pas seulement dans un document.
Résultat attendu : une DoD vivante, révisée trimestriellement, qui progresse avec le niveau de maturité de l'équipe.
Le piège à éviter
Ne jamais créer deux niveaux de DoD "selon le temps disponible". J'ai vu des équipes définir une "DoD normale" et une "DoD express" pour les sprints surchargés. Résultat : la DoD express devient la norme, et la DoD normale n'est jamais appliquée. Une seule DoD : si elle n'est pas atteignable, réduire le scope du sprint, pas les standards. C'est la discipline fondamentale d'un système agile sain.
En résumé
| Étape | Action | Résultat |
|---|---|---|
| 1 | Auditer la DoD actuelle en atelier | Identifier les items fantômes et les manques |
| 2 | Définir les 7 critères non-négociables | DoD précise et actionnable |
| 3 | Intégrer dans Jira et GitHub | DoD consultée au bon moment dans le workflow |
| 4 | Réviser chaque trimestre | DoD qui progresse avec la maturité de l'équipe |
FAQ sur la Definition of Done
1. Quelle est la différence entre la DoD et les critères d'acceptation ?
Les critères d'acceptation sont spécifiques à une story : ils décrivent ce que cette story particulière doit faire. La DoD est transversale à toutes les stories : elle décrit les standards de qualité qui s'appliquent à toute livraison, quelles que soient les fonctionnalités. Une story peut respecter tous ses critères d'acceptation et ne pas respecter la DoD (ex : pas de tests écrits, code non reviewé).
2. La DoD doit-elle être la même pour tous les types de stories ?
Généralement oui, avec des nuances légères. Certains items peuvent être contextuels (la documentation n'est pas mise à jour pour une story de refactoring interne). Mais les items fondamentaux (code reviewé, build vert, tests écrits) s'appliquent à toutes les stories sans exception. Trop d'exceptions crée de l'ambiguïté et ouvre la porte aux contournements.
3. Comment gérer la résistance de l'équipe à une DoD plus stricte ?
La résistance vient généralement de la peur que la DoD crée un blocage en fin de sprint. La réponse est de traiter la cause : si la DoD ne peut pas être respectée dans un sprint, le problème est en amont (stories trop grandes, Definition of Ready absente, capacité surestimée) pas dans la DoD elle-même. Impliquer l'équipe dans la rédaction de la DoD réduit significativement la résistance à son application.
4. Faut-il une DoD différente par équipe dans une organisation avec plusieurs équipes ?
Une base commune + des extensions par équipe est la meilleure approche. La base commune garantit un niveau minimum de qualité cohérent à travers l'organisation, particulièrement important pour les composants partagés. Les extensions permettent aux équipes d'adapter aux spécificités de leur contexte (ex : une équipe data peut avoir des items spécifiques sur la validation des schémas).
5. Comment mesurer si la DoD améliore réellement la qualité ?
Trois métriques à suivre avant/après l'amélioration de la DoD : le taux de bugs de prod sur les stories "Done" (doit baisser), le nombre de réouvertures de tickets (doit baisser), et le temps passé en correction de bugs vs développement de features (doit s'améliorer). Sur les équipes que j'accompagne, une DoD bien appliquée réduit le taux de bugs de prod de 25 à 40% en 3 mois.
Ressource gratuite : Engineering Maturity Self-Assessment
L'assessment évalue vos pratiques de qualité, incluant la Definition of Done, les pratiques de tests et de revue de code. Identifiez votre niveau actuel et les 3 actions prioritaires pour progresser.
