Une bonne gestion de la dette technique fait la différence entre un projet logiciel réussi et un échec. Ignorer ou ne pas reconnaître la dette technique peut entraîner une hausse des coûts de développement et de faibles rendements financiers. Donc, étant donné les enjeux, comprendre et traiter la dette technique devrait être une priorité pour les ingénieurs logiciels et les décideurs.
La dette technique ou dette de code n'est pas nécessairement négative ; elle peut parfois constituer un levier stratégique pour votre projet à long terme. Ainsi, si vous choisissez de contracter une dette technique, cela repose généralement sur une stratégie, une intention et une raison d'être. Et même si c'est risqué, cela peut être très bénéfique. Presque toutes les entreprises ont un certain degré de dette technique. L'astuce consiste à savoir comment l'identifier et la gérer. Cet article de blog vous aide à y parvenir. Voyons donc ce qu'est la dette technique, quels types de dettes existent, comment elles influent sur votre processus de développement et comment vous pouvez les gérer.
Dette technique, dette technologique, ou dette de code désigne le fait de retarder ou d'omettre certaines tâches pour terminer un projet ou atteindre un objectif plus rapidement, ce qui entraîne toutefois des retouches ultérieures au cours du cycle de vie du projet. On peut comparer cela à la construction d'une maison sans plans complets. La construction pourrait être terminée plus tôt, mais la maison présentera d'importants problèmes structurels qui nécessiteront plus de temps et d'argent pour être réparés plus tard.
Dans le domaine du développement logiciel, il est courant de lancer une fonctionnalité rapidement afin d'observer son évolution. Une fois qu'elle a pris de l'ampleur, nous pouvons l'adapter à sa nouvelle dimension. Restez à l'écoute, car nous aborderons tous les types de dettes techniques plus tard.
Dans l'ensemble, la dette technique peut concerner n'importe quel aspect du développement Web ou d'applications, mais elle touche généralement la programmation, en particulier la refactorisation du code. Et tout comme pour une dette financière, le code ou la dette technologique génère des intérêts : plus la dette ou l'arriéré de problèmes ignorés s'accumulent, plus il devient coûteux de les corriger.
Dans une enquête McKinsey menée en 2020, les DSI ont indiqué que 10 à 20 % du budget technologique alloué aux nouveaux logiciels est consacré à la résolution des problèmes liés à dette technique. Plus inquiétant encore, les DSI ont estimé que la dette technologique s'élevait à De 20 à 40 % de la valeur de l'ensemble de leur parc technologique avant amortissement. Cela représente des centaines de millions de dollars de dettes non réglées pour les grandes entreprises.
La dette technique est une conséquence naturelle du développement logiciel, et lorsqu'il s'agit de l'identifier, la plupart des experts s'accordent sur deux catégories principales :
Dette technique délibérée ou dette active survient lorsque les équipes choisissent sciemment une mise en œuvre rapide mais imparfaite pour 1) établir une présence sur un marché en évolution rapide ou 2) pour recueillir les retours des utilisateurs. La dette technique délibérée est souvent appliquée lors du développement de produits minimum viables (MVP), qui seront développés et corrigés en continu en fonction des retours clients.
Cependant, les équipes ont rarement le temps de revenir en arrière pour repenser la conception initiale. Il est donc toujours préférable de collaborer avec une équipe qui a correctement planifié le projet pour chaque étape de son cycle de vie. Par exemple, chez Imaginary Cloud, les développeurs commencent à optimiser et à améliorer le code de l'application ou du logiciel une fois qu'il est en ligne.
Un exemple simple et concret de dette technique délibérée est la façon dont Airbnb a initialement négligé de corriger le bouton favori de son site web. À une certaine période, le bouton permettant d'ajouter des logements ou des chambres aux favoris ne fonctionnait pas. Comme Airbnb se concentrait sur une croissance rapide à l'époque, l'entreprise a choisi d'ignorer ce problème. L'équipe ne l'a résolu que lorsque la plateforme a gagné en popularité et a atteint une phase plus mature de son cycle de vie.
La dette technique involontaire survient par accident et se produit généralement lorsque les développeurs ne comprennent pas les exigences du marché ou comment concevoir une architecture pour répondre aux exigences du marché.
Par exemple, lors de la conception d'un système logiciel, une équipe tente de trouver un équilibre entre vision à long terme et pérennité du plan grâce à la simplicité et à la mise en œuvre. À mesure que le système évolue et que les exigences changent, ils peuvent se rendre compte que leur stratégie est défectueuse ou que l'ajout de nouvelles fonctionnalités est devenu complexe et lent.
La dette technique comporte également des types spécifiques, chacun reflétant la nature du problème dans son intitulé :
Bien que ces types soient très spécifiques, le plus connu est le Quadrant de la dette technique de Martin Fowler qui classe les types de dettes (délibérées ou involontaires) selon le choix de s'endetter (prudent ou imprudent).
Chaque quadrant peut être identifié par une couleur reflétant sa désirabilité : le rouge et l'orange (en haut et en bas à gauche) signalent une mise en garde, tandis que le vert et le bleu (en haut et en bas à droite) indiquent une approche souhaitable.
Analysons chaque quadrant tour à tour et examinons le rôle d'une équipe de développement dans la gestion des risques.
Ce type de dette survient lorsque l'équipe possède les compétences nécessaires pour réaliser la tâche mais décide consciemment d'opter pour une solution rapide et de moindre qualité, généralement pour accélérer la mise en œuvre. Voici quelques questions à se poser avant de choisir cette approche :
Le fait de ne pas gérer des aspects tels que ceux mentionnés ci-dessus est ce qui fait basculer la dette technique délibérée dans l'imprudence.
Cela signifie démarrer un nouveau projet à un rythme lent, pour vous assurer que vous et tous vos collaborateurs savez exactement quoi faire et quelles procédures suivre.
La dette technique délibérée et prudente consiste à prendre des décisions éclairées en se demandant si les avantages d'une version anticipée sont supérieurs aux coûts de remboursement. L'équipe reconnaît le problème et ses conséquences mais doit fournir la fonctionnalité à temps. Dans ce cas, l'équipe prévoit également la manière de gérer les effets, en tenant compte de tous les scénarios les plus pessimistes.
L'inadvertance et l'imprudence, le type de dette le moins souhaitable que vous puissiez avoir - on l'appelle généralement entropie logicielle que nous expliquons dans le chapitre suivant. Les équipes sont censées comprendre les principes fondamentaux des technologies qu'ils utilisent, et les ignorer entraînera une application boguée avec un comportement inattendu ou une maintenance médiocre. Une équipe bien formée disposant de connaissances sectorielles à jour et des meilleures pratiques devrait être en mesure d'éviter ce type de dette technologique.
C'est le involontaire type de dette - cela peut se produire malgré une approche prudente de l'architecture et du code du projet. Souvent, c'est uniquement après la mise en œuvre d'une fonctionnalité ou une fois le projet terminé, que l'équipe réalise qu'une conception différente des composants de l'application aurait probablement permis d'aboutir à une meilleure solution. L'objectif est donc de maximiser les opportunités d'apprentissage afin de faire passer une plus grande partie de votre dette technique du statut « involontaire » à celui de « prudente ».
La pourriture binaire ou entropie logicielle est le type de dette technique que vous souhaitez éviter, comme nous l'avons mentionné plus haut. Cela se produit au fil du temps lorsqu'un composant ou un système ralentit et devient inutilement complexe en raison de nombreux changements progressifs, souvent lorsqu'ils sont effectués par plusieurs développeurs qui ne comprennent peut-être pas parfaitement l'architecture d'origine. Ce manque de maîtrise est une forme de dette involontaire et imprudente attribuable à de mauvaises pratiques de logique et de codage.
Vous voulez éviter l'entropie logicielle pour les raisons suivantes :
Nous vous recommandons de rechercher des équipes dotées d'un chef de projet dédié, capable de responsabiliser ses développeurs en veillant à ce que le processus de développement ne laisse pas de place à la pourriture binaire.
À lire aussi :
Selon une étude menée par Stepsize, 61 % des équipes d'ingénierie affirment que la majeure partie de la dette technique provient du backend, en particulier des points de terminaison des serveurs Web. Les applications, les sites Web et l'infrastructure générale des entreprises constituent également une part importante de la base de code accumulant de la dette technique. Les résultats suggèrent que les entreprises pourraient accroître considérablement leur productivité en remboursant leur dette technique dans ces zones de leur base de code.
Les autres facteurs majeurs contribuant à la dette technique sont notamment :
Ces problèmes peuvent s'accumuler au fil du temps s'ils ne sont pas supervisés, entraînant des inefficacités techniques qui devront être corrigées ultérieurement. Il est préférable de collaborer avec une équipe compétente ou de s'appuyer sur des processus, des plans et des calendriers adaptés. Cette équipe doit rendre les problèmes visibles en les consignant dans le backlog logiciel, où ils pourront être évalués et classés par ordre de priorité pour résolution.
Prenons l'exemple de La célèbre affaire Fail Whale sur Twitter. La plateforme tombait en panne à plusieurs reprises et passait en « mode maintenance d'urgence », ce qui nuisait à l'entreprise. L'apparition de ce béluga serein et optimiste est devenue une préoccupation croissante à mesure que Twitter s'étendait à un public plus large. Twitter a donc décidé d'intégrer une équipe de développement qui a instrumenté l'ensemble du système et a commencé à reconstruire chaque partie qui était sur le point de tomber en panne en déplaçant ses processus dorsaux vers une série de langages de programmation plus compatibles avec le framework Java Virtual Machine.
Une fois ces modifications mises en œuvre, l'équipe de Twitter a pu passer moins de temps à résoudre les pannes et plus de temps à développer de nouvelles fonctionnalités, à réduire la dette technologique, à éliminer les inefficacités techniques et, enfin, à offrir une meilleure expérience utilisateur.
« Le travail acharné n'est pas très gratifiant. Il est difficile de prendre la parole devant tout le monde et de dire : « Nous allons régler les choses petit à petit avec beaucoup d'efforts ». Les grands changements spectaculaires sont plus faciles à vendre la plupart du temps. Mais ils ne fonctionnent pas aussi bien et sont sujets à des échecs complets et abjects. »
Il est important de mentionner que la dette technologique ne provient pas toujours des équipes de développement. Les entreprises ou les clients qui recrutent imposent souvent des contraintes aux développeurs de premier plan qui n'ont d'autre choix que de les accepter. Il s'agit généralement des éléments suivants :
À lire aussi :
Quand elle est délibérée :
Les équipes de développement peuvent gérer la dette technique intentionnelle en : assurant un suivi dans le backlog lorsque vous reportez délibérément des travaux qui doivent être effectués. Si une équipe ne parvient pas à tenir sa promesse de réviser le code ou n'en a pas les moyens, il est peu probable que cette dette soit remboursée et elle finira par se transformer en dette de conception accidentelle au fil du temps.
Cette dette est généralement contractée à la suite de décisions commerciales ; par conséquent, les parties prenantes et les propriétaires de produits doivent être tenus responsables de son accumulation.
En cas d'accident :
Réussir à refactoriser un système est une tâche colossale, mais cela doit être effectué de temps à autre lorsque le système est dans un état stable. Dans le cas contraire, l'équipe risque de surconcevoir le système et de subir des ralentissements inutiles.
Dans ce cas, les responsables technologiques et les propriétaires de produits doivent veiller à ce que du temps soit réservé à la résolution de ce type de dette technique occasionnée par des décisions de conception et des exigences en constante évolution.
À lire aussi :
La dette technique n'est pas toujours un fardeau. Elle peut souvent constituer un levier stratégique de réussite si elle est bien gérée. Chez Imaginary Cloud, nous pouvons collaborer avec vous à toutes les étapes de développement nécessaires pour vous débarrasser de toute dette inutile, tant sur le plan technique que sur le plan de la conception. Qu'il s'agisse de donner vie à votre idée grâce au développement de logiciels Web et d'applications ou de renforcer les compétences de votre équipe grâce à l'extension d'équipe, nous veillerons à ce que votre dette technique soit maîtrisée à chaque étape.
Un spécialiste du marketing de croissance polyvalent et axé sur les données, doté d'une connaissance approfondie des affaires et informé des derniers développements dans le paysage du marketing numérique.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
