Cela fait plusieurs mois que nous avons mis en place un nouveau rituel avec l’équipe : le Mob Code Review et il est temps d’en donner un petit feedback. Comme toujours dans le développement, cet article est à nuancer avec votre propre contexte d’équipe. Prenons juste le temps d’expliquer les pour et les contre d’une méthodologie qui a changé nos journées.
Définition
On connait le Mob Programming… Le Mob Code Review, est basé sur le même principe : faire la code review en équipe, au même moment, sur un sujet donné.
Retour en arrière…
Déjà, un peu de contexte. Karnott, c’est une équipe produit de moins de 10 personnes, avec beaucoup de compétences différentes. Système embarqué, Gestion de base de données, de l’infra, du soft backend, du front, du mobile… Et pour faire tourner tout ça, une multitude de langages différents (citons Golang, Java, Kotlin, C, Rust, SQL, Javascript, Bash…), et ne parlons même pas des frameworks utilisés dans chaque brique technique. Le choix du langage n’a jamais été un sujet chez nous, on fait au mieux avec ce qu’on maitrise et la problématique à traiter, Jusqu’au jour où cette variété de compétences est devenue un frein à notre vélocité.
Pourquoi cette perte de vélocité ?
Il y a bien longtemps qu’on avait identifié le Bus Factor : laisser quelqu’un dans son coin avec ses compétences et ses connaissances fonctionnelles était inacceptable. L’une des manières de forcer le partage de connaissance, c’est de passer par la case code review. (En plus des divers avantages liés à la qualité de code, bien entendu).
Malheureusement, les tâches avaient tendance à s’accumuler en To Review. Nous en avons parlé et avons identifié deux raisons principales :
- Faire de la review, c’est prendre le temps de le faire. Je suis sûr que tout le monde a eu ce souci à un moment ou à un autre : il faut s’interrompre dans sa propre tâche, se plonger dans une autre, en comprendre la complexité, etc. Bref, faire de la review, c’est une vraie tâche en soit, et ce n’est pas si simple de savoir quand le faire.
- On ne se sent pas toujours pertinent à faire la review. Trop éloigné de son domaine de compétence, technique ou fonctionnelle…
Premier test : à la suite du daily
Quand une solution s’offre à nous, et qu’elle nous parait pertinente, nous l’intégrons aux rituels d’équipe pour ne pas être tenté de le squizzer. Il faut vraiment jouer le jeu. Nous nous sommes mis d’accord sur un daily à 9h30, qui permet d’identifier les tâches à review, suivi d’une review collective et systématique.
Avantages :
– On a découvert le Mob Code Review tous ensemble
– Aucune tâche ne pouvait plus être laissée de côté
– L’équipe s’est vraiment intéressée à tous les sujets, même si on sortait de notre zone de confort
– Uniformisation des pratiques de développement
Inconvénients :
– Si plusieurs tâches sont à review, ça peut être chronophage.
– Alors qu’une partie de l’équipe se sent plus productive le matin à coder, enchainer tous les jours daily + review, la matinée était rapidement perdue.
Fonctionnement actuel
Comme toujours, on prend les feedbacks, et on itère pour améliorer les choses. On a donc déplacé la review au début d’après-midi, et on essaie d’être là, sauf impératif. Pour que tout le monde soit au courant de la nécessité d’une review, on a mis un petit rappel slack qui apparait à 11h tous les jours :
Déroulé
Mais comment ça se passe, une mob review ?
NB : Notre équipe est en full remote depuis plusieurs mois / années maintenant (ça fait bizarre de le dire d’ailleurs). Donc premier conseil, choisissez une plateforme de streaming qui permet de partager son écran en haute def, ce qui permet la lecture de code. Exit Discord, on se retrouve sur Google Meet.
Le / la responsable du code va présenter :
– Le but de sa Pull Request
– Le contenu, plus ou moins détaillé
– Potentiellement il y aura une démo
S’en suivront un jeu de questions, de remarques, on voit si toutes les choses obligatoires y sont (documentation / tests).
Si tout est OK, la PR pourra être mergée dans la foulée. Et si ça nécessite du travail en plus et bien pas de problème, la personne retravaillera dessus quand elle le pourra.
Alors, en avez-vous besoin ?
Si vous avez une équipe avec des compétences homogènes, sur un scope fonctionnel bien délimité, je ne pense pas qu’il faille aller jusque là.
Mais si vous voulez faire monter des personnes en compétence et améliorer la communication horizontale entre les membres, c’est un très bon outil. Chez nous, il en a découlé des choses rigolotes, comme du Pair Programming entre des personnes qui n’avaient, jusque là, pas grande intéraction.
Des tâches qui ne peuvent plus rester bloquées, une équipe soudée, un partage de connaissance, bref, on valide tous. L’investissement en temps est le bon, dans notre contexte, même s’il est non négligeable. Mon conseil sera simplement d’écouter l’équipe pour arriver à trouver le bon équilibre.