Dette fonctionnelle vs Dette technique dans le développement de logiciels

De Wiki Agile
Version datée du 1 mars 2024 à 17:23 par Fabrice Aimetti (discussion | contributions) (Page créée avec « Category: Portail Product Owner Category: Dette technique Auteur : Roman Predein<br /> Source : [https://apiumhub.com/tech-blog-barcelona/technical-debt/ Functional Debt Vs. Technical Debt In Software Development]<br /> Date : 25/04/2020<br /> ---- Traducteur : Fabrice Aimetti<br /> Date : 01/03/2024<br /> ---- Traduction :<br /> <br /> Toute personne ayant participé au développement d'un logiciel connaît probablement le terme "dette technique". Il s'a... »)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)

Auteur : Roman Predein
Source : Functional Debt Vs. Technical Debt In Software Development
Date : 25/04/2020


Traducteur : Fabrice Aimetti
Date : 01/03/2024


Traduction :

Toute personne ayant participé au développement d'un logiciel connaît probablement le terme "dette technique". Il s'agit d'une métaphore brillante issue du monde de la finance qui représente le comportement de la maintenance du code et de l'évolutivité au fil du temps. J'aimerais parler aujourd'hui de la dette logicielle, de la dette fonctionnelle et de la dette technique.

Dette technique

Chaque fois que vous êtes obligé de laisser certaines parties de votre code avec une mention "à faire", "à remanier" (à refactorer) ou "à revoir plus tard", c'est un élément de dette supplémentaire que vous accumulez. De cette façon, vous prenez de l'argent pour acheter du temps. Vous respectez le délai, vous lancez le produit à temps et vous avez un prototype à présenter lors d'un cycle d'investissement. Mais vous ne pouvez pas oublier les réductions de la qualité du code, car il s'agit de votre dette. C'est quelque chose dont vous êtes redevable, c'est quelque chose que vous devez rembourser.

Si vous l'ignorez et que vous continuez à construire dessus, votre produit deviendra progressivement moins stable et moins évolutif, et son coût de maintenance montera en flèche. Pour garder l'analogie avec le monde réel, c'est comme si vous preniez un nouveau prêt pour rembourser celui que vous avez pris plus tôt, de manière répétée.

Au début, tout semble bien se passer. Mais au fur et à mesure que le prêt augmente pour couvrir les intérêts et les autres dépenses, c'est comme une boule de neige que l'on ne peut pas arrêter. C'est pourquoi il est important d'allouer le temps nécessaire au remaniement (refactoring) et même parfois à la refonte des parties du code qui ont été identifiées.

Même si nous connaissons très bien cette situation, nous avons trouvé une solution pour respecter le délai (livrer à temps) et éviter la dette technique. Mais en fin de compte, nous obtenons une nouvelle forme de dette. Quelque chose que j'aime appeler la dette fonctionnelle.