6 min lecture • Guide 693 of 877
Améliorer la Performance d'Équipe avec les Métriques
Les métriques illuminent la performance d'équipe et guident l'amélioration quand elles sont utilisées avec réflexion. GitScrum fournit des analytics d'équipe incluant la vélocité, le cycle time et les métriques de qualité qui aident les équipes à identifier les opportunités d'amélioration sans favoriser une compétition néfaste.
Philosophie des Métriques
Culture de Métriques Saine
PRINCIPES DES MÉTRIQUES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ À FAIRE: │
│ ✓ Utiliser les métriques pour l'apprentissage d'équipe │
│ ✓ Se concentrer sur les tendances, pas les valeurs absolues│
│ ✓ Laisser les équipes choisir et posséder leurs métriques │
│ ✓ Discuter des métriques en rétrospectives │
│ ✓ Célébrer l'amélioration │
│ ✓ Utiliser plusieurs métriques (tableau équilibré) │
│ │
│ À NE PAS FAIRE: │
│ ✗ Comparer les individus avec des métriques │
│ ✗ Lier les métriques directement à la compensation │
│ ✗ Utiliser les métriques de manière punitive │
│ ✗ Optimiser pour une seule métrique │
│ ✗ Ignorer le contexte lors de l'interprétation │
│ ✗ Fixer des cibles arbitraires │
│ │
│ LOI DE GOODHART: │
│ "Quand une mesure devient une cible, elle cesse d'être │
│ une bonne mesure." │
│ │
│ Exemple: Si vous mesurez les lignes de code, les gens │
│ écriront du code plus verbeux, pas du meilleur code. │
└─────────────────────────────────────────────────────────────┘
Catégories de Métriques
FRAMEWORK DE MÉTRIQUES ÉQUILIBRÉES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LIVRAISON: │
│ Combien de travail est accompli ? │
│ • Vélocité (story points/sprint) │
│ • Throughput (items/semaine) │
│ • Taux de complétion de sprint │
│ │
│ VITESSE: │
│ À quelle vitesse le travail circule ? │
│ • Cycle time (début à terminé) │
│ • Lead time (demande à terminé) │
│ • Temps de retour de revue │
│ │
│ QUALITÉ: │
│ Quelle est la qualité du travail ? │
│ • Taux de défauts (bugs par feature) │
│ • Défauts échappés (bugs en production) │
│ • Ratio de dette technique │
│ │
│ SANTÉ D'ÉQUIPE: │
│ Comment va l'équipe ? │
│ • Sondages de satisfaction │
│ • Taux de turnover │
│ • Rythme soutenable │
│ • Sécurité psychologique │
└─────────────────────────────────────────────────────────────┘
Métriques Clés
Métriques DORA
MÉTRIQUES DORA:
═══════════════
4 MÉTRIQUES CLÉS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. FRÉQUENCE DE DÉPLOIEMENT: │
│ À quelle fréquence déployez-vous en production ? │
│ Élite: Multiple fois/jour │
│ Haute: Hebdomadaire à mensuel │
│ Moyenne: Mensuel à semestriel │
│ Faible: < semestriel │
│ │
│ 2. LEAD TIME FOR CHANGES: │
│ Temps du commit à la production │
│ Élite: < 1 heure │
│ Haute: < 1 semaine │
│ Moyenne: 1-6 mois │
│ Faible: > 6 mois │
│ │
│ 3. TAUX D'ÉCHEC DES CHANGEMENTS: │
│ % de déploiements causant des échecs │
│ Élite: 0-15% │
│ Haute: 16-30% │
│ Moyenne/Faible: 31-100% │
│ │
│ 4. TEMPS DE RESTAURATION: │
│ Temps pour récupérer d'un incident │
│ Élite: < 1 heure │
│ Haute: < 1 jour │
│ Moyenne: < 1 semaine │
│ Faible: > 6 mois │
│ │
└─────────────────────────────────────────────────────────────┘
Vélocité et Cycle Time
VÉLOCITÉ:
═════════
SUIVI DE VÉLOCITÉ:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Sprint │ Engagé │ Complété │ Vélocité │ Tendance │
├─────────────────────────────────────────────────────────────┤
│ S20 │ 35 │ 32 │ 32 │ │
│ S21 │ 38 │ 29 │ 29 │ ↓ │
│ S22 │ 32 │ 30 │ 30 │ ↑ │
│ S23 │ 34 │ 33 │ 33 │ ↑ │
│ S24 │ 36 │ 31 │ 31 │ ↓ │
├─────────────────────────────────────────────────────────────┤
│ MOYENNE: 31 pts │ STABLE: ✓ │
└─────────────────────────────────────────────────────────────┘
CYCLE TIME:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Type de Travail │ Moyenne │ P50 │ P90 │ Tendance │
├─────────────────────────────────────────────────────────────┤
│ Bug fix │ 2.1j │ 1.5j │ 4j │ ↓ │
│ Feature petite │ 3.2j │ 2.5j │ 6j │ → │
│ Feature moyenne │ 7.5j │ 6j │ 12j │ ↑ │
│ Feature grande │ 15j │ 12j │ 25j │ → │
└─────────────────────────────────────────────────────────────┘
Utiliser les Métriques
Rétrospectives Basées sur Données
ANALYSE EN RÉTRO:
═════════════════
FORMAT:
1. Présenter les métriques du sprint
2. Identifier les patterns
3. Discuter des causes racines
4. Définir des actions d'amélioration
EXEMPLE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ OBSERVATION: │
│ Cycle time moyen passé de 3j à 5j ce sprint │
│ │
│ ANALYSE: │
│ • 3 PR ont attendu 2+ jours en revue │
│ • 2 reviewers en vacances │
│ • PR plus grandes que d'habitude │
│ │
│ ACTIONS: │
│ • Établir SLA de revue (24h max) │
│ • Limiter taille PR (max 400 lignes) │
│ • Backup reviewer quand absences │
│ │
│ MÉTRIQUE À SUIVRE: │
│ Cycle time revient < 4j prochain sprint │
│ │
└─────────────────────────────────────────────────────────────┘
Dashboard GitScrum
Visualisation
DASHBOARD ÉQUIPE GITSCRUM:
══════════════════════════
┌─────────────────────────────────────────────────────────────┐
│ PERFORMANCE ÉQUIPE ALPHA - Q1 2024 │
├─────────────────────────────────────────────────────────────┤
│ │
│ VÉLOCITÉ: │
│ ████████████████████████████░░ 31 pts (moy 6 sprints) │
│ Tendance: Stable │
│ │
│ CYCLE TIME: │
│ ████████░░░░░░░░░░░░░░░░░░░░░░ 4.2 jours (P50) │
│ Cible: < 5 jours ✓ │
│ │
│ QUALITÉ: │
│ Défauts échappés: 2/mois (cible < 3) ✓ │
│ Couverture tests: 78% (cible > 75%) ✓ │
│ │
│ SANTÉ: │
│ Satisfaction équipe: 4.2/5 │
│ Burnout risk: Faible │
│ │
│ [Voir détails] [Exporter] │
└─────────────────────────────────────────────────────────────┘