La dette technique est inévitable dans le processus de développement logiciel. Correctement géré, il peut être un outil puissant qui peut générer un véritable avantage concurrentiel, tout comme un prêt financier.
Trop souvent, cependant, cela devient incontrôlable. Lorsque nous contractons des dettes, nous ne comprenons pas les conditions ou lorsque nous ne gérons pas correctement la dette technologique, les conséquences peuvent être graves.
Si vous êtes ici, vous en connaissez probablement certains.
Cet article explique comment arrêter la pourriture en s’attaquant à la dette technologique existante.
Nous verrons comment reconnaître les créances irrécouvrables et les symptômes révélateurs d’une dette mal gérée, puis nous verrons comment élaborer une stratégie pour réduire la dette technologique.
Nous parlerons également de ce à quoi ressemble un équilibre sain de la dette technologique et de la manière dont les dirigeants peuvent l’utiliser à leur avantage.
Bonne dette technologique contre mauvaise dette technologique
Robert Kiyosaki, l’auteur de Rich Dad Poor Dad, a dit :
Une mauvaise dette prend de l’argent de votre poche, tandis qu’une bonne dette met de l’argent dans votre poche.
Il en va de même pour la dette technologique.
Une bonne dette technologique est accumulée prudemment et délibérément pour être expédiée plus rapidement. Il y a toujours un plan pour rembourser une bonne dette technologique.
Les mauvaises dettes technologiques sont généralement accumulées par inadvertance ou par imprudence. Ou potentiellement les deux. C’est un peu comme contracter un prêt pour des vacances coûteuses que vous ne pouvez pas vous permettre.
Une mauvaise dette technologique rendra probablement vos PM heureux pendant une semaine ou deux. Mais dans deux mois, ils demanderont pourquoi tout est en retard et traiteront les plaintes des clients parce que les choses ne fonctionnent pas correctement.
J’aime la matrice de la dette technologique de Martin Fowler pour un moyen simple de visualiser la dette technologique.
De quelle dette technologique avez-vous à vous soucier ? D’une manière générale, c’est la dette technologique qui n’est pas documentée et non suivie et la dette technologique qui échappe à tout contrôle sans plan pour freiner.
Pourquoi votre dette technologique ne cesse de croître
Avant de parler de l’élaboration d’une stratégie pour résoudre la dette technologique, nous devons d’abord parler de la façon dont elle devient incontrôlable.
Tout est question de visibilité.
Résoudre les problèmes de dette de code est impossible si :
- Vous n’avez aucune trace des problèmes de dette technique que vous avez
- Vous avez un backlog, mais vous ne pouvez pas voir quels problèmes sont liés à quel code
Dans les deux cas, vous ne pouvez pas donner la priorité à la dette technologique plutôt qu’à l’envoi de nouvelles fonctionnalités.
Malheureusement, la blague fait une bonne analogie car, finalement, les équipes qui privilégient l’expédition rapide finiront par abandonner toutes les cartes.
Je veux obtenir plus de détails sur ce qui affecte ces deux cas de dette technologique ci-dessus.
- Problème d’invisibilité – Il n’y a pas de source de connaissances partagées. Les informations sur la santé de la base de code sont verrouillées dans la tête des ingénieurs.
- Aucune culture de la qualité du code – Expédition rapide, quel qu’en soit le prix, comme si elle n’était plus à la mode.
- Mauvais processus – Le travail sur la dette technologique est nul. Personne n’aime créer des tickets Jira. « Jira » est devenu un gros mot.
- Investissement à court terme – Justifier le temps de réparer la dette technologique ou de refactoriser est une bataille constante.
- Manque de contexte – Les problèmes dans Jira sont très éloignés de la dure réalité de la base de code. Ils ne sont en aucun cas liés.
Alors, quelle est la racine ? Parlons stratégie.
Spoiler… il s’agit de changer le comportement des développeurs pour suivre correctement les problèmes.
Créer une stratégie pour réduire la dette technique
Piste. Questions. Correctement.
Une bonne gestion de la dette technologique commence par l’excellence à l’échelle de l’équipe dans le suivi des problèmes.
Vous ne pouvez pas avoir de stratégie de dette technologique sans suivi.
Le travail du responsable de l’ingénierie consiste à faciliter le suivi des problèmes. Il doit y avoir un logiciel pour ça, Jira. Ou Linéaire. Ou Asana.
Le problème est que je n’ai jamais cru qu’ils allaient vraiment au fond du problème, et après en avoir discuté avec des dizaines d’ingénieurs et de dirigeants, ils ne le font généralement pas non plus.
Vous souhaitez trouver un moyen de…
- Montrez aux ingénieurs quand ils travaillent sur du code avec une dette technologique sans qu’ils aient à faire quoi que ce soit.
- Faites en sorte qu’il soit facile (en fait facile, pas comme Jira) pour les membres de l’équipe de signaler la dette technologique.
- Créez un moyen naturel de discuter des problèmes de base de code.
- Intégrez le travail de dette technologique dans votre flux de travail.
C’est exactement ce pour quoi j’ai co-fondé Stepsize. Nous avons créé le premier outil de suivi des problèmes dans l’éditeur au monde. Les problèmes liés directement au code sont créés directement depuis l’IDE. Et il s’intègre à Jira. Les ingénieurs l’adorent car ils n’ont pas à changer de contexte. Les problèmes sont visibles et gérables depuis l’IDE. C’est un outil Developer Experience (DX) autant qu’autre chose. Les chefs de projet l’adorent car les ingénieurs consignent systématiquement les problèmes exploitables et de haute qualité qui peuvent être hiérarchisés efficacement.
Vous n’êtes pas obligé d’utiliser Stepsize, bien sûr, mais je pense honnêtement que c’est le meilleur moyen pour les équipes de scale-up et les entreprises modernes de prendre au sérieux l’excellence de l’ingénierie de la dette technologique.
Assez parlé de nous – parlons de la hiérarchisation des problèmes.
Donner la priorité à la dette technologique percutante
Espérons que cela soit évident maintenant, mais prioriser les bons problèmes n’est possible que si vous suivez des problèmes de haute qualité.
Une fois que vous les avez, vous voulez les utiliser régulièrement et systématiquement pour décider quoi traiter. Cela se produit généralement lors du raffinement du backlog (beaucoup appellent cela le toilettage du backlog) et de la planification du sprint.
Ce processus décisionnel doit être stratégique.
Une bonne façon de commencer est de choisir un thème chaque fois que vous hiérarchisez les problèmes. Par exemple, vous pouvez hiérarchiser les problèmes qui…
- ont un impact sur une fonctionnalité spécifique sur laquelle vous devez travailler
- ont un impact sur l’interface utilisateur du client
- Affectent le moral de l’équipe
Cela devrait être simple si vous avez des problèmes de haute qualité qui sont intrinsèquement liés au code et étiquetés correctement.
Les gens me demandent souvent comment j’organiserais le temps pour régler la dette technologique dans le développement agile. À mon avis, il existe deux modèles de base pour cela. Pour les simplifier :
- Consacrez 15 à 20 % de chaque sprint à la résolution de la dette technologique
- Consacrez un sprint entier à la résolution régulière de la dette technologique (2 semaines par trimestre)
Les ingénieurs ne donneront généralement pas la priorité au travail de dette technologique par eux-mêmes en raison de la pression concurrentielle de l’expédition rapide. Un engagement envers les travaux de refactorisation et de maintenance du code doit être approuvé et soutenu par le haut et renforcé régulièrement.
Votre budget de dette technologique
Vous essayez de résoudre la dette technique de votre équipe (ou vos équipes) de développement. Mais vous ne devriez pas essayer de tout résoudre.
Une dette technologique prudente, correctement gérée, est puissante. C’est comme une dette financière. Vous pouvez l’utiliser pour investir dans votre logiciel et obtenir un véritable avantage concurrentiel.
À condition que vous contractiez une dette technique prudente, que vous la suiviez et que vous la remboursiez avant que l’impact ne s’aggrave, votre équipe devrait contracter une dette technologique.
Ce qui compte, c’est que votre équipe d’ingénieurs suive correctement la dette technologique et rembourse la bonne dette au bon moment.
Mes dernières pensées
La dette technique est l’un des domaines les moins prioritaires du développement logiciel. Il n’est souvent prioritaire que lorsqu’il approche du marqueur trop tard.
La bonne nouvelle est que lorsque les dirigeants se réunissent et conviennent de s’y attaquer, une stratégie cohérente et axée sur les processus est généralement efficace.
Les meilleures équipes d’ingénierie ne cessent de réfléchir à la manière de déployer leur budget de dette technologique pour obtenir un avantage concurrentiel.
Nous avons construit une solution SaaS qui facilite le changement de comportement nécessaire dans votre équipe d’ingénierie et que les chefs de projet vont adorer aussi. Cela rend la gestion des problèmes de dette de code transparente.