News - Clients

Réduire la dette technique : Les pratiques

26.01.2016



La dette technique est ce fléau invisible et insidieux des projets de développement itératif. Comment l’identifier, la comprendre, la maîtriser.
Dans ce premier volet nous passerons en revue différentes stratégies et méthodes. 

Un projet ne peut pas être à la fois rapide, de bonne qualité et pas cher. Le budget étant le plus souvent le paramètre incompressible, il faudra jouer entre la qualité et la rapidité. Pour chaque livraison, il faudra choisir entre assurer le niveau de qualité requis au risque de prendre du retard sur les fonctionnalités, ou avancer sur les fonctionnalités au risque de laisser passer des défauts. C’est souvent la deuxième option qui est choisie. 

Et lorsque l’on laisse passer des défauts, intentionnellement ou non, le logiciel n’est plus au niveau de qualité initialement défini, il prend un déficit de qualité : c’est ce que l’on appelle la dette technique (technical debt en anglais). 
On sait qu’il faudrait un jour rembourser cette dette, c’est-à-dire corriger les défauts. Mais plus le nombre de défauts augmente, et plus ils sont difficiles à gérer. Et plus les les défauts persistent, et plus ils coûtent cher à corriger. Exactement à l’image d’une dette financière, plus elle s’allonge et plus elle s’étale, plus il en coûtera à la rembourser. 

Définir la dette technique

Le concept de dette technique a été introduit par Ward Cunningham en 1992, cela ne date donc pas d’hier. Pour Cunningham, la dette technique représente des parties de code non utilisées, ou difficile à modifier et à faire évoluer. Aujourd’hui, il existe bon nombre de définitions. Pour faire simple, on peut dire que la dette technique est la différence entre ce qui a été promis et ce qui est livré. Ou encore l’effort nécessaire pour amener le logiciel à un niveau de qualité acceptable. D’une manière générale, cela se traduit par des coûts supplémentaires bien supérieurs aux économies censées être réalisées initialement. 

Si vous percevez certains signes et observez certains indicateurs mesurables tels que : 

  • L’insatisfaction des utilisateurs lors des livraisons, livraisons non acceptées
  • Le ratio de plus en plus important entre la durée de la livraison et la complexité de son code
  • Le nombre de bogues et d’incidents sur une période donnée
  • Le temps passé en investigation sur les codes hérités
  • La dépendance de l’équipe à des rôles spécialiste
  • Le nombres d’heure supplémentaires effectuées par les développeurs 
  • L’insatisfaction des développeurs à travailler sur le projet
  • Le besoin en formation et outils

Alors vous avez sans doute une dette technique, surtout si ces indicateurs ont tendance à croître plutôt qu’à diminuer.

Identifier la dette technique

La dette technique peut être volontaire ou non.

La dette technique volontaire résulte de décisions de livrer du code tout en sachant qu’il comporte encore des défauts : pour livrer à temps en respectant le cahier des charges fonctionnel, pour obéir aux impératifs du time-to-market, pour convaincre les utilisateurs avec des fonctionnalités innovantes. Une pratique largement répandue dans le milieu des startups où l’objectif est d’acquérir rapidement un maximum d’utilisateurs en proposant des fonctionnalités avant la concurrence. Dans ce cas, la dette technique représente un investissement, de la même manière qu’une entreprise contracte un emprunt bancaire ou effectue une levée de fonds pour booster son activité, en espérant que le gain occasionnée sera supérieur au remboursement de la dette. Pour certains, la dette technique est une bonne chose, qu’il faut l’embrasser ou du moins c’est un risque à mesurer et à prendre. 

La dette technique involontaire, naturelle, est inévitable quand un projet regroupe des développeurs avec des expériences et des sensibilités différentes. Un logiciel qui évolue et qui grossit voit sa complexité croitre dans le temps. Pressés par les délais, les développeurs introduisent du bruit dans le code par des implémentations non conformes aux normes ou en codant des erreurs de conceptions... C’est ce que Martin Fowler appelle des Code Smells (mauvais code) : commentaires incompréhensibles, méthode trop longue, code dupliqué, complexité exagérée, classes trop longues, code inutilisé... Des défauts qui ne se traduisent pas toujours par des bogues visibles et gangrènent le code, silencieusement au fil des livraisons...

Martin Fowler propose une classification des dettes techniques en quatre types, formalisés dans son Technical Debt Quadrant

[Source : le blog de Thiguys]

