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 part de dette technique. Selon lui, plus le système est ancien, plus les développeurs, certains meilleurs codeurs que d'autres, ont probablement travaillé dessus. Le code est continuellement mis à jour et modifié, les anciennes bases de code s'agrandissent avec le temps, et cela rend la maintenance plus difficile.

En ce qui concerne l'ancien code, Clos a déclaré que, plus l'on ajoute du code à des applications existantes, plus l'on risque d'introduire de nouvelles complexités ou de rompre la logique existante, ce qui se traduit par un plus grand nombre de défauts et une augmentation du temps de développement. Il estime que les bogues plus anciens sont généralement plus difficiles à trouver et à corriger. « Et même si les produits sont vérifiés pour leurs hautes performances avant leur sortie, la dette technique est inévitable lorsque vous évoluez rapidement », a-t-il déclaré.

« Elle s'accumule rapidement en raison du manque de temps disponible pour remanier le code, construire un environnement d'automatisation des tests ou même écrire une bonne documentation », a-t-il ajouté.

Documentation insuffisante

Clos a souligné qu'il est facile d'accumuler technique liée à la documentation, car les développeurs font le plus souvent un mauvais travail à ce stade. Il explique qu'avec Agile, les systèmes changent beaucoup plus fréquemment que Waterfall. Cela signifie que la documentation doit elle aussi évoluer rapidement. Cependant, selon l'analyste, les développeurs ont tendance à documenter les changements sans tenir compte du flux global de la documentation "produit" destinée aux clients.


Il estime que, si l'on n'accorde pas l'attention nécessaire à la manière dont la documentation est ajoutée à un guide, l'on se retrouve rapidement avec un ensemble d'instructions gonflées et inutilisables. « Lorsque vous commencez à transformer des applications Waterfall matures en processus Agile, la dette technique dans la documentation existante est généralement évidente, les instructions sont omises, des étapes sont omises, les choses ne sont pas transmises clairement et les nouvelles mises à jour exacerbent le problème », a-t-il déclaré.

La définition du travail à faire

Selon Clos, la définition de l'objectif peut aussi devenir un facteur d'accumulation de la dette technique. Toutefois, il a ajouté qu'il est difficile pour une dette technique de découler d'un nouveau développement si la définition du travail à faire est strictement suivie. Ce que cela signifie, c'est que :

• le travail de développement est achevé tel que défini dans la feuille de route et répond aux critères d'acceptation ;
• des cas de test manuels et/ou automatisés sont ajoutés et exécutés selon les besoins ;
• toute la documentation applicable est complétée ;
• il n'y a aucun défaut dans le nouveau code associé à l'histoire ;
• le propriétaire du produit a accepté les changements.

Par ailleurs, il poursuit en disant que, dans l'approche Agile, le propriétaire du produit est responsable de déclarer qu'un cahier des charges est terminé. Cela dit, l'équipe est responsable de faire respecter la définition de "terminé". Selon Clos, lorsque la définition de "terminé" n'est pas respectée, il peut en résulter une dette technique, notamment :

• un code inefficace ou un code qui ne satisfait pas les objectifs de l'entreprise ;
• des tests insuffisants, qui se manifestent dans les travaux futurs ;
• une documentation technique ou une documentation client insatisfaisante ;
• un code bogué qui nécessitera de futurs travaux de maintenance.

Prendre trop de travail

D'après Clos, une dette technique peut également survenir si votre équipe mainframe prend trop de travail. Il estime que cela est particulièrement vrai pour les équipes agiles qui travaillent en sprint. Il existerait plusieurs cas où cela peut se produire, dont :

