11 min lecture • Guide 748 of 877
Implémentation d'une Politique Zéro Bug
Une politique zéro bug signifie corriger les bugs dès leur apparition, pas les accumuler. GitScrum aide les équipes à suivre et prioriser les bugs efficacement pour maintenir un backlog propre.
Philosophie Zéro Bug
Ce que Signifie Zéro Bug
POLITIQUE ZÉRO BUG DÉFINIE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ZÉRO BUG SIGNIFIE: │
│ │
│ ✅ Bugs corrigés quand trouvés, pas plus tard │
│ ✅ Backlog bugs reste à ou près de zéro │
│ ✅ Qualité est une constante, pas une phase │
│ ✅ Tout le monde possède la qualité │
│ ✅ "Faillite bugs" jamais nécessaire │
│ │
│ ZÉRO BUG NE SIGNIFIE PAS: │
│ │
│ ❌ Aucun bug jamais │
│ ❌ Ne jamais livrer avant parfait │
│ ❌ Arrêter travail features pour bugs │
│ ❌ Tout est également urgent │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ L'ALTERNATIVE (Accumulation Bugs): │
│ │
│ Semaine 1: 5 bugs, on corrigera plus tard │
│ Semaine 2: 12 bugs, on corrigera plus tard │
│ Semaine 4: 35 bugs, ça devient préoccupant │
│ Semaine 8: 78 bugs, "on a besoin d'une semaine bugs" │
│ Semaine 12: 150 bugs, impossible de trouver les importants│
│ → Faillite bugs: fermer tous vieux bugs, recommencer │
│ │
│ APPROCHE ZÉRO BUG: │
│ │
│ Semaine 1: 5 bugs, corrigé 5 bugs │
│ Semaine 2: 7 bugs, corrigé 7 bugs │
│ Semaine 4: 4 bugs, corrigé 4 bugs │
│ → Durable, prévisible, propre │
└─────────────────────────────────────────────────────────────┘
Pourquoi Zéro Bug Fonctionne
BÉNÉFICES POLITIQUE ZÉRO BUG:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUALITÉ: │
│ • Bugs corrigés quand frais (plus facile) │
│ • Problèmes qualité composés évités │
│ • Utilisateurs expérimentent moins de problèmes │
│ │
│ PRODUCTIVITÉ: │
│ • Pas de réunions triage bugs │
│ • Pas de "semaines bugs" perturbant roadmap │
│ • Contexte frais lors correction │
│ • Moins de temps à gérer backlog bugs │
│ │
│ PRÉVISIBILITÉ: │
│ • Capacité pour bugs connue │
│ • Roadmap pas déraillée │
│ • Rythme soutenable maintenu │
│ │
│ MORAL: │
│ • Fierté du produit qualité │
│ • Moins de firefighting │
│ • Codebase propre pour travailler │
│ │
│ CONFIANCE CLIENT: │
│ • Problèmes traités rapidement │
│ • Moins de plaintes récurrentes │
│ • Produit semble fiable │
│ │
│ LE CALCUL: │
│ Corriger bug aujourd'hui: 1 heure │
│ Corriger même bug dans 3 mois: 4+ heures │
│ (Contexte perdu, code changé, plus de risque régression) │
└─────────────────────────────────────────────────────────────┘
Implémentation
Processus Triage Bugs
TRIAGE STRICT BUGS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CHAQUE BUG REÇOIT L'UN DE TROIS RÉSULTATS: │
│ │
│ 1. CORRIGER MAINTENANT (Ce sprint) │
│ • Vrai bug │
│ • Affecte utilisateurs │
│ • Reproduction claire │
│ → Corriger immédiatement │
│ │
│ 2. PAS UN BUG │
│ • En fait une demande fonctionnalité │
│ • Fonctionne comme conçu │
│ • Cas limite accepté │
│ → Fermer et expliquer, ou convertir en feature │
│ │
│ 3. CORRIGER SI RAPIDE (< 30 min) │
│ • Problème très mineur │
│ • Correction facile │
│ • Vaut la correction mais pas urgent │
│ → Corriger dans contexte actuel ou fermer │
│ │
│ IL N'Y A PAS DE PILE "CORRIGER PLUS TARD" │
│ │
│ QUESTIONS TRIAGE: │
│ │
│ 1. Est-ce vraiment cassé ? │
│ Non → Fermer comme "fonctionne comme conçu" │
│ │
│ 2. Cela affecte-t-il de vrais utilisateurs ? │
│ Non → Fermer comme won't fix │
│ │
│ 3. Peut-on le reproduire ? │
│ Non → Demander plus d'infos ou fermer │
│ │
│ 4. Ça vaut la correction ? │
│ Oui → Corriger maintenant │
│ Non → Fermer │
└─────────────────────────────────────────────────────────────┘
Allocation Sprint
CAPACITÉ POUR BUGS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ALLOCATION CAPACITÉ SPRINT: │
│ │
│ [████████████████████████░░░░░░░░░░░░░░] │
│ │ Features 65% │Bugs 15%│Tech 10%│Buffer 10%│ │
│ ↑ │
│ Capacité bugs dédiée │
│ │
│ COMMENT ÇA MARCHE: │
│ │
│ 1. Réserver 15% du sprint pour bugs │
│ 2. Corriger bugs quand ils arrivent │
│ 3. Si capacité dépassée, pause travail features │
│ 4. Si sous capacité, utiliser pour autre travail │
│ │
│ EXEMPLE (sprint 40 points): │
│ │
│ Features: 26 points │
│ Bugs: 6 points réservés │
│ Dette tech: 4 points │
│ Buffer: 4 points │
│ │
│ SI BUGS DÉPASSENT ALLOCATION: │
│ │
│ • D'abord, utiliser buffer │
│ • Puis, réduire scope features │
│ • Investiguer cause racine │
│ • Considérer initiatives amélioration qualité │
│ │
│ SUIVI: │
│ Si capacité bugs constamment dépassée: │
│ → Problème qualité en amont │
│ → Besoin plus de tests, meilleures pratiques │
└─────────────────────────────────────────────────────────────┘
Workflow Bug Quotidien
GÉRER BUGS QUOTIDIENNEMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MATIN: │
│ 1. Revoir nouveaux bugs (5 min) │
│ 2. Trier chacun (corriger/fermer/quick-fix) │
│ 3. Ajouter au sprint si correction │
│ │
│ PENDANT JOURNÉE: │
│ 1. Prendre bug quand contexte permet │
│ 2. Le corriger │
│ 3. Tester correction │
│ 4. Déployer │
│ 5. Déplacer vers terminé │
│ │
│ FIN DE JOURNÉE: │
│ Compte bugs devrait être: 0 ou proche de 0 │
│ │
│ ═══════════════════════════════════════════════════════════│
│ │
│ BOARD BUGS GITSCRUM: │
│ │
│ Reporté Trié En Cours Corrigé │
│ ───────── ──────── ─────────── ────── │
│ [BUG-1] [BUG-2] [BUG-3] [BUG-4] │
│ [BUG-5] [BUG-6] │
│ [BUG-7] │
│ │
│ MÉTRIQUES: │
│ • Bugs dans Reporté: 0 (trier immédiatement) │
│ • Bugs dans Trié: < 3 (corriger bientôt) │
│ • Bugs En Cours: 1-2 (corrections actives) │
│ • Temps dans système: < 2 jours typique │
└─────────────────────────────────────────────────────────────┘
Gérer Cas Limites
Qu'est-ce Vraiment un Bug ?
BUG VS PAS-UN-BUG:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✅ VRAI BUG: │
│ │
│ • Feature marchait avant, maintenant cassée │
│ • Comportement diffère de documenté │
│ • Corruption ou perte données │
│ • Vulnérabilité sécurité │
│ • Crash ou erreur qui ne devrait pas arriver │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ PAS UN BUG (Demande Feature): │
│ │
│ "Le bouton devrait être bleu, pas vert" │
│ → Préférence design, pas bug │
│ │
│ "Je veux exporter vers Excel, pas seulement CSV" │
│ → Nouvelle fonctionnalité │
│ │
│ "C'est confus à utiliser" │
│ → Amélioration UX │
│ │
│ "C'est trop lent" │
│ → Amélioration performance (sauf si spec cassée) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ZONE GRISE - UTILISER JUGEMENT: │
│ │
│ "Le format date est faux pour mon pays" │
│ → Bug si on prétend supporter cette locale │
│ → Feature si on ne supporte pas encore │
│ │
│ "La recherche ne trouve pas correspondances partielles" │
│ → Bug si documentation dit que devrait │
│ → Feature si jamais prétendu marcher ainsi │
└─────────────────────────────────────────────────────────────┘
Décisions Sévérité
CLASSIFICATION SÉVÉRITÉ BUGS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CRITIQUE (Corriger immédiatement): │
│ • Production down │
│ • Perte données possible │
│ • Brèche sécurité │
│ • Feature majeure complètement cassée │
│ → Arrêter autre travail, corriger maintenant │
│ │
│ HAUTE (Corriger ce sprint): │
│ • Feature cassée pour beaucoup utilisateurs │
│ • Workaround significatif requis │
│ • Affecte fonctionnalité core │
│ → Corriger sous quelques jours │
│ │
│ MOYENNE (Corriger dans sprint): │
│ • Feature partiellement cassée │
│ • Workaround existe │
│ • Affecte certains utilisateurs │
│ → Corriger dans le sprint │
│ │
│ BASSE (Quick fix ou fermer): │
│ • Inconvénient mineur │
│ • Workaround facile │
│ • Cas limite │
│ → Corriger si < 30 min, sinon fermer │
│ │
│ RÈGLE ZÉRO BUG: │
│ Aucun bug reste non trié > 1 jour │
│ Aucun bug trié non corrigé > 1 sprint │
│ Sévérité basse soit corrigé vite soit fermé │
└─────────────────────────────────────────────────────────────┘
Mesurer le Succès
Métriques Bugs
MÉTRIQUES ZÉRO BUG:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MÉTRIQUES CLÉS: │
│ │
│ COMPTE BUGS OUVERTS: │
│ Cible: 0-5 │
│ Actuel: 3 ✅ │
│ Tendance: ↓ Décroissante │
│ │
│ TEMPS RÉSOLUTION BUG: │
│ Cible: < 2 jours │
│ Actuel: 1.2 jours moy ✅ │
│ │
│ BUGS CRÉÉS VS RÉSOLUS: │
│ Ce sprint: 8 créés, 9 résolus ✅ │
│ (Résoudre plus que créer = sain) │
│ │
│ TAUX D'ÉCHAPPEMENT: │
│ Bugs trouvés en production vs en test │
│ Cible: < 20% taux échappement │
│ Actuel: 15% ✅ │
│ │
│ UTILISATION CAPACITÉ BUGS: │
│ Allouée: 6 points │
│ Utilisée: 5 points ✅ │
│ (Sous budget = bonne qualité amont) │
│ │
│ DASHBOARD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Santé Bugs: 🟢 SAINE ││
│ │ ││
│ │ Bugs ouverts: 3 ││
│ │ Âge moyen: 1.2 jours ││
│ │ Plus ancien: 3 jours (en correction) ││
│ │ Créés cette semaine: 8 ││
│ │ Résolus cette semaine: 9 ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Changement Culturel
Adhésion Équipe
ADOPTER CULTURE ZÉRO BUG:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRÉOCCUPATIONS COMMUNES: │
│ │
│ "On n'a pas le temps de corriger chaque bug" │
│ → Vous n'avez pas le temps de NE PAS le faire. │
│ La dette bug est coûteuse. │
│ │
│ "Et tous nos bugs existants ?" │
│ → Faillite bugs: fermer tous > 90 jours, recommencer │
│ │
│ "Certains bugs ne valent pas d'être corrigés" │
│ → Alors fermez-les. Ne les laissez pas ouverts. │
│ │
│ "Mais la roadmap..." │
│ → Réservez capacité. Qualité permet vélocité. │
│ │
│ OBTENIR ADHÉSION: │
│ │
│ 1. Montrer coût dette bugs │
│ 2. Commencer avec expérience un sprint │
│ 3. Mesurer avant et après │
│ 4. Partager résultats │
│ │
│ FAIRE TENIR: │
│ │
│ • Triage bugs quotidien (faire une habitude) │
│ • Compte bugs visible sur dashboard │
│ • Célébrer sprints zéro-bug │
│ • Investiguer quand bugs pic │
│ • Tout le monde possède qualité, pas seulement QA │
└─────────────────────────────────────────────────────────────┘