Mob Programming, une pratique agile ?

Coach agile en permanence à la recherche de la meilleure manière de faire, nous allons aborder ici l’une des dernières méthodes à la mode en terme de programmation collaborative dans un contexte agile : Le mob programming !

De l’anglais “mob” qui signifie foule, le Mob Programming se traduit littéralement par la programmation en groupe. Ces derniers mois, il a souvent été présenté comme le petit nouveau du monde de l’agilité.
Pour le décrire en quelques mots, l’idée de base du Mob Programming est de faire travailler toute une équipe sur une seule tâche. Les développeurs vont, à tour de rôle, coder sur une seule machine avec un écran visible par tous. Un genre de pair-programming++, ou encore un full-team pair-programming.

Genèse du concept

La notion de Mob Programming a été créée par Roy Zuill (a.k.a. Woody) et son équipe. Woody est un coach agile, un manager, et un développeur depuis près de 30ans. Il est le porte-parole de cette méthodologie. Il administre le site officiel du Mob Programming, et anime aussi des présentations comme celle réalisée en Suède que je vous invite fortement à regarder :

Woody explique que cette méthode s’est imposée progressivement. Dans un premier temps l’équipe travaillait de manière plus classique, chacun à son poste. Puis, comme dans de nombreux projets, le besoin de se réunir en équipe dans une salle de réunion s’est fait ressentir lors de problèmes complexes, touchant le cœur du projet et nécessitant les connaissances de l’ensemble des membres de l’équipe.
Woody, passionné d’agilité, a donc organisé des Coding Dojo en y ajoutant des notions de la méthode de pair-programming “Driver/Navigator”. L’équipe a alors immédiatement réalisé la puissance de cet embryon de Mob Programming et pris l’habitude d’en réaliser régulièrement. Ainsi, une réalité s’est imposée : non seulement les développeurs appréciaient d’avantage leurs journées, mais en plus, le nombre de tâches réalisées (et donc leur productivité) était significativement amélioré.

La mise en pratique

Voici quelques conseils donnés par Woody pour une mise en pratique optimale :
Un seul ordinateur est utilisé pour la programmation de la solution. Cependant, chaque développeur doit aussi avoir son propre laptop pour pouvoir effectuer des tâches en parallèle de la programmation. En effet, on doit pouvoir avoir, par exemple, plusieurs personnes en train de rechercher la meilleure solution en même temps.
Un ou deux projecteurs doivent être installés sur l’ordinateur central. Il est important pour l’équipe d’avoir des outils de qualité. Les écrans doivent être facilement visibles par tous et doivent avoir une bonne résolution.
La zone de travail doit être assez grande pour que tout le monde soit confortablement installé. Tout le monde doit pouvoir se trouver en face des écrans.Des personnes comme le product owner, ou un DBA doivent pouvoir se greffer à l’équipe, il est donc important que ces personnes aient la place de s’installer.

Plusieurs jeux de clavier/souris doivent pouvoir être installés. Inutile de forcer des développeurs à utiliser un clavier sur lequel ils ne sont pas à l’aise. Pensez aussi à prendre des lingettes antibactériennes et/ou des gels pour les mains.

Utilisez le style Driver/Navigators. Ce style est inspiré de la méthode de pair-programming introduite par Llewellyn Falco. Concrètement, des développeurs vont incarner le rôle de “navigateur”, qui va consister à réfléchir, discuter et décrire des solutions. Ensuite, les développeurs vont incarner, chacun à leurs tours, le rôle de “conducteur” qui va consister à rédiger le code sur l’ordinateur. Dans d’autres termes, le code va passer du cerveau à la bouche des navigateurs, puis passer des oreilles aux mains du conducteur.
Bien qu’il puisse participer aux conversations, le rôle de base du conducteur est d’être une sorte d’interface évoluée capable de comprendre et vérifier ce qu’on va lui dire. Si le conducteur n’est pas très expérimenté, le reste de l’équipe va pouvoir le guider et lui apprendre très rapidement à être efficace.
Effectuez des rotations. À vous de trouver le bon rythme, mais contrairement à certaines méthodes de pair-programming, Woody préconise des cycles très courts. Son équipe, par exemple, change de conducteur toutes les 15 minutes.
Répondez aux mails et aux appels téléphoniques ensemble. Mettez le téléphone en haut-parleur, en précisant que toute l’équipe écoute. Rédigez vos mails ensemble, en signant de la part de toute l’équipe.

Analyse du concept

Le Mob Programming se base sur le fait qu’un développeur passe plus de temps à réfléchir, conceptualiser et communiquer avec son équipe qu’à écrire du code. Il est évident que si vous calculez l’efficacité d’une équipe par le nombre de lignes codées par minutes, le Mob Programming ne va pas vous sembler très avantageux. Ceci étant dit, comment expliquer qu’en faisant du Mob Programming une équipe peut être plus productive ?
Voici trois axes de réponse :

