Dette technique

La dette technique est une expression qui a été créée en 1992 par Ward Cunningham. Ce nom vous dit quelque chose ? En effet c’est l’un des 17 créateurs du manifeste agile en 2001 et le créateur du concept du wiki.

Qu’est-ce que la dette technique ?

Ce terme définit tout ce qui n’est pas de la conception initiale et inutilisé dans le code informatique ; cela peut être intentionnel ou non.

Voici des éléments considérés comme de la dette technique :

• des bugs
• des parties de code devenues obsolète
• un code qui ne va pas à l’essentiel
• non respect des normes de codage

Rappelons que ce terme est en réalité un terme associé à l’Extreme Programming. Pour ceux qui ne le savent pas, ce framework impose le développement incrémental avec la technique du TDD ; et donc nous pouvons supposer que tout le code qui ne va pas à l’essentiel est considéré comme une dette technique.

En effet, tout code alourdit n’amènera qu’à une plus grande difficulté de compréhension du code dans le futur. La dette technique ne se concentre pas seulement sur les bugs.

Pourquoi l’éviter ou la limiter ?

La dette technique devient rapidement une perte de temps phénoménale pour les équipes. Plus grave encore, elle participe aussi à l’augmentation de la dette émotionnelle de l’équipe.

L’Extreme Programming propose un framework qui a pour but de ne pas avoir de dette technique. Si cela peut paraitre utopique, le framework propose en effet de nombreuses pratiques pouvant la limiter au maximum : TDD, pair programming, BDD..

L’objectif dans un projet informatique est donc de la diminuer au maximum pour éviter les conséquences futures non négligeables :

• perte de temps à chercher à corriger des bugs
• difficulté d’intégration dans le code des nouveaux développeurs
• moins de temps consacré à rajouter de la valeur sur le produit

Scrum et la dette technique

Bien que le scrum guide rappelle l’importance de l’excellence technique, il ne dit pas comment faire ; en effet, scrum est un cadre léger. Et si certaines équipes y arrivent avec brio, c’est pas le cas de toutes les équipes scrum.

En analysant les équipes de développement qui tentent réellement d’avoir une très haute excellence qualité, on s’aperçoit qu’elles piochent la plupart de ses pratiques au sein de l’Extreme Programming. N’oublions pas que Scrum est appliqué dans 99% des cas sur des équipes où la programmation est le coeur du produit.

Mais pour les autres équipes scrum, la dette technique est malheureusement au rendez-vous… Et cela peut-être même pire qu’avec des méthodes plus traditionnelles.

L’aspect « backlog dynamique » et le travail en petits lots peut amener certaines équipes à avoir une dette technique très importante. Il n’est pas rare de voir malheureusement des produits qui sont techniquement bien en deçà de l’exigence que nous devrions avoir.  

L’aspect qualité est en mon sens trop souvent sous-estimé dans les équipes agiles. Et cela peut avoir plusieurs sources possibles :

• pression des planning
• désintérêt du management pour la qualité
• équipes techniques ne sachant pas comment faire
• …