De la dette technique dans un projet

14/08/2010 Développement:// De la dette technique dans un projet
Je parlais il y a peu de la dette temporelle que l'on accumule parfois dans sa vie, et de ces temps de pause qui permettent de l'éponger, voire du plaisir de reporter vers eux tout ce qui n'est pas urgent.

Dans un projet logiciel on peut avoir une dette temporelle, qui en générale se transforme en date de livraison qui glisse, mais on a également une dette technique : l'accumulation de la non-qualité, l'ensemble des petites choses dont on n'est pas très content mais que l'on reporte à plus tard, à quand on aura le temps. Les fonctions trop grosses. Les configurations mal faites. Le code peu lisible. Tout ce qui n'empêche pas le programme de tourner, mais qui va se révéler la prochaine fois que l'on touchera à ce code, ou quand on voudra l'installer ailleurs.

Ce "plus tard" n'existe que sous une seule forme : la pause qualité. Une sorte de retraite où on accepte de ralentir, de ne pas ajouter de nouvelle fonctionnalité, et où on améliore la structure du code, où l'on polit un peu ce qui en a besoin, voire où on procède à un changement d'architecture pour apporter plus de souplesse. Dans ce contexte bien précis, on prend le temps d'épurer la dette. Mais on ne fait cela que pour les logiciels importants, pour les frameworks que l'on utilise à plusieurs endroits : la plupart des logiciels n'ont pas la chance de profiter d'une telle cure thermale!

C'est cette constatation qui justifie le haut niveau d'exigence qualité dans les méthodes agiles, eXtreme Programming par exemple : il faut construire la qualité jour après jour, avec courage et ténacité. On peut reporter une fonctionnalité, réduire le périmètre fonctionnel, mais pas la qualité. Les pratiques de binomage ou de relecture du code, l'usage des tests unitaires, YAGNI et KISS sont autant d'aides, de soutien dans cette tâche parfois difficile. Quand ma volonté faiblit, je pense simplement à ce que ma petite lâcheté va me coûter plus tard, et je trouve généralement la motivation pour faire bien.

Rubriques des billets

Commentaires(s)

2010-08-16 10:22:40 - Mère Teresa
"Une sorte de retraite où on accepte de ralentir, de ne pas ajouter de nouvelle fonctionnalité, et où on améliore la structure du code, où l'on polit un peu ce qui en a besoin, voire où on procède à un changement d'architecture pour apporter plus de souplesse."

Comme tu dis, mais quand l'environnement de travail est peu réceptif à l'agilité comment justifier qu'on a eu des faiblesses, des "petites lâchetés" comme tu dis, auprès de son CP ?
2010-08-16 10:53:16 - Cédric
Ces petits relâchements existent partout, on n'a rien à avouer et on ne doit pas en avoir honte. Le terme "lâcheté" est sans doute un peu fort et induit une faute, ce qui va à l'encontre de la communication.

Ce n'est pas ici l'agilité qu'il faut vendre à son CP, mais la qualité, et surtout les coûts qu'induit la non-qualité. L'agilité de son côté prône seulement de ne pas attendre la pause qualité, et d'agir au quotidien plutôt que de reporter à un plus tard qui ne vient en général pas. Comme toute l'agilité, c'est UNE solution au problème. Tout comme le binomage est une variante de la revue de code, et a presque les mêmes objectifs : il faut simplement faire l'un des deux, ou avoir une troisième pratique qui assure les mêmes résultats (partage de la connaissance, meilleure exigence de qualité, code plus lisible, ...)

Je pense qu'il faut mettre en valeur le coût induit par l'état du code dans chaque tâche, montrer les risques auqel on fait face. Si on me demande de rajouter une fonctionnalité sur un logiciel mal conçu et surtout dont on n'a pas fait évoluer la structure pour répondre à son évolution (rigole pas, ça va m'arriver à la rentrée) je mettrais l'accent sur le risque d'incompréhension, de perturber un fonctionnement peu lisible, bref, la cotation augmentera.
En mettant en valeur ce coût, on peut finir par convaincre un bon gestionnaire qu'un peu de qualité ne fera pas de mal.

Bon dans mon cas on fait vivre le logiciel et on n'a pas le temps de le reprendre, mais mon article vise les logiciels actuellement en développement, pour qu'ils ne deviennent pas des tours de Babel dans le futur.

Ecrire votre commentaire

16/08/2010 - Systeme