Créer une Definition of Done Efficace

Quand "fait" signifie des choses différentes pour différentes personnes, vous obtenez du travail incomplet, des parties prenantes surprises, et de la dette technique. Une Definition of Done (DoD) claire crée une compréhension partagée de ce à quoi ressemble la complétude, assurant une qualité cohérente et une livraison prévisible.

Pourquoi la DoD Compte

Composants de la DoD

Catégories à Couvrir

CATÉGORIES DEFINITION OF DONE
═════════════════════════════

QUALITÉ CODE :
├── Le code compile sans erreurs
├── Pas d'avertissements linting
├── Suit les standards de codage
├── Pas de code smells évidents
└── Code auto-documenté

TESTS :
├── Tests unitaires écrits et passent
├── Tests d'intégration passent
├── Pas de baisse de couverture
├── Cas limites testés
└── Tests manuels complets

REVUE DE CODE :
├── PR créée avec description
├── Revue demandée
├── Feedback traité
├── Au moins 1 approbation
└── Pas de commentaires non résolus

DOCUMENTATION :
├── Commentaires code où nécessaire
├── README mis à jour si nécessaire
├── Docs API mises à jour
├── Docs utilisateur mises à jour (si UI)
└── Entrée changelog ajoutée

DÉPLOIEMENT :
├── Mergé dans branche main
├── Déployé en staging
├── Smoke test passé
├── Pas d'erreurs en monitoring
└── Prêt pour production

Exemples de Définitions

DoD Basique (Petite Équipe)

DEFINITION OF DONE (Basique)
════════════════════════════

Avant de marquer une tâche "Fait" :

CODE :
- [ ] Le code compile sans erreurs
- [ ] Pas d'erreurs linting
- [ ] Suit le guide de style équipe

TESTS :
- [ ] Tests écrits pour nouveau code
- [ ] Tous les tests passent
- [ ] Tests manuels complets

REVUE :
- [ ] PR approuvée par 1 reviewer
- [ ] Feedback traité

DÉPLOIEMENT :
- [ ] Mergé dans main
- [ ] Déployé en staging
- [ ] Vérifié fonctionnel

DoD Complète (Enterprise)

DEFINITION OF DONE (Enterprise)
════════════════════════════════

DÉVELOPPEMENT COMPLET :
- [ ] Feature complète selon critères d'acceptation
- [ ] Code compile dans pipeline CI
- [ ] Pas d'avertissements analyse statique
- [ ] Dette technique documentée (si présente)
- [ ] Feature flag configuré (si applicable)

TESTS COMPLETS :
- [ ] Tests unitaires : >80% couverture nouveau code
- [ ] Tests intégration écrits et passent
- [ ] Tests E2E pour flux utilisateur (si UI)
- [ ] Performance testée (si applicable)
- [ ] Scan sécurité passé
- [ ] Accessibilité testée (WCAG 2.1 AA)

REVUE COMPLÈTE :
- [ ] Description PR complète
- [ ] 2+ revues code approuvées
- [ ] Tous commentaires revue résolus
- [ ] Approbation architecture (si changement majeur)
- [ ] Revue sécurité (si gestion données)

DOCUMENTATION COMPLÈTE :
- [ ] Documentation code inline
- [ ] Documentation API (si changement API)
- [ ] Documentation utilisateur (si changement UI)
- [ ] Runbook mis à jour (si impact ops)
- [ ] ADR créé (si décision architecture)

DÉPLOIEMENT COMPLET :
- [ ] Mergé dans branche main
- [ ] Pipeline CI/CD vert
- [ ] Déployé en staging
- [ ] QA sign-off sur staging
- [ ] Alertes monitoring configurées
- [ ] Prêt pour déploiement production

HANDOFF COMPLET :
- [ ] Product owner a vérifié
- [ ] Demo enregistrée (si feature majeure)
- [ ] Équipe support informée (si face-client)
- [ ] Notes de release rédigées

DoD par Type de Tâche

DoD PAR TYPE DE TÂCHE
═════════════════════

CORRECTION BUG :
├── Cause racine identifiée
├── Fix implémenté
├── Test de régression ajouté
├── Pas de problèmes liés
└── Déployé et vérifié

FEATURE :
├── Tous critères d'acceptation remplis
├── Tests complets
├── Documentation mise à jour
├── Revu et approuvé
└── Sign-off produit

DETTE TECHNIQUE :
├── Problème adressé
├── Pas de changement fonctionnel
├── Tests toujours passent
├── Performance maintenue
└── Apprentissages documentés

