La relation entre l'organisation des équipes et l'architecture applicative

Cette relation est connue sous le nom de loi de Conway, \u00e9nonc\u00e9e par Melvin Conway en 1967 : \u00ab Les organisations qui con\u00e7oivent des syst\u00e8mes […] sont limit\u00e9es \u00e0 produire des conceptions qui sont des copies des structures de communication de ces organisations. \u00bb

La communication au sein de l’\u00e9quipe est fr\u00e9quente et fluide, avec des r\u00e9unions de planification r\u00e9guli\u00e8res, des dailies, des r\u00e9trospectives et des d\u00e9mos. Cela permet \u00e0 l’\u00e9quipe d’avoir un haut niveau d’alignement et une coordination agile, ce qui est fondamental pour le d\u00e9veloppement d’un composant. Si vous d\u00e9cidez soudainement de diviser cette \u00e9quipe en 2 \u00e9quipes, il y a une rupture dans la communication. La communication avec les autres \u00e9quipes est beaucoup moins fr\u00e9quente, car l’une des id\u00e9es des \u00e9quipes est de les isoler des facteurs externes afin qu’elles puissent se concentrer sur leur p\u00e9rim\u00e8tre. Cette r\u00e9duction de la communication entre les \u00e9quipes rend la t\u00e2che de maintenir un seul composant plus complexe. Dans ces cas, il y a deux options : 1) Diviser le composant en 2, un par \u00e9quipe, ce qui permet aux \u00e9quipes de se d\u00e9coupler et de travailler de mani\u00e8re plus autonome. 2) Maintenir un seul composant, ce qui implique la mise en place d’une s\u00e9rie de m\u00e9canismes de coordination et de r\u00e9unions entre les \u00e9quipes, avec la surcharge que cela entra\u00eene. De plus, les \u00e9quipes sont interd\u00e9pendantes, ce qui r\u00e9duit la vitesse et l’autonomie et affecte la productivit\u00e9 (puisqu’elles doivent travailler si \u00e9troitement ensemble, on pourrait presque dire que, pour des raisons pratiques, il n’y a toujours qu’une seule \u00e9quipe).

Traditionnellement, la r\u00e9organisation des \u00e9quipes est souvent faite par le haut, et pas toujours par des personnes ayant une connaissance approfondie de l’architecture applicative. \u00c0 maintes reprises, j’ai vu des \u00e9quipes \u00eatre r\u00e9organis\u00e9es autour des clients, de sorte que lorsqu’un nouveau client arrivait, une nouvelle \u00e9quipe \u00e9tait cr\u00e9\u00e9e. Et dans certains cas, nous finissions par forker le code comme solution pour que la nouvelle \u00e9quipe soit ind\u00e9pendante et agile. Avec tout ce que cela implique : dupliquer le code, avec tous ses bugs et sa dette technique ;

Afin de r\u00e9aliser une r\u00e9organisation plus sensible \u00e0 l’architecture qui n’impacte pas n\u00e9gativement l’application, il existe ce qu’on appelle la manoeuvre inverse de Conway. Celle-ci consiste \u00e0 organiser l’\u00e9quipe de mani\u00e8re \u00e0 ce qu’elle imite l’architecture de l’application \u00e0 atteindre. Pour concevoir ce type de r\u00e9organisation, il est essentiel de compter sur la collaboration des architectes logiciels, qui aideront \u00e0 la concevoir en utilisant les principes de l’architecture logicielle. Les \u00e9quipes peuvent \u00eatre vues comme un syst\u00e8me, avec diff\u00e9rents composants ayant leurs responsabilit\u00e9s et dont la communication se fait \u00e0 travers des interfaces bien d\u00e9finies.

Si ce sujet vous int\u00e9resse davantage, je recommande le livre Team Topologies, de Matthew Skelton et Manuel Pais. Et si vous avez besoin d’aide ou de conseils pour aborder une r\u00e9organisation, vous pouvez me contacter ici.