Press "Enter" to skip to content

Distribuer le rôle d’architecte au sein des Feature Teams

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

Distribuer le rôle d’architecte au sein des Feature Teams

Notre expérience similaire aux Chapters de Spotify

Faire des Feature Teams, c’est facile sur le papier. On vous vante les nombreux avantages : une vision produit complète, réduction drastique des boucles de feedback, responsabilisation, bref en quelques mots un meilleur produit qui apporte plus de valeur en moins de temps. C’est donc génial, il faut y passer.

Si vous êtes petit, aucun problème

Tant que le produit est petit, prenons l’exemple d’une jeune start-up, cela ne fait aucun doute. Finalement, cela revient à utiliser son bon sens : est-ce qu’on n’irait pas plus vite si les gens se parlaient et que tout le monde travaillait ensemble ?

Passer aux Feature Teams c’est du bon sens : est-ce qu’on n’irait pas plus vite si tout le monde travaillait ensemble ?

Si vous êtes gros, on arrive dans les 50 nuances de gris

Par contre qu’en est-il si on parle d’un gros produit ? Par exemple une bonne grosse solution B2B ? Ou simplement une appli un peu complexe ? Bref, un produit où plusieurs équipes travaillent en même temps sur le même produit. Que va-t-il se passer si on applique la démarche des Feature Teams jusqu’au bout ? Qui vont toutes travailler en même temps sur la même base de code ? Plutôt que d’avoir des Component Teams en charge de composants individuels ?

Que va-t-il se passer si toutes les équipes travaillent en même temps sur la même base de code ?

Voici le genre d’inquiétudes que cela soulève, souvent des inquiétudes fondées et très légitimes :

Ça va faire une base de code monstrueuse à maîtriser pour chaque équipe !

Tout le monde aura le droit de toucher à ces composants communs ? Ohlà, attends, mais ils vont ressembler à rien ces composants !

Comment on saura que ces composants communs marchent bien ? Autant rester sur une vieille version, qu’on sait marcher, que de prendre systématiquement la dernière.

Si on a un problème à un composant commun, qui pourra-t-on aller voir ? J’ai besoin d’une personne dont c’est la responsabilité.

En d’autres termes : personne ne remet en question l’intérêt des Feature Teams, par contre on s’inquiète du risque de perdre des Component Teams. C’est à dire : avoir des composants communs, partagés entre les équipes, qui ne ressemblent à rien et qui ne sont pas maintenables. Ce qui, en cascade, posera énormément de problèmes à toutes les équipes qui en dépendent !

Personne ne remet en question l’intérêt des Feature Teams, par contre on s’inquiète du risque de perdre des Component Teams

En pratique, la question de la maintenabilité est relativement facile à répondre : de bonnes pratiques de développement, une culture de la qualité. Des concepts qui seront utiles, pardon, qui devraient être nécessaires, et ce sur toutes les bases de code. Pas uniquement sur les composants communs. Oui oui, je parle bien, entre autres choses, de pratiquer rigoureusement et exhaustivement les tests unitaires. Le TDD et une couverture de 100% devraient être la norme.

Cependant, si on y regarde un peu plus loin, au-delà de la maintenabilité pure du code, se pose la question de la pratique de l’architecture logicielle en Feature Teams. C’est à dire : qui va se charger d’avoir la big picture en tête lorsqu’il touchera à du code commun ? Et comment s’assurer que cette vision est partagée entre les Feature Teams ?

Qui va se charger d’avoir la big picture en tête lorsqu’il touchera à du code commun ?

Ce problème, nous nous le sommes posé au projet Player de la Direction du Numérique de France Télévisions. Non pas dans le contexte d’une ré-organisation de plusieurs Component Teams existantes en Feature Teams, mais dans le contexte d’une unique équipe qui grossit en taille et qui devient plusieurs équipes. Au final, nous avons rencontré les mêmes problèmes : maintenant que plusieurs équipes touchent au même code, comment s’assurer de la cohérence de la base de code commune ?

Mise en place des spécialités

Avant de détailler ce que nous mettons en place, j’aimerais évoquer la “méthode Spotify”. Car à première vue notre approche est assez similaire.

Une première approche : Spotify et les Chapters

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

Comment ça se passe chez Spotify ? Dans l’organisation de Spotify, il existe un mécanisme appelé Chapters : ce sont des entités transverses qui font le lien entre les Squads. Les Squads, c’est le nom des cross-functional teams de Spotify, des équipes qui regroupent toutes les compétences nécessaires pour accomplir des missions fonctionnelles de bout en bout. Bref, l’état de l’art des Feature Teams !

Et donc, ces Chapters regroupent les différentes compétences entre les Squads. Par exemple, les dev backend de chaque Squad forment ensemble un Chapter. Idem avec les QA de chaque Squad qui forment ensemble un autre Chapter, et ainsi de suite.

Le but des Chapters ? Gagner en efficacité. Comment ? Par exemple en partageant du code… Ah-ah, voilà les fameux composants communs ! Les Chapters, c’est donc la réponse de Spotify pour s’assurer que les composants communs sont bien maintenus, pour répondre aux inquiétudes vis-à-vis des Feature Teams. D’une manière plus générale, c’est aussi le moyen de partager les bonnes pratiques, ou de comme j’aime le dire : d’aligner techniquement les équipes.

Les Chapters, c’est la réponse de Spotify pour s’assurer que les composants communs sont bien maintenus

Alors, est-ce que c’est une solution miracle ? Est-ce qu’il suffit de faire “comme Spotify” pour que tout aille dans le meilleur des mondes ?

Il faut bien entendu relativiser. La solution de Spotify marche diablement bien, et bien, justement parce qu’elle est appliquée à Spotify ! Elle est adaptée à leur contexte, à leur produit, à leur manière de travailler, à leur culture. Ainsi, Spotify est une entreprise qui, dans sa croissance, a mis en place les mécanismes techniques qui permettent à de nombreuses équipes de travailler en parallèle sur le même produit sans se marcher sur les pieds. Ils ont littéralement architecturé et construit leur produit pour permettre cet exploit.

La solution de Spotify est adaptée à Spotify

Pour résumer : tout le monde n’est pas Spotify. C’est donc un modèle intéressant à analyser et dont on peut s’inspirer, mais ce n’est pas forcément une bonne idée de le reprendre tel quel.

Justement, en quoi notre situation est-elle différente de celle de Spotify ?

Rappelons que nous sommes le projet Player de la Direction du Numérique de France Télévisions. En d’autres termes, même si nous allons essayer de nous rapprocher au maximum du principe des Feature Teams, ne nous voilons pas la face pour autant : dans l’organisation actuelle et vu de l’extérieur, le Player reste un composant qu’intègrent les autres équipes.

Autre conséquence directe de ce contexte, nos équipes ne sont pas des cross-functional teams idéales, pouvant gérer une fonctionnalité de bout en bout ; nous avons moins de diversité des compétences.

Essayer de faire des Feature Teams dans un tel contexte reste malgré tout pertinent : bien que notre domaine reste limité au Player seulement, finalement rien d’autre qu’un composant, ce n’est pas une raison pour découper ce domaine en encore d’autres sous-composants. Essayons de faire grandir et évoluer ce composant comme un produit à part entière, avec des Feature Teams qui prennent de la hauteur.

Notre domaine est limité à un composant, mais évitons de le découper en encore d’autres sous-composants

Nos problèmes à résoudre

Avant de parler de notre solution, qui correspond à notre contexte, rappelons les difficultés que nous voulons résoudre en nous éloignant des Component Teams :

  • Plusieurs équipes travaillent en même temps sur le même code
  • Besoin d’aligner techniquement les équipes, via les bonnes pratiques, la mise en place d’outillage et de code utilitaire, mais aussi en ayant un même niveau d’exigence sur le code et la qualité
  • Besoin de prendre de la hauteur sur le code partagé, d’avoir des discussions d’architecture, d’avoir une vision qui dépasse l’équipe
  • Ne pas dépendre d’une seule personne qui cumule tous les savoirs (le tech lead ou l’architecte), les équipes doivent continuer à tourner même lors des absences et des imprévus
  • Être efficace — ce qui en fait sous-entend : ne pas impliquer systématiquement tout le monde dans tout !

