Agile pourrait-il conduire les organisations vers une dette technique plus importante ? Oui

Selon Don Clos, développeur logiciel, qui propose une analyse détaillée de la situation

Agile est une méthodologie largement populaire dans le développement logiciel, et Scrum et Kanban en sont deux des implémentations les plus utilisées. Toutefois, quelle est son incidence sur la dette technique ? Don Clos, responsable du développement logiciel chez Compuware, une société américaine qui édite des logiciels, a déclaré que, contrairement à ce que beaucoup croient, Agile est une approche qui permet l'accumulation de la dette technique. Dans une analyse détaillée sur le sujet, il identifie au moins cinq situations qui entraînent l'accumulation de la dette technique pour les équipes.

Rapport entre la dette technique et la méthodologie Agile

La dette technique (aussi connu sous le nom de dette technologique ou dette de code) décrit les résultats obtenus lorsque les équipes de développement prennent des mesures pour accélérer la livraison d'une fonctionnalité ou d'un projet qui doit être revu ultérieurement. En d'autres termes, c'est le résultat de la priorité donnée à la livraison rapide plutôt qu'au code parfait. Ainsi, lorsque les gens parlent de dette technique, ils font en fait référence aux conséquences à long terme des changements "rapides et sales" (quick-and-dirty) apportés aux programmes pour respecter les délais au lieu de coder "la meilleure conception".


Selon Martin Fowler, auteur et conférencier spécialisé dans le développement de logiciels, la façon dont les organisations informatiques accumulent une dette technique est comparable à la façon dont les gens accumulent une dette financière. « La dette technique entraîne des paiements d'intérêts, qui se présentent sous la forme d'un effort supplémentaire que nous devons faire dans le futur en raison du choix d'une conception rapide et sale », a-t-il déclaré. D'après Don Clos, cette affirmation est particulièrement vraie pour les équipes qui font du développement Agile.

« Lorsque vous utilisez l'approche Agile, le rythme est plus rapide et vous fournissez les fonctionnalités dont les clients ont besoin dès que possible. Les choses doivent simplement fonctionner pour que vous puissiez continuer, et bien qu'elles doivent bien fonctionner, le travail "rapide et sale" se fait toujours et les dettes techniques s'accumulent », a expliqué Clos. Selon lui, c'est ce qui se passe avec les équipes mainframes, alors que de plus en plus d'équipes passent de la méthode Waterfall à la méthode Agile. Voici quelques défauts qu'il cite comme facteurs de l'accumulation de la dette technique.

• des pratiques de développement et d'exploitation mal définies, y compris des raccourcis techniques pour respecter les délais des projets ;
• manque de documentation sur la logique du code, ce qui empêche le développeur de comprendre un programme pour trouver le code à modifier ;
• des outils de développement inadaptés pour la gestion du code source, le débogage, les normes de codage et leur application, la couverture du code et les tests ;
• tests automatisés inexistants ou inefficaces, laissant la place à des erreurs ou à des tests négligés en raison de processus manuels.

Par ailleurs, il est important de noter que la dette technique est une expression inventée à l'origine par le développeur de logiciels Ward Cunningham. En plus d'être l'un des 17 auteurs du Manifeste Agile, Cunningham est également reconnu pour avoir inventé le wiki. Il a d'abord utilisé cette métaphore pour expliquer aux acteurs non techniques de WyCash, un système de gestion de portefeuille, pourquoi il fallait prévoir des ressources pour la refonte. Enfin, il est bon de savoir quelles activités (ou leur absence) sont à l'origine de l'endettement technique.

Dette technique : les origines probables selon Clos

Selon Clos, la première étape si vous décidez de rembourser votre dette technique, c'est de déterminer l'endroit où elle se situe. Alors, comment s'y prendre ? « En fonction de la culture, des processus et des outils qui entourent votre atelier informatique, l'endroit où vous voyez la dette technique s'accumuler le plus variera, en particulier pour ceux qui passent de Waterfall à Agile. Il existe au moins cinq cas communs dans lesquels la dette technique s'accumule pour les équipes mainframes qui se lancent dans cette aventure », a expliqué Clos. Voici les points que Clos a énumérés.

Tout d'abord, rappelons que le modèle Waterfall ou le développement en cascade est un modèle classique utilisé dans le cycle de vie du développement d'un système pour créer un système avec une approche linéaire et séquentielle. Il est appelé "cascade" parce que le modèle se développe systématiquement d'une phase à l'autre de manière descendante. Ce modèle est divisé en différentes phases et la sortie d'une phase est utilisée comme entrée de la phase suivante. Chaque phase doit être achevée avant le début de la phase suivante et il n'y a pas de chevauchement des phases.

Héritage de Waterfall

Selon lui, le développement en cascade vous donne le temps de planifier, de rechercher, de concevoir, de coder, de tester et de corriger les bogues avant de déployer votre nouvelle fonctionnalité. L'inconvénient est que vous ne livrez pas assez vite pour satisfaire les demandes des clients, des entreprises et du marketing. Par contre, le développement Agile peut être utilisé pour créer plus rapidement de petits éléments de fonctionnalités ciblées afin de répondre plus rapidement aux pressions de l'entreprise grâce à de nouvelles fonctionnalités. D'après Clos, c'est une bonne chose pour les entreprises et leurs clients à l'ère du numérique.

Cependant, il estime que, si vous faites passer des applications matures de Waterfall à Agile, la dette technique est souvent héritée de vieux systèmes et de vieux codes. Par rapport aux anciens systèmes, il a déclaré que tout système qui existe depuis un certain temps a très probablement sa...