La dette technique est l'un des concepts les plus mal utilisés dans le leadership d'ingénierie. Les ingénieurs l'utilisent comme raccourci pour "code dont nous ne sommes pas fiers." Les dirigeants l'entendent comme "des choses que nous nettoierons plus tard." Aucun cadrage ne capture ce qu'est réellement la dette technique : un instrument financier à intérêts composés, libellé en vélocité d'ingénierie, qui facture silencieusement votre organisation à chaque sprint.
Le modèle financier de la dette technique
Comme la dette financière, elle a un principal (l'implémentation sous-optimale) et des intérêts (le coût continu de contourner cette implémentation dans chaque changement futur). Le taux d'intérêt n'est pas fixe. Il se compose.
“Dans notre expérience, les organisations avec une dette technique non gérée significative opèrent à 40-60% de la vélocité d'ingénierie qu'elles auraient avec une base de code propre comparable. C'est un énorme désavantage concurrentiel qui n'apparaît jamais sur un bilan.”
Quantifier l'impact business
La façon la plus utile de quantifier la dette technique pour la direction est de mesurer son effet sur la vélocité de livraison. Commencez par une baseline de vélocité de sprint d'une période avant que la dette soit significative. Comparez-la à la vélocité actuelle du sprint sur un travail de complexité équivalente.
La présenter à la direction
Le cadrage qui fonctionne avec la direction exécutive n'est pas "nous devons refactoriser notre code." C'est "nous payons actuellement une taxe de vélocité de 45% sur chaque sprint d'ingénierie, et voici la feuille de route pour la réduire à moins de 15% au cours des trois prochains trimestres, ce qui se traduit par X fonctionnalités supplémentaires par trimestre."
- Dette architecturale : décisions structurelles fondamentales qui contraignent ce qui peut être construit et à quelle vitesse.
- Dette de tests : couverture de tests insuffisante qui transforme chaque changement en risque inconnu.
- Dette de documentation : connaissances qui vivent dans les têtes humaines, pas dans les systèmes.
- Dette de dépendances : bibliothèques et frameworks obsolètes qui accumulent des vulnérabilités de sécurité.