La dette technique : comment l’appréhender et la maîtriser ?

La dette technique : la responsabilité du Product Owner

En tant que responsable produit, délivrer un maximum de features dans les délais, sous la pression de ses utilisateurs (ou sponsors/membre du co-pilotage) peut souvent passer en première ligne de compte, dé priorisant parfois la structure du code. Mais vous avez à coeur de maintenir la qualité de votre produit à un haut niveau, influant directement sur votre aptitude à atteindre vos objectifs stratégiques et business.

Au milieu de tout ça, il y a : la dette technique.

FOCUS !

La dette technique : kesako ?

Comme le sujet fait débat, notamment entre les développeurs et les responsables produit, demandons à Bastien Jaillot de trancher :

En construisant un projet Web, de nombreux choix sont effectués, et ceux-ci, combinés à leurs implémentations, ont un impact sur le cycle de vie de votre projet. Cela s’appelle la dette technique: l’accumulation des risques pris lors des différentes phases techniques tout au long de la vie d’un projet.

Bastien Jaillot, La dette technique

Comment la dette technique s’installe ?

Le cycle traditionnel de développement d’un produit source de la dette technique

Lors de la conception de logiciels, la méthode traditionnelle est une approche basée sur les phases de développement des fonctionnalités :

• Il y a tout d’abord la mise à disposition de l’alpha (souvent un prototype fonctionnel non exempt de bugs).
• Ensuite celle de la beta (se rapprochant d’une version utilisable).
• Puis la version finale (version stable livrée en production).

Chaque versions commence par une phase de construction de nouvelles fonctionnalités, et « idéalement » les problèmes résiduels laissés par la dernière version sont traités.

Le cycle de développement « alpha » est atteint lorsque chaque fonctionnalité est implémentée et prête à être testée.

La bêta apparaît lorsque suffisamment de bugs ont été corrigés pour permettre aux utilisateurs (souvent early adopters ou les internes) de faire part de leurs feedbacks.

Bien évidemment, chaque production de code entraîne son lot de nouveaux bugs, l’équipe se retrouve à devoir résoudre le mythe de l’Hydre de Lerne : corriger un bug et deux autres apparaissent !

En tant que Product Owner, vous avez la responsabilité d’adresser les priorités de développements de l’équipe, il vous faut donc construire une stratégie pour endiguer ce flux de bugs.

Les chapitres suivants vous montreront comment limiter la création de la dette ainsi que la façon d’aborder celle existante tout ça dans le but de faciliter le pilotage de votre backlog.

Comment limiter la création de dette technique ?

Comme évoqué précédemment, chaque développement logiciel entraine la production (plus ou moins importante) de bugs, des choix d’architectures et de structures de code qui pourront engendrer de la dette technique.

Voici quelques conseils pour la rendre visible et vous permettre de la maitriser :

1. La Definition of Done

Vous avez du mal à détecter, en tant que Product Owner, si une fonctionnalité répond aux critères ? Si elle est terminée ou non ? Si elle va créer de la dette non maitrisé? Eh bien, il y a une astuce : s’accorder avec l’équipe Scrum pour définir ce qu’est une tâche dite « fini » (Definition of Done).

La Definition of Done (DoD) est un artefact invisible de Scrum regroupant un ensemble de critères définis par l’équipe Scrum déterminant si une User Story est considérée comme fini pour le sprint.

Lorsqu’un élément du Backlog produit ou un Incrément est décrit comme « Fini », tout le monde doit comprendre ce que « Fini » signifie.

Scrum Guide

L’agilité intègre la qualité dans l’approche du développement itératif afin que l’équipe puisse maintenir un niveau de qualité constant après chaque livraison. Si une fonctionnalité ne répond pas aux critères d’exigence (DoD), elle n’est pas mise en production.

