Team Topologies

1L'organigramme ment sur qui parle vraiment à qui

Toute organisation a trois structures à la fois :

• la formelle (l'organigramme, pour la conformité) ;
• l'informelle (qui a de l'influence) ;
• celle de création de valeur (comment le travail se fait vraiment, de personne à personne).

L'organigramme ne photographie que la première, et pourtant on continue de s'en servir pour répartir le travail. La vieille blague du livre résume tout : « si vous avez quatre groupes sur un compilateur, vous obtiendrez un compilateur à quatre passes » (Eric Raymond, ch. 1).

Et le vrai goulot caché sous l'organigramme, c'est la charge cognitive : le livre s'ouvre sur une équipe de huit chez OutSystems qui couvre à la fois la CI, la CD, l'infrastructure et l'exécution des tests, touche-à-tout experte en rien, dont la motivation s'effondre doucement sous le context-switching (ch. 1).

2La loi de Conway, et la manœuvre qui la retourne

La loi de Conway (1968) dit que la conception d'un système est forcée de copier la structure de communication de l'organisation qui le construit. La reformulation de Ruth Malan est la phrase à retenir : « si l'architecture du système et celle de l'organisation s'opposent, c'est l'architecture de l'organisation qui gagne » (ch. 2).

Plutôt que de lutter contre cette force, le livre la retourne : la manœuvre inverse de Conway, c'est façonner les équipes d'abord pour obtenir l'architecture voulue. Vous voulez quatre services indépendants au lieu de quatre applications collées à une seule base partagée ? Arrêtez de mutualiser un DBA central et mettez la compétence base de données dans chaque équipe. Adidas a fait exactement ce genre de redécoupage et a multiplié sa fréquence de release par soixante (ch. 2).

Avec le corollaire contre-intuitif : plus de communication n'est pas mieux, deux équipes qui se parlent en permanence alors que le design dit qu'elles ne devraient pas, c'est un symptôme, pas une vertu.

3L'équipe est l'unité de livraison, et la charge cognitive est son budget

