6 min lecture • Guide 189 of 877
Identifier les Goulots d'Étranglement dans le Workflow de Développement
Les goulots d'étranglement sont les contraintes cachées qui limitent la production de toute votre équipe. Une équipe de 10 personnes avec un goulot d'étranglement de revue de code d'une seule personne est effectivement une équipe d'une personne pour la revue. Trouver et éliminer les goulots d'étranglement est l'amélioration à plus fort effet de levier que vous puissiez faire.
Indicateurs de Goulots d'Étranglement
| Symptôme | Goulot Probable |
|---|---|
| PR en attente pendant des jours | Revue de code |
| Bugs après release | Tests/QA |
| Déploiement prend des heures | Processus de déploiement |
| Réponses prennent des jours | Exigences/décisions |
| Travail s'accumule dans une colonne | Activité de cette colonne |
Trouver les Goulots d'Étranglement
Analyse des Données
ANALYSE DE RÉPARTITION DU TEMPS DE CYCLE
════════════════════════════════════════
MESURER LE TEMPS À CHAQUE ÉTAPE:
──────────────────────────────────────────
Étape Temps Moy. % du Total
──────────────────────────────────────────
Prêt → Début 0.5 jours 10%
Développement 2.0 jours 40%
Revue Code 1.5 jours 30% ← Goulot?
Tests QA 0.5 jours 10%
Déploiement 0.5 jours 10%
──────────────────────────────────────────
Total 5.0 jours 100%
ANALYSE:
├── La revue représente 30% du temps total
├── Par rapport au développement (40%), c'est disproportionné
├── Le temps d'attente en revue = gaspillage
└── Concentrer l'amélioration ici
TENDANCE HEBDOMADAIRE:
Semaine 1: Revue 1.2 jours
Semaine 2: Revue 1.5 jours
Semaine 3: Revue 1.8 jours ← S'aggrave
Semaine 4: Revue 2.1 jours
Temps de revue croissant = goulot de capacité
Observation du Board
DÉTECTION VISUELLE DES GOULOTS
═══════════════════════════════
REGARDEZ VOTRE BOARD:
┌────────────────────────────────────────────────────────┐
│ Prêt │ En Cours │ Revue │ QA │ Fait │
├────────────────────────────────────────────────────────┤
│ [T1] │ [T5] │ [T8] │ [T14]│ [Fait] │
│ [T2] │ [T6] │ [T9] │ │ [Fait] │
│ [T3] │ [T7] │ [T10] │ │ [Fait] │
│ [T4] │ │ [T11] │ │ │
│ │ │ [T12] │ │ │
│ │ │ [T13] │ │ │
└────────────────────────────────────────────────────────┘
↑
GOULOT: Travail s'accumule ici
SIGNES D'ALERTE:
├── Beaucoup de cartes dans une colonne
├── Cartes restent longtemps dans une colonne
├── Colonne suivante souvent vide
└── Équipe se plaint d'attendre
Techniques d'Identification
Analyse Quantitative
MÉTRIQUES À SUIVRE:
═══════════════════
1. TEMPS EN COLONNE:
┌─────────────────────────────────────┐
│ Étape │ Temps Moy. │ Tendance│
├─────────────────────────────────────┤
│ Développement│ 2.1 jours │ Stable │
│ Revue │ 1.8 jours │ ↑ +20% │
│ QA │ 0.8 jours │ Stable │
│ Déploiement │ 0.3 jours │ Stable │
└─────────────────────────────────────┘
2. FILE D'ATTENTE PAR ÉTAPE:
┌─────────────────────────────────────┐
│ Étape │ Queue Moy. │ Max │
├─────────────────────────────────────┤
│ Développement│ 2 tâches │ 4 │
│ Revue │ 6 tâches │ 12 ← │
│ QA │ 1 tâche │ 3 │
│ Déploiement │ 0 tâches │ 2 │
└─────────────────────────────────────┘
3. RATIO TRAVAIL/ATTENTE:
Temps productif: 40%
Temps d'attente: 60% ← Problème!
Analyse Qualitative
SOURCES D'INFORMATION:
══════════════════════
RÉTROSPECTIVES:
├── "On attend toujours les revues de code"
├── "Les décisions prennent une éternité"
├── "Le déploiement bloque tout le vendredi"
└── "On ne peut pas tester tant que X n'est pas fait"
STANDUPS:
├── Mêmes tâches "en revue" depuis des jours
├── Blocages récurrents sur les mêmes étapes
└── Frustration visible de l'équipe
OBSERVATION DIRECTE:
├── Développeurs inactifs en attente
├── Multitâche forcé par les blocages
└── Contournements informels
Stratégies d'Élimination
Ajouter de la Capacité
AUGMENTER LA CAPACITÉ DU GOULOT:
════════════════════════════════
PROBLÈME: Revue de code = goulot
(1 reviewer, 5 développeurs)
SOLUTIONS:
┌─────────────────────────────────────────────────────────┐
│ │
│ 1. FORMER PLUS DE REVIEWERS: │
│ ├── Rotation des responsabilités │
│ ├── Pair programming = revue intégrée │
│ └── Critères de revue simplifiés │
│ │
│ 2. AUTOMATISER LA REVUE: │
│ ├── Linting automatique │
│ ├── Tests automatisés │
│ └── Analyse statique de code │
│ │
│ 3. RÉDUIRE LA CHARGE: │
│ ├── Petites PR (< 200 lignes) │
│ ├── Revue par paires │
│ └── Standards de code explicites │
│ │
└─────────────────────────────────────────────────────────┘
Éliminer les Étapes
SUPPRIMER OU SIMPLIFIER:
═════════════════════════
AVANT:
┌──────┬────────┬──────┬────────┬─────┬────────┬──────┐
│ TODO │ En Dev │Review│ QA Man │Appr.│ Deploy │ Done │
└──────┴────────┴──────┴────────┴─────┴────────┴──────┘
↓ ↓ ↓ ↓ ↓
Goulots potentiels à chaque transition
APRÈS (simplifié):
┌──────┬────────┬──────┬────────┬──────┐
│ TODO │ En Dev │Review│ Verify │ Done │
└──────┴────────┴──────┴────────┴──────┘
CHANGEMENTS:
├── QA manuel → Tests automatisés
├── Approbation → Critères objectifs
├── Deploy manuel → Déploiement continu
└── Moins de transitions = moins de goulots
Surveillance Continue
Tableau de Bord de Flux
MÉTRIQUES DE SANTÉ DU WORKFLOW:
═══════════════════════════════
CYCLE TIME (moyenne 14 jours):
Semaine 1: ████████████████░░░░ 4.2 jours
Semaine 2: ███████████████░░░░░ 3.9 jours
Semaine 3: ██████████████████░░ 4.6 jours ⚠️
THROUGHPUT (tâches/semaine):
Semaine 1: ████████████████ 12
Semaine 2: ██████████████████ 14
Semaine 3: ████████████░░░░░░ 10 ⚠️
ALERTES AUTOMATIQUES:
├── ⚠️ Temps en revue > 24h: 5 tâches
├── ⚠️ Queue revue > 8 tâches
└── ✅ Déploiement: normal
Plan d'Action
PROCESSUS D'AMÉLIORATION:
═════════════════════════
1. IDENTIFIER (hebdomadaire):
├── Analyser les métriques
├── Écouter l'équipe
└── Observer le board
2. PRIORISER:
├── Impact sur le débit
├── Facilité de résolution
└── Coût du changement
3. EXPÉRIMENTER:
├── Une amélioration à la fois
├── Mesurer avant/après
└── Timebox: 2 semaines
4. STANDARDISER:
├── Si amélioration confirmée
├── Documenter le changement
└── Former l'équipe