BT

Diffuser les connaissances et l'innovation dans le développement logiciel d'entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles La Dette Technique...N'Est Pas Technique : Comment Les Entreprises Peuvent La Régler ?

La Dette Technique...N'Est Pas Technique : Comment Les Entreprises Peuvent La Régler ?

This item in japanese

Favoris

Points Clés

  • La dette technique a un impact sur l'ensemble de l'entreprise, mais elle touche plus particulièrement les ingénieurs, car plus de dette technique signifie plus de bugs, de problèmes de performance, de temps d'arrêt, de lenteur de livraison, de manque de prévisibilité dans les sprints, et donc moins de temps pour travailler sur de nouveaux projets passionnants.
  • Les ingénieurs perdent sept heures par semaine sur la dette technique, qui est souvent invisible pour les parties prenantes. Parler aux parties prenantes non techniques en utilisant des termes opérationnels est le meilleur moyen de rendre la dette technique facilement visible.
  • Le désordre n'est pas toujours mauvais, tout comme la dette technique ne signifie pas toujours qu'il y a un problème. L'essentiel est d'éliminer la bonne quantité de dette technique au bon moment.
  • Les entreprises doivent s'efforcer de traiter la dette technique de manière proactive et continue. Le traitement continu de la dette technique donne aux équipes l'occasion de fournir régulièrement de la valeur et permet aux ingénieurs de prendre des décisions. 
  • À l'avenir, la dette technique deviendra moins un problème d'ingénierie et plus un prérequis fonctionnel important qui aidera à fournir plus de valeur à nos clients et à l'entreprise.
     
  •  

Dans cet article, trois experts - Alex Omeyer, Nicolas Carlo et Maarten Dalmijn - échangent sur les principales conclusions du rapport "State of Technical Debt 2021", notamment l'impact de la dette technique sur les équipes d'ingénieurs, les avantages et les inconvénients du traitement continu des travaux de maintenance, l'avenir de la dette technique et ce que chaque équipe d'ingénieurs peut faire pour communiquer l'importance du traitement de la dette technique aux dirigeants d'entreprise.

Enquête sur l'état de la Dette Technique 

Le rapport 2021 sur "l'Etat de la Dette Technique” a été créé par Stepsize, après avoir interrogé plus de 200 ingénieurs et responsables de l'ingénierie. Le rapport montre l'impact de la dette technique sur le moral des équipes d'ingénierie, la vélocité et l'expérience client. Les principales conclusions sont les suivantes :

  • 52 % des ingénieurs pensent que la dette technique a un impact négatif sur le moral de leur équipe. Plus de 60% des ingénieurs pensent que la dette technique déclenche des bugs, des pannes et ralentit le processus de développement.
  • L'ingénieur moyen consacre sept heures par semaine (environ une journée) à la dette technique.
  • La majorité des ingénieurs (66%) pensent que l'équipe livrerait jusqu'à 100% plus vite si elle avait un processus pour la dette technique.
  • Malgré le fait que les ingénieurs soient convaincus de l'impact négatif de la dette technique sur l'entreprise, 58% des entreprises n'ont toujours pas de processus de gestion de la dette technique.

Pourquoi la dette technique influe-t-elle sur le moral des équipes d'ingénieurs ?

Imaginez que vous êtes un cuisinier qui doit préparer de nombreux plats différents tous les jours dans une cuisine en désordre, pleine de poêles et de casseroles sales. Difficile de trouver facilement les ustensiles de cuisine dont vous avez besoin et de place pour préparer vos ingrédients. Malheureusement, vous n'avez pas le temps de nettoyer et vous êtes donc condamné à travailler dans cet environnement dantesque qui vous ralentit et rend la cuisine impossible.

Aimeriez-vous être cuisinier dans une telle cuisine ? Imaginez combien il serait frustrant de devoir préparer un plat dans de telles conditions à chaque heure, tous les jours de la journée en plus des retards inévitables et des clients mécontents.

Comme le souligne Dalmijn, "c'est la même situation dans laquelle se trouve un développeur de logiciels lorsqu'il travaille sur un système présentant une dette technique élevée. Ce gâchis ralentit les développeurs et les empêche même parfois de faire leur véritable travail. La dette technique peut aussi les empêcher d'être fiers du travail qu’ils font, car ils perdent beaucoup de temps à s'occuper d'obstacles gênants. Vous êtes comme un joueur de football qui doit marquer des buts uniquement de la tête, sans utiliser ses jambes pour tirer ou faire des passes. Il n’est pas étonnant que la dette technique soit source de frustration".

