Blog Arolla

Quand réussir complique les choses

Refonte architecturale et refonte organisationnelle vont souvent de pair. D’un côté, les refontes architecturales actuelles promeuvent la modularisation en composants techniques, faiblement couplés et hautement cohésifs. Similairement, dans le cadre d’une transformation organisationnelle, le paradigme de la petite équipe pluridisciplinaire et autonome tend à être adopté. Dans ces deux cas, alors, vient la question de comment découper les équipes d’une part et les modules d’autre part, puis comment faire correspondre modules et équipes, pour finalement espérer déployer ces nouvelles organisations et architectures globalement.

Nous proposons dans cet article une abstraction théorique permettant de mieux agir sur cette problématique, autour du trinôme produit-composant-fonctionnalité. Nous aimerions que cela soit le point de départ d’articles ultérieurs, qui proposeront d’analyser au travers de cette grille de lecture des cas concrets qu’Arolla a pu rencontrer à travers différentes missions.

Two-pizzas team et architecture modulaire, même combat !

Côté architecture, le paradigme de modularisation est porté par les approches microservices, et plus encore le DDD et ses bounded contexts. Du côté de l’organisation le paradigme de la petite équipe pluridisciplinaire est notamment porté par les transformations agiles, partant de l’objectif de permettre de prendre la décision tactique au plus près du terrain, en optimisant le ratio information/personne pour que chacun puisse réagir au plus vite.

Les deux modèles fonctionnent nativement ensemble lorsque l’on a une une seule équipe, pour un seul produit, il est alors facile de faire évoluer le logiciel. Mais vite, si tout va bien, cette petite équipe va se retrouver face à deux enjeux.

product-team

Premier enjeu : l’Histoire.

Le “temps qui passe” peut vite commencer à poser problème : c’est ce qu’on appelle aussi Legacy en développement logiciel. Une façon de l’expliquer, que j’emprunte à Jessica Kerr, est que l’image mentale que les membres de l’équipe ont du système va se dégrader au fur et à mesure : du fait des roulements des personnes ou des projets, la représentation des systèmes que chacun se fera va se distordre ou se dissoudre. Cela va se traduire par la perte de confiance de l’équipe dans ses capacités à faire évoluer le système, elle va se le désapproprier. La pièce va s’assombrir, pour reprendre la métaphore puissante que file Christophe Thibaut dans le demi-cercle.

On peut se battre contre cela, notamment grâce aux bonnes pratiques XP/crafts, et ça demande de battre des pieds constamment pour garder la tête hors de l’eau. Après, c’est toujours mieux que de sombrer…

Second enjeu : la croissance

Curieusement, une fois qu’une entreprise a un produit qui fonctionne ou qui est utilisé, ce produit a tendance à grossir.

On me souffle que cela a été théorisé par les lois de Lehman (article en anglais) : par exemple, l’une d’elle dit que le contenu fonctionnel d’un système, dans un environnement réel doit être continuellement étendu, au cours de sa vie, afin de maintenir la satisfaction des utilisateurs. Pourtant, je n’ai pas encore trouvé en pratique les raisons profondes qui font qu’un site qui vend des voyages ou qui permet à des particuliers de publier des petites annonces, alors que la première version a pu être développée par une équipe de quelques développeurs, soient maintenus quelques années après par des équipes contenant des centaines d’ingénieurs. J’ai l’intuition que cela vient de problèmes de riches, c’est à dire venant du fait qu’on a plein de clients, nécessitant par exemple l’automatisation des processus métier, ce qui n’avait pas de sens à petit échelle ; des clients plus variés nécessitant ajustement et customisation ; parce qu’il y a de nouveaux besoins en termes de connaissances et de relationnel : analytics, BI, SAV, CRM, Marketing relationnel ; parce qu’enfin de nouveaux besoins techniques apparaissent : scalabilité de l’infrastructure, voire lassitude des équipes de travailler sur des technologies vieillissantes. Tout cela fait qu’on a envie de sortir plus d’incréments fonctionnels par jours (augmenter le débit). Sans compter les investisseurs qui, voyant l’argent rentrer, ne comprendraient pas qu’on ne puisse pas avoir plus de fonctionnalités juste en allongeant le cash. Si l’on ajoute en plus qu’il va falloir utiliser une partie de la bande passante à maintenir le legacy, aussi léger soit-il : le legacy tout seul, même iso-fonctionnel, va coûter de plus en plus. Et même de plus en plus à mesure qu’on ajoute des développeurs pour les raisons précédentes…