Dans une approche plus traditionnelle, une tâche de développement « Finie » signifie : « assez bon pour que l’étape de recette commence« .
« Assez bon », notion tout à fait subjective, en fonction de qui va travailler sur la fonctionnalité, par exemple ,entre une validation d’un PO, d’un QA, ou du Dev.
Le problème, c’est que cette approche provoque de la confusion dans la qualification d’un travail fini, et amène à des allers retours constants entre ces interlocuteurs.
Conséquence, par manque de temps, on baisse la qualité et on achemine des bugs jusqu’en production : le début de votre dette technique !

Dans une approche Agile, la définition du « Fini » est d’être prêt à être mis en ligne, ce qui signifie que les développeurs ne passent pas à la User Story ou à la fonctionnalité suivante tant que les taches développées ne sont pas prêtes à être entre les mains de vos utilisateurs.

2. Workflow Branching Git

Pour accélérer les choses, les équipes Scrum utilisent des techniques comme le Workflow Branching git , les tests automatisés et l’intégration continue tout au long du cycle de développement.

La branche principale ou master doit toujours être prête à être mise en production. C’est la priorité numéro 1 car c’est elle qui apporte de la valeur à votre produit.

Ainsi, les nouvelles fonctionnalités commencent leurs vies sur une branche de développement contenant du code, mais également des tests automatisés.
Une fois la fonctionnalité terminée et les tests automatisés réussis, la branche peut ensuite être fusionnée en master (branche de mise en production).

Parce que le niveau de qualité est toujours élevé, la dette technique est identifiée, gérée sur la branche de développement (ou branche de recette selon les environnements) et reste sous contrôle.

Encore une fois, il ne faut pas procrastiner sur la dette. Plus il y a de bugs qui persistent, plus ils sont dur à garder sous contrôle et à corriger.

3. Go/No-Go ou la validation Product Owner comme gage de qualité

Pour de nombreuses organisations produit, il s’agit d’un changement culturel énorme. L’agilité est orientée vers des produits démontrables et de qualité. Le Product Owner doit se concentrer à maximiser la valeur.

Chez MonsieurGuiz nous avons la conviction que le PO est « maitre » de son produit et qu’il peut donc mettre son veto sur une livraison car elle compromettrait la qualité du produit, mais on sait que dans certaines organisations ce n’est pas possible ….malgré les contres indications celle ci ne seront pas prise en compte lors de la livraison.

Comment diminuer une dette technique existante ?

Si vous travaillez avec du code existant (Legacy), il est probable que vous ayez hérité d’une dette technique. Les points suivants vous aideront à réduire la dette existante et permettront à votre équipe de se concentrer sur des tâches plus stimulantes.

1. Prioriser la dette

Lors de la mise en place du Backlog, il est essentiel de ne pas séparer les taches concernant la dette (tests auto, bugs…) du reste des tâches apportant de la valeur (US, epic…).

Prioriser la dette technique dans la planification du sprint, comme pour le développement habituel des fonctionnalités.

On s’attable ici sur la partie du tableau « Remboursement de la dette technique » :

Comme pour le début de sprint, partez sur un poker planning pour estimer les éléments associés à la dette technique afin de donner de la visibilité sur les deux axes de valeurs : complexité technique ainsi que l’impact de chaque éléments :

Pour finir, alignez-vous avec les équipes sur la partie du tableau la plus prioritaire.

De manière générale, le PO part sur les techs wins à fort impact mais ayant peu de complexité, avant de s’attaquer à la partie correspondante aux taches à forte complexité.
Parfois, certains préfèrent un mix des deux afin de ne pas démoraliser les équipes qui ne supporteraient pas d’avoir des sprints à forte complexité technique à gérer.

2. Établir un processus de qualité

Vous pouvez dès lors mettre en place un Workflow de correction des bugs majeurs. Par exemple, faire une branche de maintenance pour les bugs à résoudre en production ou mettre des étapes de validation pour la résolution de bug au travers d’un Kanban.