Le plus gros problème est que, contrairement à une cuisine sale, la dette technique est le plus souvent invisible pour nos parties prenantes non techniques. Ils ne peuvent que constater l'effet de ralentissement qu'elle a ; mais quand ils le font, il est souvent déjà trop tard. Tout tourne autour des nouvelles fonctionnalités, l'ajout constant de nouveau code sur des fondations déjà fragiles.

Un autre problème est qu'une dette technique trop importante oblige les équipes d'ingénieurs à être en mode pompier. La dette technique a un impact sur l'ensemble de l'entreprise, mais pour les ingénieurs, plus de dette technique signifie plus de bugs, plus de problèmes de performance, plus de temps d'arrêt, une livraison lente, un manque de prévisibilité dans les sprints et donc moins de temps passé à construire des choses sympa.

Les ingénieurs consacrent sept heures par semaine à la Dette Technique

"Je ne suis pas surpris que ce soit le cas", déclare Carlo. "Je pense que le développeur moyen gaspille encore plus de sept heures par semaine en dette technique. Clairement les développeurs passent la plupart de leur temps à lire / déboguer / tester le code existant."

Une étude de Microsoft publiée en 2017 a conclu que 58 % du temps des développeurs est consacré à la compréhension du code, surtout lorsque le logiciel est expédié en production et que vous devez désormais le maintenir. Un phénomène que les développeurs reconnaîtraient intuitivement eux-mêmes : moins vous êtes familier avec le code, plus cela prend du temps. Plus il y a de surprises en chemin, plus c'est long. Plus il est difficile de reproduire tous les scénarios, plus il faut de temps pour bien faire les choses ; c'est d’ailleurs là que de bons tests automatisés prouvent vraiment leur valeur.

Lire du code est plus difficile qu'en écrire. Un montant élevé de dette technique signifie souvent que vous avez plus de code à lire et que le code est plus difficile à comprendre. La dette technique signifie également que les membres de votre équipe comprendront seulement de petites parties du système sans en avoir une vue d'ensemble. 

Le temps perdu à résoudre ce problème est souvent invisible pour les parties prenantes non techniques et le gain de productivité est invisible jusqu'à ce qu'un autre changement soit effectué, et ce plusieurs mois plus tard. Une cuisine propre ne vous rend pas plus rapide tant que vous n'avez pas besoin d'y cuisiner. Nous entendons rarement un développeur dire : "Ma foi, ce changement a été facile parce que, la dernière fois nous avions passé plus de temps à corriger la dette technique !". Le gain de productivité est loin d’être évident ; d'où cette absence de temps supplémentaire alloué à la correction de la dette technique.

Les entreprises pourraient livrer jusqu'à 100% plus vite si elles maîtrisaient la dette technique

La maîtrise de la dette technique est une condition préalable à la livraison régulière de valeur, tout comme une cuisine organisée et propre est une condition préalable à la livraison régulière de plats délicieux. Ce qui ne signifie pas que vous ne devez pas avoir de dette technique. Vous aurez toujours un peu de désordre et c'est tant mieux. L'objectif n'est pas que tout soit en ordre mais de se débarrasser de ce qui vous ralentit et vous empêche de faire de la bonne cuisine.

"Dire que les entreprises pourraient livrer deux fois plus vite n'est pas la bonne façon de voir les choses à mon avis. Personne ne se demande s'il serait avantageux d'avoir une cuisine propre et ordonnée pour servir un restaurant rempli de clients pressés qui se plaindront si la préparation prend trop de temps ou si leur plat arrive froid", explique Dalmijn.

Cependant, le désordre n'est pas toujours mauvais. Parfois, il est même nécessaire pour rester dans le flow. Lorsque vous faites quelque chose de nouveau, par exemple la construction d'un lit Ikea, vous allez laisser des traces pendant le montage. Si vous nettoyez immédiatement ce désordre pendant que vous êtes occupé à construirel, vous tuez tout momentum. Il s'agit de régler la bonne quantité de dette technique au bon moment.

Traiter plus efficacement la dette technique est essentiel. Cela signifie qu'il ne faut pas se préoccuper autant de la dette technique dans les aspects de votre produit qui sont rarement utilisés ou modifiés. Cela signifie également que vos développeurs ne devraient pas avoir à justifier la réparation de la dette technique. De la même manière que le nettoyage de la cuisine fait partie de la cuisine, la réparation de la dette technique fait partie du codage.

"J'ai été surpris de voir des chiffres aussi élevés", déclare Omeyer. "Mais je peux les valider empiriquement. Pensez-y de cette façon : combien de fois avez-vous estimé qu'une fonctionnalité prendrait un sprint... pour en prendre finalement deux, voire trois ? Imaginez maintenant cela à l'échelle d'une entreprise entière et les ramifications que cela aurait. Il n'est pas difficile de croire que les entreprises qui maîtrisent vraiment leur dette technique livrent deux fois plus vite que celles qui ne le font pas."

