Travailler ensemble en direct : pair, mob, shadowing et swarming

Pair programming, mob, shadowing, swarming : les quatre façons de travailler ensemble en temps réel, leurs variantes, leurs pièges, et comment choisir celle qui convient à votre situation.

Dans le guide des modes de collaboration, nous avons posé une règle : le savoir tacite ne se transmet que par le contact. Les modes synchrones sont donc irremplaçables — mais ils ont un coût, et ce coût fait peur. « Deux personnes sur une seule tâche, c’est diviser la productivité par deux. » Cet article démontre le contraire et détaille les quatre grandes façons de travailler ensemble en direct, avec leurs variantes et leurs pièges.

I. Pourquoi le synchrone est irremplaçable  

Un expert qui diagnostique une panne ne suit pas une procédure : il élimine des hypothèses à une vitesse qu’il ne saurait pas lui-même décrire. Demandez-lui d’écrire sa méthode, il vous rendra une liste appauvrie. Ce savoir-là — l’ordre dans lequel on regarde les choses, ce qui déclenche un soupçon — n’existe que dans l’action.

C’est la raison d’être des modes synchrones : ils ne transmettent pas un contenu, ils exposent un raisonnement en train de se faire. Voir quelqu’un hésiter, revenir en arrière, écarter une piste : c’est là que le savoir tacite passe.

Quant au coût, il est presque toujours mal calculé. On compare le temps passé à écrire le code, alors qu’il faudrait compter l’ensemble : la revue de code devenue inutile, les allers-retours évités, les bugs non introduits, le collègue formé au passage. Le travail à deux ne double pas le coût d’une fonctionnalité — il déplace une partie de l’effort en amont, là où il coûte le moins cher.

II. Le pair programming  

Deux personnes, un clavier. C’est le mode de base, et le plus souple.

Le fonctionnement classique repose sur deux rôles :

• Le pilote (driver) tient le clavier et se concentre sur le geste immédiat : écrire le code qui marche.
• Le navigateur (navigator) garde la vue d’ensemble : la direction, les cas oubliés, la cohérence avec le reste.

La règle d’or est la rotation régulière. Sans elle, l’un devient un exécutant et l’autre un spectateur — et la transmission s’arrête. Un changement toutes les dix à quinze minutes suffit à maintenir les deux cerveaux engagés.

Trois variantes valent le détour :

• Le ping-pong pairing — le binôme façon TDD : A écrit un test qui échoue, B écrit le code qui le fait passer, puis B écrit le test suivant, et ainsi de suite. C’est la meilleure façon de transmettre une discipline de test, parce qu’elle s’exerce plutôt qu’elle ne s’explique.
• Le strong-style pairing — formulé par Llewellyn Falco : « pour qu’une idée aille de ta tête à l’ordinateur, elle doit passer par les mains de quelqu’un d’autre ». Celui qui sait dit, celui qui apprend tape. Contre-intuitif, mais redoutablement efficace quand l’écart d’expérience est grand : le novice ne peut pas rester passif.
• Le promiscuous pairing — la rotation fréquente des binômes au sein de l’équipe (Arlo Belshee). Le savoir cesse de circuler entre deux personnes pour irriguer tout le groupe.

III. Le mob programming  

Toute l’équipe, un seul problème, un seul écran. Ce que Woody Zuill a popularisé sous le nom de mob programming (aussi appelé ensemble programming).

Le déroulé ressemble au binôme, à l’échelle du groupe : une personne au clavier, les autres qui réfléchissent et guident, avec une rotation minutée du pilote — souvent toutes les cinq à dix minutes. Le minuteur n’est pas un gadget : il évite qu’un seul monopolise le clavier et garantit que chacun passe par le geste.

Quand l’utiliser. Le mob n’est pas fait pour la production de masse. Il excelle sur :

• le démarrage d’un projet ou d’un module, quand les conventions se fixent ;
• une décision d’architecture qui engage tout le monde ;
• un système critique que trop peu de gens connaissent ;
• l’arrivée de plusieurs recrues en même temps.

Sur ces sujets, il fait en une matinée ce que des semaines de documentation et de revues ne feraient pas : il aligne toute l’équipe d’un coup.

Son coût réel est plus faible qu’il n’y paraît, car il absorbe des activités qu’on paie ailleurs : plus de revue de code à faire, plus de réunion d’alignement, plus de transfert de contexte. Reste qu’il est fatigant — on y revient en section VII.