DOCUMENTATION :
├── Contenu précis
├── Orthographe vérifiée
├── Liens vérifiés
├── Revu par expert
└── Publié

SPIKE/RECHERCHE :
├── Question répondue
├── Conclusions documentées
├── Recommandation faite
├── Équipe informée
└── Tâches de suivi créées

Implémenter la DoD

Créer Votre DoD

PROCESSUS CRÉATION DoD
══════════════════════

ÉTAPE 1 : Atelier Équipe (60 min)
─────────────────────────────────────
- Quels problèmes le travail incomplet a-t-il causé ?
- Qu'est-ce qu'on oublie toujours ?
- À quoi devrait ressembler "fait" ?

ÉTAPE 2 : Brouillon Catégories
─────────────────────────────────────
Grouper les suggestions en :
├── Code
├── Tests
├── Revue
├── Documentation
├── Déploiement

ÉTAPE 3 : Prioriser
─────────────────────────────────────
- Doit avoir (non-négociable)
- Devrait avoir (standard)
- Bien d'avoir (aspirationnel)

ÉTAPE 4 : Commencer Petit
─────────────────────────────────────
Commencer avec 5-8 éléments. Étendre au fur
et à mesure que l'équipe mûrit et les capacités croissent.

ÉTAPE 5 : Rendre Visible
─────────────────────────────────────
- Poster dans wiki projet
- Lier depuis GitScrum
- Référencer en standup
- Revoir en rétros

DoD dans GitScrum

APPLIQUER LA DoD DANS GITSCRUM
══════════════════════════════

TEMPLATE TÂCHE :
─────────────────────────────────────
Inclure checklist DoD dans description tâche

## Definition of Done
- [ ] Code revu et approuvé
- [ ] Tests écrits et passent
- [ ] Documentation mise à jour
- [ ] Déployé en staging
- [ ] Vérifié fonctionnel

AUTOMATISATION :
─────────────────────────────────────
Règle : Empêcher déplacement vers "Fait" si
checklist DoD pas complète

VISIBILITÉ :
─────────────────────────────────────
Afficher % complétion DoD sur carte tâche

Gérer les Violations DoD

QUAND LA DoD N'EST PAS RESPECTÉE
════════════════════════════════

NE PAS :
✗ Laisser passer "juste cette fois"
✗ Blâmer la personne
✗ Ajouter lourdeur bureaucratique

FAIRE :
✓ Discuter en rétro
✓ Comprendre pourquoi c'est arrivé
✓ Ajuster processus ou DoD
✓ Fournir support pour la respecter

EXCEPTIONS VALIDES :
├── Fix urgence production (documenter dette tech)
├── Travail expérimental/prototype
├── Skip explicitement convenu (documenté)

MÊME ALORS :
Créer tâche de suivi pour compléter
les éléments DoD sautés

Évolution de la DoD

Faire Mûrir Votre DoD

NIVEAUX MATURITÉ DoD
════════════════════

NIVEAU 1 : BASIQUE
├── Code compile
├── Tests passent
├── Code revu
└── Mergé

NIVEAU 2 : STANDARD
├── Tout du Niveau 1
├── Exigences couverture
├── Documentation
├── Déploiement staging
└── Vérification

NIVEAU 3 : MATURE
├── Tout du Niveau 2
├── Scan sécurité
├── Tests performance
├── Accessibilité
├── Monitoring configuré
└── Prêt production

NIVEAU 4 : EXCELLENT
├── Tout du Niveau 3
├── Feature flags
├── A/B testing prêt
├── Plan rollback
├── Support formé
└── Analytics configuré

Progresser à travers les niveaux au fur
et à mesure que capacités équipe et outils s'améliorent.

Meilleures Pratiques

Pour la Definition of Done

1. Commencer petit — 5-8 éléments, pas 20
2. Rendre visible — Tout le monde la voit constamment
3. L'appliquer — La DoD est non-négociable
4. Revoir régulièrement — Trimestriellement minimum
5. Appropriation équipe — Tout le monde est d'accord

Anti-Patterns

ERREURS DEFINITION OF DONE :
✗ DoD existe mais personne ne suit
✗ Trop d'éléments (irréaliste)
✗ Pas revue ou mise à jour
✗ Équipes différentes, DoDs différentes (pas de standard)
✗ DoD violée "à cause deadline"
✗ DoD c'est juste les tests (ignore autres aspects)
✗ Personne ne sait où DoD est documentée

Solutions Connexes

• Créer des critères d'acceptation clairs
• Configurer les quality gates pour les releases
• Améliorer la qualité des revues de code