Prérequis

Dans mon post précédent je mentionnais l'article captivant de Jérémy 🧑🏽‍🦱 Buget qui relate une action de fusion de versions particulièrement intéressante, et je notais un des points importants qu'il retient de cette expérience et qui ont fonctionné :

• Courage, méthodologie, rigueur et patience.

Pour ce qui est du courage, on le trouve en abondance dans les entreprises, et pas seulement celles qui s'occupent des problèmes de qualité à temps.

Pour les 3 autres dispositions, elles me paraissent très importantes car elles peuvent nous servir de boussole pour se sortir des ronces.

Quelles ronces ? La dette technique, of course.

Non pas la Dette Technique comme dans "j'ai une idée : on n'a qu'à persister vers du json le temps de la démo et lundi on se remet au travail sur l'ORM cible".

Non je parle de la dette technique comme dans "euh... la dernière personne qui a touché à ce code est partie fin 2018… et je ne vois pas de tests."

"dette technique" signifie : l'état de l'art de votre projet est désaligné. Des changements de contexte, d'objectifs, ou bien de vos pratiques font qu'il a perdu en cohérence. C'est inéluctable, dans toute activité de développement logiciel. La question est de savoir comment limiter et réguler cette dette avant qu'elle ne prenne les commandes du projet.

Pour identifier, réguler et limiter la dette, il faut de la méthodologie, de la rigueur et de la patience.

On peut le formuler autrement : afin de limiter la dette, votre état de l'art doit présenter 3 propriétés essentielles :

🪜 croissance par incréments

🗺️ sens partagé

🧯 prévention des défauts

Lorsque ces propriétés sont remises en question, la dette augmente, lorsqu'elles sont maintenues ou rétablies, la dette reste sous contrôle.

Exemple : "Après une semaine ou deux d'essai, on a reconnu que le pair programming n'était pas pour nous, vu qu'on ne s'entendait jamais à propos du code, du design etc. et donc on a décidé de travailler chacun dans son coin, rendez-vous en fin de sprint pour intégrer."

🅀: si aucune autre mesure n'est prise, quelle propriétés essentielles de l'état de l'art vont être impactées par ce changement ?

🅁: les trois :

🪜 l'équipe vient de décider d'intégrer moins souvent des parties de code plus longues

🗺️ les échanges (questions, compléments d'information, corrections, décisions) seront moins nombreux, et plus difficiles

🧯 moins de relecture de code ⇒ plus grande probabilité de défauts (à moins d'être un·e ninja du code)

Croissance par incréments, sens partagé, prévention des défauts : ces 3 propriétés clés peuvent donc nous guider dans la lutte contre la dette technique.

Stay Tuned !