Recommandé
Contenu connexe
Similaire à ForumPHP 2020 - La scalabilité d'une équipe ou d'un pôle technique.pptx
Similaire à ForumPHP 2020 - La scalabilité d'une équipe ou d'un pôle technique.pptx (7)
Dernier
Dernier (11)
ForumPHP 2020 - La scalabilité d'une équipe ou d'un pôle technique.pptx
- 1. LA SCALABILITÉ D’UNE ÉQUIPE OU D’UN POLE FORUMPHP 2020 - 22 OCTOBRE 2020
- 8. BACKEND FRONTEND OPS VIDEO QUALITY OF SERVICE 9 équipes 13 équipes 4 équipes 2 équipes 4 équipes 32 ÉQUIPES
- 9. RESPONSABLE R&D Développeur back Développeur back Développeur back Développeur front Développeur vidéo PRODUIT Chef de projet Chef de projet Chef de projet … Lead developer
- 10. NAISSANCE DE LA PREMIÈRE ÉQUIPE DE DÉVELOPPEMENT M6WEB
- 12. ENTRÉE PROGRESSIVE DE L’AGILITÉ DANS LES PRATIQUES DE DÉVELOPPEMENT
- 13. Lundi Mardi Mercredi Jeudi Vendredi Lead-dev A D Dev #1 B A B Dev #2 B Z A D Dev #3 C B TASK A1 TASK A2 TASK A3 TASK A5 TASK A4 TASK B1 TASK B2 TASK B3 TASK B4 TASK B5 TASK C1 TASK C2 TASK D1 TASK D2 TASK D3 TASK Z1 TASK Z1
- 17. PIZZA TEAM ÉQUIPE DONT LA TAILLE PERMET D’ÊTRE NOURRIE AVEC 2 PIZZAS Permet de conserver de la communication à l’intérieur de l’équipe
- 20. BINÔME D’ÉQUIPE ASSOCIATION FORTE D’UN LEAD- DEV ET D’UN PRODUCT OWNER DANS CHAQUE ÉQUIPE Répartition des responsabilités, mais collaboration forte
- 21. TECH LEAD MEETING RÉUNION HEBDOMADAIRE ENTRE LES ÉQUIPES D’UN VERTICAL Permet d’assurer la cohérence dans le vertical technique
- 22. MERCATO DES DEVS ÉCHANGES DE DÉVELOPPEURS ENTRE ÉQUIPES D’UN MÊME VERTICAL TECHNIQUE Permet de partager de la connaissance et des manières de faire
- 30. QUELQUE SOIT L’ÉCHELLE, MÊMES PROBLÉMATIQUES Gardons un nombre de liens humainement gérable
- 31. BACKEND FRONTEND OPS VIDEO QUALITY OF SERVICE 9 équipes 13 équipes 4 équipes 2 équipes 4 équipes 32 ÉQUIPES
Notes de l'éditeur
- Je m’appelle Mikael Randy, je suis développeur depuis bientôt 15 ans. Je suis lead-developer d’une équipe Back de Bedrock, la team Enigma
- Je travaille pour la société Bedrock. Vous devez la connaitre sous le nom M6 Web, ou M6 Distribution
- Bedrock est une société indépendante, dont les actionnaires sur le groupe M6 et RTL Group Le coeur de métier de Bedrock est de développer une plateforme de streaming vidéo (VOD) pour les acteur majeurs à travers le monde.
- Nous sommes présent dans 5 pays. Historiquement, la plateforme Bedrock était pour le produit 6play uniquement, mais depuis 2017, 4 clients du groupe RTL sont hébergés sur la plateforme, et depuis 2j, le nouvel arrivant Salto.
- Et que nous gérons un total de 35M d’utilisateurs à travers l’Europe. Je vous laisse imaginer que, pour gérer un produit de cette envergure, il faut du monde. Ce qui nous amène au sujet du jour
- Aujourd’hui, Bedrock, c’est 5 verticaux techniques, découpés en équipes, pour un total de 32 équipes Mais comment on en arrive là ?
- Quand je suis arrivé chez M6Web, il y a 7 ans, la « team M6Replay », c’était 1 responsable, 3 dev backs, 1 dev front, 1 dev vidéo 6 personnes. Bon, il y avait quelques chefs de projets, qui intervenaient en fonction des sujets à développer Mais le fonctionnement était « j’ai un besoin, donne moi du temps développeur, et le(s) développeur(s) travaillaient sur le sujet, un peu en vase clôt. Quand je suis arrivé, en tant que lead developer, je devais structurer cette équipe, et comme j’aime bien le faire, le premier travail a été de mettre l’équipe dans une bulle, pour canaliser les demandes entrantes. Le but n’est pas de couper les développeurs du reste, mais de s’assurer qu’une personne est au courant de tout, pour la cohérence, et de canaliser les demandes, pour organiser le travail.
- Et ça a été la création de la première équipe de développement chez M6Web, la fameuse Team Burton Mais qu’est-ce qu’une équipe en fait ?
- Une équipe, c’est une combinaison de personne, une organisation locale dans un organisation globale. C’est un panel de responsabilité, qui peut être plus ou moins large, plus ou moins flou. Ici, cette équipe, c’était « tout le développement Backend de l’application 6play ».
- En 2015, entrée progressive de l’agilité dans les pratiques de développement. Cette arrivée a été autant faite en parallèle dans l’équipe et par le produit
- Avec l’agilité, nous sommes passés d’un mode « Cycle en V », où demande du « temps développeur » pour avancer sur des projets, et où chaque développeur travaille plus ou moins dans son coin, à un mode « backlog » ou les demandes sont priorisées. Nous ne sommes pas là pour vanter les avantages de l’agile, mais c’est pour mettre en avant que, à ce moment là, nous avions transféré la charge « comment on avance » vers le produit. La technique avait moins de pression sur les deadlines, mais sur le fait de respecter les priorités.
- Le produit 6play prenant de plus en plus d’ampleur, la couverture fonctionnelle augmente, et il faut donc ajouter des personnes dans l’équipe Back. En parallèle, une équipe front s’installe, avec plusieurs développeurs. Mais avoir plus de projets (donc plus de PO) sur une même équipe, plus les échanges nécessaires entre lead mènent à un goulot d’étranglement. De plus, plus la taille d’une équipe est importante, plus on multiplie les échanges possibles dans l’équipe, et on crée des silos dans l’équipe. Du coup, à ce moment là, on scinde l’équipe Back en 2 équipes, avec une responsabilité plutôt découpée, même s’il y a toujours l’effet « renfort » en cas de surcharge
- Une équipe de 3 implique 3 liens. Un entre chaque personne
- Une équipe de 6 personnes fait maintenir 15 liens, et c’est exponentiel. Donc vous risquez d’avoir une scission à l’intérieur d’une équipe
- Donc, entre 2016 et 2017, petit à petit, de nouvelles équipes se forment, avec toujours des responsabilités dédiées, dans chaque vertical technique.
- Du coup, on se retrouve avec un truc qui ressemble à ça, avec un certain nombre d’équipes par vertical technique. On note également que maintenant, les PO sont dédiée à chaque équipe. Cette situation ressemble beaucoup à la situation initiale, avec un certains nombre de développeurs, qui travaillent chacun dans leur coin, sans cohésion. Mais pour éviter ça, nous avons mis en place plusieurs choses.
- Chaque équipe a un lead-dev, mais également un PO. Le binôme LD/PO travaille au quotidien ensemble pour que le produit soit au mieux fonctionnellement et techniquement
- Une réunion hebdomadaire ou chaque lead à l’occasion de partager ce qu’il fait, comment, … et d’initier l’échange technique. Cette réunion permet de connaitre la direction prise par chaque équipe, et de s’assurer que tout le monde reste cohérent.
- On se permet, sur demande d’une personne, ou en cas de différence de charge de travail, d’échanger des développeurs entre les équipes. Certes, cela bouscule un peu l’équilibre d’une équipe, mais de manière temporaire, et favorise la circulation de la connaissance technique dans le vertical technique.
- Donc, à un moment, on arrive à un nombre assez important d’équipe, avec chacune leur responsabilité. Mais ces responsabilité sont en fait très claires … dans le vertical technique Cela signifie que, en fonction des projets, les relations n’étaient pas toujours les mêmes.
- Et nous étions donc de retour dans cette situation, mais avec des équipes au lieu des personnes
- Ça, c’est la sonde Mars Orbiter. Dans le cadre du programme d’observation Mars Surveyor, la NASA développe une sonde qui doit se mettre en orbite autour de Mars pour l’étudier. Après 2 ans de développement, 7 mois de voyage entre la Terre et Mars, le 23 septembre 1999, elle lance le programme de mise en orbite … et s’écrase à la surface de Mars. Pourquoi ? Parce le logiciel de guidage de la sonde pensait recevoir des données de distance dans le système impérial alors que ces données étaient dans le système anglo-saxon. Et tout ça part d’une erreur de communication, d’une règle pas claire dans un cahier des charges, et de 2 équipes qui n’étaient pas destinées à travailler ensemble.
- J’aime bien utiliser cet exemple, parce que si on en revient à notre organisation, toutes les équipes n’ont pas l’habitude de travailler ensemble De plus, cette organisation apporte un problème important : un projet qui implique plusieurs verticaux est toujours ralenti. Il faut demander à un vertical, pour avoir une estimation, puis passer au suivant, …
- Pour réduire les cloisons entre les verticaux, et pour tenter d’accélérer le flux de développement, nous avons tenté l’approche en feature team. Une équipe avec plusieurs spécialité, et un backlog centré sur le projet. Mais c’était une fausse bonne idée. Il est très compliqué de faire un sprint qui occupe plusieurs spécialité, et ça n’empêche pas les inter-dépendances.
- Nous avons donc mis en place des product lines. Une product line, c’est un pan fonctionnel déterminé, donc une responsabilité limité, transverse à tout les verticaux techniques. Autrement dit, c’est une responsabilité FONCTIONNELLE, transverses aux différents métiers du pôle.
- Les product lines vont rassembler des équipes de différents verticaux, en rationalisant les responsabilités à travers les verticaux. Chaque équipe a donc une responsabilité à la croisée de son vertical et de sa product line. Chaque PL : n’a pas nécessairement une équipe de chaque vertical Une équipe peut être transverse à plusieurs PL Plusieurs équipe du même vertical peuvent être dans la même PL Chaque product line a un Product Manager, qui apporte la cohérence à la PL, tout en laissant chaque PO (dans chaque équipe) organiser le travail local. Les relations sont rationnalisées (juste avec les équipes d’un même vertical et/ou d’une même product line)
- Ici, apparait un pattern qui montre que plus la taille d’un pôle augmente, plus les problèmes reviennent, et tout s’articule autour du nombre de liens. Plus il faut de lien pour « tenir » une organisation, plus l’organisation devient lourde et compliquée. Il faut donc trouver une organisation pour répartir les liens entre différents niveaux : entre PM Entre le PM et les PO Entre le PO et le LD Entre les LD Dans l’équipe
- Et donc, aujourd’hui, chez Bedrock, voilà pourquoi nous sommes autant d’équipes. 305 personnes dans 32 équipes Chaque équipe est à taille humaine, on connais chaque personne de l’équipe, on a une liste identifié d’interlocuteurs de références On ne connait pas forcément tout le monde
- Et donc, aujourd’hui, chez Bedrock, voilà pourquoi nous sommes autant d’équipes. 305 personnes dans 32 équipes Chaque équipe est à taille humaine, on connais chaque personne de l’équipe, on a une liste identifié d’interlocuteurs de références On ne connait pas forcément tout le monde