Les Patterns des Grands du Web – Feature Team

Description

Dans l’article « Pizza Team », nous avons vu que les géants du Web prêtaient beaucoup d’attention à la taille de leurs équipes. Mais ce n’est pas le seul point de vigilance qu’ils ont sur leurs équipes : ils veillent aussi fréquemment à avoir des équipes organisées par fonctionnalité, autrement dit des « feature teams ».

La petite équipe polyvalente est la clé pour aller vite, et la plupart des géants du Web tentent de résister le plus longtemps possible à la multiplication d’équipes pour réaliser un seul produit.

Malgré tout, si le succès advient, arrive un moment où la dizaine de personnes ne suffit plus et où il faut pouvoir monter en charge. Même dans ce cas, on ne déroge pas à la règle des équipes « à taille humaine » et il faut donc augmenter le nombre d’équipes. Se pose alors la question de l’axe selon lequel les découpages de périmètres doivent se faire.

Il existe deux grandes options^[1] :

• Le découpage par couche « technologique ».
• Le découpage par « pan fonctionnel ».

Par « pan fonctionnel », il faut comprendre le fait de livrer de bout en bout des fonctionnalités autonomes, qui rendent un service à l’utilisateur final.

A l’inverse le découpage par couche technologique consiste à dédier chaque équipe sur un type de technologie : typiquement, la couche présentation, la couche métier, les socles transverses, la base de données…

C’est d’ailleurs traditionnellement le mode d’organisation retenu dans nos DSI où les personnes sont souvent regroupées par spécialités.

Mais à partir du moment où le Time To Market devient un enjeu critique,  le mode d’organisation par couche technologique, dit encore component team, commence à montrer ses limites. En effet, qui dit Time To Market dit souvent méthode de type Agile ou Lean. Et donc de la spécification, du développement, de la mise en production le plus possible selon des cycles courts, voire au fil de l’eau.

Or, avec des component teams, on se retrouve très vite dans des situations de goulet d’étranglement.

Prenons l’exemple décrit sur la figure 1.

Figure 1.

Les flèches rouges décrivent le premier problème. Les fonctionnalités les plus importantes (fonctionnalité 1) sur-sollicitent l’équipe Front. Les autres équipes doivent produire des choses marginales pour ces fonctionnalités. Malgré tout, on ne peut rien livrer tant que l’équipe 1 n’a pas fini. Les autres équipes, ne pouvant pas vraiment aider l’équipe 1 (car n’étant pas de la même spécialité), elles n’ont d’autre choix que de ne pas produire ou alors de faire du stock de fonctionnalités moins importantes (et le stock, en Lean, c’est mal…).

Il y a plus grave. La fonctionnalité 4 nécessite de faire collaborer les 4 équipes. Seulement voilà, en mode Agile, c’est au sein de chaque équipe que se fait l’analyse détaillée. Or, dans ce cas, il faut faire l’analyse détaillée des impacts sur les 4 équipes. Donc du coup, il faut faire une analyse détaillée en amont, ce que précisément on essaie d’éviter en fonctionnement Agile. De la même façon, en aval, il faut synchroniser le travail des 4 équipes pour pouvoir tester, et donc attendre l’équipe la plus lente. Pour limiter les impacts, cela signifie qu’il faut définir des priorisations de tâches de chaque équipe de façon centralisée. Et on se retrouve petit à petit dans des gros plannings qui cherchent à synchroniser au mieux toutes les activités mais qui enlèvent de l’autonomie aux équipes.

Bref, on se retrouve à faire de la cascade en amont à la fois pour l’analyse et la planification et de la cascade en aval pour du test et de la mise en production. Cette dynamique est très bien décrite dans l’ouvrage de Craig Larman et Bas Vodde, « Scaling Lean And Agile ».

Les feature teams permettent de corriger ces défauts : chaque équipe travaillant sur un sous-ensemble fonctionnel cohérent – et ce, indépendamment des technologies - elle est capable à tout moment de livrer de la valeur au client final en dépendant faiblement des autres équipes. Cela implique que dans une même équipe se retrouvent toutes les compétences nécessaires à la production de fonctionnalités, et cela peut vouloir dire (entre autre) un architecte, un ergonome, un développeur Web, un développeur Java, un expert base de données, et, oui, même un exploitant… car quand on pousse la logique à l’extrême, on tombe sur le « you build it, you run it » de DevOps, décrit dans notre article de blog dédié à ce sujet.

Mais du coup, comment assure-t-on la cohérence technologique de ce qui est produit, si chaque expert Java de chaque feature team prend des décisions sur son périmètre ? Ce point est adressé par le principe des communautés de pratiques. Les pairs de chaque type d’expertise se réunissent à intervalles réguliers pour échanger sur leurs pratiques et s’accorder sur des stratégies technologiques par rapport à la fabrication du produit en cours.

Les feature teams présentent également un intérêt induit non négligeable : les équipes progressent très vite sur le métier et cela favorise l’implication des développeurs dans la vision produit et dans la qualité du résultat final.

La pratique est évidemment un peu moins rose que ce que nous décrivons ici (la définition des périmètres n’est pas simple, il reste des adhérences entre équipes à gérer, il faut arriver à faire vivre les communautés de pratiques…). Malgré tout, ce mode d’organisation présente de réels avantages par rapports aux organisations en couches et permet d’être beaucoup plus efficace et agile.

Et pour en revenir à nos géants du Web, c’est un mode d’organisation qu’ils tendent à privilégier. En particulier Facebook, qui communique beaucoup sur sa culture, met en avant le principe d’équipes mixant toutes les compétences nécessaires pour construire une fonctionnalité.

C’est également une organisation retenue pour le développement de leurs produits par Viadeo,Yahoo! et Microsoft (cf. Michael A. Cusumano and Richard W. Selby. 1997. How Microsoft builds software. Commun. ACM 40, 6, June 1997, 53-61).

Et chez moi ?

Les géants du Web ne sont pas les seuls à appliquer le principe des feature teams. C’est souvent le mode d’organisation également retenu chez les éditeurs de logiciels.

Par ailleurs, l’Agile se diffuse de plus en plus largement dans nos DSI et commence à être appliqué à des projets de plus en plus gros. A partir d’une certaine taille de projet (3 à 4 équipes), les feature teams deviennent la réponse la plus efficace, si bien que certaines DSI s’orientent naturellement vers ce type de pattern.

[1] En réalité, il existe d’autres axes possibles, notamment par release, par zone géographique, par segment d’utilisateurs ou par famille de produits. Mais cela nous emmènerait un peu loin de notre propos, sachant que certaines de ces options sont des impasses, et que d’autres peuvent au final s’appréhender comme des découpages par pans fonctionnels.

Retrouver toutes les pratiques des Géants du Web sur le site dédié (www.geantsduweb.com) : pdf de l'ouvrage à télécharger, vidéo et compte-rendu de la présentation "Décrypter les secrets des Géants du Web"