Mon premier conseil serait donc de vraiment savoir si vous avez envie de croître. Certains, comme David Heinemeier Hansson, avec BaseCamp, auraient fait le choix contraire et s’en disent ravis (je cherche la référence et je vous la donne).

Le triptyque produit / composant / fonctionnalité

Sinon, si vous avez désespérément envie de grossir, ou que vous êtes déjà gros, voilà l’approche que nous proposons.

Commençons par trois des définitions. Il y a :

  • le produit : c’est ce qui apporte de la valeur, du point de vue de l’utilisateur. N’a d’existence que par sa valeur d’usage. À ne pas confondre avec le système logiciel produit par l’équipe, en tant qu’artefact, parfois aussi appelé produit par les équipes techniques notamment ;
  • le composant : c’est l’unité technique autonome d’un système informatique (dans ce sens, c’est avant tout un artefact). Certaines organisations appellent cela “application”, tandis que d’autres préfèrent voir des “services”. La séparation du système en composants permets de dessiner des périmètres de confort, avec des frontières si possible visibles, qui fait que si on touche quelque chose à l’intérieur, il y a peu de risques d’avoir des conséquences imprévues à l’extérieur. Si le système n’est pas séparé en unité distinguées par des interfaces explicites (webservices…), quelques heuristiques peuvent aider à trouver les frontières (périmètre métiers, nommage, voire plus simplement technologies différentes) ;
  • la fonctionnalité (aka feature), ou incrément fonctionnel : c’est la moindre modification du produit lui permettant d’apporter plus de valeur. C’est la différence entre après et avant un changement du système, a priori perçu par l’utilisateur.

Notre principe postule que les problèmes arrivent quand ces trois entités sont partagés entre plusieurs équipes. Autrement dit, autant ça va bien quand les produits, les composants et les fonctionnalités coïncident avec les équipes, autant ça commence à aller mal quand ça se mélange.

La première chose qui va se passer est que, très rapidement, les nouvelles fonctionnalités vont se répartir sur plusieurs produits, dans le cas où chaque produit est développé par une équipe différente. Si vous prenez l’avion, pensez à ce qui s’est passé quand certaines compagnies aériennes ont voulu rendre les bagages payants, rien que sur les interfaces auxquelles vous êtes habituées à aller en tant que client : il a fallu changer les sites de moteur de recherche (qui pouvait être des sites différents des compagnies aériennes), les moteurs de facturation sur les sites de réservation de la compagnie, ainsi que les systèmes qui vous permettent de vous enregistrer à l’aéroport. Sans être aussi extrême, on se rend vite compte que beaucoup de fonctionnalités sont transverses, ne serait-ce que par les impacts comptables, logistiques, ou RH… et que c’est finalement ce qu’on reproche à un directeur marketing quand il oublie une des fonctions non marketing de l’entreprise dans ses nouveaux projets : le product manager a naturellement du mal à voir en dehors de son propre produit.

La seconde chose qui peut se passer, c’est quand les composants et les produits ne coïncident plus. Cela peut être parce qu’un composant est partagé par plusieurs produits, chaque produit étant alors développé par une équipe différente. Des exemples sont donnés dans la littérature promouvant le DDD. Par exemple, pour un site de vente en ligne, si vous décidez de créer un composant client, vous disant que cela permettra de centraliser les données clients dans un seul référentiel, Graal du CRM, vous allez vite vous rendre compte qu’il faudra sûrement que toutes les équipes touchent à ce composant, créant un besoin de synchronisation par des couplages inutiles. (Spoil pour ceux qui ne voudraient pas lire Domain Modeling Made Functional, la solution théorique est alors que chaque composant ait en fait sa propre projection du client dans son domaine).