Carlo pense que certaines entreprises pourraient livrer deux fois, trois fois, voire beaucoup plus vite. "J'ai expérimenté différentes approches de la qualité du code. Bien qu'elles ne soient pas comparables, j'ai pu constater la différence de productivité lorsque j'étais capable de livrer un changement significatif en production en une journée, au lieu de devoir attendre une semaine. C'est en fait un bon exercice d'auto-évaluation : combien de temps faut-il à un nouveau venu pour mettre en place le projet, effectuer une modification, la tester et la déployer en production ? La réponse peut aller de quelques heures à plusieurs semaines pour des projets de taille similaire."

Les avantages et les inconvénients de la gestion continue des travaux de maintenance

Le traitement continu de la dette technique est crucial pour la plupart des entreprises, mais surtout pour celles qui ont atteint le market-fit et visent à fournir des produits de qualité à leurs clients. Ce n'est pas toujours facile à réaliser, et il y a des côtés positifs et négatifs à cette approche.

Les avantages :

  • Une méthode de travail agile. Le travail de maintenance continue est une condition préalable à la livraison régulière de valeur. Une dette technique qui nécessite un projet distinct pour la reprendre en main signifie que vous ne serez pas en mesure de fournir de la valeur régulièrement.
  • L'amélioration du bien-être des développeurs. Personne n'aime travailler dans le désordre et, un projet pour traiter la dette technique signifie qu'il y a un désordre visible avec lequel les gens ont dû composer pendant un certain temps.
  • Une valeur commerciale plus élevée grâce à un meilleur délai de mise sur le marché des nouvelles fonctionnalités. La dette technique vous ralentit, et le coût réel n'est pas dans les heures de travail perdues par les développeurs, mais dans le coût de retard de mise sur le marché d'une nouvelle fonctionnalité. Le coût du retard de cette fonctionnalité peut être nettement supérieur à la perte de productivité des développeurs. C’est le véritable coût de la dette technique, et non toutes ces heures.
  • Vous n'avez pas besoin de demander la permission. Si vous jouez au boy-scout et qu’en nettoyant le code vous devez le modifier pour déployer une fonctionnalité dans le cadre de sa mise en œuvre alors vous n'avez pas besoin de demander un budget pour cela. Cela fait partie du travail, c’est vous l'expert.
  • C'est en fait plus facile de commencer. Même si vous n'êtes pas le leader technique, vous pouvez commencer par vous-même en isolant des petites choses que vous voulez nettoyer et en les abordant au fur et à mesure (renommer certaines variables, extraire une fonction...).

Les inconvénients :

  • Il est plus difficile de s'attaquer aux gros bouts de dette technique qui se sont accumulés au fil du temps (par exemple, mettre à niveau la bibliothèque ORM qui en est à quatre versions majeures de retard). Cependant, une fois que l'équipe sera suffisamment expérimentée, elle trouvera un moyen de diviser le travail en petites séquences. Cela peut généralement se faire de manière continue également, bien que cela nécessite d'avoir une vision claire de l'objectif final - ce qui pour la plupart des équipes est plus facile à faire via un projet.
  • Il est extrêmement facile de laisser les prévisibles pressions commerciales perturber le travail de maintenance continue. Et si les ingénieurs ne sont pas récompensés pour l'amélioration de la base de code (par exemple, si seules les nouvelles fonctionnalités sont célébrées ou donnent lieu à une progression de carrière), ils ne lui accorderont pas la priorité qu'elle mérite.
  • Le travail continu est invisible et ne suscite pas d'éloges. D'après mon expérience, de nombreuses entreprises célèbrent l’extinction des incendies et non leur prévention. Combien de fois un employé a-t-il été félicité pour avoir fait des heures supplémentaires afin de résoudre un problème de production ? Combien de fois un employé a-t-il été félicité pour avoir empêché les problèmes de se produire en premier lieu ? Le travail continu passe inaperçu. L'avantage est que vous n'avez pas besoin de demander la permission et que vous n'avez pas besoin de faire des efforts supplémentaires pour régler les problèmes. Mais vous ne serez pas fêté pour autant. C'est cette attitude que j'encouragerais les responsables techniques et les directeurs de technologie à changer : célébrez la prévention des incendies !

Ces trois étapes peuvent améliorer la situation en cas de dette technique lourde 

