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 pourrait-il conduire les organisations vers une dette technique plus importante ?
Don Clos, développeur logiciel, pense que oui et 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 :

[LIST][*]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[/*]...