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.

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 ?

Faire en sorte que tout le monde voit la même chose. Est-ce un problème ? 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 ?

Vous connaissez probablement l’image de l’invention de la roue.

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 ?

5 Pourquoi ?

Si réellement c’est la règle qu’il faut revoir alors nous pourront rechercher les alternatives à la règle, à l’outil ? La plupart du temps, il y aura une cause racine de l’ordre de l’organisation d'é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 ?

Références:

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

  • L’humour décapant d’Arnaud Lemaire
  • La visualisation graphique de Romain Couturier
  • L'écrit précis et l’avis décalé d’Allan Kelly

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.