Cet article est rédigé en paire avec Hadrien. On s’est dit que c’était bien d’illustrer le concept par la pratique !

Photo de Tudor Baciu sur Unsplash

C’est quoi le pair-programming ?

Le pair programming, ou travail en binôme, est une pratique qui consiste à travailler à deux en même temps sur une même tâche de développement.
En gros, au lieu de bosser à un seul cerveau, tu bosses à deux.

Tu trouveras ici un article assez complet sur le pair-programming dans lequel tu verras comment le pratiquer et le mettre en oeuvre. Si tu n’est pas au clair avec cette pratique, je te conseille de commencer par là !

C’est quoi le mob-programming ?

“Un mob, c’est réunir toutes les personnes qui sont nécessaires au succès d’une tâche autour d’un seul poste de travail.”

Piqué par Hadrien à Woody Zuill

Bon, dit comme ça, c’est abstrait, mais concrètement, ça donne quoi ?
Si tu as connu les tasks forces, ça y ressemble !

Tu sais, le moment où c’est la m$#§e sur le projet, que la deadline arrive et qu’on met tout le monde dans une ‘war room’ pour sauver le monde (et le projet).

Ben c’est la même chose, mais avant que ce soit le bordel.

Concrètement, tu mets les développeurs du projet, et tous ceux qui sont utiles dans une même salle, en même temps, devant un seul écran.

La différence avec le pair-programming: ben c’est juste le nombre.
Au lieu d’être 2, tu peux être 3, 4, 5 ou plus si affinité.

Bon en vrai, au-delà de 6, ça va être compliqué à tenir dans le temps. Si tu as besoin de plus d’une pizza (format américain) pour nourrir ton équipe c’est qu’il est temps de la diviser.

Et finalement cette toute petite différence, tel un battement d’aile de papillon, engendre de grandes différences.

C’est ce qu’on va voir maintenant.

Pourquoi travailler en mob programming?

« Parce que nous avons décidé de travailler de cette façon » 

Woody ZUILL

On connait toutes et tous le fameux mythe : à 4 en mob, on va 4 fois plus lentement. 

Oui…

Et si on file des ballons à tous les joueurs d’une équipe de foot, le match se finit en 8 minutes. Tu as saisi l’idée.

Notre but dans ce paragraphe est de te donner envie d’aller jusqu’au bout de l’article. Alors on t’a préparé un condensé de toutes les bonnes raisons de faire du mob.

En programmant en mob, tu élimines les daily et les relectures de code à minima. 
Tu as bien lu ? Plus de daily… Rien que pour ça, tu devrais dévorer cet article !

Si tu arrives à le faire à plein temps, le travail en cours est toujours de 1. 
La loi de little prédit que ça va diminuer le temps qu’il faut à une fonctionnalité pour partir en production. Autrement dit, ça diminue ton Time-To-Market.
Et ça, je ne connais aucun manager qui déteste…

Tu verras aussi que la qualité va monter en flèche. Le code sera mieux conçu et les bugs vont diminuer. 
Faire du bon taf, c’est plus agréable comme quotidien, non ?

Comme toute l’équipe a le contexte et l’historique de toutes les fonctionnalités, ça veut aussi dire que tu peux partir en vacances quand tu veux. La propriété collective du code qu’on prône, on ne peut pas y être plus.

C’est aussi la manière la plus rapide de former un junior ou d’onboarder un développeur d’après l’expérience d’Hadrien.

Est-ce qu’on a réussi à te donner envie de tenter ?
Voyons comment on met ça en place !

Comment mettre en place le mob programming

Le mob programming, c’est un jeu d’équipe. Et pour jouer en équipe il faut… oui une équipe, c’était peut-être évident, allons-y !

Étape 1 – Assemble ta team

Il y plusieurs stratégies :

• Chope les personnes dont tu as besoin pour réaliser la tâche.
• Une question métier ? Attrape l’expert métier.
• Besoin d’aide pour les tests ? Amène ton copain craft et un quality analyst !
• Les personnes que tu aimes bien, ça peut paraître naïf, mais avoir des relations préexistantes ça peut aider
• Les personnes qui veulent bien. Forcer des gens à venir dans un mob c’est une bonne recette pour un désastre

