Comment vendre une dette technique d’un point de vue DevOps ?

On avance souvent de façon dramatique et pathétique qu’il vaut mieux ne pas créer de dette technique. Oui, c'est mieux sans, bien sûr. Mais les conséquences peuvent encore être éliminées.

J'entends par dette technique tous les changements et améliorations, les modifications d'infrastructure et les changements de processus, les changements dans les structures d'équipe visant à éliminer les lacunes (réalisées consciemment ou non dans le cadre du lancement de produits) et les fonctionnalités qui interfèrent grandement au fil du temps.

Et comme de tels problèmes ne peuvent être résolus sans un travail d’équipe ferme et confiant des départements de production et des opérations, cette histoire concerne directement le DevOps.

Dette technique : à qui appartient-elle ?

Mais d’abord, la racine du problème : pourquoi est-ce que je parle de dette technique ? Parce que je suis très offensé que les entreprises ne leur consacrent pas de temps. Ce fil rouge traverse tous les rapports, rencontres et communications entre les développeurs et les opérations.

Les affaires mauvaises, mauvaises et terribles ne consacrent pas de temps au travail avec une dette technique. Même une question juste se pose : « N'ont-ils pas du tout besoin de qualité ? Pour l'avenir, je dirai : « Personne n'a besoin de qualité ». Mais je dévoilerai cette pensée un peu plus tard.

Pour analyser cette situation, voyons pourquoi les entreprises nous font cela. Et pour obtenir une réponse, nous devons réfléchir à qui appartient la dette technique. Qui en est responsable?

Après des années d'implication, j'ai réalisé que nous étions comme Frodon, qui offrait une bague à tout le monde. C'est comme : « Aide-moi à porter ce fardeau ! » Nous attendons que les entreprises veuillent (veuillent exactement) que nous nous occupions de la dette technique. Mais la cause profonde de notre incompréhension mutuelle avec les entreprises est qu’elles ne voudront jamais le faire.

Pour nous, il s'agit d'un défi d'ingénierie, d'un moyen d'améliorer l'excellence d'un produit ou même d'un mécanisme permettant d'accroître la fierté de notre produit. Mais pour les affaires, c'est toujours une nuisance, un mal nécessaire (ou une nécessité) auquel il faut consacrer du temps.

Imaginez que vous montez dans un taxi et que le chauffeur demande : « Puis-je m'arrêter au lave-auto ?

L'entreprise dans cette situation est un client et les développeurs sont le chauffeur de taxi.

• L'entreprise s'indigne : "Pourquoi ?! Je paie le temps de trajet et tu vas au lave-auto !"

• Ce à quoi le chauffeur de taxi répond raisonnablement : « Vous n'avez pas envie de rouler dans une voiture propre et qui sent bon ?

• L'entreprise répond : "Mec, bien sûr que oui ! Mais je m'y attends par défaut, et je ne suis pas prête à m'arrêter au lave-auto maintenant pour le plaisir !"

C’est ainsi que les entreprises traitent la dette technique. C'est comme une suggestion de s'arrêter dans un lave-auto. Je choisis la catégorie appropriée lors de la commande d'un taxi pour disposer d'un salon propre ou luxueux. Au stade de la commande, je suis prêt à investir, mais passer au lave-auto ne l'est pas.

Parce que, comme je l’ai dit plus tôt, personne ne veut de la qualité. Mais c'est prévu par défaut.

C'est un impératif. Les entreprises ne peuvent pas se résigner à ne pas aller au lave-auto, et les entreprises ne peuvent pas s'y rendre au détriment de leur temps. Alors que faisons-nous? Une entreprise est une locomotive. Il a besoin de fonctionnalités, de ventes et de clients. Il est impossible de vendre la dette technique à une entreprise à travers nos « je veux » et « je souhaite ». Mais il est possible de motiver les entreprises d’une autre manière.

Au cours de mon parcours, j'ai formé 3 catégories de motivations commerciales pour « acheter » de la dette technique :

