À propos de la dette technique

Introduction

La notion de dette technique est utilisée avec plus ou moins de réussite au sein des projets.

Elle a été introduite par Ward Cunningham en 1992 notamment dans le but de pouvoir mieux dialoguer avec des décideurs non techniques. Dans cette vidéo de 2011, il explique rétrospectivement sa démarche et il est intéressant de remarquer qu’il évoluait alors dans un contexte financier, favorisant probablement son inspiration pour l’usage de cette métaphore. Elle est censée aider la ou les équipe(s) à avoir conscience et prioriser des travaux liés à des perfections techniques nécessaires ou souhaitables. Le terme de « dette » a été adopté et considéré confortable notamment pour son analogie naturelle avec le risque ; cependant il ne faudrait pas tomber dans le piège de la simplicité, cette analogie a ses limites.

Une caractéristique importante de la notion de dette est la conscience qu’on a du risque induit. Dans notre relation avec l’argent, nous nous endettons consciemment de manière à accélérer des projets (achat de voiture, de maison, …). Plus on a de dettes, plus on a de pression et plus on court de risques, logique.

En informatique, il arrive de réaliser des raccourcis consciemment, pour livrer plus vite, et on sait alors que le code devra être revu. Cependant on peut générer de la dette involontairement, le temps qui passe et les technologies qui évoluent peuvent en induire également. En conséquence nous n’avons pas toujours conscience de ce que nous appelons « notre dette technique », le PO certainement encore moins que l’équipe. C’est là une différence fondamentale qu’il faut prendre en compte dans la gestion de ce type bien particulier de « dette ». Dans certains cas, il faudra commencer par la découvrir.

De quelle dette parlons-nous ?

La dette technique peut aussi bien porter sur de l’infra que sur du code ou bien sur des choix quasi-philosophiques : refactoring, retard sur un des environnements, composant à décommissionner, montée de version à effectuer, techno à choisir… Elle peut aussi être utilisée pour pointer sur des manques liés à l’outillage. Après tout, ne pas travailler avec les bons outils peut être une forme de dette, non ? Ou plutôt un investissement nécessaire ? Le vocabulaire importe finalement peu, il y a quelque chose à faire, et le terme utilisé aujourd’hui dans la plupart des équipes est « dette ». Parfois il crée de la confusion, et pourrait à mon avis être renforcé par la bonne vieille maintenance prédictive.

Quel que soit le choix du ou des outils, il faut avoir à l’esprit qu’il faut à minima stimuler et même ritualiser des discussions sur ce sujet. Une excellente communication et collaboration au sein de l’équipe est absolument nécessaire pour avoir une bonne connaissance de ce que l’équipe considère comme « sa dette ».

À qui profite le remboursement ?

Tordons immédiatement le cou à un débat qui existe parfois : oui, toute curation de dette technique vise à finalement profiter aux utilisateurs finaux. Mais ce sera souvent indirectement et de manière non visible. Ce sont les risques sur la qualité du produit, la qualité du code et la vélocité de l’équipe qui sont en jeu, et le PO aura bien du mal à identifier et formaliser ces besoins et ces risques. La clé réside au sein de l’équipe de développement, qui a une vision quotidienne et approfondie d’une bonne partie du système*.

Certains équipiers semblent espérer voir arriver comme par magie des stories destinées à curer cette dette :

Cela n’arrive bien sûr quasiment jamais, et heureusement quand on voit à quel point cette expression de besoin pourrait être tordue venant d’un PO contraint.

Comment se représenter sa dette, et la rendre visible ?

Quelques éléments de contexte très généraux pour rappeler le cadre dans lequel nous sommes : des équipes cherchent à construire des systèmes qualitatifs qui répondent à des besoins d’utilisateurs – qualité tant fonctionnelle que technique. Pour représenter les utilisateurs et formaliser leurs besoins, nous avons un PO qui est désigné. Au moment d’embarquer une story dans un sprint, on ne considère que les stories qui respectent bien les critères définis dans la DOR (Definition Of Ready), sans rentrer dans les détails de l’implémentation technique.

J’ai déjà vu le critère suivant dans certaines DOR :

Cette règle présente bien sûr un intérêt, mais la garantie offerte est trop belle : qui aujourd’hui pourrait défendre la thèse qu’une équipe peut être garante de la non-genèse de dette technique ?

Il n’y a pas de débat, un système présente des faiblesses. Comme le système est vivant, ces faiblesses varient avec le temps, et ne font que s’accumuler si on ne fait rien contre. Logique.

Des quadrants utilisés pour prioriser et préconiser

Afin de catégoriser les différents types de dette et d’anticiper les discussions liées à la priorisation, il y a bien entendu plusieurs possibilités, dont classiquement l’utilisation d’un des trois quadrants mentionnés ci-dessous :

Quadrant 1 : degré de conscience et degré d’insouciance

Décrit dans cet article de Martin Fowler et à priori utilisé depuis des années chez Google, le quadrant qui suit est une matrice éprouvée pour classer les différentes dettes.

Les deux axes permettent de caractériser les éléments en fonction du degré de conscience au moment de la genèse de la dette, ainsi que du degré d’insouciance qui nous pousse à vouloir les traiter (plus la dette est considérée prudente, plus les impacts sur le système et la manière de rembourser sont limpides) :

