[Total : 0    Moyenne : 0/5]

La dette technique est une analogie aux prêts bancaires pour représenter le fait qu’au plus nous générons de non qualité au cours d’un projet, au plus les coûts de reprise seront importants.

Introduction

L’expression « Dette Technique » est une métaphore créée par Ward Cunningham, l’un des signataires du manifeste Agile en faisant l’analogie avec les prêts bancaires :

Un emprunt se compose du capital que nous avons emprunté et des intérêts associés. Nos mensualités servent à rembourser d’une part le capital et d’autre part les intérêts. Tout l’enjeu étant bien entendu de rembourser le plus rapidement le capital pour réduire les intérêts.

En faisant l’analogie avec le développement de projet, le capital représente la valeur ajoutée, et les intérêts représentent les différentes reprises pour corriger les problèmes ou l’augmentation de la maintenance pour résoudre les pannes. Ces intérêts sont ce que Ward Cunningham appelle la dette technique.

La notion de dette technique

Dans un contexte où l’on souhaite toujours aller plus vite et où l’on doit livrer au plus tôt, les équipes sont parfois tentées de prendre des décisions leur permettant d’accélérer les processus en effectuant des entorses aux bonnes pratiques, créant ainsi une « dette ». Ces déviations temporaires, les équipes devront les corriger. Mais, du fait que ces entorses ne soient pas visibles par le client, c’est alors aux équipes de les gérer et les traiter. C’est la somme de ces entorses que l’on appelle la dette technique. 2 définitions d’auteurs connus :

  • Selon J. Shore : La dette technique est la somme totale des imperfections.
  • Selon T. Poppendieck : La dette technique est tout ce qui rend le code plus complexe à changer.

Exemple :

Une équipe de développement est en retard. Pour aller plus vite, au lieu de développer du code spécifique et « léger », l’équipe choisi de faire un copier-coller d’un code d’un autre programme qui correspond, mais dont l’on sait qu’il sera plus difficilement maintenable. On contracte ainsi une dette technique que l’on va “rembourser” tout au long de la vie du projet sous forme de temps de travail supplémentaire pour résoudre les bugs.

Manager la dette technique

Accumuler de la dette n’est en soit pas « grave » si l’on prend bien en compte le fait qu’il faudra y remédier tôt ou tard. Dans le management des projets agiles, la dette technique fait donc partie des indicateurs pour manager les projets. Sur le tableau de bord, nous retrouvons les indicateurs suivants :

  • % Backlog livré : 80%
  • Charge consommée : 150 jours/homme
  • Vélocité : 20 Story Point par Sprint
  • Dette technique : 34 jours/homme

En prenant cet exemple, le manager de projet s’aperçoit qu’il lui faut encore planifier 37,5 jours / homme pour finir de livrer le Backlog et 34 jours pour traiter la dette technique, soit au total 71,5 jours / homme.

Les types de dette technique

L’auteur Martin Fowler propose une classification des différents types de dette technique. Cette grille nous aide à définir les ressources nécessaires et nous guide dans les choix que nous devons faire pendant le projet.

Les ordonnées : Volontaire vs Involontaire

Un premier axe est représentatif de notre niveau d’intentionnalité dans notre choix de la dette. La plupart du temps, nous générons une dette involontaire naturelle dû au fait que nous ne travaillons jamais de manière parfaite et que nous générons des défauts. Le manque de connaissances techniques ou une mauvaise communication au sein d’une équipe en sont les causes les plus répandues.

Mais de l’autre, parfois nous faisons « exprès » de faire un choix générant de la dette.

Les abscisses : Prudent vs Risqué

Le second axe identifie notre niveau de maîtrise de la dette tant dans l’aspect de l’identification de la charge de travail pour la réduire que sur les difficultés à la résoudre. En clair, au moins nous maîtrisons les choix que nous venons de prendre, au plus nous sommes dans une situation à risque.

Réduire la dette technique

On le comprend, l’enjeu est de réduire au maximum la dette technique pour éviter le paiement des « intérêts ». Quelques bonnes pratiques :

Le refactoring

Le refactoring consiste à revoir de manière continue notre travail pour l’améliorer. Il s’agit de revoir en permanence le travail effectué pour le standardiser avec ce que nous connaissons le mieux (principe du Yokoten), supprimer ce qui au final s’avère inutile… En clair, le rendre le plus léger possible.

Le pair programming

Méthode spécifique au développement de logiciel, cela consiste à développer à deux derrière un seul écran. Souvent décrié au regard du coût engendré, cette pratique possède de nombreux avantages : augmentation de la qualité du travail, réduction des coûts de reprise et de maintenance.

On recommande d’utiliser cette méthode pour les développements complexes et en faisant des paires Junior/Senior pour favoriser le partage des savoirs.

La revue de conception

Cette pratique consiste à échanger, discuter et confronter les différents choix de conception avec l’équipe au complet. L’enjeu étant de ce challenger les uns les autres pour savoir si nous avons fait les meilleurs choix.

Source

M. Fowler (2009) – Technical debt

K. Brown (2010) – Paying back technical debt

S. McConnell (2007) – Technical Debt

Share This