Guide Scrum · Artefacts et pratiques
La dette technique dans Scrum : comment la repérer et la gérer
La dette technique est le coût futur des raccourcis pris aujourd'hui : code bâclé, tests manquants, outils obsolètes. Comme une dette financière, un peu peut être utile, mais non maîtrisée, elle ralentit chaque Sprint.
À retenir
- La dette technique est le coût futur des raccourcis d'aujourd'hui.
- Rendez-la visible dans le Product Backlog.
- Prévenez toute nouvelle dette grâce à une Definition of Done exigeante.
D'où elle vient
- La pression des délais qui conduit à prendre des raccourcis.
- Une Definition of Done trop faible.
- Absence de tests automatisés.
- Des bibliothèques et une infrastructure obsolètes.
- Des connaissances détenues par une seule personne.
- Des exigences qui ont changé après la réalisation de la conception.
Signes d'une dette croissante
- En baisse ou irrégulière vélocité.
- Davantage de défauts qui atteignent les utilisateurs.
- Des modifications simples qui prennent plus de temps.
- Des Developers réticents à toucher certaines parties du code.
La gérer dans Scrum
- Rendez-la visible : ajoutez des éléments de dette au Product Backlog avec une description claire de leur coût.
- Renforcez la Definition of Done afin de ne pas créer de nouvelle dette.
- Réservez de la capacité à chaque Sprint, par exemple une part du travail de l'équipe, pour réduire la dette.
- Refactorez en continu dans le cadre du travail normal.
- Abordez-la lors de la Sprint Review afin que les parties prenantes comprennent l'arbitrage.
Expliquer la dette aux parties prenantes
Présentez la dette en termes business : « Cette partie prend trois fois plus de temps à modifier et provoque la plupart de nos incidents en production. Investir deux Sprints accélérerait tout le travail futur dans ce domaine. »
Modèles gratuits sur ce sujet
Questions fréquentes
Qui décide quand résorber la dette technique ?
Le Product Owner ordonne le backlog, éclairé par les Developers qui expliquent le coût de la dette.
Toute dette technique est-elle mauvaise ?
Non. Une dette délibérée et à court terme pour apprendre rapidement peut être judicieuse, à condition d'être suivie et remboursée.
Qu'est-ce que la dette technique ?
Le coût futur du choix d'une solution rapide ou facile aujourd'hui au lieu d'une meilleure. Elle se traduit par des modifications plus lentes, davantage de défauts et des mises en production plus risquées.
Qui a inventé le terme de dette technique ?
Ward Cunningham a introduit la métaphore de la dette en 1992 pour expliquer aux parties prenantes métier pourquoi le refactoring était nécessaire.
Comment mesurer la dette technique ?
Il n'existe pas de mesure unique. Les équipes s'appuient sur des signaux comme le temps nécessaire pour faire des modifications simples, les taux de défauts, les outils d'analyse de code et la taille des éléments de dette dans le Product Backlog.
La dette technique doit-elle figurer dans le Product Backlog ?
Oui. Rendre la dette visible sous forme d'éléments du Product Backlog permet au Product Owner de la mettre en balance avec les nouvelles fonctionnalités.
Combien de temps une équipe Scrum doit-elle consacrer à la dette technique ?
Il n'y a pas de règle. De nombreuses équipes y réservent une partie de la capacité de chaque Sprint, en l'ajustant selon le degré auquel la dette les ralentit.
Comment la Definition of Done prévient-elle la dette technique ?
Une Definition of Done exigeante, incluant tests, revue de code et documentation, empêche les raccourcis de se retrouver dans l'Increment.
Comment le refactoring réduit-il la dette technique ?
Le refactoring améliore la structure interne du code sans en modifier le comportement. Le pratiquer régulièrement empêche la dette technique de s'accumuler.
La dette technique est-elle uniquement un problème logiciel ?
Le terme vient du logiciel, mais une dette similaire existe ailleurs, comme des processus obsolètes, des connaissances non documentées ou des solutions provisoires dans les contenus et les données.
Comment convaincre les parties prenantes de résorber la dette technique ?
Expliquez-la en termes business, par exemple combien les modifications sont ralenties ou combien d'incidents elle provoque, et montrez le gain attendu de sa résorption lors de la Sprint Review.