Dette générée consciemment : choix conscient fait au moment où la story a été embarquée

• Prudente : choix réfléchi et assumé qui sera à traiter, comme prévu
• Insouciante : des raccourcis ont été volontairement pris sur la conception sans analyse d’impact détaillée

Dette générée inconsciemment : découverte faite plus ou moins longtemps après la genèse

• Prudente : avec le recul, on sait comment on aurait dû faire pour faire mieux, et donc comment on devrait faire
• Insouciante: un spike est peut-être à réaliser pour traiter un doute ou une suspicion (un spike est utilisé pour mener des travaux d’étude, d’exploration technique d’un élément du backlog)

Quadrant 2 : complexité (effort à fournir) et impact

Mon avis : le terme impact est certes un brin subjectif, cependant les discussions engendrées ont un intérêt pour toute l’équipe.

Quadrant 3 : importance et urgence (matrice d’Eisenhower)

Il est intéressant de constater que tous ces quadrants sont orientés priorisation, presque sous forme de préconisation. Il n’est pas question de la nature de la dette ou de l’impact sur l’utilisateur final.

Avoir un tel quadrant présentant une vue globale sur la dette formalisée est un confort indiscutable pour le PO et pour l’équipe de développement. Il montre à quel point l’équipe est sérieuse et connaît son système et ses faiblesses. C’est un outil qui permet d’échanger sur le système et les priorités. Il vise à être précieux pour préparer un sprint planning.

Concernant les différentes possibilités pour planifier et rembourser la dette, il y a de nombreux pattern et anti-pattern que nous aborderons dans un prochain article. C’est un sujet trop important pour être survolé, l’usage de point d’effort ou de valeur peut être envisagé ou non, que l’on soit en kanban ou en scrum.

Comment formaliser et prioriser sa dette en équipe ?

Oui mais voilà, ce beau quadrant ne va pas être alimenté par magie, et il va falloir faire des efforts et adopter des automatismes si on veut vouloir la faire rentrer dans les rituels de type sprint planning.

Une bonne relation de confiance entre le PO et l’équipe de développement est bien entendue inévitablement requise.

Uncle Bob a écrit l’article « A mess is not a Technical Debt« : pour éviter les effets de bord du brouillard et réussir à prendre des décisions rationnelles, à commencer au sein de l’équipe de développement, il convient de formaliser cette dette, au moins un minimum, d’une manière ou d’une autre.

Voici une proposition :

• La dette technique est formalisée par l’équipe de développement sous forme de story, exactement comme le fait le PO.
  • Toute personne de l’équipe de dév est susceptible d’initier et de maturer une telle story.
• Un rituel permet à l’équipe de faire un point sur la dette qui est identifiée, et de la classer sur un quadrant :
  • A ce stade, des discussions sur l’implémentation et les solutions pour traiter la dette ont eu lieu : la story est dans un stade avancé que l’on peut assimiler à « Ready » – choix d’implémentation inclu, pour le coup.
• La dette technique est explicitée au PO et on peut discuter de sa priorisation avec transparence.

Ce mode de fonctionnement n’est pas évident à mettre en place, et est particulièrement intéressant dans une équipe scrum, puisqu’on inverse les rôles : ce sont les développeurs qui pitchent des besoins, et ils sont challengés par le PO. Les échanges sont aussi riches que pour des stories écrites par le PO.

Pour la dette technique générée consciemment, est-ce une bonne idée d’attendre avant de formaliser la dette en question ? On peut imaginer une règle de DOR :

Une remarque avant de conclure : il ne faut pas faire la confusion ni même un lien direct entre le traitement de la dette technique et des initiatives d’amélioration continue. De mon expérience la part de la dette assimilable à de l’amélioration continue est bien inférieure à celle qui est critique ou même vitale. C’est cette dernière qui sera naturellement priorisée, et il ne faudra pas tomber dans le piège de croire que l’on s’améliore en continu.

Conclusion

Le plus important me semble être d’avoir des rituels qui permettent à l’équipe de développement de formaliser la dette dont il est question, et d’en faire prendre conscience au PO. La communication est absolument clé pour une bonne gestion de la dette, et on peut la voir comme un pan indépendant du backlog.

Ensuite il existe de multiples méthodes pour s’accorder sur une stratégie de curation de cette dette.

Bien entendu moins il y en a, moins sa gestion est complexe, et certains diront que la clé réside dans la capacité à en limiter la génèse.

Pour finir, deux graphes très simples avec les impacts positifs escomptés sur la vélocité de deux bonnes pratiques (on ne manquera pas de relever la subjectivité des actions en question) : écrire un code de qualité et mettre à jour le code lorsque nécessaire sont des activités bénéfiques (à terme).

Des liens pour aller plus loin

Vidéo où Ward Cunningham explique rétrospectivement l’histoire de la métaphore

Article de Martin Flower sur le sujet du quadrant 1

Article de Uncle Bob sur l’importance d’un système « propre » et d’une vision claire

Article de Henrik Kniberg sur le lien entre un code « sale » et la dette technique

(*) schéma illustrant le « système » mentionné dans cet article :