Mob Pro­gram­ming : dé­ve­lop­pe­ment de logiciels en équipe

Le mob pro­gram­ming (pro­gram­ma­tion en groupe) est une forme re­la­ti­ve­ment récente de dé­ve­lop­pe­ment de logiciels qui met l’accent sur le travail d’équipe, avec plusieurs dé­ve­lop­peurs col­la­bo­rant sur un même produit final.

Le mob pro­gram­ming est une méthode de dé­ve­lop­pe­ment de logiciels re­la­ti­ve­ment récente, qui met avant tout l’accent sur le travail en équipe avec une or­ga­ni­sa­tion bien spé­ci­fique. Il s’inspire du dé­ve­lop­pe­ment agile de logiciels et vise à supprimer les struc­tures hié­rar­chiques, qui nuisent le plus souvent à la rapidité et à l’ef­fi­ca­cité des prises de décision. L’im­por­tance accordée au travail d’équipe est également calquée sur d’autres méthodes agiles de dé­ve­lop­pe­ment de logiciels.

L’approche col­la­bo­ra­tive qui ca­rac­té­rise le mob pro­gram­ming peut également être in­ter­pré­tée comme une évolution du pair pro­gram­ming. Dans le cadre de cette méthode, les dé­ve­lop­peurs tra­vail­lent en binôme sur un logiciel, en ap­pli­ca­tion du principe « Deux cerveaux valent mieux qu’un », alors qu’une équipe de mob pro­gram­ming peut compter cinq à dix dé­ve­lop­peurs.

Mais le mob pro­gram­ming présente encore bien d’autres par­ti­cu­la­ri­tés qui le dis­tin­guent du tra­di­tion­nel travail en équipe : au lieu de tra­vail­ler de manière si­mul­ta­née sur plusieurs or­di­na­teurs en utilisant des outils de col­la­bo­ra­tion bien connus du monde in­for­ma­tique, tels que GitHub, les équipes de mob pro­gram­ming ne se basent que sur un seul terminal en projetant le plus souvent son écran sur un mur à l’aide d’un pro­jec­teur, pour que tout le monde puisse le voir. Les com­po­sants de l’ensemble du système ne sont pas non plus répartis entre les dif­fé­rents dé­ve­lop­peurs, même si ceux-ci peuvent avoir leurs propres spé­cia­li­tés.

Dans le cas du mob pro­gram­ming, tous les membres de l’équipe tra­vail­lent si­mul­ta­né­ment sur le même code. De la même manière, les dé­ve­lop­peurs dans leur ensemble prennent part à l’éla­bo­ra­tion du cahier des charges, aux tests et au dé­ploie­ment du logiciel.

Pour mieux struc­tu­rer le travail de ces équipes, chaque membre se voit attribuer un rôle spé­ci­fique au début de chaque phase de mob pro­gram­ming. Les rôles en question ne sont toutefois pas figés, bien au contraire : après un certain laps de temps (gé­né­ra­le­men 15 ou 30 minutes), ils sont re­dis­tri­bués. Chaque équipe est donc composée d’un con­duc­teur (« driver ») et de plusieurs na­vi­ga­teurs (« na­vi­ga­tors ») :

• Con­duc­teur : la personne qui finit par taper le code est le con­duc­teur. C’est elle qui con­cré­tise les idées et les concepts imaginés en équipe.
• Na­vi­ga­teurs : les autres membres de l’équipe sont des na­vi­ga­teurs, chargés de col­la­bo­rer pour dé­ve­lop­per leurs idées.

En fonction de la stratégie de mob pro­gram­ming choisie, les na­vi­ga­teurs peuvent également se partager d’autres rôles :

Le « na­vi­ga­teur dédié » structure les pistes et les idées de ses coé­qui­piers et joue le rôle d’arbitre en cas de di­ver­gences d’opinions, de manière à ce que le con­duc­teur 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 « chro­no­mé­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 « cher­cheurs ». À la moindre ambigüité ou in­cer­ti­tude, ils ef­fec­tuent les re­cherches né­ces­saires et re­cueil­lent des in­for­ma­tions 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é­ve­lop­pe­ment ; celles-ci se con­ten­tent d’observer le processus dans son ensemble et de poser des questions si certains points leur semblent obscurs. Il s’agit des « ap­pre­nants ».