Notre approche des Chapters : les spécialités

Pour se différencier de Spotify, et parce que le concept que nous mettons en place n’est pas tout à fait le même que celui de Chapters, nous utilisons le terme Spécialités.

Alors, les Spécialités, c’est quoi ? Voici une définition succincte que je donne aux nouveaux arrivants :

Les Spécialités, cela consiste à distribuer le rôle d’architecte entre les différents membres d’une équipe, et entre les différentes équipes.

Voici également une petite carte mentale qui décrit le concept plus dans le détail :

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités
Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

Distribuer le rôle d’architecte

Bien entendu, nous l’avons imprimé et affiché dans l’open-space !

Qu’entendons-nous plus précisément par Spécialités ? Quelles sont-elles ?

Nous en avons dénombré sept. Cette répartition est totalement spécifique à notre projet, à son fonctionnel ainsi qu’à ses contraintes techniques :

  • Le Media Engine et l’expérience vidéo
  • La pub
  • La UI et l’intégration
  • L’automatisation des tests
  • La stratégie de tests et la QA
  • Le monitoring et les dashboards
  • Les backends

L’idée est donc de répartir ces Spécialités entre les différents membres de chaque équipe.

Répartir les Spécialités entre les différents membres de chaque équipe

Pour cela, nous avons fait un petit atelier à base de gommettes mais aussi et surtout, à base de Predator. Vous connaissez ce film cultissime j’espère ?

Et bien, figurez-vous que ce n’était pas le cas de tout le monde au Player !!!

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

Alors, ni une ni deux, je ramène le DVD de ce morceau d’anthologie des années 80, édition collector bien entendu, et nous le regardons pendant une (grosse) pause déjeuner :

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

(Quoi j’ai des DVD chez moi ? Vous avez le droit de me traiter de vieux si ça vous fait plaisir.)

Alors pourquoi est-ce que je vous parle de ce film ?

Parce qu’au cœur de ce film, nous avons un commando d’élite, sept personnes, chacune avec son caractère et sa spécialité bien à elle.

Je m’en sers donc pour créer des fiches à l’effigie du film, et de ce commando d’élite, pour modéliser les Spécialités de nos équipes.

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités
Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

Hop, j’imprime donc une copie par personne, je passe ça au massicot pour faire un tas de cartes, et j’accompagne le tout de gommettes, 4 de chaque couleur :

  • Rouges pour indiquer les sujets que la personne voudrait éviter
  • Vert pour indiquer les sujets que la personne aimerait porter
  • Et enfin Jaune pour les sujets qui ne sont pas sa prédilection mais qu’elle est prête à porter à défaut de quelqu’un d’autre de plus motivé

Je distribue donc un petit tas de cartes et gommettes à chaque personne, et j’explique bien le but : faire en sorte que dans chaque équipe une personne soit identifiée pour chaque Spécialité.

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

Quelques jours plus tard, tout le monde a rempli ses cartes, et nous procédons à une mise en commun. Intéressant de voir les préférences de chacun, on découvre des appétits inattendus, et certains sujets qui passionnent moins les foules.

Intéressant de voir les préférences de chacun

Les équipes se posent la question de comment répartir les Spécialités. Elles procèdent généralement en sortant d’office les gommettes rouges, puis en affectant au maximum les sujets aux gommettes vertes. Le tout en essayant d’avoir à peu près le même nombre de Spécialités par personne à la fin.

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

Aucun soucis à signaler durant l’exercice, que mènent toutes seules les équipes. On conclut l’exercice en collant sur une feuille les Spécialités affectées dans chaque équipe.

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