"J'aimerais que de plus en plus de développeurs soient confrontés au défi de travailler efficacement avec du code existant (legacy). Nous n'enseignons pas ces compétences. Tout comme nous n'enseignons pas vraiment "comment lire du code". Le mantra est "essayez, expérimentez et vous apprendrez", ce qui est amusant... jusqu'au point où les gens s'appuient sur ces expériences dans la vie réelle", déclare Carlo.

À mesure que le secteur mûrit, nous continuerons à élever la barre de la qualité. Il est difficile d'écrire des logiciels faciles à maintenir. C'est un défi pour les entreprises lorsque la rotation des développeurs est inférieure à deux ans (fuite des connaissances !) et que les développeurs les plus expérimentés cessent de coder à un moment donné. À l'avenir, nous verrons un regain d’intérêt pour ces sujets car nous aurons de plus en plus de programmes à maintenir.

Ces trois étapes peuvent améliorer la situation en cas de dette technique lourde :

  1. Demandez à l'équipe d'ingénierie d'identifier la dette technique de manière proactive. Rendez-la visible d'abord, puis vous pourrez commencer à vous y attaquer.

  2. Parlez aux parties prenantes non techniques en utilisant des termes opérationnels. Nous ne nous attaquons pas à la dette technique pour le plaisir, mais parce que nous voulons livrer des fonctionnalités plus rapidement. "Nous voulons réduire notre TTM (Time-To-Market)" ou "Nous pourrions réduire notre turnover RH si nous investissions un peu de temps dans la qualité du code", entre autres exemples. Mieux : partagez des chiffres réels exposant des faits. Encore mieux : faites le lien avec la finance : "Au cours des trois derniers mois, nous avons consacré 42 % de notre temps de développement à la correction de bugs ce qui nous a coûté 1 million de dollars".

  3. Rejoignez ces communautés pour partager des connaissances avec vos pairs :

Au cours des dernières années, nous avons assisté à une explosion de nouveaux outils privilégiant les développeurs. Dans le même temps, nous avons assisté à la montée en puissance du développeur, notamment du pouvoir dont il dispose pour choisir ses outils préférés. 

Les entreprises doivent s'efforcer de traiter la dette technique de manière proactive et continue. La seule façon d'y parvenir est le refactoring. Les entreprises agiles apprennent et évoluent en permanence. Si elles n'investissent pas dans l'amélioration continue de leurs bases de code, leur code restera statique et générera un lourd passif en quelques jours. 

Investir dans l'amélioration continue de la base de code permettra de réduire le nombre de bugs, les temps d'arrêt, les demandes d'assistance, mais aussi de rendre les livraisons plus prévisibles et plus rapides, et les ingénieurs plus heureux (ou de les fidéliser).

"J'espère que la dette technique cessera d'être un problème de développeur, invisible pour les parties prenantes de l'entreprise, et qu'elle deviendra une condition préalable importante à la production de valeur ajoutée pour nos clients et pour l'entreprise", déclare M. Dalmijn.

Voici un exemple de l'invisibilité de la dette technique. Une entreprise technologique a organisé une place de marché interne pour restructurer différentes équipes de développement. Chacun pouvait décider dans quelle équipe il voulait travailler. Il y en avait une dans laquelle personne ne voulait travailler et ce n'était pas à cause de ses membres. L'équipe travaillait sur un système legacy avec une dette technique.

L'entreprise a décidé de payer une prime pour rendre plus attrayant pour les développeurs de travailler dans cette équipe au système à la dette technique élevée. Ils étaient maintenant prêts à rejoindre cette équipe. Résultat : il y avait à présent une opportunité budgétaire claire pour résoudre la dette technique. La dette technique était désormais visible et avait une valeur monétaire. Soudain, il est devenu prioritaire de s'en occuper. Avant, personne ne s'en souciait vraiment, même si elle avait le même impact négatif sur l'entreprise et le moral.

Les développeurs s'en soucient déjà ; le temps est venu d’inciter tous les autres à s'en soucier également.
 

A propos des auteurs

Alex Omeyer est cofondateur et PDG de Stepsize, un outil de collaboration SaaS permettant aux équipes d'ingénieurs de gérer la dette technique. Il passe le plus clair de son temps à parler aux meilleures équipes de développement de logiciels au monde sur la façon dont elles gèrent la dette technique.

Nicolas Carlo est un développeur web qui aime construire des communautés et des logiciels maintenables. Il organise le meetup "Software Crafters Montréal", développe des extensions VS Code et partage des trucs et astuces pour travailler avec du code legacy sur le blog Understanding Legacy Code.

Maarten Dalmijn est directeur produit chez Rodeo, rédacteur de premier plan sur la gestion de produit avec Scrum, ambassadeur et rédacteur de Serious Scrum, et rédacteur d'un blog Agile Product Management.

 

Evaluer cet article

Pertinence
Style

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT