Dette technique

Code Design
Dette technique

Quand utiliser et jusqu’où pousser la métaphore de la dette technique en développement logiciel ?

C’est la question que je me propose souvent quand j’accompagne une équipe. Et en général, j’utilise ou invite à trouver d’autres métaphores pour exprimer plus précisément la situation.

Passons-donc en revue quelques stéréotypes de situation qui cachent plus ou moins bien une difficulté de l’ordre d’un endettement collectif et d’un certain déni du risque associé.

Quand on n’en parle pas et que l’on ne la conçoit pas

Bien que tout le monde sache ce qu’est une dette, et que le concept de dette technique soit connu de pratiquement tout développeur, il se peut que l’on n’en parle pas. Cela peut signifier au moins 2 choses :

  • “Pas de ça chez nous, on travaille bien, voilà tout”
  • “Il vaut mieux pas en parler, des fois qu’on nous reproche de mal faire”

Lorsque ce qui se dit n’est pas ce qui se passe dans les fait, que peut-on penser ?

La première intention que j’essaie de partager avec l’équipe est de faire en sorte que tout le monde voit la même chose. La métaphore des savants aveugles et l’éléphant ou du cylindre vu selon différentes perspectives est très efficace, pour inciter à discuter tous ensemble.

Est-ce un problème ? Passe-t-on à côté de quelque chose sans le voir ?

Si non, à quel moment, pour qui et à quelle occasion ça pourrait devenir un problème ?

Quand on n’en parle pas, mais qu’on en pense pas moins

Lorsque l’équipe est afféré à terminer au plus vite toutes les stories du sprint, et que vraisemblablement ça va pas le faire, il s’agit de demander à l’équipe de prendre du recul, de ralentir, voire s’arrêter, pour changer quelque chose.

Bien sûr, on pourrait attendre la rétrospective. Selon que l’équipe ait échoué ou réussi, la question n’aura probablement pas la même portée.

Si l’intention est de finir le plus rapidement possible et coûte que coûte, pour employer une expression à la mode, combien ça va coûter plus tard et à qui ?

Comme métaphores utiles qui se rapprochent de cette situation, vous connaissez probablement l’image de l’invention de la roue ou encore de l’éléphant dans la pièce. Sinon je vous laisse le plaisir de les découvrir.

Quand on parle de dette technique sans la définir

C’est déjà très bien de se prendre soin du code et de s’apercevoir que quelque chose ne va pas, qu’il convient de nettoyer, réparer. Si ce travail n’est pas clairement défini, n’est pas rendu visible cela peut être pour plusieurs raisons, et aussi présage d’une résolution approximative, incomplète, pas à la hauteur du risque.

Aussi il convient de matérialiser la dette par un postit pour commencer, et une conversation pour rendre les choses explicites. Le postit deviendra rapidement une “feature” avec un objectif mesurable pour les semaines à venir et des “stories techniques” qui seront prises dans des sprints au même titre que les stories fonctionnelles à hauteur de la capacité de l’équipe.

Plus vite l’équipe aura amorcé le mouvement, plus vite elle en tirera les bénéfices, et acquéra les habitudes du boyscout.

“Laisser le camp au moins aussi propre que ce qu’on l’a trouvé”.

Quand il n’est plus besoin d’en parler

L’équipe peut avoir adopté le concept, tant et si bien qu’elle en abuse. Après tout, il n’y a rien de mal à prendre des raccourcis, pour livrer plus rapidement au business, du moment que l’on prend le temps de nettoyer entre la démo et le sprint planning. Au pire on fait une “tâche technique”. L’habitude de faire plus vite est légitimée par la tâche technique. Il devient monnaie courante de voir l’équipe déroger aux règles de qualité stricte qu’elle s’était fixée et d’accumuler des tâches techniques.

Vigilance ! Ce n’est pas parce que l’on ne parle plus de dette, ou de remboursement qu’il n’y en a plus. Un ticket Jira n’est pas une dette (même si avoir beaucoup de tickets représente déjà en soi une charge de gestion conséquente, au delà du travail de correction proprement dit)

En tant que Scrum Master, soyez attentif à rendre visible cette dette au plus près de là où elle se trouve en vrai.

Les outils peuvent vous rendre un grand service à l’équipe (et au Scrum Master qui ne voudrait pas passer pour trop critique ou subjectif sur le code qu’il relit) L’outil peut se tromper, mais encore faut-il vérifier…

Quand règles, outils et Scrummaster font suer

Quelle règle d’équipe souhaitez-vous retirer ou revoir ?

La question qui brûle ensuite est celle du “Pourquoi ?” qui renvoie à la cause racine du problème (Les 5 Pourquoi ?)

Hors le fonctionnement logique, binaire qui a tendance à catégoriser les choses en noir ou blanc, bien ou mal, etc… et à tout modéliser en relations de cause à effet, en algorithme, en programme, fait peut être partie du problème. Il existe des situations, où la recherche de problème/solution dans le même registre, empêche de s’en sortir et plus nous nous efforçons à le faire, plus nous avons tendance à penser que “c’est impossible”, que nous nous enfonçons.

Il est peut-être temps d’essayer une approche radicalement différente: Pourquoi ne pas tenter une alternative à la règle, à l’outil, au Scrummaster ? à commencer par faire sans.

Donnons-nous un point de RDV auquel nous pourrons observer ce qui s’est produit en bien, en moins bien pour les personnes potentiellement impactées, lorsque cet élément n’existe pas.

La plupart du temps, nous découvrirons quelques racines non pas problématiques mais des racines de valeur, de ce qui est réellement important pour les parties prenantes.

La difficulté est d’accepter ses propres limites, ses vulnérabilités, en affichant plus clairement ce qui est vraiment important, et en repartant de là pour reconstruire un schéma plus clair de relations viables.

L’exercice de la scierie à pratiques, à pratiquer pour de vrai, peut-être salvateur dans des contextes englués dans le process.

  1. Lister toutes nos règles, pratiques, éléments normatifs, obligations qui structurent notre activité.
  2. Quelles sont les 3 premières que vous coupez, dont vous vous séparez.
  3. dot voting, discussion, itération …
  4. Une fois descendu au top 3, comment pouvons nous nous améliorer sur ces éléments, dans ces pratiques

Eventuellement: 5. Quels sont les nouveaux éléments qui n’existaient pas et que l’on pourrait ajouter ? 6. Si ce nouveau système n’est pas encore satisfaisant, quelles sont le minimum des autres règles que ce soit viable pour l’équipe ?

Mesurer pour diminuer la dette - Outils et alternatives

Maintenant que l’on a quelques éléments pour détecter quelques signes et amener le débat sur la table, comment la mesurer et la diminuer ?

Et que faire si ce n’est pas mesurable, même par le plus sophistiqué et le plus cher des outils ?

  • Faites appel à un mentor ou cador technique sur qui toute l’équipe pourra compter
  • Faites confiance à l’équipe pour hausser son niveau d’exigence de qualité

Un indicateur d’hygiène du développement logiciel

Je propose un board avec 3 grandes zones:

  • sur la gauche, ce que l’on sait qu’il faudrait bien corriger, nettoyer mais que l’on ne fait pas ou pas assez souvent
  • à droite, ce que l’on apprécie de nos comportements habituels vis-à-vis du code
  • au centre une zone des changements à opérer avec 3 catégories:
  1. quelle action pour découvrir d’autre choses à corriger que l’on ne connait pas encore ?
  2. quelle action correctrice de ce que l’on sait déjà ?
  3. quelle action automatisable ou convertible en habitude ?

Qui décide de s’endetter, quand, pourquoi et de combien ?

Dans cet article, j’arrive enfin aux questions de fond, que je peux me poser, mais surtout poser aux membres d’une organisation, lorsqu’ils commencent à prendre conscience d’un problème d’endettement technique.

Ces questions n’ont pas pour objet de contrarier les décisions passées, mais bien pour le présent et le futur, de faire en sorte qu’une certaine transparence soit faite sur les choix et responsabilités à dégrader la qualité, ou à la réhausser.

Et ensuite ?

J’ai déjà donné quelques pistes, outils pratiques utilisables dans certaines situations. Tout ne s’explique pas, ne se décrit pas, encore moins en une page…

Références:

Choisissez le style qui vous permettra le mieux d’évoluer sur la question:

Au sens économique du terme:

  • Le numéro de Socialter consacré à la dette

  • David Graeber, dette, 5000 ans d’histoire

    En ce début février 2021, le débat fait rage au sujet de la dette contractée par les états européens parmi tant d’autres, pour sauver leur économie. La présidente de la banque centrale a dit que l’annulation n’était pas une option…

    La comparaison avec une dette technique qu’il nous aurait été obligé de contracter pour sauver une valeur sociale, puis que nous (du moins ce qui n’ont pas le choix) serions obligé de rembourser sur 10 ou 20 ans n’est pas vraiment réaliste. Quoi que.

Sur les métaphores ou paraboles:

https://amanagrawal.blog/2020/08/28/managing-technical-debt-in-software/