8 min lecture • Guide 100 of 877
Équilibrer Développement Features avec Correction Bugs
Chaque équipe de développement fait face à la tension entre construire nouvelles features et corriger bugs existants. La configuration boards GitScrum, système labels, et outils planification sprint aident équipes à trouver le bon équilibre en rendant travail bugs visible, établissant politiques allocation, et créant processus qui empêchent bugs d'être perpétuellement déprioritisés tout en livrant valeur client.
Comprendre la Tension
Le Problème d'Équilibre
PRIORITÉS EN CONCURRENCE:
┌─────────────────────────────────────────────────────────────┐
│ POURQUOI L'ÉQUILIBRE EST DIFFICILE │
├─────────────────────────────────────────────────────────────┤
│ │
│ PRESSION FEATURES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Engagements roadmap envers stakeholders ││
│ │ • Pression compétitive pour livrer ││
│ │ • Nouvelles features = progrès visible ││
│ │ • Revenue lié à livraison features ││
│ │ • Travail plus "excitant" pour équipe ││
│ │ ││
│ │ Résultat: Bugs poussés à "plus tard" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRESSION BUGS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Plaintes clients et churn ││
│ │ • Volume tickets support ││
│ │ • Dette technique ralentissant développement ││
│ │ • Moral équipe (travailler sur produit cassé) ││
│ │ • Risques sécurité et conformité ││
│ │ ││
│ │ Résultat: "Faillite bugs" si ignoré trop longtemps ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LA SPIRALE MORTELLE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Ignorer bugs → Livrer features → ││
│ │ Plus de bugs apparaissent → Ignorer bugs → ││
│ │ Livrer features plus vite (pression) → ││
│ │ Encore plus bugs → Produit déstabilise → ││
│ │ Features ne peuvent livrer (tout casse) → ││
│ │ Sprint urgence bugs → Équipe épuisée ││
│ │ ││
│ │ Briser cycle requiert allocation intentionnelle ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Stratégies Allocation
Allocation Pourcentage
APPROCHE ALLOCATION FIXE:
┌─────────────────────────────────────────────────────────────┐
│ DIVISION CAPACITÉ SPRINT │
├─────────────────────────────────────────────────────────────┤
│ │
│ MODÈLE: 70/20/10 │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Capacité Sprint: 80 story points ││
│ │ ││
│ │ ┌─────────────────────────────────────────────────┐ ││
│ │ │ FEATURES │ 56 pts │ ││
│ │ │ (Items roadmap, capacités nouvelles) │ 70% │ ││
│ │ ├───────────────────────────────────────┼────────┤ ││
│ │ │ BUGS │ 16 pts │ ││
│ │ │ (Défauts, régressions, qualité) │ 20% │ ││
│ │ ├───────────────────────────────────────┼────────┤ ││
│ │ │ DETTE TECHNIQUE │ 8 pts │ ││
│ │ │ (Refactoring, outillage, upgrades) │ 10% │ ││
│ │ └───────────────────────────────────────┴────────┘ ││
│ │ ││
│ │ DANS GITSCRUM: ││
│ │ • Utiliser labels: type/feature, type/bug, type/tech ││
│ │ • Filtrer par labels pour vérifier allocation ││
│ │ • Suivre dans analytics sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AJUSTER SELON ÉTAT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ État │ Features │ Bugs │ Dette Technique ││
│ │ ───────────────┼──────────┼──────┼─────────── ││
│ │ Sain │ 70% │ 20% │ 10% ││
│ │ Backlog bugs │ 60% │ 30% │ 10% ││
│ │ Stabilisation │ 50% │ 40% │ 10% ││
│ │ Crise │ 30% │ 60% │ 10% ││
│ │ Post-crise │ 80% │ 15% │ 5% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Jours/Rotation Bugs
TEMPS DÉDIÉ BUGS:
┌─────────────────────────────────────────────────────────────┐
│ APPROCHES ROTATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ OPTION 1: JOUR BUGS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Chaque vendredi: Jour correction bugs ││
│ │ ││
│ │ Règles: ││
│ │ • Équipe entière travaille sur bugs ││
│ │ • Pas de travail features autorisé ││
│ │ • Triage le matin, corriger toute journée ││
│ │ • Célébrer corrections en fin de journée ││
│ │ ││
│ │ Avantages: ││
│ │ • Temps bugs prévisible ││
│ │ • Pas de changement contexte pendant semaine ││
│ │ • Rituel équipe construit culture ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OPTION 2: ROTATION BUGS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Chaque sprint: Un développeur de garde bugs ││
│ │ ││
│ │ Règles: ││
│ │ • Tourne chaque sprint ││
│ │ • Garde bugs = seulement bugs, pas features ││
│ │ • Gérer bugs critiques immédiatement ││
│ │ • Travailler à travers backlog priorisé ││
│ │ ││
│ │ Avantages: ││
│ │ • Réponse rapide bugs critiques ││
│ │ • Focus dédié (pas d'attention divisée) ││
│ │ • Tous apprennent toutes zones code ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OPTION 3: SPRINT BUGS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Chaque 4ème sprint: Sprint bugs uniquement ││
│ │ ││
│ │ Règles: ││
│ │ • Sprint entier dédié à qualité ││
│ │ • Bugs, dette technique, améliorations tests ││
│ │ • Pas de nouvelles features ││
│ │ ││
│ │ Idéal pour: Équipes avec dette significative accumulée ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Priorisation Bugs
Sévérité et Priorité
CLASSIFICATION BUGS:
┌─────────────────────────────────────────────────────────────┐
│ SÉVÉRITÉ VS PRIORITÉ │
├─────────────────────────────────────────────────────────────┤
│ │
│ SÉVÉRITÉ (Impact du bug): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ S1 - CRITIQUE: ││
│ │ • Perte ou corruption données ││
│ │ • Vulnérabilité sécurité ││
│ │ • Feature complète cassée ││
│ │ • Pas de contournement possible ││
│ │ ││
│ │ S2 - HAUT: ││
│ │ • Feature majeure significativement dégradée ││
│ │ • Contournement existe mais pénible ││
│ │ • Affecte nombreux utilisateurs ││
│ │ ││
│ │ S3 - MOYEN: ││
│ │ • Feature fonctionne mais avec problèmes ││
│ │ • Contournement facile disponible ││
│ │ • Affecte quelques utilisateurs ││
│ │ ││
│ │ S4 - BAS: ││
│ │ • Problèmes cosmétiques ││
│ │ • Cas limites ││
│ │ • Impact utilisateur minimal ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRIORITÉ (Quand corriger): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ P1: Corriger immédiatement (tout lâcher) ││
│ │ P2: Corriger ce sprint ││
│ │ P3: Corriger bientôt (prochains 2-3 sprints) ││
│ │ P4: Corriger éventuellement (backlog) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MAPPING SÉVÉRITÉ → PRIORITÉ: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ │ Nombreux Users │ Quelques Users │ Peu Users ││
│ │ ─────────┼────────────────┼────────────────┼───────── ││
│ │ S1 Crit │ P1 │ P1 │ P2 ││
│ │ S2 Haut │ P1 │ P2 │ P2 ││
│ │ S3 Moy │ P2 │ P3 │ P3 ││
│ │ S4 Bas │ P3 │ P4 │ P4 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Planification Sprint
Sélection Bugs
PLANIFIER POUR BUGS:
┌─────────────────────────────────────────────────────────────┐
│ APPROCHE PLANIFICATION SPRINT │
├─────────────────────────────────────────────────────────────┤
│ │
│ AVANT PLANIFICATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Trier backlog bugs ││
│ │ • Mettre à jour priorités ││
│ │ • Fermer doublons/invalides ││
│ │ • Ajouter estimations effort ││
│ │ ││
│ │ 2. Calculer budget bugs ││
│ │ • Capacité totale × pourcentage bugs ││
│ │ • Exemple: 80 points × 20% = 16 points pour bugs ││
│ │ ││
│ │ 3. Pré-sélectionner candidats ││
│ │ • Bugs P1/P2 (requis) ││
│ │ • Plus vieux bugs P3 ││
│ │ • Bugs liés aux features du sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PENDANT PLANIFICATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Commencer avec bugs requis (P1/P2) ││
│ │ • Non négociables, doivent tenir ││
│ │ • Si trop, escalader problème capacité ││
│ │ ││
│ │ 2. Remplir budget bugs restant ││
│ │ • Choisir parmi candidats P3 ││
│ │ • Considérer: âge, impact client, travail lié ││
│ │ ││
│ │ 3. Planifier features avec capacité restante ││
│ │ ││
│ │ 4. Vérifier équilibre ││
│ │ • Allocation correspond aux pourcentages cibles? ││
│ │ • Ajuster si nécessaire ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