Il n’existe aucune véritable pres­crip­tion quant à l’or­ga­ni­sa­tion concrète du mob pro­gram­ming. Les règles dépendent plutôt des objectifs associés au dé­ve­lop­pe­ment du logiciel concerné et de la dynamique de chaque équipe. Néanmoins, le respect de certaines lignes di­rec­trices peut con­tri­buer au bon dé­rou­le­ment d’une session de mob pro­gram­ming.

Il est donc conseillé d’utiliser un grand écran commun ou un pro­jec­teur pour afficher l’interface de travail du con­duc­teur, afin que les autres membres de l’équipe puissent suivre l’évolution du code. Dans le cadre du mob pro­gram­ming, la proximité géo­gra­phique a également son im­por­tance : idéa­le­ment, toute l’équipe de pro­gram­ma­tion doit tra­vail­ler dans une seule et même pièce. Il s’agit en effet de la meilleure solution pour des échanges à la fois directs et per­son­nels.

Il est également essentiel d’attribuer des rôles aux membres de l’équipe pour réussir une session de mob pro­gram­ming. Il est donc in­dis­pen­sable de désigner le « chro­no­mé­treur » à l’origine de la rotation des rôles pour tirer parti de tous les avantages du mob pro­gram­ming. Plus la ré­par­ti­tion change au niveau de certains rôles et plus l’équipe est sus­cep­tible de bé­né­fi­cier cons­tam­ment de nouveaux éléments.

L’approche relative au mob pro­gram­ming présente de nombreux avantages. Les dif­fé­rents partages d’ex­pé­rience entre les membres de l’équipe per­met­tent de créer des logiciels de façon créative et ciblée. Les dé­ve­lop­peurs peuvent également tirer profit des com­pé­tences des autres pro­gram­meurs pour élargir leurs propres horizons. À cet égard, le mob pro­gram­ming est donc parfait pour donner l’occasion aux nouveaux col­la­bo­ra­teurs de se fa­mi­lia­ri­ser pro­gres­si­ve­ment avec les projets. Imaginé à cet effet, le rôle de l’« apprenant » fait d’ailleurs partie in­té­grante de ce modèle de dé­ve­lop­pe­ment de logiciels.

Le mob pro­gram­ming est aussi un bon moyen de partager les res­pon­sa­bi­li­tés qui vont de pair avec le dé­ve­lop­pe­ment de logiciels et de relâcher quelque peu la pression qui pèse ha­bi­tuel­le­ment sur les épaules des dé­ve­lop­peurs in­di­vi­duels. Un code élaboré de manière commune est gé­né­ra­le­ment moins sujet aux erreurs et de meilleure qualité ; les tests réalisés en équipe con­tri­buent aussi à garantir celle-ci. Comme toute une équipe travaille si­mul­ta­né­ment sur le même code, sa qualité s’en trouve forcément améliorée, car les erreurs qui sur­vien­nent nor­ma­le­ment lors de l’in­té­gra­tion des dif­fé­rents com­po­sants logiciels dé­ve­lop­pés sé­pa­ré­ment n’ont plus lieu d’être.

Toutefois, le mob pro­gram­ming présente également quelques in­con­vé­nients, notamment les in­ves­tis­se­ments con­si­dé­rables en termes de temps et de personnel né­ces­saires pour cette approche agile. L’arbitrage entre dif­fé­rentes opinions peut également s’avérer pro­blé­ma­tique lorsqu’une équipe cherche à pro­gram­mer un code cohérent. Il convient également de noter que le mob pro­gram­ming est moins efficace lorsque les membres d’une même équipe com­mu­ni­quent à distance. Si certaines approches proposent des sessions de mob pro­gram­ming en ligne, la forme tra­di­tion­nelle de cette méthode repose toutefois sur la pos­si­bi­lité d’un échange à la fois direct et personnel.