Gérer la dette technique avec DX et IA

Toute entreprise, grande ou petite, s’inquiète de la dette technique. Gartner estime qu’environ 40 % des systèmes d’infrastructure ont ce problème. Dans une enquête menée auprès des DSI par McKinsey, près d’un tiers estimaient que plus de 20 % de leur budget de nouveaux produits était consacré à la résolution de problèmes liés à la dette technique. Mais contrairement à ce que beaucoup pensent, ce n’est pas seulement un problème de codage ; c’est également un problème d’expérience développeur (DX). Car lorsque les développeurs doivent travailler avec une architecture inadéquate, des outils obsolètes et des flux de travail de développement médiocres, la productivité, les performances et le moral souffrent.

Donner la priorité à la dette technique en tenant compte du développeur, en se concentrant sur la façon dont il aborde son travail, sur les outils qu’il utilise et sur les avancées de carrière qu’il peut acquérir, aide les équipes à se concentrer et à expédier plus rapidement. C’est pourquoi la façon dont les entreprises gèrent la dette technique change, sous l’impulsion de DX et d’une attention accrue sur les outils alimentés par l’IA.

Défendre DX

La façon dont les développeurs sont souvent intégrés laisse beaucoup à désirer. Il peut falloir plusieurs semaines à quelqu’un pour commencer à contribuer à un projet. Une fois qu’ils ont 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 en raison de quelque chose de complètement sans rapport avec les modifications qu’ils ont apportées. C’est essentiellement le test de suite qui échoue en raison de problèmes de qualité médiocre, et le développeur n’a pas soumis de modifications pour faire échouer le test de suite. C’est un test flasque, mal écrit, qui ne fonctionne que 90 % du temps. L’équipe existante est probablement okay avec cela – cela ne ralentit que les processus – mais les outils peuvent être obsolètes et démoralisants pour quiconque se trouve en dehors de l’organisation.

Ceci est un exemple parmi muchos qui entravent la bonne DX. Une façon de prévenir cela consiste à avoir un champion désigné au sein de votre équipe d’ingénierie et de développement logiciel. De nombreuses petites organisations n’ont pas de leader DX, mais les grandes et réussies oui. Ces professionnels suivent des choses comme le temps qu’il faut à un nouveau développeur pour configurer un environnement. Et si deux semaines sont trop longues, ils déterminent comment réduire ce temps de moitié.

Il existe des outils pour aider, comme CircleCI, avec des fonctionnalités natives qui suivront la flasque d’une suite de tests. Ce qui est nécessaire, c’est quelqu’un pour prendre les devants et s’arrêter après chaque sprint pour aborder certaines des modifications qui rendront le code plus facile à maintenir et à travailler à l’avenir. Cela se résume à avoir un leader intéressé à améliorer DX. Pour que cela se produise, recherchez un ingénieur senior, accompagné d’un membre du personnel relativement nouveau qui peut fournir des commentaires sur les lacunes possibles.

IDC s’attend également à ce que le marché de l’automatisation des tests de logiciels alimenté par l’IA continue de croître à un taux de 31,2 % jusqu’en 2027, assurez-vous donc d’exploiter cette technologie à fond.

Métriques et signaux d’alarme

Il existe de nombreuses métriques que vous pouvez suivre lors de l’évaluation de l’impact de la dette technique sur votre équipe. Certaines métriques de base sont le « temps de correction » ou le « temps de fonctionnalité ». Disons que vous remarquez un bogue et que vous savez comment le corriger. Certains outils peuvent suivre le temps passé de l’écriture du code à la production. Par exemple, vous seriez en mesure de voir qu’un petit correctif a pris deux jours ouvrables pour être corrigé et expédié, alors que votre équipe doit être en mesure de le faire en quelques heures. Vous pouvez également suivre des ratios, comme le nombre de correctifs de bogue par rapport aux fonctionnalités terminées.

Il existe également des moyens d’identifier les problèmes de moral qui affectent les performances de votre équipe. Les leaders DX peuvent effectuer des enquêtes trimestrielles pour déterminer à quel point un développeur est heureux de travailler sur un projet ou un élément de celui-ci. Ils peuvent creuser et demander des informations sur des domaines spécifiques comme le processus CI. Et vous pouvez toujours suivre la rotation ou le turnover dans votre équipe. Si vous remarquez que les gens quittent constamment, ils pourraient avoir l’impression que leurs préoccupations ne sont pas entendues.

