Comment gérer la dette technique pendant le développement ?

Qu’est-ce que la dette technique ?

La dette technique est un phénomène qui peut être défini comme l’accumulation de temps et d’efforts consacrés à la construction d’un logiciel qui n’est pas aussi bon qu’il aurait pu l’être, ou du moins aussi bon qu’il l’aurait été si le logiciel avait été construit par quelqu’un d’autre. C’est un exemple classique de “perte de temps”. Cela arrive souvent parce que les développeurs ne sont pas conscients de toutes leurs options pour améliorer leur code avant de le construire.

La dette technique est tout type de coût encouru en raison d’une mauvaise planification, de mauvaises décisions de conception ou d’autres problèmes avec le code lui-même. En bref : c’est tout ce qui pourrait vous causer des problèmes plus tard.

Et c’est là que ça devient intéressant : la dette technique ne s’additionne pas avec le temps ; il peut être utilisé à votre avantage en utilisant les bonnes stratégies de gestion !

Pourquoi identifier la Dette Technique ?

L’identification de la dette technique est essentielle pour plusieurs raisons. Il aide les développeurs à comprendre quelles parties de leur code valent la peine d’investir plus de temps dans l’optimisation. Cela peut les aider à se concentrer sur ces éléments et à éviter de perdre du temps sur des optimisations qui ne produiront pas de grands bénéfices.

Ne devrait-il pas être considéré comme des défauts et des bogues ?

Dans de nombreux cas, la dette technique n’est pas considérée comme des défauts ou des bogues car aucun outil ou technique n’est disponible pour permettre aux développeurs de toutes les organisations de communiquer définitivement sur ce concept avec des résultats reproductibles.

Bien que la dette technique ait longtemps été associée négativement, elle n’est pas nécessairement le résultat de défauts personnels de la part de l’équipe technique. Cela peut être mieux compris avec les quadrants de la dette technique de Martin Fowler.

Voici quelques étapes qui devraient vous mettre efficacement sur la bonne voie pour gérer la dette technique :

1. Suivi

Un bon moyen de gérer la dette technique est de la suivre. Et il existe de nombreuses façons de le faire. Le suivi, la planification et l’estimation sont les trois principales étapes du processus de la dette technique. Habituellement, le suivi sera la première étape car nous ne commencerons pas à travailler sur toutes les dettes techniques immédiatement. La raison de garder tout le monde dans un seau est que la dette technique est identifiée de différentes manières ou par différentes personnes qui révisent le code afin que rien ne puisse être manqué. En outre, cela nous aide dans d’autres activités telles que la mise à jour des efforts, la hiérarchisation et le suivi de l’état. Bien sûr, il existe de nombreux outils que nous pouvons utiliser pour le suivi, mais utilisez simplement les outils qui sont actuellement utilisés pour votre projet. Par exemple, si vous utilisez Jira, créez une fiche pour la dette technique dans le backlog/product log.

2. Planification

À des fins de planification, décidez de ce qui doit être fait dans le sprint en cours ou dans le sprint à venir. Nous pouvons inclure notre sprint actuel pour les raisons suivantes :

• Donnez toujours la priorité aux facteurs liés à la sécurité dans le sprint en cours. Cela inclut à la fois les problèmes de sécurité et les problèmes de performances.
• Si la dette a un impact sur les activités en production ou sur d’autres modules de votre produit (par exemple, l’intégrité des données), elle doit être incluse dans le sprint en cours.
• Si l’équipe a atteint son objectif de sprint avant la date prévue, examinez les priorités de la dette technique qui ont un impact sur votre objectif de sprint.
• Si la dette technique est pertinente pour le module de travail actuel, elle ne devrait pas avoir d’impact sur votre objectif de sprint.
• Si les dettes sont liées au remaniement du code, à la lisibilité et à l’optimisation, elles peuvent être planifiées dans le sprint à venir.

3. Estimation et disponibilité des ressources

• Avant d’assigner une tâche, discutez avec chaque développeur qui a travaillé sur le module précédemment et identifiez l’impact avant d’estimer les heures/jours.
• Examinez les tâches et le pipeline actuels du développeur et décidez qui peut être choisi pour une nouvelle tâche.

4. Identifier l’impact sur l’objectif actuel du sprint

Si un sprint est démarré avec certains objectifs, mais vers la fin du sprint, si nous rencontrons des problèmes dans la livraison de nos livrables en raison de nouvelles dettes incluses qui n’étaient pas initialement dans le plan de sprint, alors vous pouvez décider lesquelles doivent être déplacées au sprint suivant en fonction de sa pondération.

Suivez les étapes suivantes pour identifier l’impact :

• Étape 1 : Le poids de la dette qui a été choisie dans le sprint en cours.
• Étape 2 : Comparez la pondération de la dette avec les éléments disponibles dans le budget actuel de l’UE.
• Étape 3 : Décidez de la liste des articles qui ne seront pas livrés.
• Étape 4 : Sortez ces éléments du sprint et déplacez-les vers le backlog.

5. Publier les livrables de sprint dans Scrum Meet (Propriétaire de produit, Scrum master et Développeurs)

Pour vous assurer que tout le monde est sur la même longueur d’onde, publiez le plan avec les détails suivants :

• Combien d’articles sont
• Combien d’éléments ne sont pas
• Raison des changements d’objectifs.
• Les points d’action pour les éléments non livrés.
• Les avantages des changements d’objectifs et la manière dont ils ont ajouté de la valeur au produit.

Enfin, confirmez les changements d’objectif avec le propriétaire du produit avant de commencer à travailler dessus.

6. Commençons à travailler sur la dette.

Bien qu’il s’agisse de la dernière étape de la gestion des dettes, c’est la première étape pour les développeurs de commencer à travailler sur les dettes. Faites preuve de diligence pour garder une trace de toutes les tâches qui restent incomplètes, qu’elles soient grandes ou petites, elles contribuent toutes au montant total de la dette technique de votre projet.

La dette technique peut entraîner des fonctionnalités incomplètes et des versions retardées, ce qui peut entraîner une perte de crédibilité de votre équipe auprès des clients et des parties prenantes.

Alors, que se passe-t-il lorsque vous ne vous occupez pas de la dette technique ?

Il devient plus gros et plus coûteux à réparer. En fait, lorsque votre dette technique devient ingérable, elle peut rendre les choses plus difficiles pour tous les membres de votre équipe, et pas seulement pour les développeurs qui travaillent sur chaque morceau de code (ou pour les utilisateurs qui essaient de l’utiliser).

Quel que soit le ou les outils que vous choisissez, rappelez-vous que rien ne vaut une communication en face à face entre les développeurs et les responsables de l’assurance qualité qui comprennent l’impact de chaque élément et assurez-vous que tout le monde sait qui doit faire quoi. Cela contribue également à créer une meilleure communication, empathie et transparence entre les équipes de produits et d’ingénierie et rationalise le processus à long terme.

Ce blog est co-écrit par Ashok Maruthamuthu,Responsable technique chez Zuci Systems. Ashok possède une vaste expérience dans la gestion de la dette technique sur plusieurs projets.

Vous avez des questions ? Écrivez-nous ici.

Autres lectures intéressantes pour vous :

Le code spaghetti provient d’un mauvais leadership en ingénierie

Inconvénient de ne pas avoir de système formel de retour d’information sur l’analyse des défauts