Accueil > Blog > Parlons Agile > La dette technique : des anomalies techniques sous contrôle

La dette technique : des anomalies techniques sous contrôle

par | Juil 27, 2021 | Parlons Agile | 0 commentaires

Partagez ce contenu !

Intuitivement, j’aurais dit qu’au démarrage d’un projet, les réalisations devraient nécessiter plus d’efforts que par la suite. C’est sans connaitre le concept de dette technique. Chaque fois que l’on doit apporter une modification au travail de nos prédécesseurs, on dépend de la qualité de ce travail. Ward Cunningham a théorisé le concept de dette technique pour définir cette notion.

Dans tout projet, les urgences, les complexités et beaucoup d’autres raisons amènent l’équipe à faire un raccourci ou ne pas réaliser une fonctionnalité au niveau de qualité exigé. L’ensemble de ces décisions accumulées constitue ce qu’on appelle la dette technique.

Cette dette technique est une image de la dette financière qui nous suit toute notre vie. La dette financière ralentit notre vie et nos projets tout comme la dette technique ralentit les réalisations dans le cadre du projet.

Il serait donc naturel de se dire qu’il faut la rembourser (cad corriger les défauts). Mais comme dans la vie personnelle, rembourser les dettes n’est pas toujours la priorité. Surtout quand on doit payer les études de l’ainé et le club de sport du petit dernier.

Comment et quand corriger la dette technique

Pour mon crédit immobilier, la banque a défini les mensualités, la durée et le taux d’intérêt. Je n’ai eu qu’à décider si cela me convenait ou pas.

Dans le cas de la dette technique, c’est l’équipe qui joue le rôle du banquier et du client. Donc c’est à l’équipe de décider quand les taux d’intérêts sont inacceptables et qu’ils préfèrent rembourser leur dette pour ne plus avoir à payer.

Les mensualités :

C’est le temps et l’effort nécessaire à la réparation.

Imaginez un marteau cassé, chaque fois que vous en avez l’usage, vous devez faire attention, taper moins fort et le petit bricolage prend plus longtemps. Dès que vous prenez le temps de le réparer ou remplacer, vous revenez à votre performance habituelle.

Dans le cas du marteau, les mensualités c’est le temps du trajet à votre boutique de bricolage, l’essence, le coût du nouveau marteau.

La durée :

C’est à vous de décider quand vous avez le temps de réparer le marteau. Vous savez quand c’est prioritaire et quand ça ne l’est pas.

Pour moi qui utilise un marteau 1 fois tous les 5 ans, je ne suis pas pressée. Celui qui l’utilise tous les jours a tout intérêt à le remplacer rapidement.

Le taux d’intérêt :

C’est simple : tant qu’une anomalie n’est pas corrigée, elle ralentit le travail de l’équipe. Le taux d’intérêt revient à la perte de temps et l’énergie supplémentaire dépensée à chaque fois que vous utilisez le marteau cassé.

Remboursement :

Généralement ce sont les développeurs qui identifient un élément de dette technique et qui informent le product owner. A ce moment vient une négociation indispensable. Il s’agit de discuter le niveau de ralentissement que peut impacter cette dette, l’effet sur les clients / utilisateurs du produit et le coût de réparation. Sur ces éléments, le product owner pourra intégrer le correctif dans sa priorisation de backlog.

Une autre pratique est de dédier un pourcentage de la capacité de l’équipe aux correctifs de dette technique. Ainsi les développeurs décident de ce qui est prioritaire à corriger (ce qui les ralentit le plus au quotidien).

Pour résorber la dette technique (quand celle-ci prend de grandes proportions), vous devez choisir d’y dédier une période 1 semaine – 1 mois – plus si nécessaire. Cette période permettra de remettre le projet sur les rails et effacer la partie la plus pénalisante et prioritaire de la dette.

Quand ignorer la dette technique

Vous vous en doutez quand les taux d’intérêt sont nuls ou très très bas on ne rembourse pas son crédit, on le laisse courir.

Il en est de même pour la dette technique, il faut accepter qu’un produit parfait n’existe pas. Et si un défaut n’est vu par personne, qu’il ne dérange personne, il faut accepter de le laisser là où il est.

Sur un des projets où je suis intervenue, nous avons décidé d’ignorer plus de la moitié des tickets (d’anomalie). Ceux-ci ne faisaient l’objet d’aucune réclamation client. Et aucun développeur n’a choisi de dire qu’ils l’embêtaient. Bien entendu, seuls les tickets qui avaient plus de 2 ans ont été concernés par cette décision.

Comment éviter la dette technique

Pour éviter la dette technique, il faut définir des exigences de qualité et s’y tenir.

Dans le monde de la construction, on ne commence pas à construire une maison sur des fondations déséquilibrées. Et chaque brique que l’on pose ensuite est posée selon les exigences de qualité définies. La dette technique commence quand pour partir plus tôt un soir on finit les choses à la va-vite. Quand pour tenir une date de livraison on bâcle la pose du carrelage en espérant que le client ne s’en rendra pas compte.

De même, les développeurs connaissent les bonnes pratiques de qualité. Ainsi, c’est à eux de déterminer si une activité est terminée dans les règles ou s’ils ont besoin de travail supplémentaire pour mettre en conformité.

Parmi les bonnes pratiques, je peux vous proposer de :

  • Rédiger la définition of done : un travail n’est considéré terminé que lorsqu’il remplit les contraintes du DOD (Definition of Done)
  • Automatiser au maximum les tests : Vous aurez ainsi des alertes dès qu’une anomalie s’est glissée. Ainsi vous pourrez la corriger tant que c’est encore frais dans votre tête et pas 6 mois après que vous ayez tout oublié. On peut aller jusqu’à adopter le Test Driven Development !
  • Croiser les vérifications : demander à un pair de vérifier que vous n’avez rien oublié.
  • Utiliser un vérificateur de code et de sécurité tel que SonarQube.
  • Faire du pair programming : à deux on fait moins d’erreurs que seul.
too busy

En conclusion

Lorsqu’on récupère un projet, il y a toujours une dette technique. D’ailleurs, vu qu’il n’est pas possible de valider l’absence totale d’anomalie, on peut partir du principe que tout projet a une dette technique. Celle-ci n’est pas toujours une mauvaise chose. Chaque équipe choisit de prioriser ou non le traitement de celle-ci.

Faîtes juste attention à ce que cette dette ne prenne pas des proportions inacceptables. Le manque de qualité, sécurité ou performance de votre produit peut faire fuir les clients et les talents.

Bouchra Benkassem
Bouchra Benkassem

Coach et Formatrice Agile depuis 2014.
Co-fondatrice et Directrice Générale de CreaSila.

Certifications :
PSM1 (Scrum.org), SPC (SAFe), PMPO (SAFe)

S’abonner
Notifier de
guest
0 Commentaires
Inline Feedbacks
View all comments

Nous suivre sur les réseaux


Quel Manager de Dix pour cent êtes-vous ?


Ne ratez aucun article !


Inscrivez-vous à notre newsletter !

Inscrivez-vous à notre newsletter !

Inscrivez-vous pour être notifié des nouveaux articles postés ;)

Bravo, vous êtes inscrits !