• planification des sprints : selon Clos, lors de la planification d'un sprint, l'équipe doit être sûre de pouvoir terminer tous les points prévus pour ce sprint, sinon elle risque de se précipiter et de prendre des raccourcis pour terminer le travail, ce qui entraînera un code inefficace, des défauts et une mauvaise qualité ;
• Timebox Agile : selon Clos, de nombreuses équipes ont du mal à dire "non" et, au cours d'un sprint, elles en prennent plus qu'elles ne peuvent en accomplir. Il a déclaré que c'est particulièrement vrai dans le cadre de la Timebox Agile, où les équipes "sprintent" vers la livraison d'un produit minimum viable à la date d'achèvement prévue du projet ;
• travaux en cours : Clos estime que chaque membre de l'équipe doit travailler sur un point à la fois afin de minimiser les travaux en cours. Il a déclaré qu'un travail en cours trop important peut entraîner une dette technique, car les gens passent d'une tâche à l'autre au lieu de se concentrer sur l'achèvement du travail le plus prioritaire avant d'en entreprendre d'autres ;
• la dérive du champ d'application : Clos a déclaré ici que les équipes ne doivent pas se sentir obligées d'assumer plus de travail que ce qu'elles pensent pouvoir accomplir au cours d'un sprint. Selon lui, la dérive des objectifs consiste à ajouter du travail à un sprint de longueur fixe ou à un projet limité dans le temps sans ajouter de ressources. Il a déclaré que cela entraîne souvent une dette technique.

S'éloigner du travail d'un sprint

En dernière position, Clos a déclaré que, dans la méthodologie Agile, les équipes Scrum doivent se consacrer au travail de sprint. Les interruptions, telles que les problèmes des clients et les temps d'arrêt des applications, ont un impact négatif et entraînent souvent un travail de sprint incomplet ou des heures supplémentaires pour les développeurs. De même, il a déclaré que les développeurs doivent se concentrer sur leur travail de sprint et ne pas s'inquiéter d'être obligés de gérer des problèmes de clients et de production. Pour lui, c'est à cela que servent les équipes de solutions clients.

Selon lui, ces dernières sont là pour s'assurer que les clients reçoivent l'attention qu'ils méritent pendant que les développeurs produisent les fonctionnalités dont les clients ont besoin. Néanmoins, il a déclaré qu'il a un point auquel il faut faire attention. « Bien sûr, le fait de toujours se concentrer sur les nouveaux développements peut entraîner une dette technique. Il faut consacrer du temps et des ressources pour remanier et maintenir correctement le code, améliorer les tests automatisés et mettre à jour la documentation existante. Cela n'ajoute pas de nouvelles fonctionnalités, mais évite à l'équipe de ralentir et la rend plus efficace à long terme », a déclaré Clos.

« La technologie a progressé et a fourni des fonctionnalités matérielles, logicielles et des fonctionnalités de réseau plus efficaces et plus performantes dont il peut être nécessaire de modifier le code pour en tirer parti. Plus il est facile de lire et de comprendre le code, plus il est facile de le changer et de le modifier », a-t-il ajouté.

Conclusion

« La dette technique n'est évidemment pas limitée aux équipes qui s'appuient sur la méthodologie Agile, et il y a de fortes chances que ces points s'appliquent à de nombreuses équipes qui se basent sur l'approche Waterfall, bien que dans une mesure différente. Quoi qu'il en soit, toutes les équipes mainframes sont aujourd'hui tenues d'aller plus vite. Qu'elles s'efforcent de devenir agiles ou qu'elles se battent pour demeurer dans l'approche Waterfall, lorsque vous allez plus vite, la dette technique s'accumule », a déclaré Don Clos en conclusion à son analyse.

Source : Don Clos

Et vous ?

Que pensez-vous des différents points abordés par Don Clos ?
Pensez-vous qu'Agile contribue à l'accumulation de la dette technique ?
Selon vous, comment les organisations peuvent-elles payer la dette technique ?

Voir aussi

La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas, selon Gene Bond, directeur exécutif chez iiSM.ORG

« Agile est un cancer », pour Erik Meijer, qui estime qu'il doit être banni une fois pour toutes

Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile

Comment l'Agile s'est détourné de son chemin et comment corriger cela, explique l'un des auteurs du Manifeste Agile