Cet article sur la dette technique présente de bons points, notamment:
Travailler sur les "questions techniques" fonctionne mieux quand il est motivé par des histoires. La base de code a probablement besoin de travail partout, mais le paiement ne sera reçu que là où le code va être travaillé pour des raisons liées à l'utilisateur. Si aucune histoire ne doit traverser une zone cruelle, y travailler est en grande partie gaspillé.
Par conséquent, je préfère l'approche consistant à prendre des histoires comme d'habitude (mais probablement moins) et à suivre la «règle du scoutisme» consistant à quitter le camping mieux que vous ne l'avez trouvé. En d'autres termes, où que les histoires nous mènent, écrivons plus de tests, refactorisons plus agressivement.
Cette approche présente au moins ces avantages:
- maintient le flux d'histoires "le plus sensé";
- fournit l'aide de tous les talents de l'équipe;
- permet à toute l'équipe d'apprendre à garder le code propre;
- concentre l'amélioration exactement là où elle est nécessaire;
- ne gaspille pas les améliorations qui "peuvent" être nécessaires;
J'ai vu que la qualité du code a un très grand effet sur la productivité à long terme, donc je suis convaincu que la dette technique devrait être prise en charge. Je pense que le post ci-dessus est logique, mais je ne suis pas sûr des deux derniers points. Je suis intéressé à découvrir des expériences réelles des avantages du nettoyage de la dette technique, même si cela n'était pas lié aux user stories.
Quels avantages positifs avez-vous constatés en nettoyant votre base de code et en vous débarrassant de vos dettes techniques? Quelles méthodes avez-vous utilisées pour faire le travail?