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 technologique 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 de haut niveau.
La dette technique ou la dette de code n'est pas nécessairement négative ; elle peut parfois l'être effet de levier stratégique pour votre projet à long terme. Donc, si vous choisissez d'avoir une dette technique, elle 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 technologique. 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 technologiques existent, comment elles influent sur votre processus de développement et comment vous pouvez la gérer.
Dette technique, dette technologique, ou dette codée est le concept qui consiste à retarder ou à omettre des travaux pour terminer un projet ou atteindre un objectif plus rapidement, mais qui entraîne également de nouvelles retouches plus tard dans la phase de vie du projet. Nous pouvons comparer cela à la construction d'une maison sans un ensemble complet de plans. La construction pourrait se terminer plus tôt, mais la maison présentera d'importants problèmes structurels qui demanderont plus de temps et plus d'argent à réparer plus tard.
Dans le domaine du développement logiciel, il est courant de proposer une fonctionnalité immédiatement afin de comprendre son évolution. Une fois qu'il a été considérablement redimensionné, nous pouvons l'adapter à la dimension qu'il a atteinte. Mais restez au courant, car nous couvrirons toutes sortes de dettes techniques plus tard.
Dans l'ensemble, la dette technique peut faire référence à n'importe quel aspect du développement Web ou d'applications, mais elle concerne généralement la programmation, en particulier refactorisation du code. Et tout comme la 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 est coûteux de les corriger.
Dans un Sondage McKinsey menée en 2020, Les DSI ont indiqué que 10 à 20 % de la technologie budget 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 se traduit par des centaines de millions de dollars de dettes impayées pour les grandes entreprises.
La dette technique est une conséquence naturelle du développement de logiciels, et lorsqu'il s'agit de l'identifier, la plupart des experts s'accordent sur deux catégories plus générales :
Dette technique délibérée ou dette active se produit lorsque les équipes veulent sciemment mise en œuvre rapide mais imparfaite pour 1) établir une présence sur un marché en évolution rapide ou 2) pour recueillir les commentaires des clients. La dette technologique délibérée est souvent appliquée lors du développement de produits minimaux viables (MVP), qui seront développés et corrigés en fonction des commentaires des clients et des clients en permanence.
Cependant, les équipes ont rarement le temps de revenir en arrière et de repenser la façon dont elles l'avaient initialement planifié. Il est donc toujours préférable de collaborer avec une équipe qui a correctement planifié le projet pour chaque étape de sa vie. Par exemple, chez Imaginary Cloud, les développeurs recommencent à optimiser et à améliorer le code de l'application ou du logiciel une fois qu'il est en ligne.
Un bon et simple exemple de dette technologique délibérée c'est ainsi qu'Airbnb n'a pas pris la peine de corriger le bouton favori de son site Web. Il y a eu un moment où le bouton des maisons ou des pièces préférées ne fonctionnait pas. Comme Airbnb se concentrait sur une croissance rapide à l'époque, cela n'a pas hésité à ignorer ce numéro. L'équipe n'a résolu le problème que lorsque l'entreprise a commencé à gagner 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 essaie de trouver un équilibre en pensant à l'avenir et en pérennisant son 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 la nouvelle fonctionnalité est devenue difficile et lente à mettre en œuvre.
La dette technologique comporte également des types spécifiques, chacun incluant le problème spécifique dans le titre :
Bien que ces types soient très spécifiques, le plus populaire est Quadrant de la dette technique de Martin Fowler qui décrit les types de dettes (délibérées et involontaires) et le choix de s'endetter (imprudent ou imprudent).
Nous pouvons identifier chaque quadrant en lui attribuant une couleur qui correspond à sa désirabilité : le rouge et l'orange (en haut et en bas à gauche) indiquent un avertissement ; le vert et le bleu (en haut et en bas à droite) indiquent la désirabilité.
Examinons chaque quadrant à tour de rôle et examinons le rôle d'une équipe de développement dans la gestion du risque.
Ce type de dette survient lorsque l'équipe possède les connaissances appropriées pour mettre en œuvre la tâche décide consciemment d'opter pour une solution rapide et de mauvaise qualité, généralement dans l'intérêt d'une mise en œuvre rapide. Voici quelques-unes des questions que vous devriez vous poser avant de choisir cette méthode :
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 sur le terrain de l'imprudence.
Cela signifie commencer quelque chose de nouveau à un rythme lent, pour vous assurer que vous et tous ceux qui travaillent avec vous savez exactement quoi faire et quelles procédures suivre.
La dette technologique délibérée et prudente concerne prendre des décisions éclairées et en se demandant ainsi si les avantages d'une version antérieure sont supérieurs aux coûts de remboursement. Le l'équipe reconnaît le problème et ses conséquences mais doit fournissent actuellement 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.
Par inadvertance et imprudence, type de dette le moins souhaitable vous voulez 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 si le projet est terminé, l'équipe se rend compte que si elle avait conçu différemment les différents composants de l'application, elle trouverait probablement une meilleure solution. L'objectif est donc de maximiser les opportunités d'apprentissage afin que vous puissiez passer du statut « involontaire » à celui de « prudent » pour une plus grande partie de votre dette technique.
Pourriture binaire ou entropie logicielle est le type de dette technologique 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 devient une complexité inutile grâce à de nombreux changements progressifs, souvent lorsqu'ils sont travaillés par plusieurs développeurs qui ne comprennent peut-être pas parfaitement l'architecture d'origine. Ce manque de compétence est une forme de dette involontaire et imprudente attribué à 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 des bits.
Lisez aussi :
Selon un étude menée par Stepsize, 61 % des équipes d'ingénieurs affirment que la majeure partie de la dette technique provient du backend, en particulier, dans les points de terminaison des serveurs Web. Les applications et sites Web des entreprises ainsi que l'infrastructure générale font également partie de la base de code qui accumule une importante dette technique. Les résultats suggèrent que les entreprises pourraient augmenter considérablement leur productivité en remboursant leur dette technologique dans ces zones de leur base de code.
Les autres principaux facteurs qui contribuent à la dette technique sont notamment les suivants :
Ces problèmes peuvent s'accumulent au fil du temps s'ils ne sont pas supervisés, ce qui entraîne des inefficacités techniques qui devront être corrigées à l'avenir. Il sera préférable de collaborer avec une équipe compétente ou de s'associer avec les bons processus, plans et calendriers. Cette équipe devrait rendre les objets visibles en enregistrant les entrées dans le backlog logiciel, où les problèmes seront é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 broyage n'est pas très satisfaisant. Il est difficile de prendre la parole devant tout le monde et de dire : « Nous allons régler les choses petit à petit avec beaucoup de travail ». Les gros mouvements tape-à-l'œil 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 limitations des développeurs de premier plan qui n'ont d'autre choix que de les engager. Il s'agit généralement des éléments suivants :
Lisez aussi :
Quand c'est délibéré :
Les équipes de développement peuvent gérer les dettes techniques intentionnelles en : suivi de l'arriéré lorsque vous reportez délibérément des travaux qui doivent être achevés. Si une équipe n'arrive pas à tenir sa promesse de revoir le code ou si elle n'a pas les moyens de le faire, il est peu probable qu'il soit remboursé et deviendra au fil du temps une dette de conception accidentelle.
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 devraient être tenus responsables de l'accumulation.
En cas d'accident :
Réussir à remanier un système est une tâche énorme, mais cela doit être effectué de temps en temps 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 devraient être tenus de veiller à ce que le temps soit réservé à la résolution de ce type de dette technologique occasionnés par des décisions de conception et des exigences en constante évolution.
Lisez 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 toutes les dettes inutiles, 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 de l'équipe, nous veillerons à ce que votre dette technologique soit bien géré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:
.webp)
%20(1).webp)
.webp)
.webp)
.webp)
.webp)
.webp)
