Ah, la dette technique! L’ennemi commun de tous les projets, polymorphe, invisible, insidieux ou encore tabou de bien du monde! Et que nous autres, coaches Agiles et Scrum Masters, mettons un point d’honneur à aborder fréquemment.

Connaissez-vous celle de vos équipes? Pouvez-vous la décrire? Et surtout, cherchez-vous à la réduire? Je vous propose dans ce billet une réflexion qui vous aidera à remporter quelques batailles à son sujet.

Kézako?

La dette technique a de nombreuses définitions dans le monde du développement logiciel. Pour rester bref, je la considère comme une accumulation de travail nécessaire pour garantir un produit fini et fiable, donc opérationnel et maintenable, au fil du temps. Cela en accord avec une définition de « terminé » rigoureuse décrivant les qualités que doivent respecter vos biens livrables.

Cette dette résulte des décisions et activités techniques ou organisationnelles de l’équipe de développement ainsi que de leur qualité qui évolue au cours du temps. La forme et la portée de la dette s’avèrent donc différentes d’un projet à l’autre. Toujours présente, elle tend à s’accroître de manière exponentielle si on ne l’aborde pas correctement. L’éliminer totalement n’est donc pas possible, mais l’évaluer régulièrement et agir pour la minimiser reste indispensable.

Vous, vous saurez tout sur la dette technique

De quoi est-elle composée? En voici quelques éléments :

  • la qualité et la teneur des spécifications (leur clarté, le « juste assez »);
  • le nombre de tests et leur utilité (la couverture, leur pertinence);
  • les conventions de code (la maintenabilité, le respect des standards);
  • la bonne utilisation des concepts de design (SOLID…);
  • la mise en place d’un cadre d’intégration et de remontée de feedbacks (automatisation, conversations fréquentes);
  • la documentation technique, fonctionnelle et utilisateur;

Les signaux perceptibles et impacts mesurables sont nombreux. On retrouve :

  • l’insatisfaction des utilisateurs lors de la revue ou de la livraison (non-acceptation);
  • un ratio de plus en plus important entre la durée de la livraison et la complexité d’un item;
  • le nombre de bogues et d’incidents relevés sur une période donnée;
  • la durée des investigations sur des produits, composants ou code hérités;
  • la dépendance de l’équipe des rôles spécialistes (bus factor);
  • le nombre d’heures supplémentaires que travaille l’équipe de développement subissant de la pression;
  • le score que peut donner l’équipe de développement quant au plaisir qu’elle a à travailler sur le projet;
  • le besoin de formation et d’outils;

L’argumentaire idéal

Il n’est pas rare de voir la dette s’accumuler jusqu’à l’explosion : un palier où elle devient inacceptable, mais pas forcément un point de non-retour. Ce moment est critique. Tout dépend de la décision prise par l’équipe. Continuons-nous ainsi? Posons-nous une rustine ou attaquons-nous le problème jusqu’à la racine?

Beaucoup de facteurs entrent en ligne de compte et, paradoxalement, le besoin de répondre à des urgences en livrant des items « terminés » conduit à la décision de l’aborder superficiellement… ou pas du tout.

Les causes : la résistance au changement, la facilité de prendre l’option par défaut habituelle, une mesure du rendement de l’investissement mal évaluée ou inexistante. Si le bon sens et votre courage font que vous décidez ensemble d’y couper court, je vous en félicite!

Alors que faire si la mauvaise voie est empruntée?

Je vous invite à commencer à mesurer l’impact de la dette technique. Dans l’immédiat, si vous n’avez pas d’information concrète à disposition, je vous invite à la simuler lors d’un atelier collectif ou d’une rétrospective.

Mettez le doigt là où ça fait mal et trouvez le remède.

Dans un premier temps, définissez avec votre équipe le facteur le plus fort dans la dette actuelle et trouvez comment il peut la réduire de la manière la plus directe qui soit. Si l’exercice se révèle difficile, les 5 pourquoi sont très utiles pour repérer la source du problème; donc, l’opposé au remède.

Mettez les ingrédients sur la balance et dosez.

C’est à partir de ce moment que vous pouvez utiliser les mesures constatées. Quantifiez la dette technique selon le facteur. Quantifiez ensuite le manquement qui aurait dû être commis par l’équipe ou ce qui peut être effectué à son encontre. Si ces mesures existent déjà, vous pourrez faire un constat sur votre expérience. Autrement, projetez-vous dans le présent et l’avenir, quitte à faire une simulation avec des estimations plus ou moins réalistes.

L’exercice peut prendre quelques heures, mais ça en vaut réellement la chandelle.

Voici l’exemple d’un projet fictif, mais réaliste :

Le projet comporte un certain nombre de bogues critiques qui sont signalés à chaque livraison de fonctionnalités. Personne n’a idée du coût de propriété du produit. Toutefois, grâce à son expérience, un des développeurs a été en mesure de calculer les coûts relatifs à la maintenance et l’effort à déployer. Les tests n’ont pas encore été réalisés par manque d’expertise et faute de pression sur l’équipe : s’y appliquer devrait pourtant rendre l’activité moins ardue dans le temps. Faisons donc l’approximation des pertes découlant du manque de tests sur les fonctionnalités implémentées.

Tableau 1

Tableau 2
Tableau 3

Tableau 4

Le constat de cet exemple? Oui, écarter la dette en prenant plus de temps pour concevoir des tests et entretenir leur cadre, ça a un coût qui maintient les compteurs dans le rouge à court terme. Cependant, à partir de 26 fonctionnalités terminées et livrées avec discipline, rigueur et couverture de tests, il n’y a presque plus de grossissement de la dette et surtout plus de perte financière! Donc, aucune excuse pour continuer à négliger les tests!

Encore mieux, plus tôt vous agirez, plus bénéfique sera votre action à l’avenir. Notez comment la différence croît en bas du tableau.

Suivre la prescription à la lettre pour guérir

Après avoir fait vos propres constatations, prendre une meilleure décision et suivre une nouvelle ligne de conduite doivent s’imposer naturellement. Ayez le courage et le bon état d’esprit pour vous débarrasser de la dette, et ce, même si les résultats ne se présentent qu’au bout de quelques semaines! Faites un suivi de votre progression pour garder votre motivation… et valorisez les petites victoires!

Le mot de la fin

Toute guerre ne se gagne jamais en une seule bataille, surtout contre un ennemi aussi colossal et complexe que la dette technique! Mais, au final, la victoire n’en est que meilleure et particulièrement gratifiante.

Pour vous, quel visage a la dette technique? Quel est votre plan d’action pour la faire disparaître? Partagez-nous vos victoires!

pyxis

Pyxis est présente en Amérique du Nord, en Europe et en Asie.

Nos conseillers Agiles vous aident à concrétiser réellement les avantages de l’Agilité : accroître la fréquence des livraisons et la vélocité des équipes; collaborer avec les clients en s’alignant sur leurs besoins; maîtriser les risques et les changements en cours de livraison et encourager la concentration, la rigueur et l’énergie au sein des équipes. Communiquez avec nos coaches, formateurs, Scrum Masters et développeurs pour en apprendre davantage sur nous.

Billet précédent

À quoi sert le graphique Sunset?

Billet suivant

Cette mystérieuse boîte nommée « Agilité »...

1 Commentaire

  1. kamelderouiche@yahoo.com'
    jihbed
    29/05/2017 at 09:57 — Répondre

    excellent billet merci beaucoup

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.