Identifier, mesurer et rembourser la dette technique

La dette technique

La dette technique est quelque chose de commun pour toutes les équipes en développement logiciel. Une bonne équipe de développement n’est pas une équipe sans dette technique. Il est quasi impossible pour une équipe, aussi bonne qu’elle soit, de ne pas en avoir une. On fait tous face aux mêmes enjeux d’échéanciers serrés qui amènent, parfois, certains compromis. Une bonne équipe de développement est une équipe qui minimise et gère cette dette.

Ceci étant dit, cet article ne se prétend pas être LA solution pour minimiser et gérer adéquatement la dette technique. Il se peut que vous utilisez des méthodes qui vous apportent déjà ce résultat d’atténuation et de gestion.

Dans cet article, je vais vous partager mon opinion basée sur mes expériences professionnels et identifier le tout sous quatre sections :

Définition du concept
Identification et estimation
Gestion et priorisation
Techniques de réduction

Définition du concept

Alors qu’est-ce que la dette technique, selon notre ami Ward Cunningham ?

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring . The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.”

Source: Agile Alliance

La dette technique peut être créée pour toutes sortes de raisons :

L’important, c’est que si l’on prend la décision de créer la dette, celle-ci doit être prise en équipe et justifiée au gestionnaire du carnet de produit (Product Owner) (et au client). Ensuite, cette dette doit être documentée à un endroit où elle peut être visible de tous.

Identification et estimation

Étant donné que la dette technique est stockée dans un endroit accessible par tous, l’ensemble des membres est responsable de procéder à son identification et son estimation. Chaque dette technique n’est pas créée également. Chacune possède un « taux d’intérêt » plus ou moins élevé.

C’est à l’équipe de déterminer ce qui est important ou non et de faire face à la musique (#transparence) en expliquant aux stakeholders les impacts à court, moyen ou long terme.

Voici une liste de critères qui peuvent aider à bien prioriser la dette technique :

Technical Debt item attribute	Detail, Rational
Type of impact	Which activities and, abilities will it hurt?
Amount of impact	How much will it hurt? Is the potential negative impact on the business limited or ….very high?
Duration and periodicity of the impact	Will the impact happen once, or will it recur?
Timing of the impact	Will the impact be perceived very soon (i.e. when I will need to achieve a good unit test coverage), or later, after delivery?
The age of the Technical Debt item	Is it “legacy TD,” or did the team add it during the last sprint?
Is it intentional or not?	Involuntary TD may trigger coaching and training for team members.
Refactoring cost	This will help to plan and prioritize repayment activities.
Dependencies with other Technical Debt items	Is the Technical Debt item included within the impact scope of another debt item?

Source: Agile Alliance

J’aime bien utiliser deux métriques, que je qualifierais de « maison », pour identifier une dette technique :

La récitation des mots sacrés de La Bible

Si un de mes collègues ou moi disons trop de gros mots à chaque fois que l’on touche à une section en particulier d’une application, cela signifie peut-être qu’une dette technique est nécessaire afin d’améliorer la maintenance de cette portion.

Bon, certains collègues ont la récitation biblique plus facile que d’autres. Si l’on mentionne un mot interdit pour une boucle foreach au lieu d’une instruction LINQ, ou bien que les variables ne respectent pas la case (majuscule versus minuscule) … bonne chance pour justifier l’importance de cette dette au gestionnaire de produit! La vraie solution ici, à inscrire comme dette technique, est d’ajouter un linter au projet. On peut ensuite s’assurer que l’outil est exécuté en intégration continue (CI).

Important de savoir que l’importance d’une dette technique est aussi influencée par le cycle de vie du projet (en développement versus en maintenance).

Third strike, you’re out!

Pour ceux qui connaissant mon amour du baseball, si l’on en est au troisième bogue pour la même section de code (classe, module, etc.), il est important de créer une dette technique. Il est aussi suggéré d’augmenter les tests unitaires de cette section et de s’assurer que les trois bogues sont associés à un test unitaire. J’ai aussi tendance à insérer le numéro du bogue dans les commentaires du test afin de justifier son existence!

Gestion et priorisation

Le Agile Alliance recommande plusieurs techniques afin d’assurer une gestion et une priorisation saine de la dette technique dans ce document.

Cela va de dédier des Sprints complets à la dette technique ou bien seulement une portion de la vélocité de l’équipe, dépendamment de l’importance de la charge de travail à accomplir.

Dans le cadre des projets où j’ai une influence, j’ai tendance à intégrer la dette technique directement dans le carnet de produit (backlog). Pour identifier la dette technique, vous pouvez utiliser un préfix dans le titre, un tag ou bien un autre type de tâche avec sa propre iconographie (ex.: création d’un custom workitem type avec Azure DevOps). Je crois que chaque dette technique doit être estimée en heure, dans le cadre d’une séance de tasking, et non en point pour de pas influencer la vélocité à la hausse (no double-dipping!).

Techniques de réduction

Il existe plusieurs techniques pour réduire la dette technique ou encore, pour réduire le risque d’en créer une nouvelle. En voici quelques exemples :

Avoir une Definition of Done (éviter les surprises!)
Avoir une Definition of Ready (s’assurer qu’une story est complète avant de procéder à son estimation)
Avoir de l’analyse syntaxique de code (SonarCload, linter, Roslyn Analyzers)
Revue de code (via un mécanisme de pull request)
Couverture de code (code coverage) via l’exécution des tests
S’assurer d’être à jour au niveau des versions utilisées
Formation technique
Architecture Agile (c’est-à-dire valider avant, pendant et après)
Automatisation (pour réduire les erreurs de manipulation humaines)
Boy scout rule (faire le ménage au fur et à mesure)

Toutes ces mesures sont importantes. À mon avis, les gens ne s’amusent pas à créer une dette technique. Au contraire, ils font toujours leur possible avec leurs connaissances et le temps qui leur est accordé. J’adore le boy scout rule, c’est-à-dire lorsqu’on ajoute une fonctionnalité, on doit laisser le campement, dans ce cas-ci le code, aussi propre ou sinon plus propre qu’à l’arrivée.

Faire attention ici de ne pas se lancer dans une réécriture complète en prenant un trop gros morceau. Demandez l’avis à votre équipe avant de vous lancer dans ce genre d’aventure. Essayez de vous demander quel serait le bénéfice à court, moyen et long terme.

Conclusion

Il n’y a pas de recette miracle, juste plein de techniques, beaucoup de gros bon sens, de discussions et trop d’articles sur le sujet (voir références).

Références

Agile Alliance

Martin Fowler

Autres