IV. Le shadowing  

Le shadowing est le mode le plus simple, et sans doute le plus sous-employé. Il se déroule en deux temps :

1. Le shadowing — l’apprenti observe l’expert au travail, sans intervenir. Il regarde une astreinte, un diagnostic, une mise en production. L’expert commente ce qu’il fait et, surtout, pourquoi il le fait.
2. Le reverse shadowing — on inverse les rôles. L’apprenti agit, l’expert observe sans reprendre la main, et n’intervient qu’en cas de risque réel.

Cette seconde étape est celle que l’on saute presque toujours, et c’est pourtant la seule qui prouve que la transmission a eu lieu. Observer donne l’illusion de savoir ; faire révèle ce qu’on ne sait pas encore.

Le shadowing brille particulièrement pour les savoirs opérationnels — incidents, procédures d’exploitation, gestes rares — que l’on ne pratique pas assez souvent pour les acquérir autrement.

V. Le swarming  

Le swarming, c’est la convergence de toute l’équipe sur un seul élément bloquant. La différence avec le mob tient à son déclencheur : le mob est un mode de travail choisi, le swarming est une réaction à une situation.

On l’utilise quand :

• une tâche bloque toute la chaîne et empêche la suite d’avancer ;
• un incident demande plusieurs regards en parallèle ;
• un travail traîne depuis trop longtemps entre les mains d’une seule personne.

Sa vertu de transmission est un effet de bord — mais un effet puissant : en se penchant ensemble sur un sujet, l’équipe découvre une zone du système que peu maîtrisaient. C’est souvent lors d’un swarming qu’on réalise à quel point un composant reposait sur une seule tête.

VI. Quel mode dans quelle situation ?  

Dernière ligne comprise : tout ne mérite pas d’être fait ensemble. Le synchrone se réserve à ce qui est nouveau, critique ou mal partagé.

VII. Les pièges à éviter  

• Le binôme passif. Si le navigateur regarde son téléphone, vous payez deux personnes pour le travail d’une. La rotation régulière est le remède.
• Le mob permanent. Le mob est intense ; le tenir toute la journée, tous les jours, épuise l’équipe. Beaucoup fonctionnent par sessions de deux à trois heures, quelques fois par semaine.
• L’expert qui reprend le clavier. En reverse shadowing comme en binôme, c’est le réflexe qui tue la transmission : on gagne dix minutes et on perd l’apprentissage. Laissez l’autre se tromper, c’est le prix du savoir.
• L’absence de rotation. Toujours les deux mêmes personnes en binôme, c’est un bus factor de 2 au lieu de 1. Un progrès, mais pas une solution.
• Le synchrone sans confiance. Ces modes exposent : on se trompe devant les autres. Sans sécurité psychologique, personne ne prend le clavier, et la pratique devient un théâtre.
• Le distanciel improvisé. À distance, ces modes fonctionnent très bien — à condition d’outiller le partage (édition collaborative, partage d’écran fluide) et de garder la caméra. Un binôme à distance sans visage devient un monologue.

Conclusion  

Pair, mob, shadowing, swarming : quatre façons de mettre plusieurs cerveaux sur le même problème au même moment, et quatre façons de faire passer ce qu’aucun document ne retiendra. Ils ne s’opposent pas — une équipe mature les combine selon le contexte, et les réserve à ce qui le mérite vraiment.

Retenez surtout ceci : ces modes ne coûtent pas du temps, ils déplacent du temps. Celui que vous investissez à travailler ensemble aujourd’hui, vous ne le paierez pas demain en revues interminables, en bugs, ou en départ d’expert qui emporte tout avec lui.

Useful links  

• Mob Programming — Woody Zuill
  Le blog de celui qui a popularisé le mob : principes, déroulé, et retours d’expérience sur la pratique en équipe.

• Llewellyn’s Strong-Style Pairing
  L’article d’origine sur le binôme « fort » : l’idée doit passer par les mains de l’autre, avec les règles pratiques pour l’appliquer.

• On Pair Programming — Martin Fowler (Böckeler & Siessegger)
  Un panorama complet du binôme : styles, bénéfices, difficultés courantes et conseils pour le pratiquer à distance.

• Industrial Logic — Articles & papers
  La bibliothèque d’articles d’Industrial Logic sur les pratiques agiles, dont le pair programming et la rotation des binômes.