L'avis de Gartner sur le développement d'applications pour 2012 préconise fortement l'abandon de la méthode en cascade, le passage à la méthode agile et la mise en œuvre d'un programme de remédiation de la dette technique. Ce programme doit être piloté par le Product Owner et soutenu par la direction. Mais qu'est-ce que la dette technique et comment la gérer ?
IEEE Software (Nov 2012) consacre un numéro entier à ce problème avec de nombreuses analyses et points de vue éclairants. Les pages de point-contrepoint ci-dessus montrent comment mettre un chiffre financier sur les données techniques. D'autre part, il est démontré que la dette technique a une plus grande portée que n'importe quel chiffre financier et qu'elle peut conduire au succès ou à l'échec des produits et des entreprises.
Point : La dette technique comme métaphore significative de la qualité du code par Israël Gat
Contrairement à la dette financière, la dette technique ne peut être calculée à partir du seul historique. La croissance de la dette financière en fonction du temps est déterminée en calculant les intérêts et en ajoutant les dollars dus sur des dettes plus anciennes aux dettes nouvellement contractées. En revanche, la dette technique accumulée en acceptant un niveau élevé de complexité il y a neuf mois est très différente de la dette technique accumulée en dupliquant rapidement certains blocs de code il y a six mois. Lorsque divers types de dette technique sont contractés à différents moments, le total général à un moment ultérieur est difficile à évaluer. L'équipe de développement peut encore se rappeler qu'il y a neuf mois, elle a emprunté une semaine de temps pour la complexité et, plus récemment, une journée pour la duplication du code. Cependant, entre ces deux "emprunts" et la dégradation du logiciel, faudra-t-il 6, 10, 20 ou 50 jours pour rembourser la dette ? Telle est la vraie question.
Pour déterminer votre niveau actuel de dette technique, vous devez partir de l'état actuel de votre code et creuser en profondeur : commencez par l'analyse du code, examinez les déficits de qualité, déterminez le temps de correction par déficit, déterminez le temps de correction par déficit, agrégez le temps de correction, puis agrégez le coût de la correction. Une fois la dette technique monétisée, toute partie prenante peut comprendre et apprécier ses implications opérationnelles, financières et commerciales. Un directeur financier n'aura aucun mal à comprendre une déclaration telle que "la dette technique du projet s'élève à $500 000". De même, ses collègues du marketing, des services professionnels ou de l'assistance à la clientèle évalueront facilement ce que ce niveau de dette technique signifie pour leurs départements.
Contrepoint : Une métaphore utile pour le risque - mal pratiquée par Christof Ebert
Ma propre définition (de la dette technique) est assez simple : la dette technique est la conséquence finale d'une mauvaise ingénierie d'un produit logiciel pour des avantages à court terme qui rendent le même travail plus coûteux à réaliser plus tard. Prenons l'exemple d'une étude de cas dans l'industrie.
En 1996, Netscape Navigator régnait sur le marché des moteurs de recherche avec une part de 80 % ; Internet Explorer de Microsoft détenait les 20 % restants. Cela aurait dû suffire à en faire une grosse vache à lait pour les décennies à venir. Pourtant, en 2002, la part de marché de Microsoft est passée à 96 % et celle de Netscape à seulement 2 %. Qu'est-ce qui s'est passé ? Lors de sa création en 1994, Netscape possédait un produit merveilleux et unique pour accéder à l'internet. Les ingénieurs l'ont fait évoluer rapidement mais ont perdu le contrôle - la vitesse a dominé l'ingénierie et la qualité, le code s'est dégradé avec chaque nouvelle fonction, et personne ne s'est rendu compte qu'ils avaient accumulé une dette qui ne pouvait pas être remboursée. Cela nous amène à notre première leçon : rendre la dette technique visible. Le code initial d'Explorer est également devenu incontrôlable, mais Microsoft a pris une autre direction : elle a opté pour une refonte complète d'Explorer, ce qui a retardé le produit mais l'a finalement aidé à dominer le marché. Notre deuxième leçon : évaluer les compromis. Microsoft a décidé qu'une équipe centrale d'architecture, la gestion des produits, la maintenabilité et la portabilité étaient ses principaux objectifs. En revanche, Netscape a intégré Java dans un nouveau produit, mais sans architecture ni conception de produit claires. L'entreprise a fini par disparaître. Notre troisième leçon : contrôler systématiquement la dette technique.
French 
English 
Spanish