• "Grosse" indifférence. Lorsqu'il y a un riche investisseur, le PDG peut se permettre l'équipe de développement composée de geeks bizarres. C'est comme : "Eh bien, laissez-les faire ! L'essentiel est de réaliser le produit, et l'esprit d'équipe est wow, tout est cool, et nous serions le meilleur bureau du monde".

  
  

  À mon sens, c'est un freestyle sympa qui mène souvent au désastre car la dette technique demande du pragmatisme. Quand nous ne le faisons pas de manière pragmatique, nous créons un Léviathan à l’architecture pseudo-cool.

• Peur. Il s’agit de l’un des modèles de dette technique les plus efficaces, les plus répandus et les plus efficients. De quel genre de « désir » peut-on parler ici quand ça fait peur ? Il s'agit de cas où quelque chose se produit, par exemple si un client est parti à cause d'un échec ou d'un piratage. Et tout cela est dû à la mauvaise qualité, aux freins ou à autre chose. Mais vendre sans détour par peur est également une mauvaise chose. La spéculation accompagnée de peur va à l’encontre de la confiance. Vous devez vendre avec soin et aussi honnêtement que possible.

• Confiance. C'est lorsqu'une entreprise vous donne autant de temps que nécessaire pour travailler sur la dette technique. La confiance ne fonctionne et n'est préservée que lorsque vous êtes soigneusement réduit à la part totale et aussi pragmatique que possible dans la prise de ce temps. Sinon, la confiance est détruite. De plus, cela ne s’accumule pas. Un processus constant se déroule par vagues : la confiance augmente puis disparaît.

Ensuite, je discuterai de mon expérience et de ce qui fonctionne pour moi et ma formidable équipe.

Quelle est la profondeur du terrier du lapin avec la dette technique ?

Lorsque j'ai rejoint la nouvelle entreprise il y a 3 ans, j'avais besoin de comprendre à quel point cette dette technique était importante. Je savais qu'il existait grâce aux statistiques de demandes, y compris celles des entreprises et des partenaires. J’avais besoin de comprendre à quoi je faisais face en général.

Il s’agit d’une première étape normale et obligatoire pour travailler avec la dette technique. Vous ne devriez pas vous précipiter pour faire la première chose que vous trouvez. Vous devez analyser la situation dans son ensemble.

Sur la base de ce que j'ai vu alors, j'avais supposé que l'un des problèmes fondamentaux était un couplage de code important. Désormais, j'implique moins tout le monde dans ce processus, mais à l'époque, j'avais réuni toute l'équipe de production pour déterminer les couches que nous voulions mettre en valeur dans notre suite d'applications.

Notre application comportait au moins 80 composants différents (distributions, pas installations). Après avoir compris la situation, il fallait y faire face.

Phase 1. Équipes virtuelles

Étant si intelligent, j'ai eu l'idée de faire comme si tout le monde avait du temps et de former une équipe virtuelle autour de chaque composant. Cela ressemblait à : "Les gars, qui prendra en charge quel composant ? Formulez vos suggestions sur la façon de l'améliorer." Mais pour rester concentrés, nous avons formulé tous ensemble les critères d’optimisation de la première phase :

• Couplage lâche
• Évolutivité rentable
• Connexion facile des nouveaux développeurs (principes simples et clairs : ce qui peut être fait exactement et ce qui ne peut pas être fait dans ce composant, plus isolement du code qui ne peut pas être "touché" par tout le monde)
• Possibilité d'utiliser une API externe là où cela est nécessaire
• Accessibilité de la pile technologique proposée
• Optimisations QuickWin dans les solutions actuelles
• Facilité de surveillance et de dépannage
• Principes de pureté d'audit + licence
• Principes de gestion des versions et d'obsolescence

Bien entendu, il ne s’agissait pas d’un objectif mais d’un ensemble de critères pour presque tous les aspects du développement logiciel. La liste entière peut être remplacée par une seule phrase : « Réparez tout ».

