IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bill Fassinou

301PARTAGES

27  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de stardeath
Expert confirmé https://www.developpez.com
Le 24/02/2021 à 22:52
Citation Envoyé par Bill Fassinou Voir le message
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 ?
perso, je déteste les méthodologies agiles, peut être déjà parce que j'ai l'impression que dans toutes les boites dans lesquelles je suis passé, elles ne prennent qu'un ou 2 points d'une méthodologie et jettent le reste.

donc je pense que, peut être, les méthodologies agiles ne provoquent pas une aggravation de la dette technique, mais en tout cas les appliquer mal et négliger le reste, effectivement, ça n'aide en rien.

la nécessité de livrer pour l'année dernière est sûrement beaucoup plus responsable des problèmes que l'agilité, mais comme j'ai dit, je suis mauvais public.
15  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 25/02/2021 à 14:48
Citation Envoyé par stardeath Voir le message
la nécessité de livrer pour l'année dernière est sûrement beaucoup plus responsable des problèmes que l'agilité, mais comme j'ai dit, je suis mauvais public.
En ce qui me concerne, tu prêches un convaincu.

Plus généralement, un sprint de deux semaines, toutes les deux semaines, ça veut dire qu'on est à vitesse maximale tout le temps. Que des humains doivent être à 100% tout le temps. Rien que ça, ça me fait tiquer. Ca veut aussi dire que personne ne prend jamais le temps de penser l'architecture dans sa globalité. Pas étonnant que ça pose des problèmes.

Une équipe agile chez nous, qui était sur un projet critique, est allée voir la chef, et lui a dit "il nous faut 15 jours ouvrés pour tout refactorer, sinon on va dans le mur". La chef a accepté, ce qui a vraisemblablement sauvé le projet (et peut-être la boite). Mais, pour le coup, c'était pas du vrai agile : un sprint ou il n'y arien d'autre à montrer qu'une liste sans fin de composants refactorés, c'est l'antithèse de l'agile. Mais c'était nécessaires. Quelle proportion de décideurs sont capables de dire oui à une demande pareille?
10  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 25/02/2021 à 17:00
Je suis pas convaincu qu'une méthode soit plus propice à la dette technique que les autres. Ce qui créer de la dette c'est

  • les mauvaise estimation de temps. : Il faut aller vite , on fait donc au plus rapide et c'est rarement le mieux. Ca inclus aussi les spéc foireuse puisqu'on arrive pas à les chiffrer correctement
  • des contraintes particulières : Typiquement sur certains projets ou je bosse on nous impose une "forward compatibility" qui empêche de casser certaines chose pour faire mieux.
  • le manque de compétence de l'équipe


A la limite je dirais même que l'agile peut permettre d'intercaler quelques sprint de refactoring si vraiment c'est le bordel , là ou sur des méthode plus traditionnel ca n'arrivera , éventuellement, qu'à la fin.

perso, je déteste les méthodologies agiles, peut être déjà parce que j'ai l'impression que dans toutes les boites dans lesquelles je suis passé, elles ne prennent qu'un ou 2 points d'une méthodologie et jettent le reste.
C'est un autre débat , mais je pense qu'au contraire c'est une très bonne chose de ne prendre dans les méthodes agile ce qui colle à l'équipe. Vouloir appliquer à la lettre une méthode ca ne fonctionne que très rarement. Après y'en a qui se dise agile alors qu'il ne font que de la gestion de crise en permanence.
9  0 
Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 25/02/2021 à 13:07
Je pense que l'analyse est biaisée de plusieurs manière.

déjà, l'agilité quand on fait partie d'une sorte d'ESN, ca commence mal.(c'est un peu antinomique... parce que le postulat de base de transparence et d’honnêteté ne peut pas être respecté). En plus, ca met toujours les ESN en difficulté pour faire un contrat... car en agile on vend du temps et pas de la réalisation... ce qui est difficile à contractualiser, dans tous les pays.

En plus, les défauts qu'ils citent, à savoir la suppression des tests unitaires, les outils de dev pas bien configuré... n'ont rien à voir avec l'agilité, mais avec la capacité du PO à comprendre que dans chaque sprint, il faut laisser le temps aux équipes de bien faire les choses(définition du done, part de tickets techniques, etc...)

Enfin, il est important de noter que contrairement à ce qu'il dit, le but d'un sprint n'est pas d'en mettre le plus possible et de le réaliser... si une équipe réalise 100% de ses objectifs a chaque sprint, elle n'est pas bonne. Soit elle prend de la marge, soit elle bosse sur un rythme pas soutenable ou en dégradant la qualité pou tenir les délais... ce qui va a l'encontre des principes de l'agilité.
Le découpage en sprint n'est qu'une manière d'estimer grossièrement ce que sera notre travail pendant 2 semaines. Après, la vie étant ce qu'elle est, on fait au mieux avec les impératifs qu'on a, et on livre ce que l'on peut livrer en essayant de s'approcher autant que possible de l'esprit recherché par le PO. Mais un scrum master qui dit : moi je livre cette nouvelle fonction importante dans 10 jours quoi qu'il arrive... ne fait pas son travail.