Tu binômes déjà ? C’est simple, trouvez un ou une 3ème dev et vous allez pouvoir tester des pratiques de mob.

Mais, le plus puissant, c’est l’équipe complète quand elle réunit les 3 critères ci-dessus.

Étape 2 – Trouve ton spot

L’idée c’est de viser le confort, comme pour le binômage, c’est une pratique qui demande beaucoup d’énergie alors autant se mettre bien.

Il va y avoir plusieurs choses qui vont influencer ce confort :

L’isolation phonique

Donc un espace séparé de tes collègues. Un mob ça discute non stop, ça peut vite agacer tes ami.e.s d’open space

La taille de l’écran

Si tu as déjà essayé de binômer sur un pc portable, tu sais pourquoi.
Quand on passe à plusieurs, il faut un plus grand écran qu’on peut regarder sans finir chez le kiné et l’ophtalmo (ok on a une mutuelle mais quand faut pas pousser).
Un projecteur de réunion peut bien marcher pour transformer un espace à pas cher.
Une grande télé étant souvent la meilleure option, c’est pas très cher et la qualité est largement suffisante.
Et le top du top, c’est 2 grandes télés 0:)

La qualité des fauteuils

On peut bien travailler une heure ou deux sur une chaise, mais votre corps vous dira merci si vous ne négligez pas ce critère.

Les chaises de merde, on en parle ?

La présence d’outils d’écriture

On dit qu’une image vaut mille mots. C’est pareil avec nos petits gribouillis, ils expliquent souvent mieux ce qu’on veut dire. Un tableau blanc c’est top, un paperboard ça fait aussi l’affaire, un grand cahier en dernier recours.

Les ouvertures sur l’extérieur

5 personnes qui réfléchissent à fond, dans une pièce sombre, sans fenêtres…
Tu vas le sentir, au « propre » comme au figuré. Aérer c’est bon pour la santé. Regarder dehors c’est bon pour les yeux, et le mental.
L’ouverture vers l’extérieur te permettra notamment de déconnecter un moment à regarder un oiseau, le ciel, les voitures.
En mob tu peux te le permettre, tes collègues te feront rattraper ce que tu aurais raté en deux temps trois mouvements. Et tu seras plus disponible mentalement.

Parfois on doit composer avec les moyens du bord, mais vous n’allez pas tenir longtemps à plusieurs sur un pc portable sur un coin de table dans la cafétéria.

La salle de réunion est une bonne option pour se lancer. Les fauteuils sont souvent de pas trop mauvaise qualité ; il y a un écran ou une grande télé ; on est séparés des collègues. Mais il faut jouer avec le planning de la salle, et il y a trop de salles style cave. Ne va pas déprimer sous les néons sans voir le jour de la journée.

Si vous décrochez un bureau, bingo. Sinon, installez des séparations acoustique dans votre open space peut être moins cher et aussi correct niveau résultat.

Le matériel À distance

Tous les critères ci-dessus s’appliquent, avec un petit twist. Essayez de réunir en plus les outils suivants :

• Un micro correct, on ne doit pas trop entendre le bruit environnant, ta voix doit être claire et compréhensible (et avec un casque tu peux écouter de la musique en même temps 0:) )
• Une caméra. Pas besoin de super technologie, tu vas apparaître en tout petit sur l’écran de tes collègues.
• Un endroit de ton écran pour voir tes collègues

Avoir la caméra allumée n’est pas forcément agréable ou gérable pour tout le monde. Certains peuvent se sentir fliqués. C’est ok, garde toujours le confort des membres de ton équipe en tête.

Mais si vous acceptez de la garder ouverte, ça vous facilitera la tâche. À distance, avec le lag, c’est plus difficile de prendre la parole, de ne pas se couper, de signaler qu’on veut prendre la parole.
Voir les personnes t’aidera.
Ça permet aussi de savoir que Thomas est parti enfourner son gâteau puisqu’il est pas devant son écran.

Mais surtout, tu pourras voir si quelqu’un décroche ou est train de rager silencieusement devant ce que l’équipe fait. C’est un signal précieux pour désamorcer la situation et continuer à avancer en prenant du plaisir ensemble.