Cette phase s’est soldée par un fiasco, dans le sens où rien ne s’est produit. Nous avons fait très peu de progrès dans la mise en œuvre de certaines choses parce que j'essayais de les planifier à travers un arriéré partagé. Les tâches étaient incompréhensibles. Ils étaient mis au travail manuellement. J'ai vite réalisé que c'était dur pour moi et pour l'équipe, et que les conflits et les disputes ne cessent de croître.

Je suis donc passé à la phase 2.

Phase 2. La dette technique est la mienne

Au cours de la phase 1, j'ai convenu avec le PDG de notre entreprise que nous introduireions un quota de retard. Nous consacrerions 70 % aux problèmes commerciaux, 15 % à l'élimination des défauts et 15 % à la dette technique.

Deuxièmement, lors de la phase précédente, j’ai réalisé que si tout le monde est responsable d’un problème, personne n’est responsable de ce problème. Ce n’est pas du tout une déclaration turquoise. Je n'aime pas ça moi-même. Mais l’inverse demande un très haut niveau de maturité et un travail d’équipe. C'est pourquoi j'ai décidé de former un système de leaders techniques.

Mais je n'ai pas simplement nommé une personne pour être le responsable technique d'un composant. J'ai exposé au maximum mes attentes, défini leur parcours de développement et les ai rendus responsables de la situation de la production. Les experts OPS ne sont pas réveillés si votre composant gâche la production. C'est vous qui essayez de résoudre la situation.

Et donc nous sommes partis. Il y a des leaders techniques (les responsables) et un quota de 15% de dette technique (il y a du temps). Mais à quoi ressemble finalement la réalité ?

La première chose que nous avons rencontrée, c'est que nous avons la FinTech, la conformité et la séparation des tâches, c'est-à-dire que moi et le développement n'avons pas accès à la production et ne pouvons pas l'avoir par définition. Et pourtant, je dis : « Les gars, vous êtes responsables de la situation en production !

Donnez aux gens les journaux !

Lorsque vous confiez des responsabilités aux gens, donnez-leur un outil entre leurs mains. Et c'est la première chose que nous avons faite avec les experts OPS, fournir des logs aux techniciens afin qu'ils puissent voir les logs de leurs composants.

Et nous avons mené un véritable effort de collaboration – notre premier pas vers DevOps, où les opérations et le développement travaillent ensemble. L'exploitation mettait en place le transfert des logs (Kibana, etc.), tandis que le développement devait s'assurer que les logs ne contenaient pas d'informations sensibles (données personnelles, etc.).

5% est considéré comme chanceux...

La réalité est que malgré le quota de 15 %, il y a des crises commerciales et des injections urgentes à chaque sprint car "Le partenaire en a besoin maintenant, ou il partira !" Bien sûr, cette dette technique est d'abord expulsée du sprint - en conséquence, nous avons eu des sprints à 0 %.

Il y a eu aussi des sprints à 15%, mais nous n'avions que 5 à 8% de dette technique en moyenne. C'est un gros problème car un programmeur ne peut pas savoir de combien de temps il disposera pour l'implémentation.

Pour ma part, j'ai essayé d'aider à cette situation en faisant voler sans relâche un cerf-volant au-dessus de toutes les équipes. Nous avons appris à collecter des métriques détaillées pour chaque sprint, et j'ai regardé le sprint à la fin.

Le piratage de sprint, c'est lorsque le quota de dette technique est systématiquement violé. Si le quota n’est pas atteint en un seul sprint, cela ne veut pas dire que tout va mal. En effet, les situations sont différentes et il faut être flexible.

Mais quand cela s'est répété systématiquement, j'ai réuni les experts en production, j'ai argumenté et j'ai expliqué à quel point c'était important et inacceptable parce que le quota avait été convenu. C'était mon travail quotidien de faire évoluer le processus dans ce modèle.

Et cela a effectivement évolué, mais je crois désormais que cette approche présente ses propres défauts importants.

Limites de l'approche

Les Product Owners sont habitués au fait que le backlog leur appartient entièrement et que toutes les tâches sont coordonnées par eux : « Le quota est bon, mais nous seuls décidons de ce que l'équipe fera dans ce quota de dette technique !

