REX Mob Programming : la cohésion d’équipe maximale

Nous avons essayé le Mob Programming, la méthode qui fait travailler toute l’équipe sur un seul ordinateur.

Dans cet article, nous partageons ce que nous avons appris et nos astuces pour tirer un maximum de bénéfices de cette méthode.

Tous les gens brillant travaillent :

sur la même chose

en même temps

dans le même espace

sur le même ordinateur

C’est quoi ?

Nous entendons parler du Mob Programming depuis 2012 quand il a été introduit par Woody Zuill, mais cette manière de travailler ensemble existe probablement depuis bien plus longtemps. C’est néanmoins grâce à lui et son équipe que cette méthode a été formalisée et popularisée.

Le Mob programming peut être comparé à du pair programming sous stéroïdes. Une pratique où tout le monde est impliqué pour partager la connaissance, prendre des décisions ensemble et faire avancer le développement sans les problèmes d’intégration souvent rencontrés quand chacun travaille sur son poste en isolation.

Comment ?

L’équipe code donc sur le même ordinateur avec au moins un vidéoprojecteur. Étant donné la taille d’une mob, il est conseillé de changer de conducteur par des itérations courtes, toutes les quinze minutes par exemple. Cela permet à tout le monde de participer activement.

Pour faire un parallèle avec le pair programming, il y a toujours deux rôles :

1. « conducteur » : la personne actuellement derrière le clavier ;
2. « navigateurs » : le reste de l’équipe qui dirige le conducteur dans la bonne direction.

Comme on reste devant le même écran toute la journée, il est important de donner de la liberté aux gens. C’est-à-dire que tant qu’on n’est pas le conducteur en train de coder, on a le droit de sortir comme on veut.

Il peut également arriver qu’une autre équipe ait besoin d’aide, une partie de l’équipe du mob peut le faire sans interrompre la session (il suffit qu’il reste au moins un conducteur et un navigateur).

L’équipe

Nous sommes une équipe constituée d’un expert UX, quatre développeurs « full stack » et un Product Owner.

Cela fait 6 personnes, la taille conseillée pour un « mob » !

Le déroulement

Avec cette base, nous avons commencé le matin par poser quelques objectifs de la journée :

Faire la revue de code et intégrer deux merge requests en attente et commencer une autre feature.

Plusieurs itérations de quinze minutes plus tard, nous nous retrouvons toujours sur le premier merge request… Nous avons constaté que le travail effectué par un développeur n’est pas forcement compris par les autres et nous sommes entrés dans un débat sur le nommage. Puis enfin, un code simplifié et amélioré en est ressorti. En bonus, quelques bugs ont également été trouvés et corrigés.

L’heure de la rétrospective

Avant la pause déjeuner, nous avons fait une rétrospective.

Parmi les problèmes remontés, il y a le fait que tout le monde parle en même temps et que le conducteur part parfois développer sans être guidé par les autres.

En revanche, tout le monde était d’accord pour dire que le partage de connaissances est énorme avec cette méthode.

Riche de l’expérience du matin, l’équipe se retrouve encore devant le vidéoprojecteur pour l’après-midi.

Cette fois-ci, nous avons été plus réalistes dans nos objectifs et à la fin de la journée, les deux merge requests ont été revues et intégrées dans la branche principale.

Ça donne quoi alors ?

Nous avons gardé la durée de quinze minutes par itération tout au long de la journée.

Quelques dernières astuces pour assurer le bon déroulement :

• Attention au conducteur qui va dans sa direction et qui n’écoute pas les navigateurs :
  Une personne plus expérimentée va penser avoir la meilleure solution et va vouloir avancer plus vite toute seule. Cela peut être acceptable tant qu’il explique ce qu’il fait.
• Soyez conscient que vous pourriez avoir des niveaux d’expérience différents dans l’équipe : certains vont prendre plus de temps à écrire le code ou comprendre la solution, soyez patient.
• Il est impératif d’avoir un chronomètre pour ne pas perdre la durée des itérations : nous avons pris un chronomètre trouvé sur le web, et comme il est intégré dans le navigateur web, nous l’avons fermé par erreur plusieurs fois…
• Assurez-vous d’avoir un bon vidéoprojecteur :
  Vous allez passer toute la journée à regarder du code, un vidéoprojecteur pas suffisamment lumineux va vous faire mal aux yeux. Si vous avez accès à un grand écran LCD, c’est encore mieux !

Conclusion

Le mob programming est une des meilleures manières d’aider une équipe à travailler ensemble. On voit tout de suite quand il y a un dysfonctionnement et tout le monde a envie de débloquer la situation.

Nous y avons passé 2 journées entières, et il est apparu clairement que c’est une méthode qu’il faut pratiquer plus souvent pour s’améliorer. Mais même sur un temps limité, nous en avons tiré pleins de bénéfices.

Il est important de noter qu’une équipe qui décide de faire du mob programming dès le commencement d’un projet va aussi choisir les outils ensemble en fonction des expériences de chacun. Cela peut encore améliorer la productivité de l’équipe.