Étape 3 – Sélectionne ton sujet

Ne prenez pas de tâche qui implique de beaucoup lire ou de beaucoup explorer. Synchroniser ses vitesses de lecture, ses manières de parcourir du code ou de la documentation, c’est très compliqué. Pour ces cas, il vaut mieux fouiller chacun.e de son côté en s’informant en continu de ses découvertes.

Ton premier instinct sera peut-être de prendre une tâche complexe ou bloquante pour les autres. Ça a l’avantage de te permettre de justifier le mob. L’inconvénient c’est qu’à la difficulté de la tâche, s’ajoute la difficulté du travail à plusieurs. Suivant les contextes, ça peut être le meilleur choix, mais je te le déconseille.

Toutefois, pour t’aider, voici les défis que ton équipe aura à relever :

• communiquer clairement ce qu’on veut faire
• distribuer la parole de manière équitable
• s’aligner sur les pratiques techniques
• gérer sa fatigue
• pousser toutes et tous dans le même sens
• établir de la sécurité psychologique : on ne se fera pas blâmer/moquer pour avoir dit une bêtise et on peut dire quand on sent que ça ne va pas sans avoir peur

En ayant ces défis en tête, pour commencer, favorisez des tâches simples. Crois moi, il y a suffisamment de boulot avec les défis. Puis, quand vous le sentirez, passez à plus complexe !

Est-ce qu’on fait les tâches triviales ensemble une fois rodés ? À vous de voir. Je ne veux pas te prescrire une méthodologie. Expérimentez, jaugez et jugez ensemble. Mais pour moi la réponse est un grand oui.
Les tâches triviales, ça va vite. Ça ne va pas beaucoup plus vite en séparé.
Le gain de temps à se séparer est minimal.
Et le faire ensemble, même rodés ça a des avantages : Ça vous offre un break mental à tous. Pendant que ça déroule, les mobbers peuvent papoter, ou laisser leur esprit vagabonder. Ça renforce votre niveau d’énergie et ça forge des liens plus puissants avec vos collègues.

Vous avez, ensemble, accès à des victoires faciles et rapides. La victoire c’est meilleur quand c’est partagé, même quand c’est petit.

Comment faire du mob programming ?

Parlons concret. Il y a plein de manières de travailler en mob, elles vont fonctionner plus ou moins en fonction de la personnalité de votre équipe. Mais il y a au moins une pratique essentielle : le strong style.

Si tu as une idée de code, tu n’écris pas

« Pour qu’une idée arrive dans le code elle doit d’abord passer par la tête de quelqu’un d’autre »

Llewellyn FALCO

C’est ça le strong style.

En pair-programming, c’est la meilleure technique pour s’assurer que votre binôme ait compris l’idée, jusque dans les plus petits détails d’implémentation.

Concrètement, si tu as une idée de code, de pattern, ce que tu veux, tu passes le clavier à ton binôme. Tu lui expliques l’idée, il écrit en posant des questions et, soit tu lis pour confirmer soit tu en profites pour rester dans l’abstrait et penser à l’étape suivante.
Tu verras ça aide de ne pas avoir à plonger dans les détails techniques pour suivre une idée un peu compliquée.

En mob, c’est indispensable. Accroches toi, on va parler démocratie, république et tout ça.

La personne au clavier a le pouvoir de faire entrer ou non du code dans le projet. Pour une seule personne, être la source des idées, le designer et le programmer, c’est concentrer trop de responsabilités, donc trop de pouvoir.

Ça veut dire que quand tu prends le clavier, si tu n’es pas d’accord avec une idée, tu dois la coder quand même. Tu devras attendre de changer de rôle pour proposer autre chose.

Il faut dédramatiser, souvent quand je suis en désaccord il se passe une de ces deux choses :
Soit mes collègues pensent comme moi et le disent à ma place, et je n’ai rien à faire
Soit je me rends compte en suivant le mob que c’était pas si mal, et pas si mal en mob, c’est un niveau de qualité très élevé par rapport à mon niveau « cool » en solo

Hadrien

Les rôles

De cette technique du strong style découle 3 rôles de base.

