Mob Programming : développement de logiciels en équipe

Le mob programming (programmation en groupe) est une forme relativement récente de développement de logiciels qui met l’accent sur le travail d’équipe, avec plusieurs développeurs collaborant sur un même produit final.

Le mob programming est une méthode de développement de logiciels relativement récente, qui met avant tout l’accent sur le travail en équipe avec une organisation bien spécifique. Il s’inspire du développement agile de logiciels et vise à supprimer les structures hiérarchiques, qui nuisent le plus souvent à la rapidité et à l’efficacité des prises de décision. L’importance accordée au travail d’équipe est également calquée sur d’autres méthodes agiles de développement de logiciels.

L’approche collaborative qui caractérise le mob programming peut également être interprétée comme une évolution du pair programming. Dans le cadre de cette méthode, les développeurs travaillent en binôme sur un logiciel, en application du principe « Deux cerveaux valent mieux qu’un », alors qu’une équipe de mob programming peut compter cinq à dix développeurs.

Mais le mob programming présente encore bien d’autres particularités qui le distinguent du traditionnel travail en équipe : au lieu de travailler de manière simultanée sur plusieurs ordinateurs en utilisant des outils de collaboration bien connus du monde informatique, tels que GitHub, les équipes de mob programming ne se basent que sur un seul terminal en projetant le plus souvent son écran sur un mur à l’aide d’un projecteur, pour que tout le monde puisse le voir. Les composants de l’ensemble du système ne sont pas non plus répartis entre les différents développeurs, même si ceux-ci peuvent avoir leurs propres spécialités.

Dans le cas du mob programming, tous les membres de l’équipe travaillent simultanément sur le même code. De la même manière, les développeurs dans leur ensemble prennent part à l’élaboration du cahier des charges, aux tests et au déploiement du logiciel.

Pour mieux structurer le travail de ces équipes, chaque membre se voit attribuer un rôle spécifique au début de chaque phase de mob programming. Les rôles en question ne sont toutefois pas figés, bien au contraire : après un certain laps de temps (généralemen 15 ou 30 minutes), ils sont redistribués. Chaque équipe est donc composée d’un conducteur (« driver ») et de plusieurs navigateurs (« navigators ») :

• Conducteur : la personne qui finit par taper le code est le conducteur. C’est elle qui concrétise les idées et les concepts imaginés en équipe.
• Navigateurs : les autres membres de l’équipe sont des navigateurs, chargés de collaborer pour développer leurs idées.

En fonction de la stratégie de mob programming choisie, les navigateurs peuvent également se partager d’autres rôles :

Le « navigateur dédié » structure les pistes et les idées de ses coéquipiers et joue le rôle d’arbitre en cas de divergences d’opinions, de manière à ce que le conducteur n’ait pas à faire son choix parmi plusieurs solutions de mise en œuvre. Dans le même temps, il fait très souvent office de « chronométreur » et garantit la bonne rotation des rôles au sein de l’équipe à la fin du laps de temps déterminé.

Les membres de l’équipe peuvent également être des « chercheurs ». À la moindre ambigüité ou incertitude, ils effectuent les recherches nécessaires et recueillent des informations utiles à l’ensemble de l’équipe. Toute équipe peut également être composée de personnes n’ayant rien de concret à apporter à la phase de développement ; celles-ci se contentent d’observer le processus dans son ensemble et de poser des questions si certains points leur semblent obscurs. Il s’agit des « apprenants ».

Il n’existe aucune véritable prescription quant à l’organisation concrète du mob programming. Les règles dépendent plutôt des objectifs associés au développement du logiciel concerné et de la dynamique de chaque équipe. Néanmoins, le respect de certaines lignes directrices peut contribuer au bon déroulement d’une session de mob programming.

Il est donc conseillé d’utiliser un grand écran commun ou un projecteur pour afficher l’interface de travail du conducteur, afin que les autres membres de l’équipe puissent suivre l’évolution du code. Dans le cadre du mob programming, la proximité géographique a également son importance : idéalement, toute l’équipe de programmation doit travailler dans une seule et même pièce. Il s’agit en effet de la meilleure solution pour des échanges à la fois directs et personnels.

Il est également essentiel d’attribuer des rôles aux membres de l’équipe pour réussir une session de mob programming. Il est donc indispensable de désigner le « chronométreur » à l’origine de la rotation des rôles pour tirer parti de tous les avantages du mob programming. Plus la répartition change au niveau de certains rôles et plus l’équipe est susceptible de bénéficier constamment de nouveaux éléments.

L’approche relative au mob programming présente de nombreux avantages. Les différents partages d’expérience entre les membres de l’équipe permettent de créer des logiciels de façon créative et ciblée. Les développeurs peuvent également tirer profit des compétences des autres programmeurs pour élargir leurs propres horizons. À cet égard, le mob programming est donc parfait pour donner l’occasion aux nouveaux collaborateurs de se familiariser progressivement avec les projets. Imaginé à cet effet, le rôle de l’« apprenant » fait d’ailleurs partie intégrante de ce modèle de développement de logiciels.

Le mob programming est aussi un bon moyen de partager les responsabilités qui vont de pair avec le développement de logiciels et de relâcher quelque peu la pression qui pèse habituellement sur les épaules des développeurs individuels. Un code élaboré de manière commune est généralement moins sujet aux erreurs et de meilleure qualité ; les tests réalisés en équipe contribuent aussi à garantir celle-ci. Comme toute une équipe travaille simultanément sur le même code, sa qualité s’en trouve forcément améliorée, car les erreurs qui surviennent normalement lors de l’intégration des différents composants logiciels développés séparément n’ont plus lieu d’être.

Toutefois, le mob programming présente également quelques inconvénients, notamment les investissements considérables en termes de temps et de personnel nécessaires pour cette approche agile. L’arbitrage entre différentes opinions peut également s’avérer problématique lorsqu’une équipe cherche à programmer un code cohérent. Il convient également de noter que le mob programming est moins efficace lorsque les membres d’une même équipe communiquent à distance. Si certaines approches proposent des sessions de mob programming en ligne, la forme traditionnelle de cette méthode repose toutefois sur la possibilité d’un échange à la fois direct et personnel.