toute la logique de l'agilité est de prendre en compte le réel pour accepter ce qui est... et essayer d'anticiper au mieux.
8  0 
Avatar de Kikuts
Membre éprouvé https://www.developpez.com
Le 25/02/2021 à 15:37
Pour avoir eu la chance de travailler dans plusieurs boites sur des projets de tailles et complexités différentes, j'ai constaté plusieurs problèmes.

Faire de l'agile à sa sauce : on prend 30% de la méthodo, le reste, bof, c'est chiant donc à la poubelle => forcément ça n'ira pas : si chaque société propose sa propre définition de l'agilité, on ne s'en sort pas.

Sous estimer les tâches : pas de temps allouer à la réalisation de la documentation, pas de temps pour les tests manuels et automatisé, la relecture de code et les retours.

Commencer des tâches qui ne sont correctement décrites / absence de maquette. "oh c'est simple y a juste 2 champs à ajouter et 1 bouton" alors oui si on sait exactement où les mettre, ça va vite, mais si on doit aller à la pêche aux infos, sur une tâche estimée à une demie journée, n a déjà perdu 1h à attendre que le "product owner" sorte de sa réunion, encore 1h pour qu'il se renseigne, 1h pour retrouver la documentation, 1h pour avoir le complément d'info car la doc était pas à jour. Bref, j'en rajoute peut être un peu, mais ça arrive plus souvent qu'on ne le pense.

Ensuite, le plus gros problème, c'est de négliger les sprints d'architecture en début de projet : c'est surtout à ce niveau que ça fait TOUTE la différence selon mon expérience : une société qui prend le temps de faire des tâches pour l'archi et ne pas "itérer" avant de pouvoir commencer, c'est une source de problème à moyen terme totalement désastreuse.
J'ai adoré travailler sur des projets avec des Sprint 0 - 1, Sprint 0 - 2, Sprint 0 - 3 etc jusqu'à ce que l'archi et les composants nécessaires pour dérouler le projet soient en place.
Par exemple :
- ORM : PoC pour démontrer les différentes couches à mettre en œuvre pour communiquer avec la base et remonter les infos jusqu'à l'UI (service, injection de dépendance etc)
- Logs : pouvoir remonter et piloter les logs depuis un dashboard : ça fait économiser énormément de temps d'avoir un maximum d'info
- Metrics : il peut être intéressant de connaitre la fréquence d'utilisation d'un module, d'une fonctionnalité. Ici encore, avoir un dashboard qui met le tout en évidence de façon synthétique fera gagner du temps. Ce genre de pratique permet de savoir si une refactorisation/optimisation/refonte/etc, vaut le coup : pourquoi passer 2 sprints à revoir un module utilisé par 2% des clients et que l'utilisation faite par ces 2% représente 5% du temps d'utilisation du logiciel ?
- Framework : méthodes d'extension, helpers, utilities, etc
- composants UI : point crucial et souvent négligé : on créé les composants au fur et à mesure des besoins... Alors là, c'est une méthode infaillible pour avoir du code crade, implémenté de 10 façons différentes et super emmerdant à refactoriser/tester.
Il ne faut pas être un cador pour anticiper des besoins récurrents en terme d'UI. Exemple :
Est-ce que l'appli aura besoin d'un DataGrid filtrable ?
Est-ce que l'appli proposera des liste déroulantes à choix multiples ? Si oui, est-ce qu'on aura besoin d'un bouton aucun/tous dedans ? etc.
Des présentations sous forme d'onglet ?
Des fenêtre de dialogue avec plus de choix que "oui" "non" ?
Des notifications ?
Alors oui, il est possible qu'on développe des contrôles qui ne seront pas utilisés (YAGNI) mais qu'est-ce que ça change la vie quand 10 développeurs différents sont capables à peu de chose près de pondre une UI avec les mêmes composants rapidement sans perdre 1 semaine à créer un nouveau composant. Ca permet d'estimer les réalisations avec beaucoup plus de précision puisque les composants existent en grande majorité.
- thème : on rajoute des thèmes après coup, on oublie de l'appliquer à de vieux composants, on a des visuels différents, pas les mêmes marges, des couleurs différentes etc. Que de temps perdu à aligner le tout après coup alors que ça peut s'anticiper.