Avant j’aimais expliquer les choses avec la métaphore classique de la voiture de rallye, mais maintenant je préfère parler de conduite accompagnée. Pas besoin d’être Sébastien Loeb au volant, ça soulage.

Hadrien

Pilote

Dans notre voiture, le pilote est la personne au volant. Son boulot c’est de gérer le volant, les pédales, les vitesses, le code de la route etc. Mais pas de pression, on est en conduite accompagnée, il faut juste avoir des petites bases pour prendre le volant.

Décliné à notre métier, c’est la personne au clavier. Tu écoutes, tu codes ce que tu comprends. C’est toi qui fait avancer le code dans l’équipe. C’est une de mes places préférées. C’est relax, tu réfléchis pas trop, tu codes, pas de conflits pour toi, c’est pas ton rôle. Le mieux c’est quand tu ne connais pas la technique qu’on veut te faire utiliser. C’est le meilleur tutoriel du monde, tu as ton formateur à côté et c’est toi qui fait tout le boulot.

co-pilote

C’est la personne sur le siège passager à côté du pilote. Dans les voitures de rallye, c’est la personne qui connaît par cœur le parcours. Elle va guider le conducteur : « dans 500 mètres, virage à 90 degrés sur la droite et ça passe du gravier à la boue ».

Bonjour la pression. Mais on a la chance d’être à plusieurs en mob. Reposes-toi sur tes collègues. Si tu as une idée en tête, c’est le bon moment pour la faire passer dans le code. Si tu n’en as pas, c’est le moment de jouer au modérateur. Demande à tes collègues leur idées, trouve le consensus et explique l’idée à ton conducteur !

Penses bien à expliquer ton idée au plus haut niveau d’abstraction compréhensible par la personne au clavier. Si l’idée que tu as, c’est que tu aimerais avoir un décorateur et que ton driver sait le faire, pas besoin d’aller dans les détails. S’il ne sait pas, tu peux expliquer plus finement, jusqu’à arriver à de la dictée au besoin. C’est très agaçant quand tu es au clavier et qu’on te prends plus bête que tu ne l’es.

Mobber

C’est le rôle le plus important pour que ça fonctionne bien. Dans ce rôle tu t’assures, du mieux que tu peux, que rien n’arrête ou ne freine le mob.

Qu’est-ce qui peut vous freiner en Mob ?
La fatigue -> prends une pause
Les sentiments négatifs, les collègues qui décrochent -> demande une mini rétrospective
Un problème technique -> fouille google
Une question métier -> va chercher le PO

Tu l’as compris, dans ce rôle, il faut prêter attention à ce qui se passe, à l’écran et chez tes collègues. C’est le bon moment aussi pour t’assurer que tout le monde arrive à prendre de la place dans le mob. Personne ne doit être laissé en retrait, perdu.e ou passif. Tout le monde doit se sentir en sécurité pour participer avec ses compétences.

Si tu es comme Hadrien, tu vas devoir lutter contre ton envie de parler tout le temps. Dire la bonne information au bon moment, c’est ton défi. On doit apprendre à laisser plus de silence.

Maintenant tu as une idée des rôles de bases, voyons comment on s’organise dans les faits !

La forme classique

Je te conseille de commencer par là. C’est une forme stricte et réglée mais ça aide pour s’y mettre. Elle est aussi simple, il te suffit d’appliquer les 4 règles suivantes.

Prends un chrono. Un minuteur quelconque peut faire l’affaire, mais il y en a des spécialisés dans le Mob comme Mob Time ou Mobster.

Prends une durée de tour au clavier : entre 2 et 10 minutes, surtout pas plus, sinon vous allez décrocher de ce qui se passe à l’écran. Tout le monde doit passer au clavier en une heure. Si, encore mieux, vous passez toutes et tous en 25 minutes, c’est le top.

Dès que la sonnerie retentit, on tourne. Le co-pilote devient pilote, le pilote devient mobber et un des mobbers devient co-pilote.

Attention, si tu es au clavier, dès que ça sonne, tu lâches tout ! En plein milieu s’il le faut ! Si ton ou ta collègue n’est pas capable de te succéder, c’est qu’il y a un souci de communication des idées.