Une dernière chose qui pourrait se passer c’est de séparer vos composants en couches métiers, ou, pire, techniques. Composant et produit ne vont plus coïncider et les produits seront sous la responsabilité de plusieurs équipes. Par exemple, dans un domaine ou les produits sont très complexes, comme les produits financiers, vous pourriez vouloir séparer la distribution de la production de vos produit. Ainsi, avoir d’un côté un composant portlet (sic), responsable de la promotion de vos produits, et, de l’autre, indépendamment pour chaque famille de produits, des composants protégeant le cœur du métier. Le souci va se poser dans la capacité à rapidement délivrer de la valeur, en devant synchroniser le travail de plusieurs équipes, puisqu’il faudra attendre que l’évolution se fasse d’abord côté cœur de métier, qu’elle soit déployée, pour pouvoir adapter le consommateur.

À l’attaque !

La bonne nouvelle c’est qu’une fois adoptée cette grille de lecture “composant-produit-fonctionnalité”, on peut plus facilement trouver les axes d’amélioration, en regardant ce qui ne peut pas bouger, les contraintes, voir si elles sont côté produit, feature ou composants, et ce qui va pouvoir bouger, qu’on va pouvoir redesigner, en particulier les équipes. Ou juste expliciter quand produits, features et composants ne coïncident pas, et prendre les mesures de coordination adéquates. Par exemple si le maintien du périmètre des produits est une contrainte, obligeant alors d’avoir des fonctionnalités sur plusieurs équipes produits, on pourra s’assurer de l’existence d’un comité dans lequel les différents responsables produits (ou PO) pourront examiner toutes les fonctionnalités, afin que chacun puisse se poser sept fois la question “est-ce que cette fonctionnalité va impacter mon produit”, et si la réponse est positive, intégrer des tâches de coordination dans le planning.

Nous avons déjà dans nos cartons plusieurs cas concrets que nous détaillerons dans des articles à venir. Nous avons par exemple un cas ou la volonté d’isoler la partie métier de la partie applicative est forte, ainsi qu’un autre cas où les fonctionnalités sont très vite à cheval sur plusieurs produits. Nous proposerons alors de les projeter suivant les axes produit-composant-fonctionnalité, puis identifier les zones où ils ne coïncident pas d’une part et les contraintes d’autre part, pour voir comment expliciter les frontières amovibles pourrait aider à améliorer à la fois l’architecture et l’organisation humaine.

On pourrait même classer les organisations dans une espèce d’algèbre relationnel P-C-F-T, où l’on chercherait à limiter les relations n:n, avec comme idéal un système dans lequel “plusieurs features composeraient un produit maintenu par une seule équipe au sein d’un seul composant”, comme F-n:1-P-1:1-T-1:1-C. En mettant cela dans l’ordre P-T-F-C, qui me parait finalement le plus naturel parce que cela ressemble à un impact mapping Goal/Actor/Impact/Deliverable, ça donnerait ça:

Alors, on est à deux pas d’imaginer les développeurs collaborer avec le métier sur la définition des features… Mais je m’égare.

Architecture et Organisation Indissociables

En attendant, deux groupes de personnes faciliteront cette convergence en travaillant ensemble : les architectes d’une part et les managers ou product managers d’autre part. Autour d’une table, chaque rôle comprendra avec ses mots les contraintes de l’autre. L’idée est d’éviter deux écueils : une architecture sans vision organisationnelle, et une organisation sans vision de l’architecture logicielle.

Ainsi, la définition des modules cherchera à réduire les frustrations organisationnelles telles des patterns anti-agiles, comme le contrôle ou la coordination forcée. Et réciproquement, le périmètre des équipes prendra en compte les périmètres techniques, en évitant par exemple plusieurs équipes à devoir faire évoluer des composants communs. L’article de Spotify donne un exemple des effets indésirables de ce manque d’alignement dans ce retour d’expérience : “Feature teams […] normally need to update multiple systems to get a new feature into production. The risk with this model is that the architecture of a system gets messed up if nobody focuses on the integrity of the system as a whole.” Pour spoiler, le papier propose déjà une piste de solution : “To mitigate this risk, we have a role called “System Owner”.”

À suivre !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *