6 min lecture • Guide 227 of 877
Mesurer la Performance d'Équipe Efficacement
Mesurer la performance d'équipe est essentiel mais dangereux. Les mauvaises métriques créent des incitations perverses, du gaming et des dysfonctions. Les bonnes métriques éclairent la réalité, génèrent de l'amélioration et respectent la complexité. Focalisez sur les résultats plutôt que les outputs, les tendances plutôt que les instantanés, et les métriques d'équipe plutôt qu'individuelles.
Philosophie des Métriques
| Bonnes Métriques | Mauvaises Métriques |
|---|---|
| Niveau équipe | Individuelles |
| Résultats | Outputs |
| Tendances dans le temps | Point unique |
| Mènent à l'amélioration | Mènent au gaming |
| Multiples ensemble | Une seule isolée |
Métriques Dangereuses
Ce Qu'il NE Faut PAS Mesurer
MÉTRIQUES QUI CAUSENT DU TORT
═════════════════════════════
LIGNES DE CODE:
─────────────────────────────────────
Problème: Plus de code ≠ mieux
Gaming: Code verbeux, pas de refactoring
Résultat: Codebase gonflée, inmaintenable
COMMITS PAR JOUR:
─────────────────────────────────────
Problème: Quantité ≠ qualité
Gaming: Petits commits, diviser le travail
Résultat: Historique bruyant, pas d'amélioration
HEURES TRAVAILLÉES:
─────────────────────────────────────
Problème: Présence ≠ productivité
Gaming: Rester tard à ne rien faire
Résultat: Burnout, ressentiment
BUGS TROUVÉS (pour testeurs):
─────────────────────────────────────
Problème: Incite à trouver des bugs pas à prévenir
Gaming: Reporter des issues mineures, diviser bugs
Résultat: Focus sur bugs, pas sur qualité
VÉLOCITÉ INDIVIDUELLE:
─────────────────────────────────────
Problème: Décourage l'aide aux autres
Gaming: Gonfler les estimations
Résultat: Dysfonction d'équipe
COMPARER LES VÉLOCITÉS D'ÉQUIPES:
─────────────────────────────────────
Problème: Équipes estiment différemment
Gaming: Course à l'inflation des points
Résultat: Vélocité perd tout sens
Loi de Goodhart en Action
EXEMPLES LOI DE GOODHART
════════════════════════
"Quand une mesure devient un objectif,
elle cesse d'être une bonne mesure."
EXEMPLE 1: Cible de Couverture Code
─────────────────────────────────────
Cible: 80% code coverage
Gaming:
├── Tests qui n'assertent rien
├── Tester des getters/setters triviaux
├── Ignorer le code complexe non testable
└── Couverture haute, confiance basse
Mieux:
├── Suivre coverage mais pas cibler
├── Focus sur qualité des tests
├── Revoir tests en code review
└── Mutation testing
EXEMPLE 2: Cible de Fermeture de Tickets
─────────────────────────────────────
Cible: Fermer 20 tickets/sprint
Gaming:
├── Diviser tickets artificiellement
├── Fermer sans fix correct
├── Éviter tickets difficiles
└── Quantité monte, valeur baisse
Mieux:
├── Suivre temps de cycle (moins gameable)
├── Focus sur valeur livrée
├── Revoir qualité des complétions
└── Célébrer l'impact, pas le compte
EXEMPLE 3: Cible de Temps de Réponse
─────────────────────────────────────
Cible: Répondre aux bugs en < 4 heures
Gaming:
├── Réponses rapides "acknowledged"
├── Pas de progression réelle
├── Gaming de l'horloge
└── Réponse rapide, résolution lente
Mieux:
├── Suivre temps jusqu'à résolution
├── Satisfaction client
├── Adresser les causes racines
└── Qualité end-to-end
Métriques Saines
Métriques de Livraison d'Équipe
MÉTRIQUES DE LIVRAISON QUI FONCTIONNENT
═══════════════════════════════════════
TEMPS DE CYCLE:
─────────────────────────────────────
Définition: Temps du début du travail au terminé
Pourquoi bon: Difficile à gamer, mesure le flux
Suivre: Tendance dans le temps
Cible: Diminuer (livraison plus rapide)
┌─────────────────────────────────────────────────────────┐
│ Tendance Temps de Cycle │
│ ───────────────────────────────── │
│ 12 │ │
│ 9 │ ● │
│ 6 │ ● ● ● │
│ 3 │ ● ● ● ● │
│ 0 └─────────────────────────── │
│ S1 S2 S3 S4 S5 S6 S7 S8 │
│ │
│ Tendance: Amélioration (9 jours → 4 jours) │
└─────────────────────────────────────────────────────────┘
THROUGHPUT:
─────────────────────────────────────
Définition: Items complétés par sprint
Pourquoi bon: Mesure la complétion réelle
Suivre: Moyenne dans le temps
Utilisation: Planification, pas performance
PRÉVISIBILITÉ:
─────────────────────────────────────
Définition: % du travail engagé complété
Pourquoi bon: Mesure planification réaliste
Suivre: Doit être 80-100%
Alerte: Si toujours 100%, engagements trop bas
LEAD TIME:
─────────────────────────────────────
Définition: Temps de la demande à la livraison
Pourquoi bon: Vue centrée client
Suivre: Par type de travail
Cible: Réduire pour haute priorité
Métriques de Qualité
MÉTRIQUES QUALITÉ ÉQUILIBRÉES
═════════════════════════════
TAUX DE DÉFAUTS:
─────────────────────────────────────
Mesure: Bugs trouvés après livraison
Suivre: Par release, par fonctionnalité
Cible: Tendance descendante
Attention: Ne pas punir pour bugs trouvés
INCIDENTS PRODUCTION:
─────────────────────────────────────
Mesure: Pannes causées par changements
Suivre: Fréquence et sévérité
Cible: Minimiser impact utilisateur
Lié: Change Failure Rate (DORA)
DETTE TECHNIQUE:
─────────────────────────────────────
Mesure: Estimation effort pour fixes
Suivre: Rapport dette/feature work
Cible: Maintenir ratio sain (~20%)
Action: Allouer temps régulièrement
Tableau de Bord Performance Équipe
┌────────────────────────────────────────────────────────────────┐
│ PERFORMANCE ÉQUIPE - Dashboard Mensuel │
├────────────────────────────────────────────────────────────────┤
│ │
│ LIVRAISON: │
│ Temps Cycle [████████████░░░░░░░░] 4.2 jours ↓ Améliore │
│ Throughput [██████████████░░░░░░] 18/sprint → Stable │
│ Prévisibilité [████████████████████] 92% ↑ Excellent │
│ │
│ QUALITÉ: │
│ Taux Défauts [████░░░░░░░░░░░░░░░░] 2.1% ↓ Bon │
│ Incidents [██░░░░░░░░░░░░░░░░░░] 1/mois → Stable │
│ Dette Tech [██████████░░░░░░░░░░] 18% ✅ Sain │
│ │
│ SATISFACTION: │
│ Équipe [████████████████░░░░] 4.1/5 ↑ │
│ Stakeholders [██████████████████░░] 4.3/5 → │
│ │
│ TENDANCES (3 mois): │
│ ├── Temps cycle: -25% ✅ │
│ ├── Qualité: +15% ✅ │
│ └── Satisfaction: +8% ✅ │
│ │
└────────────────────────────────────────────────────────────────┘
Utiliser les Métriques Correctement
Principes Clés
UTILISATION SAINE DES MÉTRIQUES
═══════════════════════════════
✅ FAIRE:
├── Mesurer au niveau équipe
├── Regarder les tendances
├── Combiner plusieurs métriques
├── Utiliser pour améliorer processus
├── Partager de façon transparente
├── Discuter en rétrospectives
└── Célébrer les améliorations
❌ NE PAS FAIRE:
├── Mesurer les individus isolément
├── Comparer entre équipes
├── Utiliser pour punir
├── Fixer comme objectifs rigides
├── Ignorer le contexte
├── Réagir aux fluctuations court terme
└── Créer de la compétition malsaine
Intégration GitScrum
GitScrum supporte la mesure saine de performance avec:
- Métriques d'équipe: Focus sur le collectif
- Tendances temps de cycle: Visualisation historique
- Rapports throughput: Suivi de complétion
- Dashboards personnalisables: Vos métriques importantes
- Export données: Pour analyses approfondies