7 min lecture • Guide 155 of 877
Gestion de la Charge de Travail des Développeurs
Les développeurs surchargés font plus d'erreurs, travaillent plus lentement et s'épuisent. Une gestion efficace de la charge assure un rythme durable, une qualité constante et des équipes plus heureuses. Elle nécessite une visibilité sur le travail en cours, une planification de capacité réaliste et la discipline de dire non.
Signes d'Alerte de Charge
| Sain | Surchargé |
|---|---|
| 1-2 tâches en cours | 4+ tâches par personne |
| Cycle time constant | Cycle time croissant |
| Faible taux bugs | Défauts en hausse |
| Livraison à temps | Délais manqués |
| Équipe engagée | Stress/épuisement visible |
Visibilité de la Charge
Configuration Dashboard
DASHBOARD VISIBILITÉ CHARGE
═══════════════════════════
VUE CHARGE ÉQUIPE:
┌─────────────────────────────────────────────────────────┐
│ Charge Sprint Actuel │
├─────────────────────────────────────────────────────────┤
│ │
│ DÉVELOPPEUR WIP ASSIGNÉ POINTS STATUT │
│ ───────────────────────────────────────────────────── │
│ Sarah Chen 2 4 13 🟢 OK │
│ Mike Johnson 3 5 18 🟡 Élevé │
│ Alex Rivera 1 3 8 🟢 OK │
│ Emily Watson 4 6 21 🔴 Excessif│
│ Moyenne Équipe 2.5 4.5 15 🟡 Surveiller│
│ │
│ LIMITE WIP: 3 par personne │
│ CAPACITÉ: 70% allouée │
│ │
└─────────────────────────────────────────────────────────┘
VUE INDIVIDUELLE:
┌─────────────────────────────────────────────────────────┐
│ Emily Watson - Travail Actuel │
├─────────────────────────────────────────────────────────┤
│ │
│ EN COURS (4 items - AU-DESSUS LIMITE): │
│ ├── GS-234: Refactoring API Login (M) - Jour 3 │
│ ├── GS-256: Intégration paiement (L) - Jour 2 │
│ ├── GS-267: Fix bug: timeout session (S) - Jour 1 │
│ └── GS-271: Code review: module auth - Jour 1 │
│ │
│ EN ATTENTE (2 items): │
│ ├── GS-280: Analytics dashboard (M) │
│ └── GS-285: Fix notification email (S) │
│ │
│ ⚠️ RECOMMANDATION: Terminer 2 items avant de │
│ commencer nouveau travail. Envisager réassigner │
│ GS-280. │
│ │
└─────────────────────────────────────────────────────────┘
Limites WIP
IMPLÉMENTATION LIMITES WIP
══════════════════════════
LIMITES WIP PERSONNELLES:
├── Développeurs: 2-3 items max
├── Seniors: 2 items (overhead mentorat)
├── Juniors: 1-2 items (focus apprentissage)
└── Leads: 1-2 items (overhead réunions)
LIMITES WIP COLONNES:
┌────────────────────────────────────────────────────────┐
│ Prêt │ En Cours │ Review │ Fait │
│ (∞) │ (8 max) │ (6 max) │ │
├────────────────────────────────────────────────────────┤
│ [Tâche] │ [Tâche] │ [Tâche] │ [Fait] │
│ [Tâche] │ [Tâche] │ [Tâche] │ [Fait] │
│ [Tâche] │ [Tâche] │ │ │
│ │ [Tâche] │ │ │
│ │ [Tâche] ← Si ajouter dépasse 8, │
│ │ traiter d'abord │
└────────────────────────────────────────────────────────┘
APPLICATION:
├── GitScrum alerte si limite dépassée
├── L'équipe traite blocages avant nouveau travail
├── Manager révise violations chroniques
└── Rétrospective sur patterns WIP
Planification de Capacité
Planification Réaliste
PLANIFICATION CAPACITÉ RÉALISTE
═══════════════════════════════
CAPACITÉ DISPONIBLE:
─────────────────────────────────────
Heures travail par jour: 8
Réunions moyenne: -2
Email/Slack: -1
Changement contexte: -0.5
Interruptions: -0.5
─────────────────────────────────────
Temps codage productif: 4 heures/jour
CAPACITÉ SPRINT (2 semaines):
─────────────────────────────────────
Jours disponibles: 10
Congés/Fériés: -1
─────────────────────────────────────
Jours travail: 9
Heures codage: 36 (9 × 4)
Marge (20%): -7
─────────────────────────────────────
Capacité planifiable: 29 heures
NE PAS PLANIFIER À 100%:
├── Travail inattendu arrive
├── Les estimations sont souvent fausses
├── Demandes support surgissent
├── Dette technique s'accumule
└── Épuisement si toujours au max
RÈGLE: Planifier à 70-80% de capacité
Planification Sprint
VÉRIFICATION CHARGE PLANIFICATION SPRINT
════════════════════════════════════════
AVANT DE S'ENGAGER:
1. Calculer capacité équipe
5 développeurs × 29 heures = 145 heures
2. Sommer le travail engagé
Stories: 18 = ~160 heures estimées
3. Vérifier: 160 > 145 = SURCAPACITÉ
4. Ajuster:
├── Retirer l'item de plus basse priorité
├── Réduire scope d'un gros item
├── Déplacer item au sprint suivant
└── Ré-estimer avec l'équipe
5. Revérifier: 140 < 145 = OK (96% planifié)
6. Distribuer équitablement:
├── Sarah: 28 heures (97%)
├── Mike: 30 heures (103%) ← surveiller
├── Alex: 27 heures (93%)
├── Emily: 28 heures (97%)
└── Jordan: 27 heures (93%)
Équilibrer la Charge
Stratégies de Redistribution
REDISTRIBUTION CHARGE
═════════════════════
QUAND REDISTRIBUER:
├── Limite WIP dépassée
├── Une personne bloquée
├── Vacances/maladie
├── Changement priorité
├── Mismatch compétences découvert
COMMENT REDISTRIBUER:
─────────────────────────────────────
1. Identifier personne surchargée
2. Lister leurs items en cours
3. Trouver items transférables:
├── Pas encore commencés
├── Exigences claires
├── Compétences dispo dans équipe
└── Pas critiques pour leur contexte
4. Identifier receveur:
├── Sous capacité
├── A les compétences requises
└── Disponible pour commencer
5. Passation:
├── Bref transfert contexte
├── Mettre à jour assigné tâche
└── Notifier parties prenantes
WORKFLOW GITSCRUM:
1. Ouvrir dashboard charge
2. Glisser tâche vers nouvel assigné
3. Ajouter commentaire avec contexte
4. Notification Slack envoyée auto
Gérer la Surcharge
QUAND L'ÉQUIPE EST SURCHARGÉE
═════════════════════════════
ÉTAPE 1: Reconnaître
├── "Nous avons plus de travail que de capacité"
├── Ne pas prétendre le contraire
└── Rendre visible aux parties prenantes
ÉTAPE 2: Prioriser Sans Pitié
├── Que DOIT-ON faire?
├── Qu'est-ce qui peut attendre?
├── Qu'est-ce qu'on peut abandonner?
└── Stack rank tout
ÉTAPE 3: Communiquer les Trade-offs
├── "On peut faire A et B, pas C"
├── "Si C est priorité, que retire-t-on?"
├── Laisser les stakeholders choisir
└── Documenter la décision
ÉTAPE 4: Protéger l'Équipe
├── Pas d'ajout "juste une de plus"
├── Repousser le scope creep
├── Maintenir les limites WIP
└── Accepter que certaines choses n'arriveront pas
ÉTAPE 5: Apprendre et Ajuster
├── Pourquoi étions-nous surchargés?
├── Comment prévenir la prochaine fois?
├── Meilleure estimation?
└── Plus de capacité?
Fonctionnalités Charge GitScrum
Dashboard de Charge
FONCTIONNALITÉS CHARGE GITSCRUM
═══════════════════════════════
DASHBOARD CHARGE:
├── Vue par membre équipe
├── Points par personne
├── WIP par personne
├── Indicateurs surcharge
└── Tendance sur les sprints
AUTOMATISATION:
├── Alerte si limite WIP dépassée
├── Alerte distribution inégale
├── Signalement items vieillissants
├── % utilisation capacité
RAPPORTS:
├── Résumé charge sprint
├── Tendances capacité historiques
├── Burndown par personne
├── Cycle time par niveau charge
ACTIONS:
├── Glisser pour réassigner
├── Un-clic désassigner
├── Réassignation en masse
└── Mode vacances
Bonnes Pratiques
Pour la Gestion de Charge
- Rendre la charge visible — On ne gère pas ce qu'on ne voit pas
- Utiliser des limites WIP — Prévenir surcharge structurellement
- Planifier à 70-80% — Laisser marge pour la réalité
- Redistribuer tôt — Ne pas attendre la crise
- Protéger l'équipe — Dire non quand nécessaire
Anti-Patterns
ERREURS DE CHARGE:
✗ Planification à 100% capacité
✗ Pas de limites WIP
✗ Charges individuelles cachées
✗ Ajouter sans retirer
✗ Attentes héroïques
✗ Ignorer signes d'épuisement
✗ Pas de processus redistribution
✗ Tout est priorité 1