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 Managerveille à 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 Managerdoit-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 Managerest 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 Managerconsiste à 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 PMs 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
Connaissez-vous la Matrice Impact / Effort ? C'est un grand classique en Product Management et elle peut aussi fonctionner sur un contexte plus technique :
Ici, vous allez baser vos scores d'impact et d'effort sur des critères spécifiques pour placer vos sujets dans la matrice :
- Impact : À quel point les performances de votre produit vont-elles être augmentées ? Les futurs développements vont-ils être facilités, ce qui améliorera votre vélocité ?
- Effort : Combien de temps cela prendra ? De nouveaux développeurs devront-ils être recrutés ? Les existants devront-ils apprendre une nouvelle technologique ? Y a-t-il de forts risques de régressions ?
Vous pouvez retrouver un template de matrice impact / effort dans notre Product Management Toolkit.
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.
