Introduction

Alors que le « pair programming » est assez répandu en entreprise, le « mob programming » est encore aujourd’hui marginal. Mob signifie foule en anglais. Je renvoie vers cet excellent article de Soat pour une présentation plus générale. L’arrivée d’une nouvelle recrue dans notre équipe de quatre personnes nous a donné l’occasion de généraliser cette pratique et d’en constater jour après jour tous les bienfaits. Cet article est un retour d’expérience, menée depuis plus de huit mois, assez conséquente pour qu’on puisse en mesurer tous les impacts psychologiques, techniques et organisationnels.

Aspects techniques

Rappelons les prérogatives de base :

L’écran est partagé entre tous les développeurs et l’un d’eux dispose d’un accès privilégié au clavier et à la souris. Les autres peuvent intervenir idéalement à tout moment.

En présentiel, soulignons la nécessité d’un grand écran et d’un espace assez large et isolé pour accueillir les différents protagonistes sans gêner le reste de l’équipe. Il est rare que ces conditions soit entièrement réunies et c’est peut-être l’une des raisons pour lesquelles cette pratique est si peu répandue. Chez nous, l’expérience s’est révélée assez peu concluante en raison du manque de place et d’intimité, dus à la présence d’autres équipes au sein de l’Open space. A cela, il faut ajouter les mesures sanitaires ubuesques, peu propices à un échange serein : port du masque, distanciation, panneaux séparateurs en plexiglass.

Les périodes de télétravail se sont révélées par contre très favorables et répondaient naturellement aux besoins ergonomiques. Les développeurs lançaient tour à tour un partage d’écran sous Skype et chacun d’eux était en charge de l’écriture du code, soit en proposant ses propres solutions, soit en réagissant aux remarques de l’équipe.

Le fait de disposer de sa propre machine, permettait à chacun d’essayer des solutions en parallèle à celles du présentateur. Ces efforts répartis ont souvent permis d’accélérer la résolution d’un problème, grâce selon le cas, à une plus grande détermination de l’un des participants, ou à la prise en compte d’un autre angle d’attaque.

Deux facteurs de dégradation ont tempéré néanmoins notre enthousiasme initial, assez minimes néanmoins pour ne pas tout remettre en cause :

• Les développeurs avaient des écrans de tailles hétérogènes (du 34 pouces pour les plus grands au 15 pouces pour ceux équipés de portables). A moins de se contenter d’une résolution très élevée et de souffrir d’une visibilité réduite, lorsqu’un développeur effectue sa présentation sur un écran très large, les autres sont obligés de scroller pour accéder aux différentes parties de la page. Cela peut être une source de confusion car le bout de code présenté peut ne pas correspondre à ce que nous avons actuellement sous les yeux.
• En télétravail, la qualité du réseau et la bande passante sont primordiales. Une connexion ADSL avec un débit descendant de 16 Mbit reste insuffisante pour effectuer sa présentation de manière efficace. Des retards jusqu’à 10 secondes étaient parfois constatés entre deux rafraîchissements d’écran. Avec la fibre, le problème ne se posait plus cependant. La perception d’ensemble est très dépendante du logiciel de travail à distance utilisé. Nous obtenions de meilleurs résultats avec Teams, au détriment de la qualité d’affichage. A l’heure actuelle, il est difficile de réunir le meilleur des deux mondes.

Les outils de développement tiennent de plus en plus compte de ces aspects et l’on peut se féliciter de l’intégration sous Intellij Idea, par exemple, du Remote development, et du plugin de collaboration Code With Me.

Aspects relationnels

L’équipe était relativement homogène. Nous étions majoritairement des développeurs confirmés (voire très expérimentés). Seul l’un d’entre nous débutait en programmation. Quant à moi, j’arrivais sur le projet et le mob a facilité mon intégration et m’a permis d’éviter un certain nombre d’erreurs inhérentes à la prise en main de tout programme de grande ampleur et à l’historique très chargé.

Nos profils étaient d’autre part assez complémentaires : « Craftmanship » pour les uns, bonne connaissance du domaine applicatif ou expertise technique pour les autres.

A l’instar du pair programming, le mob est particulièrement adapté aux débutants car il leur permet, grâce à l’aide des membres plus expérimentés, d’appréhender les bases d’un langage et les concepts fondamentaux d’architecture logicielle. C’est une manière pour eux d’appliquer sur le vif des théories plus ou moins bien assimilées. Quelques séances dans notre équipe ont été consacrées à l’acculturation d’un développeur junior, à l’aide d’exercices concrets, tirés de notre backlog.

La capacité pour chacun d’expliquer clairement ses choix et l’aisance avec laquelle il s’exprime sont des prérequis importants. Un développeur en autarcie peur parfois se reposer sur ses acquis et mettre en jeu des mécanismes inconscients ou des automatismes. Ce n’est pas le cas en « mob ». A moins d’agir sur des parties triviales du code, on doit faire preuve de beaucoup de pédagogie pour faire comprendre à ses collègues les solutions préconisées. Il est nécessaire pour cela que chacun commente ses actions de manière explicite, et ce d’autant plus en télétravail, ou les expressions du visage et la mimique gestuelle ne sont plus de mises. La démarche est à double sens : un présentateur aura l’impression de parler dans le vide si les personnes autour de lui ne réagissent pas ou ne font pas l’effort de participer au débat. C’est un bon moyen d’exercer son esprit analytique et son aptitude à s’exprimer en public, deux compétences dont on manque souvent.

