Community days*
Ou comment Meetic réussit à donner une journée par sprint pour souder les membres des communautés et faire reculer la dette technique.
*journées de communauté
Chronologie d’une journée qui va faire date
Fin 2017
J’arrive chez Meetic en tant que Tech Lead Android. Je prends mes marques et je commence à avoir une vision claire des changements — petits et grands — à entreprendre pour améliorer aussi bien la stack technique que le produit.
À cette époque, les équipes sont organisées par plateforme : android, iOS, web, back. Prendre des tâches techniques à chaque sprint ou entreprendre des refacto avant de commencer une feature est déjà monnaie courante. Mais avoir un impact sur tout le projet nécessite plusieurs sprints et donc plusieurs mois.
Fort de ce constat, je me pose la question : comment créer un effet coup de poing pour avoir plus d’impact en moins de temps ?
Janvier 2018
Je prépare le premier sujet. Nous avons un monolithe dans un seul module qui prend du temps à se construire. Nous faisons l’hypothèse que diviser notre module unique en plusieurs modules nous permettrait de construire plus vite en profitant du parallélisme.
Hypothèse validée, encore plus sur la CI avec ses 64 cœurs.
À vrai dire, pour cette première la préparation est assez simple, voire même simpliste.
Je crée sur une branche les modules par feature : messagerie, recherche, mon compte, etc. (ndlr : un module core avec les dépendances en commun avait déjà été extrait) puis je cale un point dans l’agenda de l’équipe et réserve une salle pour toute la journée. Rien de plus facile que faire une équipe plateforme, il n’y a pas de synchronisation à prévoir.
Jour J, 9h.
J’arrive avant tout le monde, avec le petit-déjeuner et un paquet de Schoko-bons sous le bras. Vu de l’extérieur, on se croirait dans une war room. À l’intérieur, l’ambiance est à l’inverse très détendue : on chante met une playlist, on discute, on s’entraide.
La tâche est longue mais pas compliquée en soi. Si on finit dans la journée c’est bien mais ce n’est pas un but en soi. L’objectif c’est que tout le monde comprenne l’idée de ce qu’on veut faire et comment le projet va s’organiser.
On change aussi la façon de travailler pour cette journée en planchant tous sur la même branche. Il y aura tellement de changements qu’il n’y aura pas de reviews (1000+ files + 1804–3893). Tant que la CI passe et que les écrans s’ouvrent, on est bon !
Jour J, 19h.
Ok on est restés un peu plus longtemps pour finir car on savait qu’on était pas loin.
Les retours de cette journée sont très positifs :
- satisfaction d’avoir fait tout ce boulot en une journée
- impact vraiment important
- ambiance détendue qui soude l’équipe
C’est donc décidé, on en refait une dès qu’on a un nouveau sujet :
- avril division de notre module d’api,
- juin correction de warnings lint,
- octobre, abstraction de la couche réseau,
- novembre, harmonisation de la déclaration des feature.
2019, la globalisation
L’organisation change : c’est la fin des équipes plateformes et le début des feature teams.
Lors de cette transformation, on rassemble les plateformes pour voir quels sont leurs modes de fonctionnement et comment conserver les bonnes pratiques qui sont aussi nos forces.
Deux choses reviennent : il nous faut du temps pour les tâches techniques et je tiens à conserver ce qu’on appelle encore les Android Days.
Pour le temps tech, on se dit que 30% par sprint c’est un bon ratio.
Dans les faits, c’est plus ou moins respecté. On en fait plus ou moins en fonction de la charge.
Les Android Days deviennent les Community Days.
On discute de leur fréquence à partir de notre expérience dans l’équipe Android.
Je défends l’idée qu’une journée toutes les six semaines est suffisante. Mais au niveau de l’organisation managériale, avoir un sprint sur trois amputé d’une journée semble compliqué. On décide alors de mettre en place une journée de communauté par sprint pour avoir de la stabilité (elles feront partie des 30%).
Finalement, je me dis qu’on aura jamais assez de sujets pour tenir la cadence. Mais c’était sans compter que les journées de communauté allaient évoluer et s’enrichir.
L’heure de la diversification
Il s’avère que si le modèle précédent fonctionne pour avoir un effet coup de poing ponctuel, difficile néanmoins de faire ça tous les quinze jours.
Alors au lieu de créer ces journées au fur et à mesure, les Tech Leads les préparent maintenant en amont en organisant un backlog.
Si le plus gros du boulot se fait toujours dans la journée de communauté, la préparation se fait plus en amont. On présente la stratégie ou le poc de la solution en avance pour en débattre.
Si la journée n’est pas finie, alors on embarque le reste dans les 30% de bande passante tech.
Cette journée devient un moment d’expérimentation et d’apprentissage. Libérés de toutes réunions, on peut faire de la veille ou un poc sur une nouvelle librairie ou technologie.
Force est de constater que cette journée de communauté devient aussi une vraie journée de partage. La journée étant libre, on peut facilement rassembler l’équipe pour présenter un sujet de son choix.
Libre à ceux qui ne veulent pas y participer de continuer leurs tâches habituelles en toute tranquillité.
Happy (End) Days
On peut le dire : cette journée est reconnue et appréciée de tout le monde. Et les nouvelles personnes qui nous rejoignent toujours enthousiastes à l’idée d’avoir du temps consacré à la communauté.
Cerise sur la communauté : la structuration de ces journées nous permet de les continuer tout en travaillant à distance.
Alors si je suis fier que les Android Days aient pu grandir et se propager au sein de Meetic pour devenir les journées de communauté actuelles ?
Oui, très ;).