Dette technique et dette logicielle

Pour Chris Sterling, auteur de l’ouvrage Managing Software Debt: Building for Inevitable Change, la dette technique n’est qu’un des aspects d’une dette plus générale, la dette logicielle : 

  • Dette technique : l’aspect programmation, ce sont les conséquance des activités que les développeurs ont court-cuitées ou reportées
  • Dette de qualité : conséquence d’une diminution de la capacité à vérifier la qualité fonctionnelle et technique du logiciel
  • Dette de gestion de configuration : quand l’intégration et la gestion des versions deviennent plus risquée, complexe et sujette à erreurs
  • Dette de conception : lorsque le coût pour rajouter des fonctionnalités dépasse celui pour tout réécrire from scratch
  • Dette de plateforme : lorsque l’alignement avec les objectifs métiers qui impliquent des changements dans le logiciel devient trop coûteux


Comprendre la dette technique

La dette technique prend différentes formes : 

  • Documentation incomplète ou inexistante
  • Mauvais code (code smelles)
  • Mauvaise conception architecturale (design pattern non adapté, non modulable...)
  • Bases de données mal structurées (données redondantes ou erronnées)
  • Mauvais processus (pertes de temps, inefficaces, désorganisation...)


Pour la comprendre et la combattre, on peut commencer par lister les facteurs qui peuvent être la source de cette dette : 

  • La vitesse au détriment de la qualité : la précipitation est sans doute la cause principale de la dette technique
  • La vision à court terme : bricolage et réparations “ à l’arrache ”, navigation à vue sans stratégie, sans vision architecturale
  • La course contre la montre : effort concentré sur le rattrapage du retard fonctionnel plutôt que sur la construction d’un produit de qualité pour le futur
  • L’innovation à tout prix : intégration de technologies non éprouvées, apprentissage sur le tas
  • Le manque de compétences : inadéquation entre les compétences des développeurs et la complexité des tâches assignées.
  • L’ignorance ou l’impasse sur certains risques : capacité à monter en charge, vulnérabilité du code...


D’une manière générale tout ce qui contribue à affaiblir la qualité du logiciel est source de dette technique. 

Le zéro défaut, comme la perfection, n’existent pas. Il ne s’agit donc pas d’éradiquer cette dette technique mais de la contenir, de la réduire à un minimum acceptable.

Pour les projets agiles, dont les variantes légères come Scrum se basent sur la rapidité, une méthode consiste à rendre la méthode agile plus robuste, comme l’explique Chris Sterling dans son ouvrage.

Ne livrer que du code terminé

Intégrer la qualité dans l’approche de développement agile est sans doute une des méthodes les plus radicales et efficaces : en maintenant un niveau de qualité constant, livraison après livraison, en ne livrant que du code “ terminé ”. Ce qui implique une définition stricte du terme “ terminé ” comme “ prêt pour la livraison ”, et qui inclue des tests automatisés complets dans le cadre de la user story ou de la correction des bogues initiales. Ainsi pour que les développeurs passent à la user story ou la fonctionnalité suivante, il faut en pratique que leur tâche en cours soit déjà dans les mains des clients.

Définition d’un code “ terminé ” - Source : Chris Sterling, Managing Software - Quality Debt 

Pour accélérer le processus, les équipes pourront appliquer tout au long du cycle de développement des techniques telles que les test automatisés, l’intégration continue et les workflows de création de branches de fonctionnalités. 

La branche principale master doit toujours être prête pour la livraison. Les nouvelles fonctionnalités démarrent sur une branche de tâche contenant du code pour la fonctionnalité avec ses tests automatisés. Une fois la fonctionnalité terminée et les tests automatisés passés avec succès, la branche peut être fusionnée dans le master. La barre de qualité étant toujours définie très haute, la dette technique reste maîtrisée. C’est ce qui permet au développement d’être réellement agile à long terme. 

Par ailleurs, les méthodes agiles telles que DSDM ou AgilePM permettent de combiner agilité avec architecture et design avec une approche à long terme, en aidant à établir un compromis en rapidité et dette.

Quantifier les mesures à appliquer

SavoirAgile.com propose une méthode pour cerner et régler sa dette. L’idée est de mesurer l’impact de la dette technique et de son remède au cours d’un atelier collectif ou une rétrospective.

Dans un premier temps, définissez avec l’équipe le facteur le plus fort dans la dette et trouvez comment le réduire de la manière la plus directe. La méthode des 5 Pourquoi peut aider à identifier la source du problème et donc son opposé, le remède. 

