Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

05 juillet 2010

Gérer et éliminer la dette technique

Au dernier "Agile Development Practices" de juin dernier à Las Vegas, j'ai assisté à une session de Lee "AgileDad" Henson intitulée "Managing and eliminating technical debt". Lee est un présentateur très dynamique qui est aussi un excellent pédagogue qui a débuté par expliquer ce qu'était la dette technique. C'est comme la dette financière. Une petite dette momentanée est acceptable, mais une dette plus importante peut nous conduire à la faillite.

 

Comme consommateur nos habitudes face à l'endettement ont changé au cours des dernières décennies. Je me souviens que quand j'étais plus jeune, l'endettement était socialement mal vu. Il semble bien que nous ayons transposé ces mauvaises habitudes dans le monde logiciel. Qu'elle soit intentionnelle ou non, la dette technique augmente de façon composée avec le temps. On paie de l'intérêt sur la dette, qui augmente qui notre dette. Il faut briser ce cercle vicieux.

 

Selon Henson, la dette technique peut prendre différentes formes :

à        Des bogues et problèmes connus, mais non réglés;

à        Des travaux planifiés qui ne se feront jamais;

à        Du code qui n'a pas de tests de régression automatisés;

à        Des interruptions non planifiées du travail;

à        Du code qui n'est jamais exécuté;

à        L'absence de limite au "work in progress";

à        La non-reconnaissance par l'organisation de l'existence de la dette technique.

 

Un des symptômes pour reconnaître l'endettement technique, selon moi, c'est lorsqu'on décide d'ajouter des "features", plutôt que d'améliorer l'existant. J'ai vu ça à maintes reprises et notamment dans un cas où on ajoutait de nouvelles fonctionnalités aux deux semaines depuis plusieurs années, sans adapter le code existant à la nouvelle réalité. À un point tel, qu'il était très difficile d'ajouter ou de corriger des choses simples. Dans le cadre de ce projet, j'avais décrit la situation comme une maison à laquelle on ajoute des pièces, sans changer les fondations, ou refaire la toiture ou la peinture de temps en temps. Lee avait une phrase similaire :

 

"Fix the foundation, then build the palace."

 

Henson recommande d'avoir un plan qui vise l'élimination de la dette technique. D'abord, arrêter d'ajouter de nouvelles fonctionnalités, plutôt que de "payer " la dette. Utiliser une méthode de priorisation simple qui quantifie les efforts en fonction de la douleur qu'entraîne chaque élément de dette.

dettePriorites.png

Ensuite, donner de la visibilité, assurer le plus de transparence possible, en s'assurant que chacun est bien au fait de la dette technique, du plan pour l'éradiquer. Une fois le plan identifié, s'y conformer!

 

Finalement, éviter à tout prix l'ajout de nouvelle dette technique, surtout lorsque la dette actuelle est importante.

 

Annoncer à nos clients qu'il faut gérer la dette n'est jamais facile. Cependant, notre succès conjoint en dépend. Alors, prenons notre courage à deux mains et agissons maintenant, c'est le meilleur moment pour le faire.

 

Le blog de Lee Henson sur cette présentation :

http://blog.agiledad.com/2010/06/agileroots-is-happening-now.html#links

 

Pour en savoir plus sur la dette technique :

http://www.agiledad.com/Documents/2009/AgileMentorOctober2009.pdf

http://fr.wikipedia.org/wiki/Dette_technique

http://c2.com/cgi/wiki?TechnicalDebt

http://msdn.microsoft.com/en-us/magazine/ee819135.aspx

http://msdn.microsoft.com/en-us/magazine/ee335722.aspx