9 min lecture • Guide 26 of 877
Équilibrer le Travail de Features avec la Correction de Bugs
Les équipes de développement luttent constamment avec la tension entre construire de nouvelles features et corriger les bugs existants. Trop de focus sur les features mène à la dette technique et la frustration utilisateur, tandis que trop de focus sur les bugs stagne le progrès produit. GitScrum permet une allocation équilibrée via des workflows de bugs dédiés et des métriques qui aident à maintenir le bon équilibre.
Le Dilemme Feature vs. Bug
Une allocation déséquilibrée crée des problèmes:
- Sprints lourds en features — Utilisateurs souffrent des issues non résolus
- Sprints lourds en bugs — Roadmap glisse, stakeholders frustrés
- Changement de contexte — Développeurs perdent productivité en sautant entre
- Bugs cachés — Features livrées avec issues connus
- Accumulation dette technique — Fixes rapides créent problèmes futurs
- Problèmes moral équipe — Duty bugs vu comme punition
Solutions d'Équilibre GitScrum
Outils pour maintenir l'équilibre:
Mécanismes d'Équilibre
| Mécanisme | Implémentation GitScrum |
|---|---|
| Allocation sprint | Capacité basée pourcentage |
| Priorisation bugs | Labels sévérité + impact |
| Rotation bugs | Politiques auto-assignation |
| Portes qualité | Checklists empêchant releases |
| Suivi métriques | Vélocité bugs vs. features |
| Visibilité | Vues et rapports séparés |
Stratégies d'Allocation de Sprint
Allocation Basée sur la Capacité
Planification Capacité Sprint:
Capacité Équipe: 60 story points
Modèle Allocation A: Pourcentage Fixe
─────────────────────────────────────
├── Nouvelles Features: 70% (42 points)
├── Correction Bugs: 20% (12 points)
├── Dette Technique: 10% (6 points)
└── Total: 100% (60 points)
Modèle Allocation B: Moyenne Mobile
───────────────────────────────────
├── Features Base: 60% (36 points)
├── Bugs Base: 15% (9 points)
├── Buffer: 25% (15 points)
│ └── Alloué pendant sprint selon bugs émergents
└── Total: 100% (60 points)
Modèle Allocation C: Déclenché par Qualité
──────────────────────────────────────────
├── Si bugs P0/P1 ouverts < 5:
│ └── Features: 80% / Bugs: 15% / Dette: 5%
├── Si bugs P0/P1 ouverts 5-10:
│ └── Features: 60% / Bugs: 35% / Dette: 5%
├── Si bugs P0/P1 ouverts > 10:
│ └── Features: 40% / Bugs: 55% / Dette: 5%
└── Ajuster automatiquement chaque sprint
Allocation Sprint 15 (Modèle A):
┌─────────────────────────────────────────────────┐
│ CAPACITÉ SPRINT: 60 points │
├─────────────────────────────────────────────────┤
│ Features (42 pts) │████████████████████░░░░│ │
│ Bugs (12 pts) │██████░░░░░░░░░░░░░░░░░░│ │
│ Dette Tech (6 pts) │███░░░░░░░░░░░░░░░░░░░░░│ │
├─────────────────────────────────────────────────┤
│ Engagé: │ 55 points │
│ Capacité Restante: │ 5 points (buffer) │
└─────────────────────────────────────────────────┘
Réservation Budget Bugs
Réserver Capacité Bugs:
Protocole Planification Sprint:
───────────────────────────────
1. Commencer avec Capacité Totale (60 points)
2. Réserver Allocation Bugs D'abord
├── Vérifier comptage bugs P0/P1 (actuellement 7)
├── Estimer points bugs (moyenne 2 pts chacun)
├── Réservé: 7 × 2 = 14 points pour bugs
└── Plus buffer: +4 points pour bugs découverts
Total Réserve Bugs: 18 points
3. Réserver Dette Technique (si critique)
├── Items dette critiques: 2
├── Points: 6 points
└── Total Réserve Dette: 6 points
4. Restant pour Features
├── Total: 60 points
├── Moins bugs: -18 points
├── Moins dette: -6 points
└── Disponible pour features: 36 points
5. Remplir Backlog Features
├── Sélectionner features totalisant ≤36 points
├── Prioriser par valeur business
└── Confirmer avec Product Owner
Résultat Backlog Sprint:
├── Features: 34 points (5 items)
├── Bugs: 18 points (9 items)
├── Dette Technique: 6 points (2 items)
└── Buffer: 2 points (non alloué)
Système de Priorisation des Bugs
Matrice Sévérité-Impact
Classification Priorité Bugs:
IMPACT
Bas Moyen Haut
┌─────────┬──────────┬──────────┬──────────┐
Haute│ │ P1 │ P0 │ P0 │
│ │ 24-48h │ 4-8h │ <4h │
SÉVÉRITÉ ├─────────┼──────────┼──────────┼──────────┤
Moyenne│ │ P2 │ P1 │ P0 │
│ │ Sprint │ 24-48h │ 4-8h │
├─────────┼──────────┼──────────┼──────────┤
Basse │ │ P3 │ P2 │ P1 │
│ │ Backlog │ Sprint │ 24-48h │
└─────────┴──────────┴──────────┴──────────┘
Définitions Sévérité:
├── Haute: Crash système, perte données, brèche sécurité
├── Moyenne: Feature cassée, contournement existe
└── Basse: Cosmétique, inconvénient mineur
Définitions Impact:
├── Haut: Tous utilisateurs affectés, impact revenus
├── Moyen: Segment utilisateurs significatif affecté
└── Bas: Peu d'utilisateurs, cas limite
Temps Réponse (SLA):
├── P0: Tout laisser, corriger immédiatement
├── P1: Corriger dans 24-48 heures
├── P2: Corriger dans sprint actuel
└── P3: Ajouter au backlog, prioriser plus tard
Workflow Triage Bugs
Processus Triage Bugs:
Nouveau Bug Signalé:
────────────────────
Étape 1: Triage Initial (Dans 4 heures)
├── Assigner au Lead Triage (rotation)
├── Vérifier bug reproductible
├── Évaluer sévérité (Haute/Moyenne/Basse)
├── Évaluer impact (Haut/Moyen/Bas)
├── Déterminer priorité (P0/P1/P2/P3)
└── Ajouter labels appropriés
Étape 2: Catégorisation
├── Ajouter labels:
│ ├── severity/high, severity/medium, severity/low
│ ├── impact/high, impact/medium, impact/low
│ ├── priority/P0, priority/P1, priority/P2, priority/P3
│ ├── component/[zone] (UI, API, Database, etc.)
│ └── regression/yes ou regression/no
└── Lier aux issues liés si existants
Étape 3: Routage
├── P0: Assigner immédiatement à dev senior disponible
├── P1: Ajouter à colonne "Bugs Urgents", assigner propriétaire
├── P2: Ajouter à allocation bugs sprint actuel
├── P3: Ajouter au Bug Backlog, attendre priorisation
└── Mettre à jour statut bug à "Trié"
Étape 4: Communication
├── P0/P1: Notifier équipe immédiatement (alerte Slack)
├── P2: Inclure dans standup quotidien
├── P3: Revoir dans grooming hebdo backlog
└── Rapporteur notifié de décision triage
Système de Rotation des Bugs
Distribution Équitable
Politique Rotation Bugs:
Principes:
├── Chaque développeur prend duty bugs
├── Rotation équitable et prévisible
├── Pairing Senior/Junior pour apprentissage
└── Personne coincé sur bugs indéfiniment
Calendrier Rotation:
────────────────────
Semaine │ Dev Principal Bugs │ Backup │ Focus
────────┼────────────────────┼─────────────┼─────────────
1 │ Alice │ Bob │ Bugs UI
2 │ Bob │ Carol │ Bugs API
3 │ Carol │ David │ Bugs DB
4 │ David │ Emma │ Bugs UI
5 │ Emma │ Alice │ Bugs API
(répéter)
Pendant Semaine Duty Bugs:
├── Responsable réponse immédiate P0/P1
├── Premier à trier nouveaux bugs dans zone composant
├── Attendu compléter 60% bugs alloués sprint
├── Apparié avec backup pour issues complexes
└── Travail features réduit proportionnellement
Automatisation GitScrum:
├── Auto-assigner nouveaux bugs P0/P1 au dev rotation actuelle
├── Notifier dans Slack quand bug assigné
├── Alerter si bug non assigné >4 heures
└── Rappel rotation hebdo dimanche soir
Configuration Board pour Équilibre
Kanban Double Piste
Structure Board:
Option 1: Swimlanes Séparées
────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ BOARD SPRINT 15 │
├─────────────────────────────────────────────────────────────┤
│ Features │
├──────────────┬──────────────┬─────────────┬────────────────┤
│ À Faire (5) │ En Cours (3) │ Revue (2) │ Fait (3) │
├──────────────┴──────────────┴─────────────┴────────────────┤
│ Bugs │
├──────────────┬──────────────┬─────────────┬────────────────┤
│ À Faire (8) │ En Cours (2) │ Revue (1) │ Fait (5) │
├──────────────┴──────────────┴─────────────┴────────────────┤
│ Dette Technique │
├──────────────┬──────────────┬─────────────┬────────────────┤
│ À Faire (2) │ En Cours (1) │ Revue (0) │ Fait (1) │
└──────────────┴──────────────┴─────────────┴────────────────┘
Option 2: Filtrage Basé sur Labels
──────────────────────────────────
Board unique avec toggles filtre:
├── [Tout] [Features Seules] [Bugs Seuls] [Dette Tech Seule]
├── Labels: type/feature, type/bug, type/tech-debt
├── Changement rapide entre vues
└── Progrès combiné visible dans vue "Tout"
Suivi Métriques Qualité
Dashboard Équilibre
Dashboard Équilibre Feature/Bug:
Progrès Sprint 15:
──────────────────
Distribution Travail:
├── Features: ████████████████░░░░ 80% complet (34/42 pts)
├── Bugs: ████████████░░░░░░░░ 60% complet (7/12 pts)
├── Dette Tech: █████████░░░░░░░░░░░ 50% complet (3/6 pts)
└── Global: ███████████████░░░░░ 73% complet
Métriques Bugs:
├── Bugs Ouverts: 23 (↓5 depuis début sprint)
├── P0/P1 Ouverts: 2 (cible: 0)
├── Bugs Corrigés Ce Sprint: 9
├── Nouveaux Bugs Ce Sprint: 4
├── Changement Net Bugs: -5 (bien!)
└── Taux Échappement Bugs: 2% (1 bug pour 50 features)
Tendance Qualité (6 Derniers Sprints):
──────────────────────────────────────
Sprint │ Features │ Bugs │ Bugs Net │ Taux Échap
───────┼──────────┼──────┼──────────┼───────────
10 │ 38 pts │ 12 │ +3 │ 5%
11 │ 42 pts │ 10 │ -2 │ 4%
12 │ 45 pts │ 8 │ -4 │ 3%
13 │ 40 pts │ 14 │ +2 │ 4%
14 │ 44 pts │ 11 │ -3 │ 2%
15 │ 42 pts │ 12 │ -5 │ 2%
Tendance: Comptage bugs diminue, taux échappement s'améliore ✓
Meilleures Pratiques
Pour Product Owners
- Budgéter pour bugs — Inclure allocation bugs dans planification
- Prioriser par impact — Tous les bugs ne sont pas égaux
- Accepter compromis — Impossible de corriger tous bugs immédiatement
- Communiquer équilibre — Expliquer aux stakeholders pourquoi bugs importent
- Suivre tendances — Surveiller comptages bugs dans le temps
Pour Développeurs
- Prendre possession de vos bugs — Fierté du travail qualité
- Écrire tests d'abord — Prévenir bugs avant qu'ils arrivent
- Investiguer en profondeur — Trouver cause racine, pas seulement symptômes
- Partager connaissance — Aider équipe à apprendre des bugs
- Équilibrer équitablement — Prendre son tour au duty bugs
Pour Team Leads
- Définir allocation claire — Définir et communiquer pourcentages
- Faire tourner équitablement — Personne ne doit se sentir visé
- Reconnaître travail qualité — Célébrer victoires bugs
- Surveiller équilibre — Ajuster allocation selon métriques
- Construire culture — Rendre travail bugs valorisé, pas puni