On le sait tous, chaque sprint vise à livrer des résultats tangibles, que ce soit sous forme de nouvelles fonctionnalités ou d'améliorations de performances, telles que des lenteurs qui rendent quasi impossible l’utilisation d’un logiciel.
Comment allez-vous équilibrer la pression de la dette technique avec l'impératif de livrer de nouvelles fonctionnalités ?
Cet article explore cette délicate question.
Objectif de Sprint : Rappel
Vous devez déjà le savoir, un sprint est une étape clé dans l'approche agile.
Il s'agit d'une période courte, généralement de 2 à 4 semaines, durant laquelle l’équipe se concentre sur des objectifs spécifiques tels que :
- Développement de nouvelles fonctionnalités
- Résolution de bugs
Il se doit qu’un sprint puisse aussi livrer des améliorations de la qualité du code.
L'objectif principal est donc de produire un incrément de produit potentiellement livrable à la fin de chaque sprint.
Le scrum master doit être le facilitateur, le coordinateur et le soutien pour l'équipe, pour produire un incrément livrable tout en veillant à l'atteinte des objectifs du sprint.
Dette technique : Définition
La dette technique fait référence aux choix de conception et de développement qui semblent être la solution la plus rapide ou la plus adéquate au moment d’aborder les développements d’un logiciel ou d’une application.
Rassurez-vous, aucun projet de développement n’est exempt de la dette technique.
La dette technique peut inclure :
- Du code mal organisé
- Des solutions d’architecture ou d’infrastructure temporaires
- Des tests ne couvrant pas la plupart du code, etc.
Exemple :
Choisir une taille de base de données qui fonctionne très bien au lancement du projet parce qu’il n’y a pas beaucoup de transactions, mais qui peut causer des problèmes de lenteur pour la suite du projet.
Le choix technique initial est peut-être dû à une inconnue, tel que le nombre de personnes qui vont se connecter à l’application ou à l’absence de visibilité sur le moyen et long terme.
La dette technique représente alors le coût futur de mises à jour ou de corrections nécessaires en raison de choix techniques initiaux.
Types de la dette technique
Il existe 2 types de dette technique :
1) Dette technique volontaire
Elle résulte des choix délibérés de conception ou d'implémentation.
Ces décisions génèrent souvent des problèmes dans le logiciel à long terme.
Elles sont prises consciemment pour atteindre des objectifs à court terme, comme pour accélérer la mise sur le marché d'un produit.
2) Dette technique involontaire
Celle-ci est due à des choix techniques qui entraînent des problèmes à long terme.
Ces choix n'ont pas été pris délibérément, comme le manque d’expérience de l’équipe ou l’utilisation de technologies inadaptées.
Quel est son impact ?
La dette technique peut avoir de nombreuses conséquences négatives sur un projet à moyen ou long terme :
- Des coûts de maintenance élevés dus à un code difficile à comprendre, à modifier et à maintenir.
- Des délais de développement prolongés puisque les développeurs mettent plus de temps à ajouter de nouvelles fonctionnalités ou à résoudre des problèmes.
- Image de marque dégradée dû aux bugs, des failles de sécurité et des problèmes de performances.
D’autres impacts sont aussi ressentis, qui ne concernent pas directement les clients :
- Difficultés à attirer et retenir les talents, puisque les développeurs expérimentés sont souvent réticents à travailler sur un projet avec une importante dette technique. Ceci va impliquer un grand turnover des ressources.
Certains experts estiment ainsi le coût de remplacement d'un salarié entre 6 à 9 mois de salaire.
Il y'a un risque de refonte complète du système dû à l’accumulation des problèmes techniques qui va engendrer un investissement considérable en temps et en ressources.
De plus, il y'a une perte de compétitivité sur le marché et renforcement des concurrents dû à l’absence d’évolutions majeurs.
Peut-elle être entièrement éliminée ?
La dette technique fait partie intégrante des projets de développement, qu'elle soit volontaire ou involontaire.
L'objectif est plutôt de :
- La gérer de manière proactive
- La minimiser autant que possible
- La rembourser régulièrement, plutôt que de chercher à s'en débarrasser complètement, qui est quasi-mission impossible.
Vous devez aussi travailler à "rembourser" et minimiser la dette technique.
Les bonnes pratiques pour réduire la dette technique
Il n’existe pas de recette universelle, mais il y a de bonnes pratiques pour vous aider à la réduire.
Tout dépend de votre contexte, de la taille du système, de son ancienneté, du modèle d'affaires sur lequel vous vous appuyez, de qui prend les décisions, etc.
1) Reconnaître la dette technique
Il ne faut jamais nier l’existence de la dette technique même si certaines entreprises contractent une dette technique sans s'en rendre compte.
Cependant, il arrive un moment où la dette technique n'est plus un avantage, mais un problème.
Plus tôt vous la reconnaîtrez, plus il sera facile pour vous de réduire votre dette technique.
2) Classer et documenter la dette
Le classement et la documentation sont une partie importante du remboursement de ce type de dette.
Vous devez indiquer :
- Le type de problème
- L'approche de remédiation
- La personne responsable
- Les conséquences de ne pas rembourser cette dette
3) Refactoriser et optimiser le code
C’est le fait de simplifier le code et sa lecture.
Exemple :
Vous avez des blocs de code pour :
- Calculer un prix de marchandise avec un rabais
- Calculer un prix de marchandise sans rabais
Il est utile dans ce cas d’avoir un seul bloc de code qui calcule le prix de la marchandise que cela soit avec ou sans rabais.
La refactorisation du code peut aussi inclure l’élimination des doublons entre autres.
4) Rédiger des tests automatisés
Les tests automatisés permettent de valider d’une manière automatique, et donc très rapidement, le comportement attendu du logiciel et de détecter des erreurs ou des régressions.
Exemple :
Plusieurs champs ne doivent accepter qu’un chiffre.
Les tests automatisés vont donc parcourir tous ces champs, pour vérifier qu’ils ne peuvent accepter que des chiffres et ne pas générer des erreurs lors de l’utilisation du logiciel.
Les tests automatiques ne doivent pas être utilisés que pour le remboursement de la dette technique, mais aussi pour livrer de nouvelles fonctionnalités.
5) Mettre en place une culture de revues de code
La revue de code est un processus créé par les développeurs les plus expérimentés pour relire le code et l’améliorer selon les principes précédemment mentionnés.
Comment équilibrer la dette technique et les nouvelles fonctionnalités dans un sprint ?
Après avoir compris la dette technique et ses conséquences, nous devons la rembourser.
En même temps, nous devons continuer à livrer de nouvelles fonctionnalités dans nos sprints.
C'est un défi de taille que d'apporter toute sa vision et son expérience pour trouver le juste équilibre.
Parmi les actions à entreprendre :
1) Définir des objectifs clairs de réduction de la dette technique à chaque sprint.
2) Réserver dans chaque sprint un pourcentage du temps (ex : 20%) pour le remboursement de la dette.
Dans ce cadre, il faudra obtenir l’engagement de l'équipe et des parties prenantes sur l'allocation de temps et les ressources nécessaires.
3) Identifier les synergies possibles entre le remboursement de la dette et le développement de nouvelles fonctionnalités.
Exemple :
Une nouvelle fonctionnalité va utiliser un code legacy pour fonctionner.
Utiliser cette nouvelle fonctionnalité pour refactoriser, optimiser, introduire un nouveau composant, etc.
À la fin, on se retrouve avec une nouvelle fonctionnalité, mais aussi avec une partie du code améliorée et une partie de la dette technique remboursée.
4) Profiter des moments de faible activité métier pour se concentrer sur la dette technique.
Exemple :
Si vous travaillez avec des comptables, profitez de la période de clôture comptable pour se concentrer sur la dette.
Doit-on calculer la dette technique dans la vélocité de l’équipe ?
Il est important de prendre en compte le remboursement de la dette technique dans le calcul de la vélocité de l'équipe.
Il est clair que le temps passé à rembourser la dette technique réduit la capacité disponible pour le développement de nouvelles fonctionnalités.
Et il est donc essentiel d'intégrer cette charge de travail dans le calcul de la vélocité.
Le fait d’inclure le remboursement de la dette dans la vélocité permet de donner une image plus fidèle des capacités réelles de l'équipe.
Ainsi, la prise en compte du remboursement de la dette technique dans la vélocité garantit une meilleure visibilité et une planification plus réaliste du travail de l'équipe.
Peut-on planifier un sprint pour rembourser la dette technique ?
Oui, si le besoin se justifie.
Il faut démontrer l'impact devenu trop négatif de la dette technique sur le produit et/ou la productivité, la qualité et les délais de livraison.
Bien sûr vous devez obtenir l'engagement de la direction sur l'importance de cette démarche.
Pour que le sprint dédié au remboursement de la dette technique soit efficace, il faudra définir des objectifs de réduction mesurables tels que :
- Couverture de tests à 80%
- Réduction de 50% du temps de chargement des données
- Résoudre 100% des vulnérabilités de sécurité de niveau critique
- Refactorer 3 composants clés pour améliorer leur lisibilité et testabilité
- etc
Conclusion
Que ce soit dans un sprint dédié ou dans chaque sprint, la dette technique doit être traitée tout au long du cycle de vie du projet, car elle représente un vrai défi pour les chefs de projets.
Il ne faut pas être tenté par la livraison de nouvelles fonctionnalités et se désintéresser de la dette technique.
Ce comportement ne fera qu'accumuler encore plus de dette technique.
En reconnaissant l’existence de la dette technique, et en étant conscient de l’intégrer dans la planification des sprints avec les ressources nécessaires, il est toujours possible d'équilibrer entre les nouvelles fonctionnalités et le remboursement de la dette technique.
Aucun projet n’est exempt de la dette technique.
C’est un défi permanent qui peut être relevé avec les bonnes pratiques et une vision à long terme.
