Gérer la dette technique avec DX et IA

Toutes les entreprises, grandes ou petites, s’inquiètent de la dette technique. Estimations Gartner Environ 40 % des systèmes d'infrastructure présentent ce problème. Selon une enquête menée par McKinsey auprès des DSI, près d'un tiers d'entre eux estiment que plus de 20 % Une partie de leur budget dédié aux nouveaux produits a été consacrée à la résolution des problèmes liés à la dette technique. Mais contrairement à ce que beaucoup pensent, il ne s'agit pas seulement d'un problème de codage ; c'est aussi un problème d'expérience développeur (DX). En effet, lorsque les développeurs doivent travailler avec une architecture inadaptée, des outils obsolètes et des workflows de développement médiocres, la productivité, les performances et le moral des équipes en pâtissent.

Prioriser la dette technique en pensant au développeur, en se concentrant sur sa façon d'aborder le travail, les outils qu'il utilise et les perspectives d'évolution professionnelle, permet aux équipes de se concentrer et d'accélérer les livraisons. C'est pourquoi la gestion de la dette technique par les entreprises évolue, portée par la transformation digitale et l'importance croissante accordée aux outils basés sur l'IA.

Champion DX

La manière dont les développeurs sont intégrés laisse souvent à désirer. Il faut parfois quelques semaines pour qu'un développeur commence à contribuer à un projet. Une fois qu'il a enfin pu ajouter de petites fonctionnalités ou des correctifs, il n'est pas rare de voir le service d'intégration continue (CI) échouer pour une raison totalement étrangère aux modifications apportées. Il s'agit en fait d'une suite de tests défaillante due à des problèmes de qualité, et le développeur n'a pas soumis les modifications nécessaires pour la rendre inopérante. Il s'agit d'un test bancal et mal écrit qui ne fonctionne que dans 90 % des cas. L'équipe en place s'en accommode probablement – ​​cela ne fait que ralentir les processus – mais l'outillage peut être obsolète et démoralisant pour toute personne extérieure à l'organisation.

Ceci n'est qu'un exemple parmi tant d'autres qui entravent une transformation digitale réussie. Pour éviter cela, il est conseillé de désigner un responsable au sein de votre équipe d'ingénierie et de développement logiciel. Si de nombreuses petites organisations n'ont pas de responsable de la transformation digitale, les grandes entreprises performantes en ont un. Ces professionnels suivent des données comme le temps nécessaire à un nouveau développeur pour mettre en place un environnement. Et si deux semaines sont trop longues, ils trouvent le moyen de diviser ce temps par deux.

Il existe des outils d'aide, comme CircleCI, dotés de fonctionnalités natives permettant de détecter les failles d'une suite de tests. Il faut une personne capable de prendre les choses en main et de s'arrêter après chaque sprint pour apporter les modifications nécessaires à la maintenance et à l'utilisation ultérieure du code. Il est essentiel de trouver un leader motivé par l'amélioration de la DX. Pour ce faire, recherchez un ingénieur senior, accompagné d'un collaborateur relativement récent, capable de fournir un retour sur les éventuelles lacunes.

IDC s'attend également à ce que le marché de l'automatisation des tests logiciels alimentés par l'IA se poursuive. en croissance à un TCAC de 31.2 % jusqu'en 2027, alors assurez-vous d'exploiter pleinement cette technologie.

Indicateurs et signes avant-coureurs

Il existe de nombreux indicateurs que vous pouvez suivre pour évaluer l'impact de la dette technique sur votre équipe. Parmi les plus courants, on trouve le « temps de correction » ou le « temps de mise en œuvre des fonctionnalités ». Imaginons que vous remarquiez un bug et sachiez comment le corriger. Certains outils permettent de suivre le temps écoulé depuis l'écriture du code jusqu'à la production. Par exemple, vous constaterez qu'un très petit correctif a nécessité deux jours ouvrés pour être corrigé et livré, alors que votre équipe devrait pouvoir le faire en quelques heures. Vous pouvez également suivre des ratios, comme le nombre de corrections de bugs par rapport aux fonctionnalités terminées.

Il existe également des moyens d'identifier les problèmes de moral qui impactent la performance de votre équipe. Les responsables DX peuvent mener des enquêtes trimestrielles pour évaluer le niveau de satisfaction d'un développeur sur un projet ou une partie de celui-ci. Ils peuvent approfondir leurs recherches et poser des questions sur des aspects spécifiques, comme le processus d'intégration continue. Vous pouvez également suivre à tout moment les départs et les changements de personnel au sein de votre équipe. Si vous constatez que des employés partent régulièrement, ils pourraient avoir l'impression que leurs préoccupations ne sont pas entendues.

