Mob Programming

Mob Programming

Je trouve que cette devise des mousquetaires représente bien le Mob :

Un (clavier + écran) pour tous, tous (les cerveaux) pour un (problème)

J’ai beaucoup entendu parler de Mob Programming ces derniers mois. Peut-être plus longtemps que je n’ai encore pratiqué, du moins à l’heure où j’écris ces lignes, mais c’est en train de changer.

Même si mon métier n’est plus d’écrire du code quotidiennement, mais plutôt d’aider les autres à bien le faire lorsqu’il y a une demande dans ce domaine, je profite des occasions pour coder (1) et apprendre à mieux le faire à plusieurs, en intégrant des mobs.

Depuis quelques semaines, nous nous exerçons à 3 en mob sur des katas avec Anthony et Guillaume. Auparavant j’avais eu la chance de participer à 2 code retreat global day, quelques autres ateliers ponctuels dans différentes équipes ou entre 12h-14h à l’IUT de Blagnac. On s’organisait en pair programming principalement. Rarement en mob.

Aussi, il était difficile pour moi de demander aux équipes d’expérimenter le mob, ne l’ayant jamais réellement pratiqué moi-même. Anthony m’avait prévenu assez tôt des freins et de l’intérêt d’un mentor Mob pour changer les mentalités et les habitudes.

J’avais profité de la venue de Woody Zuill sur Toulouse pour me replonger dans sa littérature et se préparer à convaincre, en convaincu à la moindre occasion. En informant quelques développeurs de cette conférence, j’obtins la réponse suivante:

Ce n’est pas parce qu’une personne fait des conférences sur un sujet, que le sujet est intéressant pour nous.

Certes, mais pour savoir si cela peut avoir un intérêt, plutôt que de (ne pas) me croire sur parole, qu’êtes vous prêts à consentir comme temps pour vous renseigner et essayer ?

Ceci pour dire que je ne sais pas combien de jours il faut pour changer les habitudes si l’on s’y prend bien, ce qui est sûr c’est que lorsqu’on ne s’y prend pas bien, il n’y a plus aucune chance que ça arrive.

Voici donc quelques recommandations qui ont marché pour nous, si vous voulez tenter l’aventure:

  1. Des gens que vous connaissez bien, qui partagent le même intérêt d’apprendre de nouvelles choses, suffisamment disponibles dans la durée. On peut commencer par 1 rendez-vous fixe par semaine. Tous les lundis entre 17h30 et 18h30 par exemple. Mieux : 2 rendez-vous d'1h30. Avec 1h30, on peut passer un peu de temps à parler du problème, rechercher la meilleure option et arriver à la mettre en place en 2 ou 3 tours.

  2. Partir du même niveau ou avec un nouveau language pour tout le monde. L’avantage est que tout le monde à des choses à apprendre.

  3. Pas nécessairement le même IDE, mais attention quand même à adopter les mêmes standards et les mêmes automatismes (build, test, visualisation des résultats des tests, gestion de conf avec git) Chacun doit s’investir pour apprendre “seul” son environnement. Lorsqu’un blocage survient relatif à son propre poste, les autres partenaires ne sauront probablement pas comment vous aider, et ne trouverons pas d’intérêt à le faire si vous avez un environnement juste un peu trop exotique…

  4. Faire des petits changements atteignables avec un résultat satisfaisant pour la séance. Au pire, la frustration de ne pas avoir fini pourra constituer une motivation supplémentaire pour se retrouver et terminer la fois suivante. Chacun pourra se rendre compte des inconvénients à se retrouver au milieu d’un gros chantier non maîtrisé. Après cette expérience vécue collectivement (qui n’aurait peut être jamais été tentée individuellement), le mob cherchera à procéder par des changements minimum pour toujours être en mesure de progresser.

  5. Au pire, le driver reste le même sur une séance, et on tourne régulièrement sur le rôle de navigateur.

Conclusion

Si vous êtes motivés et avez devant vous 2 créneaux par semaine pour retrouver 2 ou 3 partenaires de code, alors foncez, itérez et persévérez.

Références

  • Assister à une conférence d’Anthony Cassaigne sur le Mob Programming

  • Assister à une conférence de Woody Zuill

  • Jeter un oeil ici, Anthony me dit que Chris Lucian est le bras droit de Woody.

(1) Faire les exercices/devoirs d’informatique à la place des enfants, ça n’est pas leur rendre service. Leur apprendre à pêcher est autrement plus profitable pour tout le monde. Je salue au passage toutes les initiatives des “coding goûter” et attend de participer à la prochaine même si j’ai peut-être passé la limite d’âge.