7 min lecture • Guide 148 of 877
Métriques de Productivité des Développeurs
Mesurer la productivité des développeurs est essentiel mais semé d'embûches. Les mauvaises métriques créent du gaming, détruisent le moral et passent à côté de ce qui compte. Les bonnes métriques fournissent des insights, favorisent l'amélioration et respectent la complexité du développement logiciel.
Philosophie des Métriques
| Éviter | Adopter |
|---|---|
| Lignes de code | Valeur livrée |
| Commits par jour | Cycle time |
| Heures travaillées | Throughput |
| Classement individuel | Performance équipe |
| Métriques d'activité | Métriques de résultats |
Métriques Utiles
Métriques DORA
FRAMEWORK MÉTRIQUES DORA
════════════════════════
FRÉQUENCE DE DÉPLOIEMENT
├── Fréquence de déploiement en production
├── Élite: Plusieurs fois par jour
├── Élevé: Hebdo à mensuel
├── Moyen: Mensuel à annuel
├── Bas: Moins d'une fois par an
LEAD TIME DES CHANGEMENTS
├── Temps du commit à la production
├── Élite: Moins d'une heure
├── Élevé: Un jour à une semaine
├── Moyen: Une semaine à un mois
├── Bas: Plus d'un mois
TAUX D'ÉCHEC DES CHANGEMENTS
├── Pourcentage de déploiements causant des problèmes
├── Élite: 0-15%
├── Élevé: 16-30%
├── Moyen: 31-45%
├── Bas: 46-100%
TEMPS MOYEN DE RÉCUPÉRATION (MTTR)
├── Temps pour restaurer le service après incident
├── Élite: Moins d'une heure
├── Élevé: Moins d'un jour
├── Moyen: Un jour à une semaine
├── Bas: Plus d'une semaine
Métriques de Flux
MÉTRIQUES DE FLUX
═════════════════
CYCLE TIME
├── Temps du début du travail à l'achèvement
├── Mesure: Efficacité du développement
├── Utile pour: Identifier les goulots d'étranglement
├── Cible: Consistant, tendance à la baisse
Répartition Typique:
├── Développement: 40%
├── Code review: 30%
├── QA/Tests: 20%
└── Déploiement: 10%
LEAD TIME
├── Temps de la demande à la livraison
├── Mesure: Réactivité totale
├── Utile pour: Perspective client
├── Inclut: Temps d'attente avant début
THROUGHPUT
├── Items complétés par période
├── Mesure: Capacité de livraison
├── Utile pour: Planification, prédictibilité
├── Comparer: Semaine après semaine
WORK IN PROGRESS (WIP)
├── Items actuellement en cours
├── Mesure: Focus vs changement de contexte
├── Utile pour: Détection de surcharge
├── Cible: Bas et stable
Métriques de Qualité
MÉTRIQUES DE QUALITÉ
════════════════════
DENSITÉ DE BUGS
├── Bugs par feature ou par release
├── Tendance: Devrait diminuer
├── Action: Investir dans les tests si élevé
└── Contexte: Certaines features naturellement plus risquées
COUVERTURE DE TESTS
├── Pourcentage de code couvert par tests
├── Cible: 70-80% (pas 100%)
├── Action: Couvrir les chemins critiques
└── Attention: Couverture ≠ qualité
MÉTRIQUES CODE REVIEW
├── Temps jusqu'à première review
├── Cycles de review par PR
├── Tendance: Devrait être stable
└── Action: Améliorer si en hausse
DETTE TECHNIQUE
├── Items de dette connus suivis
├── Dette adressée par sprint
├── Tendance: Ne devrait pas croître
└── Action: Allouer de la capacité
Mesurer de la Bonne Façon
Équipe et Non Individu
POURQUOI LES MÉTRIQUES D'ÉQUIPE
═══════════════════════════════
PROBLÈMES MÉTRIQUES INDIVIDUELLES:
├── Encourage le gaming
├── Ignore la valeur de la collaboration
├── Punit l'aide aux autres
├── Crée la compétition
├── Ignore le pair/mob programming
└── Démotivant
AVANTAGES MÉTRIQUES ÉQUIPE:
├── Encourage la collaboration
├── Propriété partagée
├── Focus sur les résultats
├── Réduit l'incitation au gaming
├── Célèbre le succès d'équipe
└── Plus précis
EXEMPLE:
Au lieu de:
"Sarah a fait 47 commits cette semaine"
Utiliser:
"L'équipe a livré 5 features ce sprint
avec 0 incidents production"
Éviter les Métriques Vanité
MÉTRIQUES VANITÉ VS ACTIONNABLES
════════════════════════════════
MÉTRIQUES VANITÉ:
✗ Lignes de code écrites
✗ Commits par jour
✗ Heures loguées
✗ Nombre de stories complétées
✗ Points vélocité (facilement gonflés)
POURQUOI C'EST MAUVAIS:
├── Facilement manipulé
├── Récompense le mauvais comportement
├── Ignore la qualité
├── Crée des incitations perverses
└── Ne corrèle pas avec la valeur
MÉTRIQUES ACTIONNABLES:
✓ Cycle time (peut améliorer le process)
✓ Fréquence déploiement (mesure le flux)
✓ Taux d'échec (mesure la qualité)
✓ Problèmes clients (mesure l'impact)
✓ Expérience développeur (mesure durabilité)
POURQUOI C'EST BON:
├── Difficile à manipuler
├── Lié aux résultats
├── Guide l'amélioration
├── Vue équilibrée
└── Actionnable
Tableaux de Bord et Visibilité
Dashboard de Productivité
TABLEAU DE BORD PRODUCTIVITÉ ÉQUIPE
═══════════════════════════════════
┌─────────────────────────────────────────────────────────┐
│ Productivité Engineering - Mars 2024 │
├─────────────────────────────────────────────────────────┤
│ │
│ MÉTRIQUES DORA │
│ ┌─────────────┬─────────────┬─────────────┐ │
│ │ Fréq Déploi │ Lead Time │ Taux Échec │ │
│ │ 3.2/jour │ 2.1 jours │ 4.2% │ │
│ │ ↑ de 2.8 │ ↓ de 2.8 │ ↓ de 6% │ │
│ │ 🟢 Élite │ 🟢 Élevé │ 🟢 Élite │ │
│ └─────────────┴─────────────┴─────────────┘ │
│ │
│ MÉTRIQUES FLUX │
│ Cycle Time: 4.2 jours moy (↓ 0.5 du mois dernier) │
│ Throughput: 23 items/semaine (stable) │
│ WIP Moyen: 2.1 par développeur (sain) │
│ │
│ QUALITÉ │
│ Densité Bugs: 0.3 bugs/feature (↓ bien) │
│ Couverture Tests: 78% (stable) │
│ Temps Review: 4.2 heures moy (acceptable) │
│ │
│ TENDANCES (6 mois) │
│ Cycle Time: ↘↘↘↘↘ En amélioration │
│ Throughput: →→→↗↗ Stable/croissant │
│ Qualité: →→→→↗ Stable/amélioration │
│ │
└─────────────────────────────────────────────────────────┘
Expérience Développeur
SONDAGE EXPÉRIENCE DÉVELOPPEUR
══════════════════════════════
QUESTIONS SONDAGE TRIMESTRIEL:
(Échelle 1-5, avec commentaires)
FLUX & FOCUS:
├── Je peux me concentrer sur le code sans interruptions
├── J'ai les outils nécessaires pour être productif
├── Nos processus aident plutôt qu'entravent
QUALITÉ & DURABILITÉ:
├── Je suis fier du code que nous livrons
├── La dette technique est gérable
├── Notre charge de travail est durable
COLLABORATION:
├── Les code reviews sont utiles et rapides
├── Je peux obtenir de l'aide quand j'en ai besoin
├── La communication d'équipe fonctionne bien
CROISSANCE:
├── J'apprends et je progresse
├── Je comprends notre architecture
├── Je peux influencer les décisions techniques
SCORE AGRÉGÉ:
├── Score DX Équipe: 4.1/5 (↑ de 3.8)
├── Suivre dans le temps
└── Agir sur les feedbacks
Bonnes Pratiques
Pour les Métriques de Productivité
- Mesurer les équipes, pas les individus
- Focus sur les résultats plutôt que l'activité
- Utiliser plusieurs métriques (équilibrées)
- Suivre les tendances plutôt que les absolus
- Agir sur les données
Anti-Patterns
ERREURS DE MÉTRIQUES:
✗ Classements productivité individuelle
✗ Lignes de code comme mesure
✗ Punir basé sur les métriques
✗ Focus sur une seule métrique
✗ Métriques sans action
✗ Mesures faciles à manipuler
✗ Ignorer l'expérience développeur
✗ Comparer directement les équipes