Le Product Manager et la dette technique

Commençons par le commencement : qu’est-ce que la dette technique ?

La dette technique est une métaphore du développement logiciel inventée par Ward Cunningham. Il s'inspire du concept existant de dette financière et l'applique au domaine du développement logiciel.

L’analogie faite par Cunningham est la suivante : les mensualités liées à un emprunt servent à rembourser une part du capital et une part des intérêts. Si les remboursements sur le capital ne sont pas réguliers, les intérêts, directement calculés sur ce dernier demeureront importants. Ainsi dans les projets logiciels, le code endetté de nos applications correspond au capital et les bugs représentent les intérêts. Dès lors que nous ajoutons de nouvelles fonctionnalités, le capital augmente et génère davantage de bugs et de maintenance.

La dette technique représente donc des parties de code non utilisées ou dans lesquelles il est difficile d'effectuer des modifications et donc des évolutions.

Afin de pouvoir faire évoluer son produit dans le temps et ne pas être bloqué par une maintenance beaucoup trop importante, il est important que le Product Manager veille à maîtriser  la dette technique de son produit. Non, un code propre et maintenable n’est pas une perte de temps. Vous devez être le meilleur avocat de cette philosophie vis-à-vis de votre équipe et de l’extérieur.

La dette technique est inévitable… Mais encore faut-il savoir l’identifier, la catégoriser et l’expliquer

Pour ce faire nous allons utiliser le Technical Debt Quadrant de Martin Fowler de Thoughtworks.

Le Technical Debt Quadrant catégorise la dette technique en 4 types bien distincts :

Pourquoi le Product Manager doit-il se préoccuper de la dette technique ?

Parce que la dette technique concerne à la fois la maintenance, la fiabilité et l’évolutivité de votre produit.  

• La maintenance : qu’elle soit corrective, c’est à dire qu’elle consiste à corriger les défauts et les bugs liés à une application, ou adaptative, c’est à dire qu’elle consiste à adapter une application afin que celle-ci continue à fonctionner sur des versions plus récentes des briques techniques sur lesquelles elle s’appuie ; la maintenance d’une application ou d’un logiciel est au coeur de votre travail et touche directement les équipes de développement. Plus cette maintenance est conséquente, plus votre équipe de développement passera ses sprints à corriger des bugs et à livrer moins de fonctionnalités. Le temps consacré à cette maintenance sera du temps en moins à passer sur les développements de nouvelles fonctionnalités.
• L’évolutivité d’un produit : l’essence même de notre métier de Product Manager est de proposer les fonctionnalités les plus fraîches et celles qui s’adaptent le mieux aux vrais besoins utilisateurs. Si le produit n’évolue plus fonctionnellement, il finira par dégringoler. Aussi un manque d’évolutivité nécessitera des interventions sur le code plus longues et difficiles pour développer de nouvelles fonctionnalités
• La fiabilité : vous n’êtes pas sans savoir qu’un utilisateur qui est confronté à un logiciel ou une application instable et dont le comportement est aléatoire, reviendra peut-être une deuxième fois, mais jamais une troisième.

Faire un produit qui ne nécessite pas de maintenance, dont les évolutions sont faciles et rapides à mettre en oeuvre et qui est d’une grande fiabilité est très utopique. Notre travail de Product Manager consiste à trouver le bon compromis pour maximiser l’évolutivité et la fiabilité de nos produits tout en minimisant le temps consacré à la maintenance. Prendre la décision de baisser le niveau de qualité des fonctionnalités afin de les livrer dans les délais exigés existera toujours, reste à garder un niveau de fiabilité et de qualité suffisant.

Comment s'attaquer à la dette technique ?

La question que vous vous posez certainement maintenant est comment faire en sorte pour produire le moins de dette technique tout en continuant à livrer vos fonctionnalités dans les temps ? Et comment faire pour vivre avec une dette technique existante en essayant tout de même de la minimiser ?

Comment produire le moins de dette technique possible ?

Changement de culture

Il s’agit d’abord d’introduire un changement de culture dans votre structure et votre équipe au sujet de la dette technique. Assurez-vous dans un premier temps que votre Scrum Master ou facilitateur agile est en phase avec vous à ce sujet. Normalement, tout Scrum Master qui se respecte devrait l’être.

N’hésitez pas à envoyer un signal fort en affichant un poster pro-qualité et anti-dette technique dans votre Open Space “From this day forward, we no longer allow technical debt”.

Cela permettra d’une part à l’équipe de garder cette nouvelle règle en tête à toute heure de la journée, mais également d’évangéliser toutes les personnes de l’entreprise avec qui vous interagissez et notamment vos sponsors qui souhaiteraient que vous l’équipe livre toujours plus et plus vite.

Definition of Done et les bonnes pratiques de développement

