#7. Préoccupez-vous de la dette technique
Maîtriser la dette technique de son produit est aussi une des missions du Product Owner
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 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 des parties de code non utilisées, ou dans lesquelles il est difficile d’effectuer des modifications et des évolutions.
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 quatre types bien distincts :
L’article de Martin Fowler :
Pourquoi le Product Owner doit-il s’en préoccuper ?
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 Owner veille à ce que la dette technique de son produit soit maîtrisée. Vu sous cet angle : Non, un code propre et maintenable n’est pas une perte de temps. En tant que Product Owner, vous devez être le meilleur avocat de cette philosophie vis-à-vis de votre équipe et de l’extérieur. La dette technique concerne à la fois la maintenance, l’évolutivité et la fiabilité 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 donc augmentera les coûts et impactera le budget — et moins elle livrera de fonctionnalités.
- l’évolutivité d’un produit : l’essence même de notre métier de Product Owner est de faire évoluer notre produit notamment en proposant de nouvelles fonctionnalités aux utilisateurs. Un code « endetté » nécessitera des interventions 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 erratique, 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 toujours faciles et rapides à mettre en oeuvre et qui est d’une fiabilité sans faille est très utopique. La tentation 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.
Le Product Owner doit trouver le bon compromis entre la maximisation de l’évolutivité, la fiabilité des produits et la minimisation du temps consacré à la maintenance.
Quelles pratiques pour diminuer la dette technique ?
Les questions que vous vous posez certainement maintenant sont :
- Comment faire en sorte de produire le moins de dette technique tout en continuant à livrer vos fonctionnalités dans les temps ?
- Comment faire pour vivre avec une dette technique existante en essayant tout de même de la minimiser ?
Pour inverser la tendance, il faut savoir la mesurer
Avant de s’attaquer à la dette, il faut déjà maîtriser le problème. Mettre en place des indicateurs peut être un bon départ. En tant que Product Owner, montrer un intérêt pour le sujet est un signal fort. Une approche pragmatique consiste à commencer par mettre en place des outils d’inspection comme SonarQube et calculer un indice dédié à la dette technique (sonar propose par exemple un plugin d’indicateur de dette technique). Même si la pertinence de cette valeur est toujours discutable, ce qui importe est que nous avons maintenant un référentiel. Nous pouvons donc étudier l’impact de nos actions !
Prioriser
Vous souvenez-vous de la matrice BCG (matrice Boston Consulting Group) ? 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 :
- Stars : vous vous attellerez à supprimer le moindre bout de dette technique qui puisse exister ! Ces applications vous rapportent de l’argent, beaucoup d’argent.
- Cash cows : vous vous efforcerez de réduire la dette technique de façon à ce que l’application reste maintenable.
- 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.
- 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. En prévision d’une explosion de leur potentiel, vous les vaccinerez contre toute dette technique.
Valoriser les profils “craftsman”
Un profil de développeur est aujourd’hui particulièrement apprécié dans les équipes de développement, il s’agit du craftsman. Le mouvement software craftsmanship regroupe des développeurs qui militent pour une bonne connaissance des techniques de développement. Les craftsmen portent une attention particulière à la qualité et font preuve de pragmatisme dans leur travail.
Les craftsmen sont adeptes de la Boy Scout Rule appliquée au code “Leave code in a better state” (Robet C. Martin). Elle 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 !
“Definition of Done” et les bonnes pratiques de développement
Il est nécessaire de s’accorder avec votre Scrum Master sur un processus 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.
Comment s’attaquer à la dette dès demain matin ?
Faites la revue des indicateurs à chaque rétrospective, la dette technique sera ainsi un sujet régulièrement étudié par l’équipe.
- Indexez les estimations sur l’indicateur de dette technique ci-dessus afin de faire prendre conscience de cette dette. Ainsi, l’estimation du coût d’une fonctionnalité sera plus importante si le code est fortement endetté.
- Organisez des journées de nettoyage. Si l’équipe a du mal à maîtriser sa dette au jour le jour ou si le code est endetté de longue date, il peut être intéressant de faire cet investissement.
- Ne dédiez jamais tout un sprint au refactoring. Celui-ci 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. Encouragez l’équipe à proposer des refactorings sur un périmètre précis et dont la valeur est prouvée. L’équipe devra découper les sujets pour en maîtriser les potentielles dérives, comme pour les user stories !
Cet article a originalement été publié dans notre Product Academy. Si vous voulez un compagnon physique demandez votre exemplaire sur notre site !
Et si vous avez aimé cet article, n’hésitez pas à nous donner un petit coeur !
