29 févr. 2024 4 min read Functional Debt

Assurer la maîtrise de la dette fonctionnelle et technique

Tout d’abord, comprenons ce que nous entendons par :

La dette fonctionnelle se produit lorsqu’une application comporte des fonctionnalités partiellement conçues ou invisibles qui encombrent le code.
La dette technique survient lorsque la rapidité d’un projet prime sur la qualité, ce qui nécessite un travail de correction supplémentaire en aval. Cela se produit également lorsque les développeurs ne sont pas au courant des meilleures pratiques de développement, comme dans le cas d’un développeur junior.

Dette fonctionnelle

La dette fonctionnelle survient lorsque nous avons des fonctionnalités partiellement conçues ou que nous ne répondons pas aux besoins des utilisateurs. Cela résulte de choix de conception, comme la fourniture de fonctionnalités de base ou de caractéristiques techniques qui ne sont plus utilisées (tables obsolètes, code mort, etc.).

Comment mesurer cette dette ?

Contrairement à la dette technique, il n’existe pas d’outils simples pour mesurer la dette fonctionnelle. Cependant, des outils avancés tels que Code Scene ou CAST peuvent aider à détecter cette dette en se basant sur des hypothèses telles que :

Le code qui n’est jamais touché pourrait potentiellement être mort, mais pas nécessairement.
Les sections de code qui n’ont jamais été appelées ou les tables qui n’ont jamais été visitées sont peut-être mortes.
L’utilisation de ces outils peut fournir des informations, mais les discussions avec les développeurs d’applications sont également essentielles pour comprendre l’utilité de chaque composant, classe et table.

En fin de compte, pour chaque découverte, nous devons créer une tâche de correction, par exemple, avec une étiquette de dette fonctionnelle, et l’insérer dans le Backlog pour une correction future.

Dette fonctionnelle due à des fonctionnalités non implémentées ou partielles :

Cette situation existe généralement dans les projets où la livraison de fonctionnalités est mesurée par rapport à la livraison de valeur, les fonctionnalités non livrées ayant une faible valeur.
Lorsqu’une User Story est partiellement implémentée, créez une nouvelle User Story pour la partie non implémentée, en la liant à la User Story complète.
Lorsque vous validez votre US dans GIT, le message doit contenir le numéro du ticket.
Toute livraison de projet inachevée aux États-Unis est considérée comme une dette fonctionnelle.

Dette fonctionnelle due à un code mort :

Utilisez des outils d’introspection GIT tels que Code Scene ou CAST.
Surveillez votre application à l’aide d’outils tels que Dynatrace pour identifier les parties inutilisées de votre application.
Envisagez de faire appel à un expert en modernisation logicielle pour vous aider à refactoriser votre code afin d’améliorer la maîtrise du contenu.
Documentez dans votre outil de suivi des problèmes le type de problème : Dette fonctionnelle pour les dettes identifiées mais non corrigées.

Une meilleure visibilité des données pour les dirigeants, pour des décisions plus rapides concernant ...

Dette technique

La dette technique se produit lorsque des choix, délibérés ou non, sont faits pour livrer un projet rapidement, repoussant les corrections à plus tard.

Steve McConnell, ingénieur logiciel en chef chez Construx Software, a identifié deux types de dette technique :

Volontaire (type II) : C’est lorsqu’une organisation décide délibérément d’optimiser le présent plutôt que l’avenir.
Involontaire (type I) : cette opération est considérée comme accidentelle, souvent due à de mauvais choix de conception, et est généralement réalisée lors des mises à jour ou de l’ajout de nouvelles valeurs.

Dans le choix des mesures à prendre, nous considérons deux catégories de dettes :

Dette à long terme (type II.B) : Dette qui peut attendre et qui sera corrigée plus tard ou peut-être jamais.
Dette à court terme (Type II.A) : Dette qui sera corrigée à court terme, car elle est importante pour l’équipe, comme des sujets tactiquement intéressants comme la mise à jour d’une version du framework.
- Dette à court terme ciblée (type II.A.1) : raccourcis pris dans la conception de l’application, comme la livraison sans la dernière version du framework.
- Dette à court terme non ciblée (type II.A.2) : non-respect délibéré des règles de programmation de l’OO, identifiable par des odeurs de code.

Selon le type de dette que nous traitons, différentes mesures peuvent être mises en place pour en assurer le suivi. Nous ne faisons pas de distinction entre la dette de type I et la dette de type II.

Dette ciblée à court terme :

L’équipe met en place un tableau avec ses versions de framework d’application et les suit mensuellement. Notez que certains frameworks, comme Angular ou Java, changent de version tous les six mois. Pour Angular, le non-respect de ces versions peut avoir un impact significatif, moins avec Java. Créez un ticket « Dette technique » avec les détails de la mise à jour du framework.

Dette à court terme non ciblée :