L’ordre que les équipes ont choisi pour coller les Spécialités sur la feuille est intéressant. Ce n’est pas le même que celui que j’ai donné originellement, qui suivait une certaine logique dans l’enchaînement des différents domaines. Non, ce choix d’ordre, ils l’ont fait très simplement : c’est l’ordre dans lequel les personnages meurent dans le film Predator ! Bravo les gars, je vous adore.

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

Plus tard, nous rajouterons sur les feuilles les noms des confrères de la Spécialité dans les autres équipes, puisque c’est une info utile par exemple pour organiser une revue de design entre équipes.

On peut également voir que le nom des équipes a été raturé ; c’est parce que nous avons profité de cette mise en place des Spécialités pour affirmer notre volonté de nous orienter vers les Feature Teams : les équipes ne doivent plus avoir de domaine attitré, et cela commence par des noms qui ne réduisent pas leurs champs d’action.

Fonctionnement au quotidien des Spécialités

Le moment principal où les Spécialités entrent en jeu, c’est durant le Forum Hors du Guidon. C’est un des rituels que nous avons mis en place au projet Player, qui consiste à explorer et préparer les sujets à venir pendant une journée dédiée, par itération.

Durant cette journée, toutes les équipes se mélangent justement pour réfléchir et se challenger ensemble sur ces questions d’architecture. Les Spécialités aident donc à organiser qui va parler de quel sujet, qui a besoin de passer en revue quel design.

Les Spécialités aident à organiser les discussions et revues sur les questions d’architecture

Pour plus d’information sur le Forum Hors du Guidon, je vous invite à consulter mon précédent article qui détaille cet évènement :

Est-ce que ça marche ?

Malheureusement, il est encore trop tôt pour dire si c’est un franc-succès : nous n’avons pas encore assez de recul.

Malgré tout, ce qui est sûr, c’est que ce mécanisme suffit à lever les inquiétudes que pouvaient avoir les membres des équipes vis-à-vis des Feature Teams.

Les Spécialités ont levé les inquiétudes qu’on pouvait avoir vis-à-vis des Feature Teams

Ainsi, maintenant, dès lors qu’on a un problème d’alignement technique la réponse n’est plus :

C’est parce qu’on s’est séparé en plusieurs équipes ! Il faut qu’on se réunisse tous ensemble plus souvent, qu’on partage nos rituels !

(ce qui serait un retour en arrière, avec une perte de fluidité et d’efficacité notables)

À la place on entend :

Ah oui, on a été mauvais, on a mal appliqué les Spécialités. C’est notre faute. On va faire plus attention à l’avenir. Il ne faut pas qu’on oublie d’impliquer les autres équipes, grâce aux Spécialités on sait à qui s’adresser.

Ou encore :

Oui, j’ai tendance à m’impliquer dans tous les sujets. J’ai peur qu’on oublie quelque chose d’important. Mais c’est vrai, ce n’est pas moi le porteur de cette Spécialité/ce n’est pas mon équipe ; je vais laisser mon collègue prendre le sujet en main et je serai juste là en support, si besoin.

En d’autres mots : si nous n’avons pas encore vu les effets bénéfiques en termes d’efficacité, de qualité de nos architectures, ou de capacité à gérer les absences, nous voyons par contre déjà que l’attitude et le mindset ont changé.

L’attitude et le mindset ont changé

Finalement, n’est-ce pas le plus important ? Le plus dur pour avoir une équipe auto-organisée, c’est qu’elle prenne conscience que c’est ce qu’on attend d’elle, et qu’elle réalise qu’elle en est capable.

Et carrément, qu’elles en sont capables ces équipes.

Notre solution bien à nous pour aligner techniquement nos équipes : les Spécialités

A propos de Jean-Pierre Lambert

Avant, j’étais un ingénieur logiciel. Mais peut-être pas le genre que vous imaginez ; les outils et les belles architectures logicielles me laissaient de marbre. Non, mon truc, c’était plutôt la qualité, la valeur produit, les process et les relations humaines.

Du coup, maintenant, j’aide les équipes en tant que Facilitateur Test et en tant que Scrum Master. Ce n’est pas plus mal !

J’espère vous revoir très bientôt sur ce blog pour la suite de mes aventures…

Top