Éponger la dette technique… sans perdre en productivité

Équipes dev et produit en plein clash sur le sujet de la dette technique (Wollen, Black Watch at the Battle of Quatre-Bras, 1815)

Au fur et à mesure que nous construisons une application, nous contractons de la dette. C’est inévitable. Notre base de code devient progressivement obsolète fonctionnellement (le produit change), techniquement (les technos évoluent) et humainement (l’équipe et ses conventions changent).

Concrètement, des fonctionnalités ne sont plus utilisées mais restent présentes, les versions de nos dépendances changent, des failles de sécurité font leur apparition, les bugs sont plus complexes à corriger, une petite fonctionnalité nécessite des jours de travail. Si nous ne faisons rien pour rembourser notre dette, nous perdons en productivité et nous risquons de nous retrouver un jour dos au mur.

Mais quand il faut livrer rapidement un produit puis le faire évoluer toujours plus vite, comment trouver le temps de travailler sur l’existant ? Et quand nous avons ce temps, comment être le plus efficace possible ?

Rembourser au quotidien, oui mais…

La manière la plus saine et la plus efficace de rembourser sa dette est de le faire au fil de l’eau, jour après jour. Chaque fonctionnalité qu’on ajoute est l’occasion d’un petit nettoyage qui ralentit peu le développement à court terme. Quand une nouvelle version d’une dépendance est publiée, il n’est en général pas très coûteux de se mettre à jour sur-le-champ. Si une nouvelle page vient en remplacer une autre, prenons le temps de bien nettoyer ce qui dépend de l’ancienne.

Malheureusement, nous ne faisons pas toujours ce travail continu qui maintient l’application en bonne santé. Parfois parce que nous n’avons pas le temps. D’autres fois parce que nous sommes tellement familiers avec la base de code que nous ne la remettons pas assez en question. Ou encore parce que le sujet à attaquer est trop gros pour être traité dans le cadre d’une petite fonctionnalité à ajouter au produit. Parfois enfin, parce que l’on évolue dans une équipe qui ne fait pas du tout ce travail de maintenance, ou qui ne le faisait pas.

Dans tous ces cas, nous détériorons notre application sur le long terme et il faudra sans doute trouver le temps plus tard de rembourser cette dette par un autre moyen.

Comment trouver du temps

Pour rembourser une dette technique lourde ou complexe, il faut y dédier du temps. C’est autant de temps qu’on ne pourra pas allouer à faire évoluer le produit fonctionnellement. Il faut donc réussir à convaincre sa hiérarchie et son client, qu’il soit interne ou externe, que c’est nécessaire.

Nous nous sommes retrouvés dans cette situation il y a un an. Après des essais infructueux qui avaient surtout amené des conflits entre développeurs et managers, notre application était dans une impasse technique et fonctionnelle. D’un côté beaucoup d’anciennes fonctionnalités n’avaient pas été nettoyées et augmentaient dangereusement la complexité du produit et du code, devenu difficile à appréhender. De l’autre, nos dépendances n’étaient plus à jour depuis plusieurs années, nos serveurs étaient mal configurés et notre base de code contenait des zones d’ombre qui réduisaient notre productivité et notre sérénité. Nous avons changé notre fusil d’épaule avec l’arrivée de nouveaux équipiers. Nous avons pris le temps d’expliquer notre vision de la situation à notre équipe produit, qui est notre client, en précisant en quoi c’était un problème important et quelles étaient les conséquences à venir.

Une fois ce constat partagé, nous avons pris le temps ensemble de nous organiser pour rembourser la dette de l’application sans mettre à mal les objectifs produit et business ambitieux de Captain Contrat.

Le process que nous avons fait émerger : nous réservons environ 20% de notre bande passante pour des tâches techniques que nous choisissons. Chaque tâche est présentée à l’équipe produit dans un souci de transparence, de confiance et de montée en compétence : nous avons besoin d’une équipe produit qui comprenne les enjeux techniques du développement web.

Quand tu réussis à faire comprendre l’importance de réduire la dette technique

Nous avons maintenant du temps pour faire évoluer notre application. À nous de l’utiliser efficacement.

Comment prioriser ?

Nous avons toujours l’impression de faire face à une montagne de tâches techniques à traiter, que chaque fichier contient dix fonctions à réécrire, que chaque dépendance est une complexité à maintenir et surtout que ces tâches sont toutes importantes. La raison principale est sans doute qu’il y a effectivement beaucoup de sujets à traiter et que certaines d’entre eux sont réellement importants.

Mais nous devons être vigilants à ne pas passer notre temps à réécrire du code qu’on comprend mal pour se l’approprier, ni à corriger une multitude de petits changements mineurs qui nous gênent. Ce ne sont sans doute pas ces petits cailloux dans la chaussure, certes assez gênants, qui posent le plus de problèmes sur le long-terme. Nous devons faire attention à ne pas tomber dans le piège de vouloir toujours réécrire l’existant sans avancer.

Pour nous organiser, nous listons dans un backlog commun les idées de sujets à traiter. Cela nous évite d’être frustrés quand nous rencontrons un problème : il est au moins recensé et chacun peut donner son avis dessus. Des objectifs trimestriels nous permettent ensuite de les prioriser pour nous attaquer aux sujets les plus impactants.

Pour fixer des objectifs, l’équipe se réunit 15 jours avant le début du trimestre et se met d’accord sur les sujets auxquels elle veut s’attaquer. Nous définissons des objectifs macro et des résultat-clés permettant de déterminer l’atteinte de chaque objectif. Un résultat-clé est mesurable quantitativement ou qualitativement.

Pendant un trimestre, nous choisissons lors de chaque sprint des tâches techniques qui vont nous permettre d’améliorer les métriques suivies pour l’atteinte d’un objectif. Chaque mois, nous faisons le point pour maîtriser les sujets sur lesquels il nous faut appuyer plus ou moins fort.

Un de nos objectifs sur le T3 2018 visait à améliorer notre productivité sur nos process d’intégration et de déploiement continus

Nos objectifs sont trimestriels pour correspondre à la temporalité des objectifs de Captain Contrat et des autres équipes. Nous avons essayé sur une temporalité semestrielle, mais en plus d’être désalignés avec le reste de l’entreprise, il était plus difficile d’évaluer l’ambition et la pertinence d’un objectif, puis de rester concentrés dessus pendant 6 mois.

Conclusion

Depuis octobre 2017 et l’arrivée de ce processus pour gérer notre dette technique, nous sommes fiers du chemin parcouru en termes de santé de notre application. Notre dette technique qui paraissait abyssale a été en grande partie remboursée. Nos dépendances et technos sont à jour, il reste très peu de fonctionnalités non utilisées, notre couverture de tests a augmenté, nos métriques de qualité de code sont remontées, et notre infrastructure de production est plus stable.

Équipes dev et produit en pleine discussion saine sur la dette technique (Pierre-Auguste Renoir, Le Déjeuner des canotiers, 1881)

Les deux changements clés qui nous ont permis d’atteindre ce résultat et qui sont indissociables sont :

  • la communication non-violente avec notre équipe produit et notre hiérarchie pour instaurer un climat de confiance ;
  • la prise de recul via la définition d’objectifs d’équipe englobant ce sujet pour s’assurer d’attaquer les bons problèmes.

Nous sommes entrés dans un cercle vertueux : moins de dette, moins de bugs et plus de productivité, plus de temps pour faire évoluer le produit.

Pour continuer à avancer, nous avons de nouveaux challenges devant nous :

  • continuer de remettre en question notre application pour avoir toujours un coup d’avance ;
  • faire évoluer le process pour l’adapter au fonctionnement en squads.