Loading...Dans mon précédent article, je vous présentais une définition de la dette technique d’un projet d’ingénierie logicielle et à qui il incombe de la gérer. Je vous dévoile maintenant tout ce qui rend les équipes de développement de moins en moins véloces, en clair, la dette fonctionnelle ou « functional debt ».
Qu’est-ce que la dette fonctionnelle ou « functional debt » ?
La dette fonctionnelle c’est donc :
- du code bien écrit mais pas terminé ou plus utilisé,
- mis en PROD et qui finit par polluer le code utile
- utilisé de manière peu régulière par les utilisateurs ou les clients du logiciel.
Bon cela ressemble à une définition du Larousse mais c’est la définition qui me semble la plus complète à date.
La dette fonctionnelle en quelques exemples
Rentrent dans cette catégorie, comme nous l’avons vu dans le précédent article :
- fonctions prototype,
- expérimentations,
- fonctionnalités réputées terminées mais qui n’ont pas l’usage et le succès escomptés,
- fonctionnalités qu’une réglementation a rendues obsolètes ou à revoir
(ex : l’introduction de nouvelles règles fiscales dans un logiciel de comptabilité)
Faites-vous assez souvent le ménage de votre code applicatif ? Ne laissez pas la Dette technique ni la dette fonctionnelle ralentir la vélocité de vos développeurs : code pas terminé, plus utilisé, prototypes, fonctions obsolètes… Les CTOs de SkillValue vous accompagnent dans la méthodologie (lean product development, agile, devops…) et les choix d’architecture technique de vos projets de développement avec des freelances. Crédit photo : Shutterstock.
Comment identifier et mesurer la dette fonctionnelle ?
Tout d’abord, pour trouver la dette fonctionnelle, il faut savoir l’identifier et la mesurer.
Dans le monde parallèle de la dette technique, de nombreux acteurs proposent des outils pour aider à identifier la dette technique dans un logiciel : tout comme dans l’article précédent, je ne peux que saluer la qualité de solutions comme CAST Software ou Sonar pour les plus désargentés d’entre nous.
Pour ce qui est de la dette fonctionnelle, pas possible à date de s’appuyer sur ce genre d’approche : évidemment pour un logiciel neuf, il est plus facile d’intégrer dans l’architecture des points de mesure dans le logiciel (tout comme il était plus facile de concevoir l’ajout d’un pot catalytique aux nouvelles gammes de véhicules qu’aux voitures existantes dans les années 90 : tiens, çà c’est un bon exemple de réglementation qui change).
Commençons par le plus dur : un logiciel existant
Une fois n’est pas coutume et pour respecter le principe de commencer par le plus risqué ou le plus complexe dans tout projet, je propose de parler de logiciels dont la dette s’est déjà installée au cours du temps. Je propose quand même de me « limiter » à des architectures récentes sur la base d’applications Web (type un logiciel SaaS écrit en .NET ou bien une application métier de gestion d’assurances sur portail web, tout cela hébergé sur Azure ou AWS).
Même si tout le monde ne fait pas cela, je ne suis pas en mesure de proposer des solutions concrètes sur toutes les architectures et technologies mais les principes devraient vous parler suffisamment pour pouvoir les adapter. Je suis d’ailleurs ouvert à vos commentaires et remarques. Contactez-moi.
Ne pas négliger les dinosaures : ils ont souvent beaucoup d’informations
Tout commence par une enquête auprès de vos collègues : commencez par les plus anciens ou expérimentés, ceux dont vous vous demandez pourquoi ils sont restés 10 ans dans la même boîte alors que c’est bien connu, si tu ne changes pas de boîte tous les 2 / 3 ans, tu t’encroûtes. La bonne vieille méthode consistant à leur demander :
- comment fonctionne l’application et
- ce qu’ils savent de l’utilisation réelle de telle ou telle classe ou tel ou tel composant ou bien partie du modèle de données
Vous vous rendrez compte qu’ils connaissent parfaitement l’appli et qu’ils sont heureux de pouvoir partager leur savoir.
Exemple de mesure de dette fonctionnelle
Par exemple, récemment, j’ai fait une revue de modèle de données avec mes équipes pour séparer :
- les tables qu’ils savaient obsolètes dans le modèle
- des tables qu’ils savaient utilisées et
- celles pour lesquelles ils avaient un doute.
Cette identification sur un modèle assurantiel de 900 tables a permis d’identifier plus de 300 tables inutiles par exemple (et donc le code de CRUDing, la Business Logic, les Vues, Modèles et Contrôleurs associés !!!!).
Consultez les équipes Ventes et Marketing au sujet de l’usage réel de votre application
Bon il y a aussi les équipes Ventes & Marketing. Si si, vous pouvez leur parler : ils en savent souvent beaucoup plus que vous ne le pensez sur l’usage réel de l’application. Que ce soit en termes de perception de performance ou d’utilité : ils peuvent vous donner une image que vous n’aurez qu’à inverser pour déterminer les zones qui ne semblent pas être utilisées car jamais citées.
Tout cela ne vous donne qu’une image des grandes zones à étudier plus en avant : comment faire pour être plus précis ?
C’est ce que nous verrons dans le prochain article ?
D’ici là, voici quelques lectures que je vous conseille :
L’article de Ward Cunningham sur la dette technique : c’est un MUST READ ! http:// wiki.c2.com/?TechnicalDebt
Lisez aussi mon précédent article sur le même sujet : Gérer la dette technique, c’est bien, mais qui gère la dette fonctionnelle ? – Part #1