Et lorsque les développeurs ont proposé des tâches (rappelez-vous de la connectivité forte) comme la refactorisation, l'élimination des passe-partout, etc., ils ont eu une réaction logique : "Quoi ?! De quel passe-partout ? De quoi parlons-nous ?!"

En conséquence, les tâches ont été remplacées par celles que l’on pourrait qualifier de dette technique mais qui étaient conditionnellement avantageuses pour le vendeur. C'est pourquoi j'ai dû adopter une position ferme et dire : « La dette technique est la mienne ! Et j'affirme qu'elle sera incluse dans la dette technique de chaque équipe produit dans le quota de dette technique de chaque sprint.

C'est ainsi que nous avons vécu. Même si nous vivions et travaillions normalement, la méfiance s’est renforcée. Lorsque nous faisons quelque chose sans le dire à personne et que nous ne consacrons pas de temps à des tâches professionnelles, tout le monde ne sait pas exactement quel résultat nous apportons.

Étant donné que les statistiques sur l’utilisation des quotas techniques de dette montaient en flèche, nous avons été confrontés au fait que nous ne pouvions pas réaliser de grands projets. De plus, les grands projets nécessitent souvent plusieurs équipes. Cela était également impossible car chaque équipe produit est concentrée sur son produit et vit dans ses réalités. Il est impossible de les ancrer sur un sujet complexe.

De plus, personne n’a inclus les opérations dans les sprints. Ils n'ont pas de sprints et de retards comme la production. Ils sont submergés de tâches de production, mais cela n'était pas inclus dans les plans globaux. Et lorsque le développement s'accompagnait de quelque chose de réalisé dans le cadre de ces petits éléments de dette technique à déployer en production, cela pouvait rester dans les demandes d'OPS pendant assez longtemps.

Parce qu’ils n’avaient vraiment pas de temps, étaient chargés de tâches supplémentaires et étaient empêchés de travailler.

Mais malgré les aspects négatifs de cette approche, nous avons réalisé beaucoup de choses.

Qu’avons-nous réalisé avec cette approche ?

Tout d’abord, nous avons développé la masse musculaire des autotests. En repensant considérablement l'ensemble du processus CI, nous en avons fait un processus civilisé dont nous n'avons pas honte.

Deuxièmement, nous avons mis en œuvre avec succès la lutte contre le code spaghetti dans de nombreux composants.

