4 min lecture • Guide 718 of 877
Gérer la Dette Technique dans les Équipes Agile
La dette technique est inévitable - la laisser croître hors de contrôle ne l'est pas. GitScrum aide les équipes à suivre, prioriser et rembourser la dette technique systématiquement tout en maintenant l'élan de livraison.
Comprendre la Dette Technique
Types de Dette
CATÉGORIES DE DETTE TECHNIQUE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DETTE DÉLIBÉRÉE (Choix tactiques): │
│ "On sait que c'est pas idéal, mais on livre" │
│ • Raccourcis pour deadline │
│ • Décisions MVP │
│ • Solutions temporaires │
│ Risque: Faible si suivie et planifiée │
│ │
│ DETTE ACCIDENTELLE (Lacunes d'apprentissage): │
│ "On savait pas mieux à l'époque" │
│ • Patterns obsolètes │
│ • Mauvaises décisions initiales │
│ • Meilleure approche découverte après │
│ Risque: Moyen, s'accumule silencieusement │
│ │
│ POURRITURE (Entropie): │
│ "Le monde a changé, notre code non" │
│ • Dépendances obsolètes │
│ • Intégrations legacy │
│ • APIs dépréciées │
│ Risque: Haut si lié à la sécurité │
│ │
│ CRUFT (Désordre accumulé): │
│ "Ça a grandi avec le temps" │
│ • Code mort │
│ • Code dupliqué │
│ • Patterns incohérents │
│ Risque: Moyen, ralentit le développement │
└─────────────────────────────────────────────────────────────┘
Symptômes de Dette
SIGNES DE DETTE TECHNIQUE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EXPÉRIENCE DÉVELOPPEUR: │
│ • "Les changements simples prennent une éternité" │
│ • "J'ai peur de toucher ce code" │
│ • "On doit contourner ça" │
│ • "Personne ne sait comment ça marche" │
│ • "Les tests sont flaky/lents/manquants" │
│ │
│ IMPACT VÉLOCITÉ: │
│ • Features prennent plus longtemps que prévu │
│ • Bugs apparaissent dans des zones non liées │
│ • Onboarding prend trop longtemps │
│ • Mêmes problèmes récurrents │
│ │
│ INTÉRÊTS DE LA DETTE: │
│ Comme la dette financière, la dette tech compose: │
│ │
│ Année 1: Feature prend 1 semaine │
│ Année 2: Feature prend 2 semaines (dette) │
│ Année 3: Feature prend 3 semaines (plus de dette) │
│ │
│ Éventuellement: "Ce serait plus rapide de réécrire" │
└─────────────────────────────────────────────────────────────┘
Gestion de la Dette
Inventaire de Dette
BACKLOG DETTE TECHNIQUE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ID │ Description │ Zone │ Impact │ Effort │
│──────┼───────────────────────┼─────────┼────────┼────────│
│ DT-1 │ Système auth sur │ Auth │ Haut │ Grand │
│ │ lib dépréciée │ │ │ │
│──────┼───────────────────────┼─────────┼────────┼────────│
│ DT-2 │ Pas de tests module │ Paiement│ Haut │ Moyen │
│ │ paiement │ │ │ │
│──────┼───────────────────────┼─────────┼────────┼────────│
│ DT-3 │ Logique validation │ Users │ Moyen │ Petit │
│ │ utilisateur dupliquée │ │ │ │
│──────┼───────────────────────┼─────────┼────────┼────────│
│ DT-4 │ Valeurs config │ Global │ Bas │ Petit │
│ │ codées en dur │ │ │ │
│ │
│ SCORING DETTE: │
│ Impact × Fréquence Changement Zone = Priorité │
│ │
│ DT-2 score le plus haut: │
│ Impact haut + Zone paiement change fréquemment │
└─────────────────────────────────────────────────────────────┘
Allocation de Capacité
RÉPARTITION CAPACITÉ SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Capacité totale: 40 points │
│ │
│ Nouvelles features: 32 pts (80%) │
│ Remboursement dette: 6 pts (15%) │
│ Bugs/Maintenance: 2 pts (5%) │
│ │
│ RÈGLE: Toujours allouer capacité dette │
│ Ne pas sacrifier dette pour features │
└─────────────────────────────────────────────────────────────┘