C’est une pratique intense mentalement, alors une à deux fois par jour, prenez 5 minutes pour vous posez ces 2 questions :
Comment ça s’est passé pour vous ? Est-ce que vous étiez à l’aise ? Tendus ? Heureux ? Frustrés ?
Est-ce qu’il y a quelque chose que vous aimeriez faire différemment à la prochaine session ?

Les autres formes

Une fois que vous maitrisez les rôles, vous pouvez introduire plus de souplesse. Pour certaines équipes ça fonctionne mieux.

Il y a par exemple le fishbowl, ou aquarium en français. Cette approche change la manière de prendre des rôles dans le mob. Si une personne veut être au clavier, elle va taper sur l’épaule du driver et prend sa place. Idem pour le rôle de navigator. Tu as aussi le droit de quitter le poste au clavier si tu en as assez, idem pour la navigation.

À distance, avec un outil comme LiveShare, vous pourrez échanger les rôles beaucoup plus rapidement. C’est assez plaisant, mais ça demande une bonne connaissance de la pratique et de tes collègues pour ne pas vous couper la parole sans arrêt.

Les enjeux psychologiques

Sortir de la dualité

A deux, l’opposition d’idées peut arriver vite: il suffit que je pense A et mon binôme B, et c’est potentiellement conflictuel.
Je dis potentiellement parce que si j’accepte de mettre mon idée de côté au profit de celle de mon binôme, il n’y a pas de conflit. Mais cela sous-entend d’être au clair avec soi-même, savoir exprimer ses idées de manière assertive et accepter finalement qu’il y a ait une autre manière de faire les choses, et peut-être même meilleure. 

Mais il y a des fois où c’est plus dur : si mon binôme est persuadé d’avoir toujours raison, ou que ce je fais ne lui convient pas et qu’il le montre, la situation peut se tendre et se bloquer.

Y’a pas pire personnalité dans un mob que quelqu’un qui ne veut jamais lâcher. Pour le coup, c’est la même chose qu’en pair.

Je peux même en arriver à éviter de travailler avec une telle personne.
Tu noteras que je peux aussi être la mauvaise tête de quelqu’un d’autre. 

Mais dans le mob programming, c’est différent: dès que nous sommes 3, il n’y a plus dualité. Il y a une troisième voix qui équilibre les choses.

On n’est plus dans la confrontation un à un, mais dans la recherche d’un compromis à plusieurs. Et ça peut tout changer.

Quelqu’un qui vous insupporte en binôme peut devenir un allié en mob programming lorsqu’il te sort de tes travers : n’étant plus dans la confrontation, l’équilibrage des besoins des uns et des autres peut amener à un compromis qui donne un meilleur résultat.

Bien entendu, cela sous-entend que chaque personne du mob prenne pleinement son rôle en main. Tout le monde n’a pas forcément l’âme d’un leader, mais tout le monde a une opinion sur ce qui est en train d’être fait. Et c’est le fait de l’exprimer qui permettra au groupe d’avancer en cohérence.

Travailler à plusieurs m’apporte aussi un certain confort sur les décisions. 
Seul je peux tourner en rond sur deux ou trois alternatives. Il m’arrive de ne pas réussir à assumer les mauvais côtés d’une solution. 

Hadrien

Par ailleurs, le mob change la relation à l’erreur. S’il y a un gros pépin et que 4 personne l’ont raté, c’est qu’il y a un souci d’un ordre supérieur à régler ailleurs.
Et si tu te fais engueuler, ça passe mieux à plusieurs.

Plus de liberté

En pair programming, quand l’un des deux a besoin de faire une pause, quelle qu’en soit la raison, le binôme s’arrête, par définition.

Donc le travail s’arrête aussi : le sujet qui est en train d’être traité n’avance plus, en tout cas pas dans le cadre du pair programming.

A l’inverse, le mob programming permet qu’un des membres sorte du mob, tout en continuant d’avancer.

Si tu as quelque chose à faire de plus important à un moment donné, tu peux simplement t’extraire et le mob continue d’avancer. Bien sûr tu rattraperas plus tard ce qui s’est passé. Tu raccrocheras facilement les wagons : prends un tour au clavier, ça te remettra dans le bain directement. 

