Modèles de Définition de Terminé

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

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

Audit « qualité » : 3 façons de garantir des livrables prêts à être publiés

La DoD n’est efficace que si l’équipe fait preuve de discipline. Avant de finaliser votre modèle, effectuez ces trois vérifications d’experts :

1. L’audit du « travail non achevé »

L’audit : Déplacez-vous des user stories vers "Done" en laissant la documentation ou les tests d’intégration pour le "sprint suivant" ? La solution : Vérifiez la présence de qualité différée. Un modèle de DoD professionnel doit inclure des tests de régression et la mise à jour de la documentation. Si ce n’est pas documenté et testé à l’échelle du système, ce n’est pas "Done" ; c’est juste "Developed". Votre modèle doit indiquer explicitement "No New Technical Debt" comme exigence.

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

L’audit : Votre DoD repose-t-il sur des "promesses humaines" (p. ex., "J’ai vérifié le code") ? La correction : Auditez la Vérification binaire. Remplacez, autant que possible, les vérifications manuelles par des vérifications automatisées. Au lieu de "Le code est revu", utilisez "Pull request approuvée par deux pairs." Au lieu de "Test unitaire effectué", utilisez "Couverture des tests unitaires > 80 %." Cela supprime la subjectivité et garantit que l’état "Terminé" est mesurable et indiscutable.

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 : Audit de la réalité. Commencez par une "DoD minimum viable" et faites-la évoluer au fur et à mesure que l’équipe mûrit. Si l’équipe ne peut pas raisonnablement effectuer un audit de sécurité complet à chaque sprint, ne l’incluez pas dans le DoD au niveau de la story. Déplacez-le plutôt vers une "Définition de la release". Ainsi, le DoD quotidien reste atteignable et respecté.

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 : DoD de la user story (niveau sprint)

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

  • Exemple : "Tests unitaires réussis," "PO a approuvé," "Tests fonctionnels réussis."

• Niveau 2 : DoD du sprint/de la fonctionnalité (niveau d’intégration)

  • Objectif : Comment la fonctionnalité interagit avec le reste de l’application.

  • Exemple : "Pas de régressions," "Indicateurs de performance stables," "Environnement de préproduction mis à jour."

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

  • Objectif : Conformité juridique, marketing et en matière de sécurité.

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

Principaux éléments d’un modèle de DoD

Une DoD performante repose sur cinq catégories essentielles :

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

• Tests et qualité : Les tests unitaires, d’intégration et les tests manuels de type « smoke » sont complets et réussis.

• Environnement et DevOps : Le code est déployé sur un environnement de préproduction et réussit le pipeline de build.

• Revue et approbation : La revue 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 performance, d’accessibilité et de sécurité.