Votre liste de dette technique est écrasante. Tout semble urgent. Les développeurs veulent tout corriger. Le produit veut livrer des fonctionnalités. Personne n'a de cadre pour décider ce qui compte vraiment.
Listez Toute La Dette Connue
Sortez-la des têtes des développeurs dans une liste partagée. Vieux TODOs. Zones fragiles connues. Ce qui vous ralentit. Soyez exhaustif.
Notez Chaque Élément : Impact × Fréquence
Impact : C'est grave quand ça nous mord ? (1-5). Fréquence : Ça nous mord souvent ? (1-5). Multipliez pour un score de priorité approximatif.
Classez En Trois Catégories
Utilisez les scores pour trier, mais ne soyez pas mécanique. Appliquez le jugement.
Corriger
Impact élevé, fréquence élevée. Vous fait activement mal. Planifiez ces éléments. C'est du vrai travail.
Ignorer
Impact faible, fréquence faible. Moche mais inoffensif. Arrêtez de culpabiliser. Passez à autre chose.
Supprimer
Dette attachée à du code inutilisé. Supprimez le code. La dette disparaît avec.
Planifiez Les Corrections
Les éléments à corriger vont dans la roadmap. Allouez un pourcentage de chaque sprint, ou regroupez-les dans un "sprint dette." Rendez-le réel ou ça n'arrivera pas.
Supprimez Les Suppressions
C'est la partie fun. Trouvez le code mort. Supprimez-le. La meilleure façon de corriger la dette est de la faire cesser d'exister.
Archivez Les Ignorés
Déplacez-les dans un doc "dette connue." Vous ne les corrigez pas. Vous ne les oubliez pas. Vous choisissez consciemment de ne pas vous en soucier.
Un backlog de dette priorisé. La permission d'ignorer ce qui n'est pas important. Moins de code (grâce aux suppressions). Et un plan clair pour la dette qui compte vraiment.
Cela fonctionne pour les codebases contenus. Quand la dette est entrelacée avec l'architecture, quand corriger une chose en casse une autre, quand vous devez moderniser tout en livrant : c'est une autre conversation.