Choix de la bonne organisation
Lorsque nous avons démarré un nouveau projet au sein de Cegedim qui est passé en 1 an de 3 à 30 personnes et qui va passer d'ici 1 an à 60 personnes, nous avons étudié la meilleure façon d'organiser les équipes de développement pour obtenir la meilleure efficacité possible en termes de Time To Market, sans faire de compromis sur la qualité. Nous nous sommes fortement inspirés des idées poussées par Martin Fowler, que chaque membre d'une équipe de développement devrait connaître et étudier. Voici l'ensemble des articles qu'il a proposé à la communauté à propos de l'organisation : https://martinfowler.com/tags/team%20organization.htmlNous savions que nous allions travailler en mode microservices, et penser l'organisation autour de cela était important. Il est partout préconisé d'organiser cela autour de petites équipes réactives, qui ne sont pas polluées par trop de communication et décisions inter-projets qui ralentissent les processus, et diluent au final les responsabilités. L'un des exemples classiques est la responsabilité de corriger les problèmes d'intégration continue sur un projet monolithique : potentiellement il est très difficile d'isoler qui a cassé l'intégration continue et qui doit la réparer car on trouve toujours quelqu'un qui a committé le temps que l'intégration continue fasse l'analyse (plusieurs dizaines de minutes voire quelques heures). C'est là qu'il y avait une opportunité d'utiliser une organisation de type Feature Team notamment sur un grand projet.
Transformation en Feature Team
L'idée est de raccourcir les cycles en évitant une cascade d'intervenants qui ralentissent le feedback. Dans l'organisation de droite, on a une équipe de développement auto-suffisante, avec des développeurs, des QA (qu'on appelle "Mister T" avec une petite référence à l'agence tous risques que les plus anciens auront reconnus), et des Ops, voyons les ratios qui ont été choisis.
Cela peut paraître démesuré en termes de ratio de développeurs par équipe, mais il faut bien comprendre que :
- Un Product Owner et un Scrum Master pour une équipe de 8/9 membres ne sont pas de trop surtout sur des nouveaux produits
- Scrum Master est un rôle, il va souvent développer.
- 1 Architecte ou un Technical Leader qui passe 1/3 de son temps à relire des Pull Request et à débusquer des problèmes pour que les développeurs puissent avancer sans embûches est vraiment intéressant.
- 1 Mister T, qui veille à respecter une couverture de code à plus de 80% sur les librairies et 65% sur les microservices métiers (UI et API)
- Chez nous le Mister T participe partiellement au développement par l'écriture de code de tests d'intégration, de end-to-end et de tests automatisés des applications web.
- 1 Ops qui améliore sans cesse les outils via de l'automatisation et qui gère la plateforme de production, la sécurité ...
En pratique, on peut réduire à 8 en fonction des compétences des personnes qu'on recrute, car on peut avoir 2 personnes au lieu de 3 pour les rôles de Scrum // Leader Technique / Architecte / Ops
- Le Scrum Master fait parfois office de Leader Technique
- L'architecte est parfois un passionné de l'approche DevOps et fait les deux
Composition idéale d'une Feature Team
Le Pair Programming devient une donc un moyen de rapidement monter en compétences, puis une fois cette montée en compétence faite, si les développeurs souhaitent travailler chacun de leur côté, de passer du Pair Programming aux revues de code via des Pull-Requests en Git. Ces Pull-Requests seront à nouveau validées par le Leader Technique, rôle qui est souvent assumé par le Scrum Master, car cela s'accommode bien d'un travail déjà "haché" par l'animation de l'équipe.
Point sur la productivité et le Pair Programming
Dans d'autres sociétés moins "agiles", nous avons parfois rencontrer des réticences sur l'utilisation du Pair Programming, l'argument classique étant qu'on serait 2 fois moins productif que si les développeurs étaient tout seuls derrière leur écran.
C'est mal connaître le travail du développeur, car si on imaginait que celui-ci code du premier coup les 50 lignes de code pendant une journée (cela peut paraître peu, mais c'est pourtant une moyenne assez communément admise), et sans être dactylo, il ne lui faudrait l'équivalent que d'1h au maximum sur le clavier. Mais que fait-il le reste du temps ?
- Appréhender le métier et les User Stories
- Appréhender une technologie nouvelle ou une difficulté technique
- Etablir un plan de test unitaire
- Refactorer son code
- Corriger les bugs
Or sur ces 5 éléments, en reformulant en permanence avec son collègue, il est en permanence dans l'utilisation de la méthode du Canard en Plastique (le nom prête à sourire, mais c'est très sérieux et efficace). La dynamique qui se crée divise alors par plus qu'un facteur 2 le temps passé, ce qui permet le facteur d'amélioration de la productivité.
Evidemment, pour être efficace le Pair Programming doit être dynamique et tournant (30 min / 1h max avec le clavier), sinon il peut se transformer en "Pépère Programming" ce qui n'est pas l'effet recherché !
Identité d'une Feature Team
- chaque Feature Team ait son identité propre, et rapide à identifier, notamment dans les locaux à travers un petit drapeau ou un poster collé au mur ou dans les slides des revues de Sprint
- pas de concurrence du nom ou des compétences supposées.
Initialement, nous avions pensé à des noms des avions à réactions, mais ce choix risquait d'être éventuellement source de comparaison (Rafale vs F35) et nous avons finalement opté pour un choix plus neutre, mais permettant à chaque d'avoir son "drapeau", et facile à décliner pour les prochaines équipes.
Grâce à la une neutralité des couleurs et des drapeau les équipes son pu appréhender facilement l'organisation sans se sentir dans la bonne Team ou la moins bonne. Les équipes discutent entre elle des besoins et de la répartition des compétences et de l'expérience dans chacune des équipes.
Feature Team "Plateforme" et Equipes Métier ou Pures Feature Team ?
Lorsque nous avions commencé le projet, nous avons eu pas mal de points techniques à régler, car nous partions "from scratch", et il fallait donc construire la forge logicielle, afin de pouvoir développer des premiers microservices. Mais en même temps, nous voulions nous confronter à l'écriture de premiers microservices afin de comprendre les enjeux nouveaux d'une forge qui seraient efficaces à compiler des microservices. En effet, il faut bien comprendre que le défi est de taille pour gérer :- Plusieurs dizaines de microservices en cible
- Multistack (Spring.Boot, Node.js ...)
- Multibranches à gérer pour pouvoir au plus tôt éviter de polluer l'intégration continue sur les branches principales
- Multitenancy
- Multi-cloud, avec l'utilisation du Cloud Amazon, et du Cloud Cegedim (https://cegedim.cloud/)
Comme nous aimons à le préciser, le Saint Graal des équipes DevOps sur une architecture modulaire est le déploiement en "1 clic", il faut comprendre qu'en microservices, déployer en 1 clic, sans industrialisation supplémentaire devient, déployer en N clics (n étant le nombre de microservices), ce qui n'est pas acceptable si on a des dizaines de microservices en production, avec les risques d'erreurs, de latences ...
Nous avons donc eu alors l'idée de nous confronter à l'écriture de nos premiers microservices sur la forge logicielle qu'on a appelé Bastion (qui n'est pas un Bastion SSH, mais bien la tour de contrôle de toutes nos opérations de modélisation des produits, et des déploiements), ce qui a mobilisé une équipe pendant plusieurs mois, et cette équipe Rouge est devenue de facto l'équipe "Platforme".
Cela a très bien fonctionné pendant plusieurs mois, mais nous avons décidé finalement de passer d'une équipe plateforme et de 3 équipes de développement de composants orientés métiers à 4 équipes métiers en récupérant les compétences techniques et en les injectant dans les équipes. Voici les raisons qui nous ont poussé à faire ce choix :
- Nous avions besoin de prioriser les besoins métier et d'y associer les compétences techniques nécessaires.
- La roadmap technique est très difficile à construire car l'équipe plateforme est forcément plus orientée problématique technique que métier avec une vision moyen/long terme. Etant donné que les personnes compétentes n'étaient pas réparties dans les équipes métiers, il était plus difficile pour eux d'appréhender les soucis quotidien des développeurs.
- d'être sûr que l'équipe technique traite les vrais problèmes déjà localement et dans l'ordre des priorités puisqu'elle a les compétences et un problème concret à résoudre
- qu'on ne fait pas de surconception en se bloquant par rapport à toutes les contraintes d'autres équipes.
Néanmoins, nous avons mis en place pour combler le besoin nécessaire de transversalité :
- des Guildes permettant transversalement de partager les bonnes pratiques et de faire converger les plateformes techniques sans ralentir pour autant la productivité de chacune des équipes :
- Guilde API
- Guilde Back-End
- Guilde ReactJS
- Guilde Mister T
- des Commandos techniques qui sont des structures éphémères répondant à un besoin précis comme par exemple pour effectuer les migrations telles que le passage de Java 8 à Java 10 ou le passage de Postgres 9 à Postgres 10 sur l'ensemble des microservices, car cela oblige sinon à gérer de multiples versions de moteurs dans l'infrastructure de déploiement continue déjà complexe.
Cela permet à chacun de pouvoir saisir l'opportunité de devenir Guilde Master ou Commando Master et de se confronter aux difficultés de synchronisation dans une équipe.
Dans un prochain article, nous parlerons des problématiques d'Onboarding des nouveaux collaborateurs afin d'être le plus efficace possible dans la montée en charge de ce projet.
Pour aller plus loin :
- https://blog.octo.com/feature-team-au-dela-du-buzzword/
- https://blog.xebia.fr/2017/06/26/devops-ou-sarrete-la-responsabilite-dune-feature-team/
@svanacker
Aucun commentaire:
La publication de nouveaux commentaires n'est pas autorisée.