Comment contrôler la multiplication des logiciels

Au début, les symptômes de la multiplication des logiciels peuvent être difficiles à reconnaître. Il peut s'agir de problèmes mineurs qui sont mis de côté au profit de priorités plus importantes. Pourtant, si rien n'est fait, la multiplication des logiciels peut paralyser les équipes de développement en raison d'une charge cognitive plus élevée, réduire l'engagement des équipes et annuler les avantages associés à une architecture à couplage lâche. Comme le dit le proverbe : « Le meilleur moment pour planter un arbre était il y a 20 ans. Le deuxième, c'est maintenant. » La réussite future nécessite de maîtriser la multiplication des logiciels avant qu'elle ne pose problème.

Vous trouverez ci-dessous trois signes de la multiplication des logiciels et différentes solutions pour maîtriser le chaos tout en créant un environnement innovant et dynamique qui libère le potentiel de chaque équipe.

L'un des premiers symptômes de la multiplication des logiciels est la présence de plusieurs revues post-incident (PIR) indiquant que les changements en amont sont à l'origine d'un incident. Le nombre croissant de microservices et l'augmentation du volume de changements au sein d'un environnement peuvent mettre à rude épreuve les normes existantes en matière de collaboration des développeurs et de coordination des changements. Même une légère augmentation de la fréquence des changements de mensuelle à hebdomadaire pour une application modernisée peut se traduire par une multiplication par 100 des livraisons par mois. Rien d'étonnant à ce que les développeurs aient besoin d'adapter leur méthode de collaboration. Les incidents sont plus susceptibles de survenir en production lorsque les normes de collaboration des développeurs ne sont pas adaptées à un environnement dynamique.

Créer un moyen non intrusif permettant aux développeurs de se tenir informés des changements en amont et en aval constitue un excellent moyen de maîtriser l'impact de la multiplication des logiciels. Chez Atlassian, nous utilisons Compass (un portail de développement qui aide les équipes à comprendre les architectures distribuées) pour envoyer une notification dans l'app aux équipes de développement concernant les changements problématiques apportés aux services en amont et en aval. Lorsque les équipes responsables des services dépendants accusent réception de cette notification, elles indiquent à l'initiateur du changement qu'elles ont pris connaissance de ce dernier. Cela permet de collaborer sur le changement si des tickets sont prévus, afin de réduire le risque d'impacts imprévus sur la production. Comme les incidents sont inévitables dans un environnement dynamique, la collaboration des développeurs en cas d'incident est essentielle pour rétablir rapidement les services.

Dans les revues post-incident, où les changements en amont constituent la cause profonde, il est fréquent que le temps nécessaire pour restaurer les services soit affecté par le temps nécessaire pour identifier le changement en amont problématique, ainsi que l'équipe ou la personne propriétaire du service. Logiquement, la réduction du temps nécessaire pour identifier le changement en amont problématique réduit le temps moyen de reprise d'activité (MTTR) au fil du temps. Cela est d'autant plus difficile dans une architecture à couplage lâche, où les services présentent une hiérarchie de dépendances riche et où la cause profonde d'un incident peut se situer à n'importe quel niveau de la stack. Traditionnellement, les intervenants sur l'incident parcourent les journaux ou les enregistrements des changements pour identifier ceux susceptibles d'être à l'origine d'un incident. Dans un environnement dynamique, c'est comme détruire une fourmilière pour retrouver la fourmi qui vous a mordu.

Chez Atlassian, nous utilisons le flux d'activité de Compass pour réduire le MTTR. Il affiche tous les événements relatifs aux systèmes en amont ainsi que les informations sur l'équipe propriétaire. Cela réduit considérablement le temps de tri en favorisant la collaboration des développeurs en cas d'incident. Des incidents peuvent se produire, mais il est essentiel d'identifier rapidement un changement en amont comme étant la cause profonde d'un incident pour limiter l'impact et restaurer rapidement les services.

L'adoption d'une architecture à couplage lâche est l'un des principaux ingrédients de la productivité et de la satisfaction de l'équipe : la possibilité d'agir avec un haut niveau d'autonomie. Si rien n'est fait, la multiplication des logiciels peut annuler certains de ces avantages, ce qui se traduit par une équipe débordée, mais non productive et mécontente. Les équipes de développement se plaignent souvent que tout fonctionne bien jusqu'à ce qu'elles doivent interagir avec une autre équipe. Cela est d'autant plus vrai lorsque la multiplication des logiciels devient un problème. Un environnement qui s'étend et se développe rapidement réduit la capacité des développeurs à savoir qui impliquer en cas de dépendances en amont ou en aval, ce qui entraîne un ralentissement et une frustration accrue pour les équipes qui essaient de garder le rythme.

À titre d'exemple, imaginons que les équipes Alpha et Bêta aient le même nombre de tickets et de story points terminés dans Jira chaque semaine. L'équipe Alpha consacre 90 % de ses efforts à livrer de nouvelles fonctionnalités en production, tandis que l'équipe Bêta consacre 30 % aux nouvelles fonctionnalités et 70 % à la recherche de moyens d'interagir avec les nombreux services en amont dont elle dépend. Les deux équipes affichent le même niveau de charge, mais seule l'équipe Alpha peut éventuellement être considérée comme productive. La multiplication des logiciels accentue la nécessité de collaboration entre les équipes. Il est essentiel de trouver des moyens intelligents permettant aux équipes autonomes d'interagir avec la demande pour tirer pleinement parti d'un environnement à couplage lâche.

Dans un environnement dynamique et en pleine croissance, la possibilité d'accéder à des informations en libre-service est importante pour la productivité et la satisfaction de l'équipe. L'un des moyens d'y parvenir est d'implémenter un catalogue centralisé de composants logiciels avec une gestion décentralisée. Il s'agit d'un catalogue centralisé dans lequel chaque équipe est chargée de créer et de mettre à jour les services dont elle est propriétaire. Les environnements traditionnels disposent généralement d'un catalogue centralisé géré par une équipe ou une fonction spécifique. Cependant, cette configuration ne permet pas de s'adapter aux changements dans un environnement distribué, ce qui oblige les équipes à créer des wikis fictifs pour savoir avec qui interagir et comment. Chez Atlassian, nous avons découvert qu'une approche décentralisée réduit les efforts invisibles et inutiles des équipes, améliore les fonctionnalités en libre-service et crée un environnement d'interaction à la demande. Maîtriser la multiplication des logiciels en fournissant des informations en libre-service sur les dépendances en amont et en aval est un excellent moyen d'améliorer non seulement la productivité, mais aussi la satisfaction et l'engagement de l'équipe.