6 min lecture • Guide 514 of 877
Comment Gérer la Dette Technique avec les Effort Points GitScrum
La dette technique s'accumule silencieusement jusqu'à paralyser la vélocité de livraison. Le système d'effort points de GitScrum permet aux équipes de quantifier les éléments de dette aux côtés du travail de fonctionnalités, rendant le vrai coût visible aux parties prenantes et permettant des décisions basées sur les données concernant quand et quoi rembourser.
Estimation de la Dette Technique
| Type de Dette | Facteurs de Complexité | Points Typiques |
|---|---|---|
| Refactor simple | Fichier unique, bien testé | 1-2 |
| Amélioration module | Multiples fichiers, tests nécessaires | 3-5 |
| Redesign composant | Cross-module, breaking changes | 8-13 |
| Changement architecture | Système entier, migration nécessaire | 13-21+ |
Suivi de la Dette avec Effort Points
INVENTAIRE DETTE TECHNIQUE
┌─────────────────────────────────────────────────┐
│ STRUCTURE BACKLOG DETTE │
│ │
│ Epic: Réduction Dette Technique T1 │
│ │
│ Catégorie: Database (Total: 34 points) │
│ ├── [5 pts] Migrer vers connection pooling │
│ ├── [8 pts] Ajouter index manquants │
│ ├── [13 pts] Refactorer usage ORM │
│ └── [8 pts] Implémenter cache requêtes │
│ │
│ Catégorie: Couche API (Total: 21 points) │
│ ├── [3 pts] Standardiser réponses erreur │
│ ├── [5 pts] Ajouter validation input │
│ ├── [8 pts] Implémenter rate limiting │
│ └── [5 pts] Ajouter versioning API │
│ │
│ Catégorie: Frontend (Total: 26 points) │
│ ├── [8 pts] Remplacer state management legacy │
│ ├── [5 pts] Extraire composants partagés │
│ ├── [8 pts] Ajouter mode strict TypeScript │
│ └── [5 pts] Améliorer bundle splitting │
│ │
│ TOTAL BACKLOG DETTE: 81 points │
└─────────────────────────────────────────────────┘
Allocation Capacité Sprint
PLANIFICATION SPRINT AVEC ALLOCATION DETTE
VÉLOCITÉ ÉQUIPE: 40 points/sprint
┌─────────────────────────────────────────────────┐
│ RÉPARTITION CAPACITÉ: │
│ │
│ Développement Fonctionnalités: 28 pts (70%) │
│ ├── User stories │
│ └── Nouvelles fonctionnalités │
│ │
│ Dette Technique: 8 points (20%) │
│ ├── Refactoring │
│ ├── Améliorations tests │
│ └── MAJ architecture │
│ │
│ Maintenance: 4 points (10%) │
│ ├── Corrections bugs │
│ └── MAJ dépendances │
└─────────────────────────────────────────────────┘
CRITÈRES SÉLECTION DETTE SPRINT:
┌─────────────────────────────────────────────────┐
│ Ordre de priorité: │
│ 1. Dette bloquant fonctionnalités planifiées │
│ 2. Dette causant problèmes production │
│ 3. Dette ralentissant vélocité │
│ 4. Dette avec implications sécurité │
│ 5. Gains rapides (haut impact, bas effort) │
└─────────────────────────────────────────────────┘
Guide d'Estimation Points Dette
ESTIMATION EFFORT POINTS POUR DETTE
1 POINT - Trivial
┌─────────────────────────────────────────────────┐
│ • Renommer pour clarté │
│ • Ajouter vérification null manquante │
│ • MAJ commentaire obsolète │
│ • Corriger code smell simple │
│ Temps: < 2 heures │
└─────────────────────────────────────────────────┘
2-3 POINTS - Simple
┌─────────────────────────────────────────────────┐
│ • Extraire méthode/fonction │
│ • Ajouter tests manquants fonction unique │
│ • Remplacer appel librairie dépréciée │
│ • Corriger duplication code fichier unique │
│ Temps: 2-4 heures │
└─────────────────────────────────────────────────┘
5 POINTS - Moyen
┌─────────────────────────────────────────────────┐
│ • Refactorer classe/module │
│ • Ajouter couverture tests composant │
│ • Remplacer pattern dans multiples fichiers │
│ • Extraire utilitaire partagé │
│ Temps: 1-2 jours │
└─────────────────────────────────────────────────┘
8 POINTS - Large
┌─────────────────────────────────────────────────┐
│ • Refactorer dépendance cross-module │
│ • Remplacer librairie dépréciée │
│ • Ajouter couche cache │
│ • Changement infrastructure test significatif │
│ Temps: 2-4 jours │
└─────────────────────────────────────────────────┘
13 POINTS - Très Large
┌─────────────────────────────────────────────────┐
│ • Redesign architecture composant │
│ • Refonte state management │
│ • Migration schéma database │
│ • MAJ version majeure (framework) │
│ Temps: 1-2 semaines │
└─────────────────────────────────────────────────┘
Dashboard Métriques Dette
SANTÉ DETTE TECHNIQUE
INVENTAIRE DETTE:
┌─────────────────────────────────────────────────┐
│ Backlog dette total: 81 points │
│ Dette critique: 21 points (26%) │
│ Haute priorité: 34 points (42%) │
│ Priorité normale: 26 points (32%) │
└─────────────────────────────────────────────────┘
PROGRÈS SPRINT:
┌─────────────────────────────────────────────────┐
│ Sprint Ajouté Supprimé Changement Net │
│ ───────────────────────────────────────────── │
│ Sprint 14 5 pts 8 pts -3 pts ↓ │
│ Sprint 15 3 pts 10 pts -7 pts ↓ │
│ Sprint 16 8 pts 6 pts +2 pts ↑ │
│ Sprint 17 2 pts 12 pts -10 pts ↓ │
│ ───────────────────────────────────────────── │
│ Trimestre 18 pts 36 pts -18 pts ↓ │
└─────────────────────────────────────────────────┘
IMPACT VÉLOCITÉ:
┌─────────────────────────────────────────────────┐
│ Avant réduction dette: 32 pts/sprint │
│ Après réduction dette: 40 pts/sprint (+25%) │
│ │
│ Investissement dette: 32 pts sur 4 sprints │
│ Gain vélocité: 8 pts × 4 sprints = 32 points │
│ ROI: Déjà positif, continue de croître │
└─────────────────────────────────────────────────┘
Bonnes Pratiques
- Estimer dette comme fonctionnalités avec même échelle points
- Allouer capacité constante (15-25% par sprint)
- Suivre backlog dette séparément mais visiblement
- Prioriser dette par impact sur vélocité et qualité
- Célébrer réduction dette comme réussite équipe
- Mesurer améliorations vélocité du travail dette
- Ajouter contexte aux items dette (pourquoi important)
- Éviter faillite dette par paiements constants
Anti-Patterns
✗ Ne pas estimer items dette
✗ Pas de capacité dette dédiée
✗ Dette seulement "quand on a le temps"
✗ Gros items dette sans découpage
✗ Pas de suivi dette ajoutée vs supprimée
✗ Traiter dette comme travail moindre