Qu'est-ce qu'une dette technique ?
Les programmes logiciels traditionnels adoptent, en matière de développement, une approche en plusieurs phases : développement des fonctionnalités, alpha, bêta et golden master (GM).
Chaque livraison commence par une phase de développement des nouvelles fonctionnalités où (dans l'idéal) les problèmes résiduels de la dernière livraison sont traités (mais soyons honnête, cela arrive rarement). Le cycle de développement atteint l'étape « alpha » lorsque chaque fonctionnalité a été mise en œuvre et qu'elle est prête pour les tests. Pour atteindre l'étape « bêta », il faut que suffisamment de bogues aient été corrigés pour pouvoir recevoir le feedback des clients. Malheureusement, tandis que l'équipe est occupée à essayer de corriger suffisamment de bogues pour atteindre la bêta, de nouveaux bogues apparaissent. C'est le cas chronique du marteau qui tape sur la tête d'une taupe : vous corrigez un bogue et deux autres surgissent. Enfin, la livraison atteint l'étape de golden master lorsqu'elle ne comporte plus aucun bogue ouvert. Pour y parvenir, il faut généralement corriger certains problèmes identifiés et reporter le reste (la plupart des problèmes ?) sur la livraison suivante.
Le fait de reporter sans cesse la correction des bogues est dangereux pour le développement de logiciels. Plus le nombre de bogues augmente, plus ils sont difficiles à gérer. C'est ainsi que naît le cercle vicieux de la dette technique. Pire encore, les calendriers ne sont plus suivis étant donné que la programmation liée aux bogues ralentit le développement. Pendant ce temps, les clients meurent à petit feu à cause de défauts non corrigés. Car oui, certains finiront par vous quitter.
Il doit y avoir une meilleure solution.
Réduire la dette technique avec Agile
En introduisant la qualité dans l'approche de développement itératif, Agile permet à l'équipe de maintenir un niveau de qualité constant, livraison après livraison. Si une fonctionnalité n'est pas à la hauteur des attentes, elle n'est pas livrée. Vous avez du mal à le croire ? En fait, voilà le truc : il faut définir ou redéfinir le terme « terminé ».
Pour les équipes traditionnelles, « terminé » signifie « suffisamment bon pour commencer l'assurance qualité ». Le problème avec cette définition, c'est que les bugs apparaissent tôt dans le cycle de livraison et ne cessent de se faufiler. Ainsi, lorsque l'assurance qualité finit par se pencher sur le produit, celui-ci présente des défauts par couches entières. Les équipes Agile, en revanche, définissent le terme « terminé » comme « prêt pour la livraison ». Ainsi, pour que les développeurs passent à la user story ou fonctionnalité suivante, il faut que leur tâche en cours soit entre les mains des clients. Pour accélérer le processus, elles appliquent des techniques telles que les workflows de création de branches de fonctionnalité, les tests automatisés et l'intégration continue tout au long du cycle de développement.
La branche principale de la base de code doit toujours être prête pour la livraison. C'est la priorité numéro un. Par conséquent, les nouvelles fonctionnalités commencent leur parcours sur une branche de tâche contenant du code pour la fonctionnalité elle-même, plus ses tests automatisés. Une fois que la fonctionnalité est terminée et que les tests automatisés ont abouti, la branche peut alors être fusionnée dans la principale. La barre de qualité étant toujours fixée (et fixée à un niveau très haut), la dette technique est toujours maîtrisée.
Pour de nombreuses entreprises, cela constitue une évolution culturelle énorme. Avec Agile, les équipes mettent moins l'accent sur les calendriers et davantage sur le développement de logiciels démontrables et de qualité. Le Product Owner est habilité à focaliser l'équipe en priorité sur les tâches les plus utiles, réduisant ainsi le périmètre de la version sans compromettre la qualité.
Il ne faut pas l'oublier : plus les bugs persistent, plus ils sont difficiles à corriger.
Dompter la dette de votre équipe
Si vous travaillez avec un code pré-existant, vous avez probablement hérité d'une dette technique. Les rubriques suivantes vous aideront à dompter la dette existante et permettront à votre équipe de se concentrer sur des aspects plus amusants, comme le développement de nouvelles fonctionnalités.
Définir la dette
Les développeurs et les gestionnaires de produits ne sont pas toujours d'accord sur ce qui constitue la dette technique. Mettons fin à la controverse une bonne fois pour toutes.
Cela inclut les éventuels raccourcis techniques empruntés pour respecter les délais de livraison !
Côté développement, on est tenté de caractériser le travail architectural comme une dette technique. Cela peut être vrai ou pas ; tout dépend de la nature du changement (par exemple, le remplacement d'un raccourci par la solution « réelle » ou la division d'une base de code monolithique en micro-services). En face, la gestion de produit considère souvent que le développement de nouvelles fonctionnalités est plus urgent que la correction de bugs ou la lenteur des performances. Pour éviter que l'un soit blasé par l'opinion de l'autre, tous doivent comprendre la différence entre la dette technique, les changements architecturaux souhaités dans la base de code et les nouvelles fonctionnalités. Des communications claires entre le développement et la gestion de produit sont essentielles pour la hiérarchisation du backlog et l'évolution de la base de code.
Priorisez la dette technique dans la planification du sprint, comme pour le travail habituel sur les fonctionnalités. Ne la dissimulez pas dans un backlog ou un outil de suivi des tickets séparé.
Attention aux sprints et tâches de tests
Résistez à l'envie de transiger sur la définition de « terminé » en ajoutant une tâche de test séparée dans la user story originale. Il est très facile d'opter pour un report, ce qui ne fait qu'accentuer la dette technique. Si les tests ne sont pas réalisés dans le cadre de la user story ou correction des bogues initiale, la user story ou la correction des bogues n'est pas menée à terme. Conservez une définition stricte du terme « terminé » dans votre programme et assurez-vous qu'il inclut des tests automatisés complets. Rien ne sape plus l'agilité de l'équipe que des tests manuels et une base de code remplie de bogues.
Automatiser les bogues pour les éliminer
Lorsqu'un bogue est identifié dans le logiciel, prenez le temps d'ajouter un test automatisé qui va faire la preuve de son existence. Une fois que le bogue a été corrigé, exécutez à nouveau le test pour vous assurer que le logiciel réussit le test. Cela constitue le cœur du développement basé sur des tests, une méthodologie qui, au fil du temps, permet de préserver la qualité dans le développement agile.
Où commencer ?
Il n'est pas facile de changer la philosophie de l'équipe (et celle des parties prenantes de l'équipe) sur la façon de gérer la dette technique. L'entreprise a parfois besoin de réduire ses délais de développement pour commercialiser plus rapidement le produit. Dans cette optique, récapitulons certains éléments d'action utiles pour dompter la dette technique.
- Éduquez le responsable produit quant au coût réel de la dette technique. Assurez-vous que les valeurs des story points sont exactes pour les futures user stories qui nécessitent une résolution de la dette technique existante.
- Modularisez votre architecture et prenez clairement position sur la dette technique dans les nouveaux composants ou les bibliothèques de l'application. Si l'équipe et l'entreprise perçoivent l'agilité de ces nouveaux composants, elles voudront tout naturellement étendre ces pratiques à d'autres parties du code.
- Créez des tests automatisés ! Rien ne protège mieux contre les bogues que des tests automatisés et une intégration continue. Lorsqu'un nouveau bogue est identifié, créez un nouveau test pour le reproduire, puis le corriger. Si ce bogue réapparaît ultérieurement, le test automatisé permettra de le déceler avant les clients.
N'oubliez pas que la dette technique est une réalité pour toutes les équipes de développement. Personne ne peut totalement l'éviter. Le principal est de s'assurer qu'elle ne parte en spirale pour devenir incontrôlable.