A l’opposé, la pression du pair est quelque chose de très fatigant : il faut aligner son rythme avec celui de l’autre. C’est prenant et il y a une part de chance. Si l’autre a un rythme comparable au tien, ça sera super. Sinon, ça risque d’être lourd et compliqué.

C’est aussi ce qui fait la richesse et l’intensité du binôme : le fait d’être à deux pousse à rester concentré au maximum. 

Mais j’avoue que j’ai souvent eu du mal à prendre une pause. Comme cela `force` mon équipier, j’hésite avant de le proposer.

Benoit

C’est là que le mob peut briller par l’ouverture des possibilités qu’il apporte: le groupe peut trouver ses solutions sur mesure pour gérer l’énergie de chacun

Hadrien

Gérer les émotions

Les émotions c’est la grosse différence entre nous et les machines. C’est ce qui fait le sel de la vie.
Et c’est aussi ce qui met le bordel dans les équipes.

Ca tombe bien, pour desamorcer les pièges liés aux émotions, Hadrien et Thomas t’ont préparé une super conf 50% retour d’expérience, 50% bonnes pratiques. C’est cadeau.

Economie du mob-programming

Travailler à deux sur la même tâche, c’est déjà pas évident à faire passer d’un point de vue financier. Le premier réflexe de nombreux managers sera d’avoir l’impression de payer deux fois plus cher pour pas grand chose.

Mais alors comment justifier de faire la même chose à 3, 4 ou 5 ?

Cela ressemble à une hérésie. Et pourtant, pas tant que ça quand on y regarde de près.

Alors mettons les pieds dans le plat tout de suite : oui, travailler en binôme ou en mob coûte généralement plus cher. Mais ce coût additionnel n’est pas du gaspillage comme on pourrait le croire. 

Quand on travaille en mob-programming, les décisions sont prises par l’équipe de manière synchrone. C’est au cœur même du processus.

Du coup, plus besoin de réunions pour savoir comment on va faire les choses, se mettre d’accord sur ce qu’on a compris ou pas, donner un statut sur l’avancement du projet.

En gros tu supprimes 90% des réunions. 

Ça fait rêver, non ?

Dans une équipe qui bosse en mob, à quoi bon faire des daily stand up à part faire plaisir au chef de projet ? La fonction réelle, se synchroniser entre membres de l’équipe, est native au processus.

Même chose pour les revues de code : la revue est intégrée lors de la production puisque le code est revu par toute l’équipe en temps réel.

Enfin les décisions sont prises par toute l’équipe en temps réel. Tous les membres ne sont pas obligés d’être d’accord, mais on débat séance tenante et à la fin, il n’y aura qu’un code qui partira en production. Il faudra donc converger vers une décision qui sera à priori un compromis permettant à chacun de s’y retrouver. Rien que ce point permet de gagner non seulement du temps en effort, mais aussi en délai : l’équipe va plus vite pour prendre les meilleures décisions qui s’imposent à elle.

Le fait d’être plusieurs à soutenir la décision permet aussi de se sentir plus serein : au final si quelque chose nous tracasse, mais que le reste de l’équipe pense que c’est ok, tu n’es pas seul à porter la décision et c’est rassurant.

Le revers de la médaille c’est qu’en cas de problème, c’est toute l’équipe qui va prendre un savon. Mais au fond, si on embrasse l’idée de responsabilité collective, cela ne devrait-il pas déjà être le cas ?

En tout cas le savon passe mieux à plusieurs que seul : on peut se consoler mutuellement.

Hadrien

C’est quoi la suite ?

On va pas te mentir : le mob-programming fait partie des pratiques les plus engagées et rares du software craftsmanship.

Dans l’eXtreme Programming, le pair-programming est prescrit dans la méthode. Mais force est de constater que cette pratique est aussi peu répandue que le mob-programming, même dans les boites qui ont une forte culture craft.

Donc si tu as envie d’expérimenter ça dans la vraie vie, il va falloir bien chercher le contexte favorable ou alors le créer si tu as des collègues férus eux aussi.

Quand à Hadrien et moi-même, on a pris beaucoup de plaisir à rédiger cet article et on réfléchit à en faire une v2.
Alors si tu as des suggestions, envoie nous un message !