Modèles de Définition de Terminé

Qu’est-ce qu’un modèle de Définition du « Done » ?

Un modèle de Définition du « Done » (DoD) est une liste de contrôle exhaustive des critères techniques et fonctionnels qu’une user story ou une tâche doit satisfaire avant d’être considérée « terminée ». Contrairement aux critères d’acceptation (propres à chaque user story), la DoD est une norme globale appliquée à chaque élément de travail. Elle évite la dette technique en garantissant que les tests, la documentation et la conformité ne sont jamais sacrifiés au nom de la rapidité.

L’audit « Qualité » : 3 façons de faire respecter des normes « livrables »

La DoD n’est efficace que si l’équipe fait preuve de discipline. Avant de finaliser votre modèle, appliquez ces trois « contrôles de santé » d’expert :

1. L’audit « Travail non terminé »

L’audit : Déplacez-vous des histoires utilisateur vers "Done" tout en laissant la documentation ou les tests d’intégration pour le "next sprint" ? La solution : Auditez la Qualité différée. Un DoD professionnel doit inclure les tests de régression et la mise à jour de la documentation. S’il n’est pas documenté et testé sur l’ensemble du système, il n’est pas "Done" ; c’est juste "Developed". Votre modèle doit indiquer explicitement "Pas de nouvelle dette technique" comme exigence.

2. Le test "Vérité automatisée"

L’audit : Votre DoD repose-t-il sur des « promesses humaines » (p. ex., « j’ai vérifié le code ») ? La solution : Audit de la Vérification binaire. Autant que possible, remplacez les contrôles manuels par des contrôles automatisés. Au lieu de « Le code a été révisé », utilisez « Pull request approuvée par deux pairs. » Au lieu de « Tests unitaires effectués », utilisez « Couverture des tests unitaires > 80 % ». Cela élimine la subjectivité et garantit que l’état « Done » est mesurable et incontestable.

3. Le conflit « global vs local »

L’audit : Votre DoD est‑il si long que l’équipe en ignore la moitié pour atteindre l’objectif du sprint ? La solution : Auditez la réalité. Commencez par une "DoD viable minimale" et faites‑la évoluer au fur et à mesure que l’équipe mûrit. Si l’équipe ne peut pas réaliser de manière réaliste un audit de sécurité complet à chaque sprint, ne l’incluez pas dans la DoD au niveau des user stories. Déplacez‑le plutôt vers une "Définition de Release". Ainsi, la DoD quotidienne reste réalisable et respectée.

Cadres stratégiques : Les trois niveaux de "Done"

Une organisation professionnelle utilise souvent trois modèles distincts pour gérer les différentes étapes d’achèvement :

• Niveau 1 : le DoD de la user story (niveau de sprint)

  • Focus : Qualité du code, révision par les pairs et respect des critères d’acceptation spécifiques.

  • Exemple : "Tests unitaires réussis", "Approbation du PO", "Tests fonctionnels réussis."

• Niveau 2 : le DoD Sprint/Fonctionnalité (niveau d’intégration)

  • Focus : Comment la fonctionnalité s’intègre au reste de l’application.

  • Exemple : "Aucun bug de régression", "Indicateurs de performance stables", "Environnement de préproduction mis à jour."

• Niveau 3 : le DoD de la version (niveau marché)

  • Focus : Conformité juridique, marketing et sécurité.

  • Exemple : "Test d’intrusion réussi", "Traduction terminée", "Manuel utilisateur mis à jour."

Composants clés d’un modèle de Definition of Done

Un DoD performant exige ces cinq catégories principales :

• Normes de développement : Le code est commenté, refactorisé et intégré dans la branche principale.

• Tests & Qualité : Les tests unitaires, d’intégration et les "smoke tests" manuels sont terminés et réussis.

• Environnement & DevOps : Le code est déployé dans un environnement de préproduction et passe le pipeline de build.

• Révision & Approbation : La révision par les pairs est terminée et le Product Owner (PO) a approuvé la fonctionnalité.

• Exigences non fonctionnelles : La fonctionnalité respecte des critères précis de rapidité, d’accessibilité et de sécurité.