Definition of Done (Définition de « Terminé »)

Format de collaboration Définition de « Terminé »

Critères de qualité

Quels standards de qualité le travail doit-il atteindre pour être terminé ?

Ce sujet capture les références techniques et de qualité que chaque travail doit satisfaire avant d'être considéré comme achevé. Encouragez l'équipe à réfléchir à la qualité du code, à la couverture des tests, à la performance et aux standards. Posez des questions exploratoires comme « Qu'est-ce qui nous donnerait confiance que cela ne cassera pas en production ? » pour faire émerger les attentes implicites et les transformer en critères explicites et mesurables.

Documentation et communication

Que faut-il documenter ou partager avant d'être terminé ?

Utilisez ce sujet pour faire émerger les attentes en matière de partage de connaissances et de documentation qui maintiennent l'équipe alignée et réduisent la confusion future. Invitez les participants à réfléchir à qui doit être informé du changement et à quels artefacts devraient exister. C'est souvent la partie la plus négligée de « terminé », alors encouragez une réflexion honnête sur les manques passés.

Tests et validation

Comment vérifions-nous que le travail fonctionne vraiment ?

Ce sujet se concentre sur les étapes de vérification qui prouvent que le travail répond aux exigences et se comporte comme prévu. Guidez l'équipe à réfléchir au-delà des tests automatisés pour inclure les tests manuels, exploratoires et d'acceptation. Encouragez-les à définir qui valide le travail et dans quel environnement.

Déploiement et préparation

Que doit-il être vrai pour publier le travail en toute sécurité ?

Ici, l'équipe définit ce que signifie pour un travail d'être prêt à être publié et mis en ligne devant les utilisateurs. Suscitez la discussion autour du déploiement, de la surveillance, des plans de retour arrière et de la préparation opérationnelle. Cela aide les équipes à éviter l'écart courant entre « code terminé » et « apporter réellement de la valeur ».

Quand recourir à cette analyse rétrospective

• Lorsqu'une nouvelle équipe se forme et doit établir des standards de qualité partagés dès le départ.
• Lorsque le travail est fréquemment rouvert ou que des bugs se glissent en production, signalant des critères d'achèvement flous.
• Avant de démarrer un nouveau projet ou sprint pour s'assurer que tout le monde s'accorde sur ce à quoi ressemble « terminé ».
• Lors de l'intégration de nouveaux membres qui doivent comprendre les attentes de qualité de l'équipe.
• Pendant une rétrospective lorsque l'équipe identifie une incohérence dans la façon dont le travail est considéré comme terminé.

Exemples de questions pour brise-glace

• Si « terminé » avait une personnalité, comment serait-il — perfectionniste, pragmatique ou héros de dernière minute ?
• Quelle est la chose la plus surprenante que vous ayez découvert un jour comme N'ÉTANT PAS réellement terminée ?

Idées et conseils pour votre réunion de rétrospective

• Co-créez la Définition de « Terminé » avec toute l'équipe afin que chacun se sente impliqué — évitez de laisser une seule personne dicter les standards.
• Gardez des critères réalistes et atteignables ; une DoD trop ambitieuse qui n'est jamais respectée en perd son utilité.
• Rendez chaque critère spécifique et vérifiable afin qu'il n'y ait aucune ambiguïté sur le fait qu'il a été satisfait.
• Traitez la Définition de « Terminé » comme un document vivant et révisez-la périodiquement à mesure que les standards et les outils de votre équipe évoluent.
• Encouragez les membres plus discrets à contribuer en laissant à chacun le temps d'ajouter ses idées de manière indépendante avant la discussion de groupe.
• Distinguez la Définition de « Terminé » des critères d'acceptation — la DoD s'applique à tout travail, tandis que les critères d'acceptation sont spécifiques à une story.

Foire aux questions