Press "Enter" to skip to content

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 :

bliki: TechnicalDebtQuadrant

technical debt tags: There’s been a few posts over the last couple of months about TechnicalDebt that’s raised the…

martinfowler.com

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
Un classique qui vient tout seul à l’esprit

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Top