Jeux d’outils avec l’IA

L’essor de l’outillage IA est censé rendre les développeurs et les ingénieurs plus productifs et les produits expédiés plus rapidement, mais la dette technique ralentit cela. Disons que vous utilisez un outil comme GitHub ou Copilot pour aider aux modifications de code, puis soumettez la demande d’extraction, et que CI met quelques heures à vous répondre. Entre-temps, un développeur travaille-t-il sur autre chose ? Vérifie les e-mails ? C’est un changement de contexte et un tueur de productivité.

Les développeurs veulent travailler sur des produits où ils peuvent simplement se concentrer sur le code. L’outillage est là pour les aider à le mettre en production, et non pour constituer un obstacle constant. L’IA peut gagner du temps, mais c’est 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 a un niveau acceptable de dette technique. Avant cela, tenez une discussion ouverte et obtenez l’approbation de l’équipe d’ingénierie sur le seuil acceptable de dette technique et de qualité de code. Assurez-vous que tout le monde sache que dépasser cette marque nécessite une remédiation immédiate. Une fois que vous avez défini ces normes, l’IA entre en jeu.

Il y a un cas pour les agents IA avec les ingénieurs agissant en tant qu’orchestrateurs. Une enquête menée par Capgemini auprès de 1 100 dirigeants d’entreprises de grande taille a révélé que 82 % prévoient d’intégrer des agents IA dans les trois prochaines années, et qu’ils ont déjà un impact sur l’avenir du travail. Vous pourriez être en train d’examiner un rapport de bogue et de voir qu’il est suffisamment petit pour qu’un agent IA le gère de l’inception à la révision de code, ce qui économise du temps à votre équipe et la libère pour effectuer des travaux plus complexes. Cependant, parfois, lorsque nous suivons ces outils de manière aveugle, il existe des compromis que l’IA a du mal à prendre en compte.

C’est alors qu’une opinion humaine devient le facteur décisif.

Aligner la dette technique avec les objectifs

Comment aligner la réduction de la dette technique avec les objectifs que vous essayez de réaliser ou les résultats mesurables ? Cela revient à la dette technique acceptable, et parfois, dans les affaires, vous devez expédier rapidement. Vous pouvez le faire en sachant qu’un produit ne sera pas évolutif et qu’il peut y avoir des problèmes de performances avec le temps. Souvent, un développeur fera une note pour y revenir plus tard, lorsqu’il y aura le temps de résoudre ces problèmes, mais cela se produit rarement. Et lorsque cette mauvaise culture prend le dessus, dans laquelle vous devez constamment expédier demain, l’impact de la dette devient abondamment clair.

Ceci est compréhensible pour une startup, mais pas pour une entreprise qui fonctionne depuis une décennie. Vous devez commencer à modifier votre culture tôt et activement pour gérer la dette technique ; sinon, vous allez dépenser une tonne d’argent pour corriger les bogues de production ou vous inquiéter de la sécurité et de la conformité.

Enfin, il existe des métriques pour aider à communiquer la valeur de la réorganisation ou du remboursement de la dette technique aux parties prenantes. Le temps pourrait en être un, de l’inception à la production, ou de l’ouverture d’une demande d’extraction à la fusion et à l’expédition à la production. Un autre est le temps moyen de réparation (MTTR). Dans ce cas, vous avez peut-être trouvé un bogue ou une construction cassée, et vous mesurez le temps qu’il faut à votre équipe pour le corriger. Vous pourriez également suivre le nombre de bogues que vous avez en production. Si vous voyez que ce nombre augmente, il pourrait y avoir un problème lié à la dette technique.

Dette technique avec intérêts

Toute organisation peut consacrer quelques heures chaque semaine pour améliorer son DX et aider à réduire la dette technique. Si ce n’est pas le cas, vous pourriez payer pour cela plus tard, probablement par une performance lente, 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 de Ruby on Rails pendant une décennie. Soudain, le coût d’un projet est augmenté de 500 000 dollars parce que la version de Ruby est quatre générations en retard, vous laissant avec une masse de code et des dépendances obsolètes.

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