Pair et Mob Programming

1. Définitions

a. Pair-Programming

Le pair-programming est une pratique de développement consistant à avoir deux développeurs collaborant sur la même tâche pour mutualiser leurs réflexions.

b. Mob-Programming

Le mob-programming consiste à avoir plusieurs personnes collaborant pour développer une fonctionnalité.

2. Diverses méthodes d’application

Le pair-programming réparti les deux développeurs en deux rôles distincts :

– Le Conducteur, qui a les mains sur le clavier et écrit le code
– Le Navigateur, qui donne les directives et indique quelle est la prochaine étape à développer

Les développeurs doivent échanger leurs rôles régulièrement afin de ne pas tomber dans une routine qui induirait de la lassitude et un décrochement.

Le mob-programming possède également ces deux rôles mais contient également celui de Mobber. Ce rôle consiste à apporter les idées. Lorsque la session de mob-programming comporte plus de 3 personnes, tous ceux qui ne sont pas Conducteur ou Navigateur sont Mobber.

Les Mobbers discutent entre eux des idées d’implémentations et proposent leurs avis au Navigateur qui prend la décision finale sur ce que doit écrire le Conducteur.

Il existe plusieurs méthodes pour le roulement des rôles en mob-programming.

Les plus fréquemment utilisés sont :

– Un roulement cyclique basé sur un timer, toutes les 5 ou 10 minutes (durée ajustable en fonction de l’envie de l’équipe) les rôles changent. Le Conducteur devient Mobber, le Navigateur devient Conducteur et un Mobber devient Navigateur.

Dans cette configuration, il est important que tous les membres de l’équipe effectuent chaque rôle dans un temps raisonnable.

– Le « fishbowl », il n’y a pas de roulement fixe mais n’importe qui peut décider à tout moment de changer de rôle. Si un Mobber veut prendre le rôle de Conducteur, le Conducteur actuel doit se retirer de sa position et laisser la place. De même, si le Conducteur ou Navigateur souhaite arrêter de tenir ce rôle, il peut rejoindre les Mobbers et quelqu’un d’autre doit prendre la place.

Dans ce format, il est important que les rôles tournent régulièrement entre les différentes personnes. Il ne faut pas que seules deux personnes se relaient sur un même rôle.

3. Précision de la navigation

Il existe plusieurs niveaux d’indications que le Navigateur peut donner au Conducteur :

– Indications générales

Cela représente des instructions globales au Conducteur telles que « Ecrit un test pour ce cas de figure » ou « Refactorise cette méthode » en lui laissant le choix de l’implémentation sous la surveillance du Navigateur.

– Lignes de conduites

Cela représente des instructions plus précises de la part du Navigateur telles que « Crée une boucle pour itérer sur cette liste » ou « Récupère cette donnée depuis tel objet »

– Instructions détaillées

Cela revient quasiment à ce que le Navigateur dicte au Conducteur ce qu’il doit écrire et à quel endroit dans le code. Le conducteur a alors pour charge de demander des précisions sur les raisons d’une telle implémentation au Navigateur s’il en ressent le besoin.

4. Avantages et inconvénients

Ces méthodes possèdent de nombreux avantages, tels que :

– Assure que les différentes personnes sont au même niveau d’information et de compréhension

– Permet de monter en compétence des personnes récemment arrivées sur le projet

– Réduit le temps passé sur la revue de code puisqu’il a été développé en collaboration

– Obtenir un code de meilleure qualité grâce aux interactions et discussions engendrées

– Réduit le temps de passation de connaissance en cas d’absence

Néanmoins, il existe quelques inconvénients à ces méthodes, tels que :

– L’entente entre les différentes personnes peut aboutir à des conflits

– Lors de pair-programming, si l’un des deux membres du binôme souhaite prendre une pause, le binôme entier doit s’arrêter. Cela n’est pas le cas lors d’un mob.