Il est nécessaire de s’accorder avec votre Scrum Master sur un process et une “definition of done” qui atteste que pour chaque user story livrée les bonnes pratiques de développement ont été respectées : lisibilité du code, tests unitaires et fonctionnels, refactoring, code review et pair programming entre autres.

Les outils d’intégration continue et de mesure de la qualité

La mise en place de plateformes de déploiement continu qui permettent à tout moment de connaître l’état de santé de vos applications doit  être associée à des bonnes pratiques techniques telle que :

• La publication régulière du code
• La prise en charge immédiate des anomalies par les personnes ayant travaillé sur la fonctionnalité concernée

Les outils de mesure de la qualité mettent à disposition des équipes de développement un certain nombre d’indicateurs liés à la dette technique contractée tout le long du cycle de vie de votre application : détection des mauvaises pratiques de code, détection de code dupliqué, couverture en tests, les erreurs mal gérées, etc.

Vous n’êtes bien sûr pas garant de la mise en place de ce type d’outils dans votre structure, votre équipe de développement devrait s’en charger. Mais il est important pour nous PO de comprendre l’importance de ces outils et leur rôle dans la mise en place d’une vraie logique de qualité technique de nos applications. Même si l’application de ces bonnes pratiques et la mise en place de ces outils ne donnent pas des résultats immédiats. Cet investissement dans la qualité vous permet sur  le long terme de diminuer vos coûts de maintenance et d’améliorer  l’évolutivité et la fiabilité..

Comment vivre avec une dette technique existante et la minimiser ?

La prioriser 

Vous souvenez-vous de la matrice BCG ? Certes, elle est un peu has been, mais dans ce cas précis, elle peut vous être très utile.

Pour rappel, cette matrice nous permet de catégoriser nos produits ou applications en Stars, Cash cows, Dogs et Problem Children. Pour vous attaquer à leur dette technique, vous appliquerez les règles suivantes :

• Dogs : vous ne vous attaquerez pas à leur dette technique. De toute façon, ce sont des produits que vous comptez ignorer petit à petit. Donc autant ignorer leur dette technique.
• Cash cows : vous vous efforcerez de réduire la dette technique de façon à ce que l’application reste maintenable.
• Stars : vous vous attellerez à supprimer le moindre bout de dette technique qui puisse exister ! Ces applications vous rapportent de l’argent, beaucoup d’argent.
• Problem children : vous ferez en sorte de minimiser toute dette technique sur ces applications. Prévention, prévention. Ces applications sont vos bébés et potentiellement vos futures stars. Donc en prévision d’une explosion de leur potentiel,  vous les vaccinerez contre toute dette technique.

S’y attaquer

Pour s’y attaquer, il vous faudra être transparent avec votre équipe, leur dire que vous êtes de leur côté en ce qui concerne ce sujet, que vous ne souhaitez surtout pas que les choses se fassent en sous-marin, au risque de surprises lors de vos démos ou devant vos clients ! Aussi, n’hésitez pas à accorder des points, voire des “stories” techniques dans votre backlog, engagez-vous par exemple sur un pourcentage de récupération de la dette technique qui leur sera accordé à chaque sprint.

Une autre façon de s’y attaquer est de mettre en place un “Debt Backlog”. Le Debt Backlog répertorie au fur et à mesure les actions de dette volontaire prises par l’équipe, leur justification business, le sprint qui a provoqué la dette, les tâches associées pour la corriger, l’estimation du temps que la correction prendrait ainsi que la date attendue pour rembourser cette dette. Ce backlog permet d’avoir une vision claire de la dette existante mais également de celle que l’on crée au fur et à mesure et de vous rendre maître de votre backlog de dette, ce qui vous permettra de le prioriser selon vos besoins et vos prévisions de roadmap.

Deux petites règles à garder en tête pour la fin

• Le Boy Scout Rule appliqué au code “Leave code in a better state” (Robet C. Martin), permettra à votre équipe de s’attaquer à la dette technique quasi gratuitement. Le principe est simple : à chaque fois que quelqu’un touche un bout de code, il devra le laisser dans un état meilleur. Une simple question d’amélioration continue !
• Ne dédiez jamais tout un sprint au refactoring. Le refactoring, ou “réusinage de code” pour nos amis québécois, consiste à retravailler le code source d'un logiciel  sans ajouter de fonctionnalités ni corriger de bugs, mais en améliorant sa lisibilité pour simplifier sa maintenance, ou le rendre plus générique.

Les sprints entiers de refactoring font passer un mauvais message auprès des donneurs d’ordre. En situation de crise, c’est l’aveu que le PO a perdu le contrôle de son produit.

Cet Article vous a plu ? Retrouvez toutes les bonnes pratiques des Product Owners et Product Managers d'élite dans notre livre Les Clés du Product Management.