En utilisant les mesures constatées, l’expérience des développeurs, on peut quantifier la dette par fonctionnalité : 

Source : SavoirAgile.com

Ensuite, projetez-vous dans le futur avec une simulation : 

Source : SavoirAgile.com

Le constat de cet exemple : prendre le temps de concevoir des tests, cela génère un coût qui accentue la dette à court terme. Mais à partir de 6 fonctionnalités terminées avec ses couvertures de test et livrées, l’effort commence à compenser la dette. Au-delà des 26 fonctionnalités, la dette ne s’accentue plus et surtout il n’y plus de pertes financières. Il n’y a plus qu’à s’appuyer sur cette simulation pour mettre en place un politique de tests automatiques et comparer les bénéfices. 

Consigner la dette dans un registre

James Higgs propose une stratégie simple pour gérer la technique. Plutôt que de chercher à éliminer entièrement la dette, il suggère de la maintenir à un niveau acceptable pour que vous puissiez ajouter des fonctionnalités relativement facilement, en prenant des décisions informées et délibérées sur quand contracter une dette et quand la rembourser. 

Pour ce faire, Higgs conseille de tenir un registre de la dette technique, dans un format simple dans la bibliothèque de code source et avec celui-ci. Efforcez-vous à ce que chaque développeur comprenne ce registre et saisisse une ligne correspondante quand il ajoute à la dette dans le même commit. Quand vous réglez la dette, enlevez l’entrée correspondante dans le registre.

À chaque itération, faites une revue du registre de dette et assurez-vous que vous avez un plan actif pour adresser chaque ligne. Partagez le registre avec le client. Assurez-vous qu’il comprenne la raison d’encourir une nouvelle dette, la taille du remboursement, et d’une manière générale l’impact de vos prises de décisions sur le projet. 

La chose importante à faire comprendre au client est qu’il doit avoir un budget pour le développement continu du projet.

Une dette technique judicieusement gérée avec un plan de remboursement clair est une approche raisonnable du développement logiciel, selon James Higgs.

Vivre avec une dette technique

Le blog des Thiguys donne quelques conseils pour vivre avec une dette existante et la minimiser.

  • La prioriser, en utilisant par exemple la matrice BCG
  • S’y attaquer, en restant transparent avec l’équipe. Accordez des points voire des stories techniques dans votre backlog, engagez-vous sur un pourcentage de récupération de la dette accordé à chaque sprint. On peut mettre en place aussi un backlog pour la dette, qui rejoint un peu l’idée du registre de la dette précédemment décrit
  • Appliquez le Boy Scout Rule de Robert C. Martin : à chaque fois que quelqu’un touche à un bout de code, il devra le laisser dans un état meilleur !
  • Ne dédiez jamais tout un sprint au refactoring


Mesurer et prioritiser la dette technique

Sur le blog CoderbreakFast, voici une méthode simple et efficace pour prendre conscience de l’état global du projet, identifier et prioritiser les portions de code les plus atteintes par la dette technique.

Imaginez que vous perdiez tout le code source d’un module. Pas de backup, pas de versions de source. Quel serait l’effort pour sa restauration. A-t-on toutes les informations, est-il souhaitable de réécrire à l’identique ? 

L’exercice consiste à réunir toute l’équipe et à estimer par vote pour chaque module la facilité de redéveloppement et la volonté de réutiliser l’ancien code s’il était retrouvé, sur une note de 1 à 3. Le produit des deux notes donne une idée de la dette technique du module. 

Les différences de notes entre les votants, dues souvent à des niveaux de connaissance différents, permet d’engager le dialogue. Les notes obtenues sont par nature subjectives, peuvent être combinées à des outils d’analyse de code pour au final détecter des zones à risque et fédérer l’équipe autour d’un plan d’action. Elles permettent par exemple de prioritiser et de planifier le refactoring des modules.

Moderniser son IT

Au final, toutes les méthodes décrites tendent vers la même approche : analyser l’existant, identifier la dette technique, établir et mettre en œuvre un plan d’action à plusieurs niveaux (refactoring du code, automatisation des tests, modernisation du système IT). 

Dans le prochain volet Réduire la dette technique : les outils nous passerons quelques techniques et outils pour aborder cette nécessaire modernisation.


Article rédigé par Pierre Tran 

© 2014 Codecase, all right reserved
Credits - Legal notices

X

Let's meet !