Outils autour de l'IA

L'essor des outils d'IA est censé améliorer la productivité des développeurs et des ingénieurs et accélérer la livraison des produits, mais la dette technique ralentit ce processus. Imaginons que vous utilisiez un outil comme GitHub ou Copilot pour vous aider à modifier le code, que vous soumettiez ensuite la pull request et que l'intégration continue prenne quelques heures pour vous répondre. Pendant ce temps, un développeur travaille-t-il sur autre chose ? Consulte-t-il ses e-mails ? C'est un changement de contexte et un frein à la productivité.

Les développeurs souhaitent travailler sur des produits où ils peuvent se concentrer uniquement sur le code. Les outils sont là pour les aider à passer en production, et non pour les bloquer constamment. L'IA peut faire gagner du temps, mais il appartient aux équipes d'ingénierie de définir leurs propres normes de complexité acceptable. Pour ce faire, assurez-vous d'abord que tout code ajouté à votre branche principale présente un niveau de dette technique acceptable. Avant cela, engagez une discussion ouverte et obtenez l'adhésion de l'équipe d'ingénierie sur le seuil acceptable de dette technique et de qualité du code. Assurez-vous que chacun comprenne que dépasser ce seuil nécessite une correction immédiate. Une fois ces normes définies, l'IA entre en jeu.

Il existe un argument en faveur d'agents d'IA dont les ingénieurs seraient les orchestrateurs. Une enquête Capgemini menée auprès de 1,100 XNUMX dirigeants de grandes entreprises révèle que 82 % prévoient d'intégrer des agents d'IA dans les trois prochaines années, et ils ont déjà un impact sur avenir du travailVous pouvez consulter un rapport de bug et constater qu'il est suffisamment petit pour être traité par un agent d'IA, de sa conception à la révision du code, ce qui permet à votre équipe de gagner du temps et de se consacrer à des tâches plus complexes. Cependant, lorsque nous suivons aveuglément ces outils, l'IA a parfois du mal à prendre en compte certains compromis.

C’est à ce moment-là que l’opinion humaine devient le facteur décisif.

Aligner la dette technique sur les objectifs

Comment aligner la réduction de la dette technique sur les objectifs à atteindre ou les résultats mesurables ? Cela revient à une dette technique acceptable, et parfois, en entreprise, il faut livrer vite. On peut le faire en sachant qu'un produit n'est pas évolutif et que des problèmes de performance peuvent survenir au fil du temps. Souvent, un développeur prend note de revenir sur ce point plus tard, lorsqu'il aura le temps de résoudre ces problèmes, mais c'est rare. Et lorsque cette mauvaise culture s'installe, où il faut constamment livrer demain, l'impact de la dette devient on ne peut plus évident.

C'est compréhensible pour une startup, mais pas pour une entreprise en activité depuis dix ans. Il est essentiel de commencer à faire évoluer votre culture d'entreprise dès le début et de manière proactive afin de gérer la dette technique ; sinon, vous dépenserez des sommes considérables pour corriger des bugs de production ou vous soucier de la sécurité et de la conformité.

Enfin, il existe des indicateurs permettant de communiquer l'intérêt d'une refactorisation ou d'un remboursement de la dette technique aux parties prenantes. Le temps peut être un indicateur, de la conception à la production, ou de l'ouverture d'une pull request à sa fusion et son envoi en production. Le temps moyen de réparation (MTTR) est un autre indicateur. Dans ce cas, vous avez peut-être détecté un bug ou une version défectueuse, et vous mesurez le temps nécessaire à votre équipe pour le corriger. Vous pouvez également suivre le nombre de bugs en production. Si ce nombre augmente, il pourrait y avoir un problème lié à la dette technique.

Dette technique avec intérêts

Chaque organisation peut consacrer quelques heures par semaine à l'amélioration de sa DX afin de réduire sa dette technique. Dans le cas contraire, vous risquez d'en payer le prix plus tard, probablement par une baisse des performances, un ralentissement considérable de la vitesse de développement ou des problèmes de sécurité. Par exemple, votre équipe d'ingénieurs et de développeurs aurait pu reporter les mises à niveau vers Ruby on Rails pendant une décennie. Soudain, le coût d'un projet augmente d'un demi-million de dollars car la version de Ruby a quatre générations de retard, ce qui vous laisse avec une masse de code et des dépendances obsolètes.

Si vous aviez effectué la mise à niveau progressivement, vous ne seriez pas dans cette situation. Alors, soutenez votre équipe de développement logiciel et payez au fur et à mesure. Sinon, cette dette technique reviendra vous hanter, avec des intérêts.