4 min lecture • Guide 874 of 877
Modèle d'Analyse de Rétrospective de Sprint
Les rétrospectives efficaces nécessitent une structure. Sans modèles, les discussions s'égarent, les éléments d'action se perdent et les équipes répètent les mêmes problèmes. Un bon modèle de rétrospective guide la conversation, capture les insights et suit le suivi des actions d'amélioration.
Formats de Modèles Rétrospective
| Format | Meilleur Pour | Structure |
|---|---|---|
| Start/Stop/Continue | Rétros rapides | 3 colonnes, simple |
| 4Ls | Réflexion profonde | 4 catégories, équilibré |
| Mad/Sad/Glad | Check-in émotionnel | Basé sentiments |
| Voilier | Équipes visuelles | Métaphore |
| 5 Pourquoi | Cause racine | Focalisé problèmes |
Modèles Classiques
START / STOP / CONTINUE
═══════════════════════
MODÈLE :
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ │
│ START STOP CONTINUE │
│ (Commencer à faire) (Arrêter de faire) (Continuer) │
│ ────────────────── ───────────────── ─────────── │
│ │
│ □ Pair programming □ Sauter revue □ Standups │
│ sur tâches de code async quotid│
│ complexes │
│ │
│ □ Documenter □ Changements □ Session de │
│ décisions scope tardifs planification│
│ architecture sprint │
│ │
│ □ Temps dédié □ Réunions pendant □ Bloqueurs │
│ dette technique heures focus dans Slack │
│ │
└─────────────────────────────────────────────────────────────┘
RÉTROSPECTIVE 4Ls
═════════════════
MODÈLE :
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ │
│ AIMÉ APPRIS │
│ (Ce qui a bien marché) (Nouveaux insights) │
│ ───────────────────── ────────────────── │
│ □ Collaboration équipe □ GraphQL est plus │
│ sur Feature X rapide que REST ici │
│ □ Revues PR rapides □ Besoin buffer pour │
│ □ Exigences claires tests intégration │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ MANQUÉ DÉSIRÉ │
│ (Ce qui manquait) (Souhaité avoir) │
│ ───────────────────── ────────────────── │
│ □ Couverture tests □ Meilleurs dashboards │
│ module paiements monitoring │
│ □ Ownership clair □ Plus temps pour │
│ code partagé refactoring │
│ □ Specs design tôt □ Environnement staging│
│ │
└─────────────────────────────────────────────────────────────┘
Suivi Éléments d'Action
ÉLÉMENTS D'ACTION DANS GITSCRUM
═══════════════════════════════
CRÉER TÂCHES D'AMÉLIORATION :
─────────────────────────────────────
Depuis rétrospective, créer tâches GitScrum :
┌─────────────────────────────────────────────────────────────┐
│ Tâche : [RETRO] Implémenter pair programming tâches complexes│
├─────────────────────────────────────────────────────────────┤
│ │
│ Type : Amélioration │
│ Sprint : 15 │
│ Assigné : Tech Lead │
│ Labels : rétrospective, processus │
│ │
│ Description : │
│ De rétro Sprint 14 : Démarrer pair programming sur tâches │
│ estimées 5+ points pour réduire bugs et silos connaissance. │
│ │
│ Critères d'Acceptation : │
│ □ Définir planning pairing pour Sprint 15 │
│ □ Suivre quelles tâches ont utilisé pairing │
│ □ Réviser résultats dans rétro Sprint 15 │
│ │
└─────────────────────────────────────────────────────────────┘
Meilleures Pratiques
- Contrôlez le temps strictement - 45-60 minutes maximum
- Alternez les formats - Prévenez fatigue rétrospective
- Utilisez données - Basez discussions sur métriques
- Limitez actions - 2-3 items qui seront vraiment faits
- Assignez responsables - Actions sans owner ne se font pas
- Suivez complétion - Révisez dans prochaine rétro
- Focalisez vers l'avant - Discutez solutions, pas blâme
- Impliquez tous - Brainstorming silencieux aide voix discrètes