Métaphores
La dette technique est une métaphore utile, mais ce n'est pas un indicateur. Elle indique vaguement qu'un certain nombre d'évènements qualitatifs sont survenus sur le projet. On ne peut pas réellement compter ce qu'on a accumulé ou retiré de ce sac là.
Imaginez que dans notre équipe, depuis toujours on aime employer l'expression "c'est tiré par les cheveux" (comme cet exemple). On emploie aussi sa forme latinisée : c'est capillotracté ! Un jour, l'équipe, dans un moment de pataphysique, en fait un indicateur : …en considérant un nombre de cheveux, une certaine extensibilité du cheveu, son élasticité, la charge appliquée et la distance… 🤔
La Dette Technique est une grandeur métaphorique qui indique du non-quantifiable. "Volume" est aussi une grandeur métaphorique, mais cette fois-ci appliquée à une autre grandeur très réelle : le nombre total d'octets représentant des informations à conserver pour nos besoins applicatifs.
Comme pseudo-indicateur, la DT est une sorte d'appel à l'action, mais qui reste vague, parce que c'est un faux agrégat. Par comparaison, "volume des données gérées" est un réel agrégat, dont l'évolution déclenche des décisions possibles :
< 10 Go : notre solution de stockage est surdimensionnée → on pourrait faire des économies
> 4 To : on va bientôt manquer d'espace → il faut investir
Au delà de quel seuil la dette technique entraîne t'elle une décision dans votre projet ? Comment avez-vous déterminé ce seuil ?
Qu'est-ce que nous voulons dire, lorsque nous disons "cette solution comporte une dette technique considérable" ?
Que le temps a passé, et que notre état de l'art a perdu de sa cohérence. C'est à dire ?
- une contrainte a changé, qui rend certains de nos procédés caducs, inopérants
- ou bien un objectif a changé, qui rend certains de nos procédés insuffisants ou au contraire superflus
- ou bien certains procédés n'ont plus cours, alors que nos objectifs et nos contraintes n'ont pas changé
- ou bien certains procédés sont en contradiction avec d'autres
- ou bien un peu de tout cela à la fois.
Un projet et son état de l'art sont des affaire incertaines. Avec la pression, la tentation est forte pour tous les acteurs de changer l'état de l'art afin de gagner du temps.
Exemple d'un état de l'art en évolution :
➡️ On utilise [User Story].
🔀 Plot twist : au lieu d'avoir les conversations autour d'un écran, on s'envoie les US par écrit, comme une [Spécification], mais sans les détails (bref, un titre).
🔀 Puisqu'avec notre [Backlog de US] on peut piloter et tracer l'activité de l'équipe, on y mettra aussi les [Tâches Techniques] sous-jacentes à la réalisation. Des [User Story Techniques] en quelque sorte.
🔀 On avait initialement [Refactoring en continu] mais on a négligé cette pratique, et maintenant on doit poser des [Story de Refactoring] sur le backlog.
la dette technique fait une sorte de bilan de cette évolution.
Stay Tuned !