Échapper au trou noir de la dette technique

//ÀFAIRE (je rigole !) Mais sérieusement, votre réflexe est-il de grogner lorsque vous voyez cela ? Oui, nous aussi.

Dan Radigan Dan Radigan
Parcourir les rubriques

Les programmes 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).

Dette technique Agile | Atlassian – Le coach Agile

Chaque livraison commence par une phase de développement des nouvelles fonctionnalités au cours de laquelle (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é implémentée et qu'elle est prête pour les tests. Pour atteindre l'étape « bêta », il faut que suffisamment de bugs aient été corrigés pour pouvoir recevoir le feedback des clients. Malheureusement, tandis que l'équipe est occupée à essayer de corriger suffisamment de bugs pour atteindre la bêta, de nouveaux bugs apparaissent. C'est le cas chronique du marteau qui tape sur la tête d'une taupe : vous corrigez un bug et deux autres surgissent. Enfin, la livraison atteint l'étape importante « Golden Master » lorsqu'elle ne comporte plus aucun bug 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 bugs est dangereux pour le développement. Plus le nombre de bugs 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 bugs ralentit le développement. Pendant ce temps, les clients vivent un véritable cauchemar en raison 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, ou master, 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 débutent leur vie 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 faire l'objet d'un merge dans master. La barre de qualité étant toujours définie (et définie très haut), la dette technique demeure maîtrisée.

Pour de nombreuses entreprises, cela constitue une évolution culturelle énorme. Grâce à 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 cahier des charges 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 responsables 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. 

Conseil de pro :

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 bugs initiale, la user story ou la correction des bugs 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 bugs.

Automatiser les bogues pour les éliminer

Lorsqu'un bug 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 bug 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 certaines actions utiles pour dompter la dette technique :

  • Éduquez le Product Owner 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 bugs que des tests automatisés et une intégration continue. Lorsqu'un nouveau bug est identifié, créez un test pour le reproduire, puis le corriger. Si ce bug 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. 

suivant
Testing