[new_royalslider id=”13″]

1.Une équipe sur une seule tâche:

• Dans des processus classiques, il arrive qu’un développeur passe plusieurs jours sur une tâche avant qu’on ne se rende compte que ça ne correspondait pas à ce qu’il fallait. Ce genre d’erreur de compréhension peut avoir des effets dramatiques. Il s’agit d’une des problématiques les plus ciblées par les méthodes agiles.
• Dans le Mob Programming, les erreurs de compréhension entre les membres internes de l’équipe sont nulles. En effet, à la moindre dérive c’est l’ensemble de l’équipe qui va pouvoir remettre le développement dans la bonne direction. De même, le product-owner est invité à participer aux séances de développement. Ainsi, lorsqu’il établit des scénarios, tous les membres de l’équipe vont les analyser. A la moindre imprécision ou ambiguïté l’équipe va toujours chercher à comprendre clairement ce qui est attendu.
• Une des plus grandes forces du Mob Programming est le « continuous learning ». Tout d’abord, un nouveau membre sera directement intégré au développement. Il pourra apprendre très naturellement avec beaucoup d’explication orale. Ensuite, les profils juniors vont pouvoir énormément profiter des connaissances techniques des profils seniors, alors qu’inversement, les profils juniors n’hésiteront pas à parler des dernières nouveautés à la mode. Le niveau d’échange est très important, que ce soit vis à vis de bonne pratique, ou même de raccourcis clavier ou autres fonctionnalités des outils utilisés. Le niveau de l’ensemble de l’équipe va perpétuellement s’améliorer.
• Pour finir, comme l’ensemble des programmeurs travaille sur l’intégralité de la solution, il est inutile de préciser que le bus factor est très important.

2.Une équipe soudée face à son environnement:

• S’il y a des problèmes liés à l’environnement externe, comme par exemple du bruit, c’est toute l’équipe qui sera mobilisée pour remédier au problème, et non juste un seul développeur qui se sera retrouvé dans le mauvais bureau. De plus, si toute l’équipe est interrompue, au moins un des membres de l’équipe se souviendra précisément où l’équipe s’était arrêtée, et elle pourra donc rapidement reprendre où elle s’était arrêtée.
• Il sera plus facile pour l’équipe de faire avancer son avis sur des questions fonctionnelles, comme par exemple supprimer des fonctionnalités pour aller à l’essentiel. Face aux product-owners, ou aux supérieurs, toute l’équipe pourra argumenter sur ce qu’elle estime être la meilleure chose à faire.

3.L’équipe avant l’individu:

• En informatique, il n’est pas rare de voir des développeurs qui arrivent à bien se vendre sans pour autant être très compétent. Lorsque l’on fait du Mob Programming on est exposé, on ne peut plus mentir sur ses capacités. À l’inverse, une personne beaucoup plus modeste sur ses capacités pourra être reconnue à sa juste valeur.
• Le fait de travailler en équipe, et de faire l’équivalent d’un code review permanent, va largement augmenter la qualité du code de la solution. Chaque décision aura été réfléchie et discutée.
• Enfin, contrairement à des méthodologies plus classiques où un développeur s’attacherait uniquement à sa partie, ici tout le monde travaille pour l’ensemble de la solution. Il n’y aura donc pas de place pour la politique, chaque développeur va faire de se son mieux pour que la solution soit complète.

Critique du concept

Comme toutes méthodes, il faut déterminer les points forts, mais aussi les points faibles. Le Mob Programming ne peut s’appliquer que dans certains environnements. Voici quelques éléments auxquels il est important de faire attention :

• Cette méthodologie n’a de sens que si la qualité du code est la priorité principale. Si vous essayez de mettre en place une équipe qui fait du Mob Programming, mais que vous laissez de côté les principes essentiels de l’agilité vous ne vous en sortirez jamais.
• Il faut des moyens pour pouvoir la mettre en place. Une entreprise pourrait avoir à investir dans des projecteurs et des laptops pour que la mise en pratique soit la plus optimale possible. Dans tous les cas, il vous faudra au moins l’espace pour le faire.
• Réunissez les bonnes personnes. Le fait de devoir travailler en permanence avec les autres nécessite évidemment une bonne entente entre tous les membres. Soyez attentif aux relations entre chaque personne et aux personnes qui pourraient être trop introverties.

Pour conclure

L’important est de savoir quand cette méthodologie sera particulièrement adaptée et quand il faudra l’éviter. De plus, il faudra que l’équipe se remette régulièrement en question pour avoir sa propre façon de faire du Mob Programming. À vous de déterminer le nombre de personne optimal, à vous de déterminer le temps entre chaque rotation, etc.
Si cette méthodologie vous intéresse, pourquoi ne pas faire comme Woody et son équipe à leurs débuts : donnez-vous les moyens pour réaliser des petites sessions d’une heure ou deux quand cela vous semble adapté.