Les projets qui anticipaient un max de chose en amont se sont avérés bien plus agile par la suite que celles qui négligeaient ces aspects. Après, c'est mon retour d'expérience perso.
8  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 26/02/2021 à 8:43
Sujet intéressant que celui de la dette technique où il n'est jamais facile de faire le tri et de hiérarchiser les facteurs, tant ils sont nombreux.

Tout d'abord, j'aurais tendance à dire que la méthode sur ce sujet précis n'est pas l'ennemi. Si on n'a pas envie, ou pas les moyens de faire du "bon boulot", que la méthode soit Agile ou Waterfall, ou un mix des deux, on aboutira fatalement à un SI fait de bric et de broc, de rustines faites dans l'urgence ou par incompétence, ou les deux à la fois, croulant sous un héritage rigide et obsolète.

Il est de bon ton et à la mode de taper sur l'Agile. Parfois par méconnaissance, parfois par paresse intellectuelle. Cette méthode a des défauts et n'est pas adapté à tous les projets, mais dire qu'elle est la principale responsable de la dette technique d'une entreprise, c'est un peu fort de café. Les organisations n'ont pas attendu de se mettre aux méthodes Agile pour voir apparaître des boulets techniques dont elles ont du mal à s'en défaire, malgré des moyens financiers parfois colossaux.

Les deux principaux facteurs qui me semblent directement contribuer à la dette technique sont :

* Les personnes : sauf à vouloir être dans le déni, nous sommes tous contributeurs à des degrés divers d'une dette technique. Chaque décision prise, chaque ligne de code écrite, peut potentiellement se révéler à long terme être de la dette technique. Tout simplement car les besoins évoluent et l'état de l'art dans notre milieu évolue sans cesse. Je dis souvent qu'il ne sert à rien de voir 10 ans à l'avance, c'est ridicule, cependant, il est toujours bon d'avoir quelques coups d'avance.
Le niveau de compétence des personnes est important pour limiter la dette technique, mais bizarrement, et je suis pourtant un grand avocat de remettre en avant la technique, avoir un développeur très compétent par rapport au reste de l'équipe peut aussi poser des problèmes. Ce dernier pouvant être difficile à manager, à canaliser et à faire rentrer dans un certain schéma global.

* L'organisation : il y a des formes d'organisation, des cultures d'entreprise qui favorisent davantage la dette technique que d'autres. Pour avoir bossé dans différent secteur, j'ai pu constater que les petites organisations avaient tendance à favoriser la culture de la bidouille et du "chacun fait comme il veut". Ce qui est très bien pour l'innovation, mais a ses limites lors du passage à l'échelle et en terme de pérennité et d'évolutivité. A contrario, les organisations plus grosses, avec davantage de process limitent ce problème avec l'existence de normes, même partielles, mais en contrepartie génèrent de la dette technique par la lenteur de la mise en œuvre.

Pour limiter la dette technique, il convient donc d'être à la fois rapide dans la mise en œuvre et structuré. Ce n'est pas antinomique avec les méthodes Agile.
La dette technique, c'est comme la poussière, il faut passer le balai tous les jours.
C'est donc plus une question de volonté au quotidien, de faire régulièrement de l'administratif (documentation) ou des tâches rébarbatives (refactoring, mise à jour des suites de tests, etc) que d'une méthode sur un projet donné.
7  0 
Avatar de kunnskap
Membre éclairé https://www.developpez.com
Le 26/02/2021 à 16:47
Tout part de la volonté des décideurs de projet: si ils ne sont là que pour faire de la merde et ne cherchent pas l'amélioration, laissez tomber, peu importe la méthode ce sera un fiasco.

J'ai fait des sprints de 15 jours en agile pendant des années sur un progiciel, les livrables étaient testés, fonctionnels, il n'y a jamais eu de crash en production, mais toute l'équipe bossait dans le même sens. Si il y avait des portions à refactoriser, et bien c'est une fiche à intégrer dans un sprint, c'est tout. Et j'ai pu refondre 75% du code du projet au fil des sprints tout en patchant les bugs et en ajoutant du fonctionnel, une énorme partie de la dette a été soldée ainsi et ce fut un succès. Couplé à une approche DevOps ont a pu améliorer les retours clients et les retours en interne des salariés du support technique.

L'agilité, l'approche DevOps, sont des états d'esprit à avoir, ils traduisent une autre façon d'appréhender l'informatique et son utilisation par tous les acteurs. Malheureusement j'en ai croisé beaucoup qui n'ont pas cette approche, ils considèrent que c'est une perte de temps d'améliorer les systèmes dans ce sens. Ils ne voient pas le gouffre financier que les coûts cachés induits par la dette technique amène, puisque c'est de l'argent indirectement dépensé quand j'annonce qu'il me faut 10 jours pour le faire au lieu de 5.