Arrêtez d'assigner le travail à des individus. L'unité du livre, c'est « un groupe stable de cinq à neuf personnes qui travaillent vers un but commun en tant qu'unité » (ch. 3), durable (il faut des semaines pour qu'une équipe se soude), et propriétaire pleine de son périmètre : « chaque partie du système doit être possédée par exactement une équipe ». Démanteler une équipe qui fonctionne, c'est, selon la phrase d'Allan Kelly citée en exergue du chapitre, de la « psychopathie d'entreprise » (ch. 3).

Et le vrai budget d'une équipe n'est pas son effectif, c'est sa charge cognitive, que le livre découpe en trois :

• intrinsèque : la difficulté inhérente au problème, à minimiser par la formation ;
• extrinsèque : comment redéployer, comment configurer, du bruit pur, à éliminer par l'automatisation ;
• germane : le domaine métier qui mérite l'attention, à maximiser.

Le geste pratique : dimensionner la part de système de chaque équipe pour qu'elle tienne dans sa tête, et publier une « Team API », le code, la doc et les canaux dont les autres équipes ont besoin pour interagir avec vous sans réserver une réunion.

4Quatre types d'équipes suffisent, pas trente

La plupart des organisations accumulent les types d'équipes comme du sédiment : infra, ops, outillage, middleware, QA, DBA, « l'équipe DevOps ». Le livre réduit tout ça à quatre, qui agissent comme des aimants vers lesquels chaque équipe devrait converger :

• Stream-aligned (alignée sur un flux) : alignée sur un flux de valeur unique (un produit, un parcours), livre de bout en bout sans passage de relais, et doit être la grande majorité, « le ratio d'équipes stream-aligned aux autres types devrait être entre 6:1 et 9:1 environ » (ch. 5).
• Enabling (habilitante) : des spécialistes qui aident une équipe de flux à acquérir une compétence manquante, puis s'en vont, elles visent leur propre disparition.
• Complicated-subsystem (sous-système complexe) : une équipe rare pour une partie si pointue qu'elle exige des experts (un codec vidéo, un moteur de tarification), créée pour réduire la charge cognitive des autres, pas parce qu'un composant est partagé.
• Platform (plateforme) : fournit du self-service interne pour que les équipes de flux n'aient pas à maîtriser toute la stack, et elle doit être « juste assez grosse », la plateforme viable la plus fine possible, parce que des développeurs livrés à eux-mêmes construisent toujours une plateforme plus grosse que nécessaire.

5Trois façons d'interagir, pas une de plus

Avoir les bonnes équipes ne suffit pas, il faut définir comment elles se touchent. Le livre n'autorise que trois modes :

• Collaboration : deux équipes travaillent étroitement pour une durée bornée, avec responsabilité partagée, idéal pour défricher un terrain nouveau (du cloud plus de l'embarqué, par exemple), mais coûteux, vous gardez le contexte de l'autre équipe en tête, donc une équipe ne collabore qu'avec une seule autre à la fois.
• X-as-a-Service : une équipe consomme ce qu'une autre fournit (une API, une plateforme) avec une friction minimale et sans coordination quotidienne, livraison prévisible une fois la frontière propre, au prix d'une innovation plus lente sur cette ligne.
• Facilitating (facilitation) : une équipe en aide une autre à lever des blocages et à apprendre, le mode par défaut des équipes habilitantes.

Le test tranchant qui suit : toute interaction qui n'est pas l'un de ces trois modes est du gaspillage, et le signe d'une frontière d'équipe mal placée.

6Où découper un système : trouver ses plans de fracture

Pour qu'une équipe possède sa part sans buter sans cesse sur les autres, il faut découper le système le long de coutures naturelles. Le livre les appelle des plans de fracture : « une couture naturelle dans le système logiciel qui permet de le scinder facilement en deux parties ou plus » (ch. 6), comme un tailleur de pierre frappe le marbre là où il veut se briser.

La couture par défaut, c'est le domaine métier (le bounded context du DDD) : un service de streaming musical se scinde proprement en découverte, diffusion et gestion des droits. D'autres coutures au besoin : le périmètre réglementaire (isoler la partie soumise au PCI-DSS pour que ses règles n'infectent pas le reste), la cadence de changement, le risque, la performance.

Le test pratique pour savoir si votre découpe est bonne : prenez votre prochaine fonctionnalité réelle et comptez combien d'équipes doivent se coordonner pour la livrer. Une seule = la couture est au bon endroit. Trois = vous avez coupé à travers un domaine, pas le long. (C'est le même test que pour les microservices dans la fiche Clean Architecture.)

Et le piège à fuir avant tout, c'est le monolithe distribué, le pire des deux mondes : « si vous avez des microservices mais que vous attendez de faire un test de bout en bout d'une combinaison avant une release, ce que vous avez, c'est un monolithe distribué » (Amy Phillips, ch. 6). Découper le code sans découper le déploiement vous achète le coût des microservices sans aucune de leur autonomie.

7Rien n'est figé, et le cadre seul ne suffit pas

Les topologies ne sont pas un état figé, elles évoluent sur des déclencheurs que le livre nomme : le logiciel dépasse ce qu'une seule équipe peut tenir (vous avez franchi les ~15 de Dunbar), la livraison ralentit, ou trop de services s'empilent sur un socle commun qui devrait devenir une plateforme. Le déclencheur le plus net se voit à l'œil nu : votre stand-up dépasse quinze personnes et traîne en longueur parce que la moitié n'écoute que sa propre partie. C'est le signal de Dunbar : l'équipe a dépassé la taille où chacun garde le contexte de tous. On scinde. Les équipes stables aux chemins de communication clairs deviennent les organes sensoriels de l'organisation, la façon dont elle sent le marché et se pilote elle-même.

Et le livre se referme sur une honnêteté rare : « Team Topologies seul ne produira pas une organisation efficace de livraison et d'exploitation logicielle » (Conclusion). Il faut en plus une culture saine, de bonnes pratiques d'ingénierie (déploiement continu, test-first, opérabilité), des finances saines et une vision business claire. La structure, c'est le plan de plantation, sans bon sol, eau et lumière, même le meilleur plan ne fait rien pousser. Une équipe a résumé tout l'esprit du livre : « on a utilisé Kubernetes parce qu'on voulait changer notre organisation », pas l'inverse (uSwitch, ch. 8).