Sur le plan psychologique, on doit être capable de remise en question. Les points de vue contradictoires sont fréquents et les développeurs à l’égo sur-dimensionné n’y trouveront pas leur compte. C’est aussi une formidable opportunité pour améliorer son écoute et mettre un frein à son impulsivité naturelle.

Un déséquilibre peut se produire lorsqu’un membre de l’équipe dispose d’une plus grande réactivité ou d’une meilleure capacité d’analyse. Cela peut engendrer une perte d’autonomie de la part des autres membres et les conduire à se reposer systématiquement sur leur collègue plus expérimenté, notamment lorsqu’il s’agit d’opérer des choix clivants. La dissolution des responsabilités et l’effritement du savoir sont peut-être les deux aspects les plus critiques du Mob.

Afin d’y remédier, il est nécessaire que la prise en main se fasse à parts égales et que les « sachants » se fassent parfois plus diserts afin de laisser le temps aux autres de mieux cerner les difficultés, tout en leur offrant plus d’espace pour exprimer leurs opinions.

Le Mob perd tous son intérêt s’il n’y a pas d’échange entre les protagonistes. S’il n’est pas assez communicatif ou explicite, le présentateur peut très vite retomber dans un exercice solitaire, entraînant les personnes qui l’accompagnent à suivre passivement ses actions à l’écran. Il est nécessaire pour lui d’aiguiller en permanence l’attention de ses collègues en les sollicitant sous forme de questions ou d’observations. Il peut même parfois introduire des erreurs volontaires ou proposer des solutions non conventionnelles pour susciter les réactions de l’auditoire.

D’autre part, il existe bien des manières de résoudre un problème et l’on ne doit pas rejeter les points de vue exotiques. Aborder la question sous un autre angle permet d’y répondre parfois de manière beaucoup plus efficace. A plusieurs, il y a plus de chances justement, compte tenu de la diversité des expériences et des compétences de chacun, de découvrir de nouveaux angles d’attaque.

C’est l’une des principales attentes du Mob : que chacun soit un acteur à part entière et que le résultat soit vraiment le produit de réflexions mises en commun.

Aspects organisationnels

Vu de l’extérieur, la pratique du Mob peut donner l’impression d’une perte de temps, en raison du manque de parallélisme engendré par la mobilisation des ressources sur une tâche unique. C’est d’autant plus flagrant lorsque ces tâches sont visualisées sous forme de Kanban logiciel, dans un tableau Jira par exemple. Il est intéressant de constater que les outils les plus répandus ne proposent pas à l’heure actuelle d’assigner une activité à plusieurs personnes. Pour l’anecdote, lorsque je travaillais sur un logiciel de planning éducatif, je n’avais pas prévu qu’un cours puisse être dispensé par plusieurs professeurs. Ce fut pourtant une demande de la part d’un de nos clients. C’est un peu ici du même ordre d’idée. La représentation du temps, associant une tâche à une personne, est tellement ancrée dans les organisations qu’il est difficile d’envisager une autre mode de fonctionnement et les logiciels censés la modéliser ne font que correspondre à cet état des lieux.

Ce manque de parallélisme est toutefois à nuancer. En Mob, il arrive fréquemment de travailler simultanément sur plusieurs « stories », compte tenu de leur interdépendance. Tout le monde travaillant sur le même sujet, les problèmes de synchronisation ne se posent plus et les développeurs n’ont plus à attendre la fin d’une tâche pour démarrer la suivante. On se débarrasse ainsi des problèmes de gestion de version et des nombreux conflits qui peuvent résulter de la mise en commun des mêmes parties de code. Les choix d’implémentation, les corrections et l’affinage des algorithmes étant traités bien en amont, les revues de code n’ont plus qu’un rôle minime et sont considérés comme une simple formalité. Il nous est arrivé plusieurs fois de terminer en très peu de temps un ensemble de « stories ». En travaillant sur la première, la résolution des suivantes coulait de source et nécessitait beaucoup moins d’efforts que si chacune d’elles avait été traitée indépendamment. Cela entraîne en pratique une accélération du temps de développement mais aussi et surtout une plus grande homogénéité et des résultats de bien meilleure qualité.

Le temps passé sur une tâche ne se résume pas d’autre part au seul temps de développement. Il faut tenir compte de tous les autres temps cumulés : compilation, démarrage des applications, déroulement des tests, allers-retours consécutifs aux Pull Requests (Merge Requests), avancement des pipelines, indisponibilité des services, etc. Il y a fort à parier que la somme de ces temps cumulés, multipliée par le nombre de développeurs soit bien plus importante que celle qui aurait été engendrée par la mise en commun d’une ou plusieurs tâches.

Et n’oublions pas pour finir l’analogie de la « cordée » dans le domaine alpin : en face de tâches rebutantes ou de problèmes complexes on se sent toujours plus fort à plusieurs. Il suffit d’une personne avec un peu plus de courage pour qu’elle influence positivement son entourage et qu’il vienne à bout d’une difficulté, dont il aurait fait sinon une « montagne ».

Conclusion

Mettre le savoir de chacun au service des autres, miser sur la pluralité des points de vue et des compétences sont les points forts incontestables du Mob programming. La démarche que nous avons menée depuis huit mois nous a permis d’en avoir une idée très concrète. Dans les environnement dits « agiles », ce serait paradoxal d’en ignorer les bénéfices. En ces périodes de télétravail, nous ne pouvons qu’encourager les équipes à tenter l’expérience.

Auteur: Jean-Marc GOBAT