Par contre, quand on leur dit que la modif est facile à implémenter et que j'en ai pour 2 jours, j'entends "ah bah c'est cool!"
Oui, mais réveilles toi, j'ai passé 2 semaines à la conception initiale. Merci l'anticipation. On a rien sans rien, si tu veux aller vite au début, t'iras lentement plus tard!
7  1 
Avatar de pdcdec
Futur Membre du Club https://www.developpez.com
Le 05/03/2021 à 9:07
Salut à tous,

Comme facteur important de dette technique, j'ai souvent constaté que les cahiers des charges et les spécifications détaillées sont très défaillants.

Ca n'est pas seulement parce qu'on y passe trop peu de temps. C'est plus grave : on ne sait pas écouter le client et on ne sait pas l'aider à exprimer ses besoins. Si j'osais quitter le domaine technique pur un instant, je dirais qu'on manque parfois d'empathie.

Pour pallier ce problème, en tant que spécialiste UX/UI, je participe avec le PO aux interviews client et, en parallèle des specifications "classiques", je réalise un prototype très réaliste (avec des interactions avancées puisque j'utilise la programmation simple d'Axure).

Quand je réalise le proto, je tombe sur des dizaines de questions qui obligent à préciser le métier. Je suis obligé donc de comprendre le fonctionnel dans le détail (là où il y a le diable, vous savez), sinon, je suis bloqué. Et il vaut mieux traiter ces points en amont que plus tard en dev...

Ainsi, le client valide les specs en "jouant" avec le proto et en se l'appropriant. Ca devient son "bébé".

Ce qui est difficile parfois, c'est de faire comprendre qu'il faut investir plusieurs jours d'étude supplémentaires pour prototyper. Pour les cas compliqués, ça peut représenter jusqu'à 5 à 10% de la charge de développement.

Je conçois que ça puisse sembler énorme, mais, après des dizaines et des dizaines de projets, je peux témoigner que, du point de vue dette technique, nous avons toujours été largement gagnants.

Quand je dis "nous", c'est nos équipes, mais aussi les clients qui apprécient cette façon de faire.

Voilà, ça n'est que mon expérience concrète, mais si ça peut aider certains à réduire la dette...

Phil
4  1 
Avatar de stardeath
Expert confirmé https://www.developpez.com
Le 25/02/2021 à 17:48
Citation Envoyé par grunk Voir le message
C'est un autre débat , mais je pense qu'au contraire c'est une très bonne chose de ne prendre dans les méthodes agile ce qui colle à l'équipe. Vouloir appliquer à la lettre une méthode ca ne fonctionne que très rarement. Après y'en a qui se dise agile alors qu'il ne font que de la gestion de crise en permanence.
c'est possiblement un autre débat, mais quand même, si au final tu te dis agile parce que tu fais un morning meeting (véridique, j'ai déjà subit ce type "d'agilité", tout ce qui sera tenté d'être construit par la suite sera naze.
parce qu'en plus, d'après mon expérience, on ne prend pas d'agile ce qui colle à l'équipe, mais ce qui plaît à une hiérarchie et en général ça ne colle pas à l'équipe, mais on doit subir de la même manière.
et quand, sous couvert ce cette agilité, tu délaisses les specs (genre les specs fonctionnelles faites par des dévs), les tests (on m'a demandé plusieurs fois de ne pas tester, car ça prend du temps), la qualité de dév, etc., faut pas s'étonner d'avoir une dette qui devient encore plus ingérable.

après on est toujours au même point, j'ai toujours eut l'impression que malgré qu'on me vende de l'agile, je n'en ai jamais fait.
ça donnait surtout l'excuse de ne pas traiter les problèmes parce que pas dans un sprint, une road map, etc.
2  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 25/02/2021 à 21:00
Citation Envoyé par grunk Voir le message
Je suis pas convaincu qu'une méthode soit plus propice à la dette technique que les autres.
L'une des sources de la dette technique est le fait de s'engager à la fois sur le périmètre et le délai de livraison. En effet, en cas d'estimation optimiste, les développeurs, pour essayer de tenir les délais à court terme, produisent un résultat dont la qualité est en dessous de ce qu'ils savent faire. Si la méthode rend la qualité prioritaire sur le périmètre, alors cela fait une source de dette technique en moins.

Par exemple, en vrai SCRUM, la qualité ne diminue pas en cours de sprint. En cas de problème d'estimation, la variable d'ajustement, c'est le périmètre. La DOD (Definition Of Done) doit être respectée, ce qui limite la croissance de la dette technique.

Je cite le guide SCRUM :
During the Sprint:
  • No changes are made that would endanger the Sprint Goal;
  • Quality does not decrease;
  • The Product Backlog is refined as needed; and,
  • Scope may be clarified and renegotiated with the Product Owner as more is learned.
Cela dit, parmi les entreprises qui disent faire du SCRUM, peu en font vraiment.
2  0