Nous avons réalisé une modularisation et réduit les passe-partout. Ces tâches ne peuvent pas être vendues à l’entreprise, même par peur. Si les lacunes technologiques de votre produit contiennent ces problèmes et que vous devez les résoudre (s'ils existent, cela doit être fait en premier), vous n'avez même pas besoin d'essayer de les vendre. Cela ne peut se faire qu’à travers le modèle « Dette technique – c’est à moi », uniquement par le biais de quotas.

J'ai vu de nombreuses tentatives et j'ai essayé de procéder différemment moi-même dans la première phase. Cela n'a pas fonctionné.

En effet, travailler dans ce mode ne peut pas durer longtemps. C'est une carte blanche limitée que vous donne la direction, vous faisant confiance en tant que CTO et chef d'équipe.

Phase 3. Projet légitime

Ensuite, nous avons lancé la phase 3 – un projet « légitime » pour travailler sur la dette technique. L'hypothèse était que nous nous éloignons d'un quota fermé, planifions à travers un backlog de produit commun (c'est-à-dire que les propriétaires de produits acceptent que ces projets doivent être réalisés) et que nous nous dirigeons vers une vente propre. Pour y parvenir, nous avons fait 2 choses :

• J'ai réduit au maximum la portée des travaux que nous avons commencé à réaliser dans le cadre de ce projet.

• J'ai formé des attentes concrètes sur ce pour quoi nous nous battrons en production. C'était un rejet total de l'idéalisme, car nos tâches devaient être aussi pragmatiques que possible, compréhensibles et utiles au service d'un point de vue commercial.

Un point important est que nous avons une certaine illusion que nous essayons de calculer la valeur commerciale de la dette technique, même si cela est rarement possible. Et si cela peut encore être calculé, alors nous avons une dette technique cauchemardesque !

Une valeur positive fonctionne mieux pour les entreprises qu’une valeur négative. Si vous dites : « Ce client va partir. Il rapporte tellement d’argent », alors jusqu’à ce qu’il parte, cela ne marchera pas. Ce n'est pas une valeur commerciale. De plus, la culture du travail avec les risques n'est pas encore très élevée, c'est pourquoi le mode est le suivant : « Aucune perte jusqu'à leur départ ».

Il n’est pas non plus nécessaire de démontrer une valeur commerciale. Là où vous pouvez le montrer, mais vous pouvez montrer la valeur technologique, seulement elle doit être calculée.

Guide sur la façon de vendre de la dette technique

Voici l’intégralité du workflow de cette phase de vente de dette technique.

Choisissez un domaine d'intérêt (un seul)

Puisqu’il s’agit de vendre par peur, choisissez un domaine qui affecte réellement votre entreprise. Les domaines peuvent être différents : disponibilité, rapidité de retouche, sécurité des tests et expériences A/B et coût de retouche. Il existe un grand nombre de domaines et de sujets.

Dans mon cas, j'ai choisi l'accessibilité parce qu'elle était sur le radar de l'entreprise et qu'elle avait un certain impact sur notre service. Il est essentiel de ne pas s’éparpiller et de ne choisir qu’un seul sujet.

Faire une analyse intégrale

J'ai analysé les statistiques de disponibilité et d'incidents pour l'année et analysé en détail toutes les autopsies de toutes les situations survenues tout au long de l'année. Après cela, j'ai acquis une compréhension de haut niveau de ce sur quoi nous devons travailler autant que possible techniquement, mais encore une fois, sur le fond.

La première règle de disponibilité n’est pas d’essayer de construire un système qui sera toujours disponible mais d’être prêt lorsqu’un incident survient. C'est ce que nous devons garantir.

Le deuxième problème et règle de base de la disponibilité est l'accord de dégradation : quelque chose va forcément se produire un jour, et vous devez être prêt à préserver votre service, peut-être au prix de renoncer à certaines fonctionnalités que vous fournissez. Cet accord doit être maintenu, y compris au niveau des programmes.

Le troisième problème concerne le suivi et l’observabilité. Il s’agit de la localisation rapide des sources d’incidents et du temps de détection des réponses. Si vous avez beaucoup de tests irréguliers, vous devrez cesser de faire confiance à votre surveillance. Si vos tests de production contiennent des instructions pour les réactions du service desk telles que « Si le message ne s'est pas éteint dans 5 minutes, appelez-moi » - vous ne surveillez pas la situation de production. Le test doit être aussi clair que possible : "Ça se voit, ça veut dire qu'il y a un problème quelque part, allons-y !"

Effectuer une analyse composant par composant

À cette fin, nous avons défini ce que nous ferons exactement pour chaque direction et chaque composant. Nous voulons dire où nous allons insérer le maillage de services, comment nous allons bouleverser la surveillance et en fonction de quoi. Ici, nous en avons répertorié environ 15 %, mais en fait, il y a beaucoup d’améliorations du programme.

Nous avons tout expliqué, mais ce n'est pas encore commercialisable. Pour le montrer ouvertement maintenant, nous avons fait ce qui suit pour chaque projet de cette phase.

Formuler des indicateurs substantiels et quantitatifs

Nous avons très peur des indicateurs quantitatifs : comment mesurer la qualité du travail des développeurs avec des indicateurs quantitatifs ? Nous avons de nombreux arguments contre les indicateurs quantitatifs, mais il ne faut pas les prendre de front.

La valeur ne doit pas être considérée uniquement comme une valeur commerciale. Ils peuvent être formulés, par exemple, comme « pas plus de X faux positifs ».

Vous pouvez répertorier un ensemble spécifique de composants pour lesquels il est essentiel de fournir des versions Canary ou la possibilité de garantir une restauration garantie des correctifs. La disponibilité globale doit bien entendu être un indicateur quantitatif. C'est un impératif.

Défendre les projets

Avec cet ensemble de projets pragmatiques, des mesures aussi claires que possible et les résultats que nous devons atteindre, j'ai dit : « Les gars, j'ai besoin d'un quota de dette technique. J'ai besoin que vous incluiez ces projets dans votre pool pour les accélérer afin qu'ils entrer dans la planification globale sur une base entièrement légale avec les objectifs commerciaux.

Cela a été entendu, nous l’avons fait et cela a fonctionné. Je pense que c'est comme la vidéo sur la façon de dessiner un hibou : "Dessinez un ovale et deux tirets". À la fin – magique – vous obtenez un hibou ! Mais toute la magie réside dans le fait qu’il faut réussir tout ce projet et le mener à son terme.

Non seulement faire certaines choses dans ce sens mais les amener au résultat. C'est-à-dire atteindre les indicateurs quantitatifs énoncés et les montrer. Cet abîme ne peut pas être franchi dans 95 % des cas. Il faut le sauter complètement.

Avantages de l'approche

Alors, nous avons commencé à sauter (par-dessus l'abîme). Nous le faisons avec succès. Nous en sommes maintenant à la deuxième phase de ce projet. Autrement dit, nous avons sélectionné le premier groupe de projets et convenu du deuxième groupe de projets. Qu'est ce qui a changé?

Augmenter la confiance

La confiance est puissamment accrue grâce à l’ouverture si nous montrons des mesures réelles et quantifiables. Mais la vérité est que la vente technique de dette découle de la peur. Cette étape ne peut être évitée. Mais il ne faut pas non plus en avoir peur ou en avoir honte. L’essentiel n’est pas de spéculer sur la peur mais de réellement l’analyser, comme je l’ai montré en différentes phases (analyse intégrale, analyse composante par composante).

Réaliser de grands projets

Puisqu’il s’agit désormais de projets légitimés, nous pouvons synchroniser toutes les équipes et réaliser de très gros projets. Certains projets ont été réalisés séquentiellement de sprint en sprint. Nous sommes suivis régulièrement (une fois par semaine) au sein de ce projet par la composition de l'équipe technologique et comprenons qui est où (dans quelle phase).

Ces informations sont aussi ouvertes et transparentes que possible. L'avancement des projets et les statuts actuels sont publiés et disponibles pour les propriétaires de produits (et toute autre personne souhaitant les voir).

Les OPS dans le projet

Plus important encore, nous avons réalisé que nous avions beaucoup de choses à repenser dans l'infrastructure et le processus de déploiement. Les OPS ont été explicitement inclus dans ce projet.

Dans mon esprit, il s'agit plus de DevOps que de Kubernetes et de Docker lorsque les OPS discutent avec les développeurs de la façon de modifier l'architecture d'un composant, et que les développeurs discutent avec les OPS de la meilleure façon de modifier l'infrastructure.

Pourquoi ne l'ai-je pas fait tout de suite ?

On revient ici à ce dont je parlais à la fin de la phase 2 : ça n'aurait pas marché avant. Parce que ce que nous avons fait dans la phase 2 (le code spaghetti que nous avons repensé, le renforcement des tests et la refonte des processus CI) aurait été impossible à vendre à l'entreprise en termes de mesures mesurables.

Cette situation n'était liée à aucune peur particulière, et notre argument standard, "Nous prenons beaucoup de temps à coder parce que le code spaghetti" - personne dans le secteur n'écoute. Nous n’aurions donc pas pu adopter cette approche.

De mon point de vue, si vous disposez d’une plate-forme technologique qui nécessite une refonte aussi profonde de l’infrastructure, vous ne pouvez pas éviter la phase 2.

Il faut y aller, mais il faut être prêt non seulement à voler comme un cerf-volant tout le temps mais aussi à fermer cette boutique assez rapidement pour ne pas perdre la confiance de votre entreprise.