5_11_2013 École du tech lead: Conversation autour de la dette technique

École du tech lead: Conversation autour de la dette technique

----

TLDR de Cyrille Deruel @CyrilleDeruel

Les 3 phrases sur la dettes 
- Pas dépuration de la dette sans refactoring et pas de refactoring sans tests automatisés
- Normalement tu n'as pas besoin d'aller chercher la dette, c'est la dette qui te trouve 
- Ta dette tu la gères tous les jours 

Les 3 rituels graduels pour gérer sa dette 
- Code Review obligatoire
- Revue de code collectif
- Dojo de fin d'itération (pour les changements importants)

Les 3 bons réflexes : 
- Règle du boy-scout : l'endroit doit être plus propre quand tu le quittes
- Journée du Jardinage : 1 fois par mois, l'équipe bloque sa journée sur des tâches de désendettement qui n'ont pas été traité sur le mois
- Maintenabilité Check : Est-ce qu'en 5 min je suis capable de comprendre le code et savoir ce qu'il fait ?

Hors catégories 
- La dette technique ce n'est pas que dans le code, c'est aussi l'UDD et hors du code 
- La notion de dette technique doit être partagée par l'équipe de développement et le client 

----

CR au fil de l’eau

Quels indicateurs de dette technique ?
- On ne touche pas sinon ça va casse
- On ne touche pas, il n’y a que X qui connait
- Anomalie dans les chiffrages sur un composant
- Quand on arrive sur un nouveau projet et qu’on récupère du code endeté, sur un client qui a payé moins cher
- Pas de test

À quoi on reconnait du bon code ?
- Code maintenable sur lequel tu peux agir en confiance
- Code refactorable
- Vélocité haute
- Les mêmes user stories devraient couter de moins en moins cher, en cas de dette leur coût augmente

Dans le monde financier une dette c’est pour atteindre un certain objectif (acheter une maison), est-ce que dans le monde IT c’est le même cas ?

En faisant des choses plus rapidement qu’on le devrait on crée de la dette plus rapidement qu’en temps normal, mais il ne faut pas escamoter la dette ensuite mais la prendre en compte dès le début (exemple: on fait du quick & dirty pour le jalon x, on planifie le refactoring dans le jalin x + 2). Le reste du temps on créé quand même de la dette en continu qu’il faut traiter par de l’amélioration continue.

Éviter les paiement d’un bloc qui a un trop gros impact sur la livraison de nouvelles fonctionalités: si possible le faire sur plusieurs jalons même si ça a un surcout à cause des merge.

Gros chantiers: séparer l’équipe en deux pour qu’une partie soit dédiée à une grosse migration est mauvais pour la cohésion de l’équipe.

Comment mesurer la rentabilité d’un investissement pour rembourser de la dette technique ? Il faut une situation de confiance avec le client pour qu’il accepte ce chantier.

Au pire on arrive à s’adosser sur un soucis bloquant qui déclenchera le chantier (fonctionalité nécessaire impossible à mettre en place avec une version existante, produit en fin de vie).

Pratiques de planifier des moments dans les itérations pour se focaliser sur la dette.

Comment est ce qu’on peut la factualiser pour pouvoir prendre des décisions objectives ?

L’idéal c’est de la purger au quotidien, sinon une bonne pratique est de référencer quelque part les points de dettes, mais attention à trop d’empilements => possible de déclencher automatiquement du désendettement quand le nombre de ces éléments sont trop nombreux.

La dette technique ne se limite pas au code: UDD par exemple, et dans ce cas il est plus facile de l’ignorer et de le laisser s’accumuler, il faut être vigilant.

Est ce que la vision du code endetté est partagée dans l’équipe ? Les peers review permettent ce genre de choses, par exemple en fin de user story.

Est ce que toute dette est bonne à corriger / comment faire pour décider ?

Très important de ne pas introduire de régression dans ce genre de refactoring qui n’apporte pas de nouvelles fonctionalités.

Est ce qu’il y a besoin de passer du temps à identifier la dette ? En principe la dette te trouve: tu identifies la dette par les douleurs, si du code est endetté mais qu’il ne te gène pas car tu n’interviens pas dessus dans ce cas c’est pas grave.