Press "Enter" to skip to content

Recenser et suivre la dette technique

Recenser et suivre la dette technique

Quelques formats de visualisation

Ah ! La dette technique… On est tous passé par là. Beaucoup d’entre nous, d’ailleurs, n’ont même jamais connu un projet sans legacy et sans la dette technique qui l’accompagne.

Alors comment recenser et suivre cette dette technique ? Je vous propose quelques formats de boards servant à référencer cette dette pour un usage futur.

TL;DR

Choisir comment représenter votre dette technique, ce n’est pas qu’une question de goût. Sa représentation va être liée au process que vous mettez en place pour absorber la dette technique.

Les quadrants de la dette technique

Commençons par un format largement couvert par la communauté. Voici par exemple un article du toujours excellent Martin Fowler, sur ce concept des quadrants de la dette technique :

Voici ce que ça peut donner :

J’ai mal orthographié “quadrant”, mais vous ne m’en voudrez pas !

Un atelier avant tout

Cette représentation est très utile pour mener un atelier d’identification de la dette technique sur un projet existant. Les différents quadrants, sans être prescriptifs, aident la session de brainstorming à trouver les différents types de dette présents sur le projet.

On peut voir sur cet exemple qu’il y a deux types de post-its. Les seconds post-its, oranges et penchés, consistent à essayer de modéliser le coût que représente cette dette (les intérêts que l’on paie régulièrement) et le coût pour la rembourser. Il faut donc se forcer à expliquer en quoi cet élément de dette technique est un problème, et estimer l’effort nécessaire pour s’en débarrasser. Cette démarche va permettre de mettre en place un plan d’action conséquent, qui sera approuvé en dehors de l’équipe technique.

Parler impact business plutôt que technique

Exemples d’analyse d’impact

De mon expérience les équipes ont beaucoup de mal à démarrer ce genre d’exercice qui consiste à parler en termes d’impact business. Alors voici quelques exemples d’analyses d’impact de dette technique :

  • Epée de Damoclès : risque qu’un jour cet élément de build échoue, sans même que l’on s’en rende compte, provoquant des problèmes en prod
  • Temps d’immersion dans le code allongé pour les nouveaux arrivants
  • Les évolutions futures de cette partie du code seront beaucoup plus coûteuses que sur le reste du produit, et les estimations beaucoup moins fiables (mauvaise prédictibilité)
  • Temps perdu à faire à la main la non-régression et/ou risque de régressions plus élevés à cause de tests manuels non-exhaustifs
  • Temps perdu lors des sessions de test manuelles (outil mal fichu/inadapté/pas à jour)

Prioriser le rachat de la dette

Cette démarche est importante, car elle permet justement aux non-techniques de comprendre les enjeux, et donc de les prioriser. On ne peut pas demander à un PO de prioriser des sujets purement techniques s’il ne les comprend pas. Par contre si on lui explique les enjeux, et donc les impacts sur le business, il en devient capable et sera même le premier porteur.

Prioriser intelligemment le rachat de la dette

Mais en plus, il ne s’agit pas simplement de convaincre qu’il faut racheter la dette. Il s’agit de la racheter intelligemment. Typiquement les risques sont souvent contextuels, par exemple pour la formation des nouveaux arrivants, ou lorsqu’on modifie un module spécifique du projet. On peut donc délibérément laisser de côté des éléments de dette technique qui ne nous impactent que peu pour le moment, ou à l’inverse s’occuper en priorité de la dette technique qui va nous gêner pour les prochains sujets à venir.

Suivi au quotidien bof-bof

Par contre, le suivi au quotidien de ces quadrants de la dette technique n’est pas terrible. C’est un très bon exercice pour recenser la dette technique, mais pas pour la garder visible et dans la tête de chacun.

  • Quand on découvre un nouvel élément de dette technique, en général on ne sait pas trop où le placer par rapport aux différents quadrants, et en même temps cette classification n’apporte pas de valeur
  • Quand on va réfléchir en planning ou en refinement on ne va pas naturellement penser à tenir compte de ces éléments de dette technique

Analyse coût vs. risque

Le second format que je vous propose, est très simple.

On place le post-it de dette technique en fonction d’une analyse du coût de la correction par rapport au risque que comporte la non-correction :

  • En ordonnée, le niveau de risque, de gravité et d’impacts que représente cette dette technique
  • En abscisses, le coût que représente le rachat de cet élément de dette technique
J’ai mal orthographié “quadrant”, mais vous ne m’en voudrez pas !

Sans avoir besoin de comprendre les tenants et les aboutissants, il est plutôt simple de déterminer ce qu’il faut corriger en premier : les éléments à risque élevé mais coûtant peu cher à racheter.

Pour la priorisation d’un temps récurrent dédié au rachat de la dette

Le format précédent était adapté à une sensibilisation des non-techniques aux implications des différents éléments de dette technique, leur permettant ainsi de les prioriser. Il n’en est pas sujet ici. On est capable de faire une priorisation par rapport aux placements relatifs des différents post-its, mais on ne va pas pouvoir faire de choix éclairé tenant compte du contexte actuel et toujours changeant.

Au final, c’est donc un outil qui servira à l’équipe de développement pour faire sa propre priorisation de rachat de dette technique. Sous-entendu par là, le cas où ils arrivent à dégager du temps à y consacrer mais ce temps n’est pas explicitement marqué à la correction d’un élément de dette technique en particulier. Toute cette partie-là est opaque.

Diagramme d’architecture du produit

Une chose que l’on veut faire : penser lorsqu’on est en planning ou en refinement aux éléments de dette techniques qui vont impacter la solution technique, le macro-chiffrage, les tâches techniques. Les deux précédents formats n’aident pas vraiment en ce sens, et c’est ce que propose ce troisième format.

On fait un dessin géant du diagramme d’architecture du produit, modélisant les différents composants du produit. Et on positionne les post-its de dette technique sur les composants qui sont impactés par cette dernière.

J’ai mal orthographié “quadrant”, mais vous ne m’en voudrez pas !

Démarche de rachat au fil de l’eau, et la “boy-scout rule”

L’enjeu ici n’est donc pas tant que planifier et prioriser le rachat de la dette technique, mais plutôt d’en tenir compte au fur-et-à-mesure du projet et à la racheter petit à petit quand on touche au code impacté.

C’est le principe de la boy-scout rule :

Toujours laisser un endroit dans un état meilleur que celui où vous l’avez trouvé.

Quand on va modifier du code, on va le nettoyer au passage. Ce sera donc le moment idéal pour corriger divers éléments de dette technique.

Par contre, cette règle ne va pas suffire pour addresser les gros chantiers. Dans ces cas-là, rien ne remplace l’analyse d’impact pour l’expliciter aux non-techniques.

Et ça sert aussi de doc

Effet secondaire de ce genre de tableau, il affiche en gros un diagramme d’architecture du produit. C’est toujours un plus appréciable, quand on en explique son fonctionnement.

Conclusion

Vous pouvez représenter votre dette technique de plusieurs manières différentes. Cependant, cette représentation va influer, voire définir comment vous prenez en charge la correction de la dette technique.

Ainsi les trois modèles présentés sont plus ou moins adaptés selon votre profil et volume de dette technique, mais aussi selon comment vous gérez votre backlog produit.

Expérimentez !

Vous avez aimé cet article ? Cliquez sur le cœur pour m’encourager !

Et abonnez-vous à moi via le bouton Follow pour être notifié de mes nouveaux articles. J’en rédige au moins un par semaine.

Top