Créez des tests automatisés ! Rien ne protège mieux contre les bugs que des tests automatisés et une intégration continue. Lorsqu’un nouveau bug est identifié, créez un nouveau test pour le reproduire, puis le corriger. Si ce bug réapparaît ultérieurement, le test automatisé mis en place permettra de le déceler. C’est une méthode qui permet de garder au fil du produit la qualité et le maintien du développement.

Une mise en place des KPIs tech (couverture de code, duplication, vulnérabilité…) à prendre en compte et challenger par l’équipe de développeur ou l’architecte afin de mesurer la qualité du code et avoir une vue sur l’évolution de la dette technique.

3. Attaquer la dette

En tant que Product Owner vous devez allier maîtrise de la dette et développement de nouvelles feature, vous savez que le temps investi sur une architecture et du code propre sera gage de gain de temps par la suite, vous devez aussi faire adopter cet état d’esprit à votre équipe de façon à ce qu’elle corrige des périmètres précis et définis par itération plutôt que tout un sprint de refactoring.

Sur de la dette existant , j’ai tendance à catégoriser mon backlog produit pour plus de visibilité, ça permet d’identifier l’état de santé de mon produit (un backlog avec 85% de story technique regroupant dette et bugs en tout genre n’est jamais bon signe ça impact aussi le morale des équipes).

Avec deux enjeux prioritaires :

• Remotiver les équipes.
• Ré-apporter de la valeur au produit et couper le cycle sans fin de refacto.

Pour commencer à attaquer celle ci je suis parti sur des sprints avec 40% de nouvelles features et 60% de réduction de la dette, ça peut être un bon compromis, d’une part pour motiver à nouveau les équipes et d’autre part pour apporter un début de paix sociale avec les intervenants en apportant des features à fortes valeurs ajoutées.
On continue au fur et à mesure des itérations avec comme objectif d’inverser la tendances : 60% de nouvelles features et 40% de dette à traiter. Ce sera un signal fort annonçant une amélioration progressive de l’état de santé de votre produit.

4. Éduquer vos équipes ainsi que les décideurs

Ne pas définir de KPI revient à ne pas avoir d’argument à avancer aux décideurs lors de la mise en place de process pouvant réduire la dette, voire pas de visibilité sur la dette en question.

Pour pallier à cela, éduquez le responsable produit quant au coût réel de la dette technique et la nécessité de les résoudre :

• La mise en place d’un management visuel pour mettre en avant les risques liés au produit et quadriller la dette « volontaire » afin de ne pas l’oublier.
• Réalisez des points de synchronisation sur l’évolution de la dette.

En bref, tout ce qui amène de la visibilité sur la dette technique est source de bienvenue et permettra d’anticiper les prochaine actions à mener.

Pour ce qui est des équipes le gros de la partie se joue lors du recrutement , privilégiez des profils Craftsman tournés vers l’amélioration continue et ayant une bonne maitrise des méthodes agiles (Pair programming, Moob programming, eXtreme Quotation ….).

La gestion de la dette technique fait partie d’un investissement long terme responsable. Vous ne pourrez pas l’éviter totalement mais il existe de nombreuses solutions pour la réduire et mettre en place un écosystème durable. Le plus important sera donc d’anticiper en gardant un oeil dessus et d’éduquer votre équipe pour que ça ne parte pas dans une spirale sans fin.

L’essentiel à retenir :

Le PO doit garder un oeil sur la dette technique et etre le garant de la qualité de son produit.

Pour limiter la dette :

• Il doit mettre en place des process garantissant cette qualité ( definition of done , workflow de correction de bug ).
• Avoir la possibilité de valider ou pas la livraison de son produit.

Sur de la dette technique existant :

• Prioriser votre dette technique avant de l’attaquer et de la diminuer progressivement.
• Ne consacrez pas un sprint entier à la réduction de la dette.
• Penser équipe performante au travers de profils Craftsman.
• Rendre visible cette dette au travers de management visuels et de KPI.