INFOTEL VOUS REMERCIE POUR VOTRE CANDIDATURE

Un chargé de recrutement prendra contact avec vous prochainement.

Mob programming

Mob Programming

Conférence DEVOXXFR : retour d’expérience d’Alexandre Victoor et Johan Rouve, deux développeurs de la start-up Fluo sur la pratique du Mob Programming.

CONCEPT :
« Toute l’équipe de développement travaille sur la même chose, au même moment, dans le même espace et sur le même ordinateur. »
Cette méthode se base sur l’extrême programming et le lean management : en complément du développement, l’équipe va se charger du design, des tests, du déploiement et travailler directement avec le client (MOA/PO).

Vous avez sans doute déjà entendu parler du « Pair Programming ». Ce moment où vous vous arrachez les cheveux car vous n’arrivez pas à développer ou contourner un problème et qu’un de vos collègues vient à votre rescousse. Mais avez-vous déjà entendu parler du « Mob Programming » ?

Alexandre Victoor et Johan Rouve ont mis en place le « Mob Programming », une technique inspirée du « Pair Programming », au sein de leur startup.

Dans le « Pair Programming », il existe deux rôles/acteurs : le « driver » qui est la personne aux commandes du clavier et le « navigator », personne guidant le « driver » sur ce qu’il doit coder.

Ce qui est « révolutionnaire » dans le « Mob Programming », c’est le nombre illimité de participants/acteurs. Les rôles restent les mêmes (« driver » et « navigator »), mais le nombre de « navigator » sera égal au nombre total de personnes moins un.

Les développeurs qui vont incarner le rôle de « navigator », vont réfléchir, discuter et décrire les solutions à implémenter. Ensuite, les développeurs vont incarner, chacun à leur tour, le rôle de « driver » qui va consister à rédiger le code sur l’ordinateur.
Le rôle de base du « driver » est d’être une sorte d’interface évoluée capable de comprendre et vérifier ce qu’on va lui dire.

Quels sont les prérequis d’application du « Mob programming » au sein de votre équipe ?

Pour passer en mode « Mob programming » de manière optimale, il est nécessaire de posséder :

  • Au minimum 1 projecteur branché sur l’ordinateur central : toute l’équipe doit bien voir le rendu final
  • Quelques chaises et un espace de travail suffisamment grand
  • Des développeurs disposant chacun d’un PC portable afin de pouvoir effectuer des tests de son côté
  • Un problème

D’où est venue cette idée ?

Les développeurs sont souvent seuls devant leur écran à coder et peuvent rester longtemps sur des points de blocage. Très souvent, les développeurs ne font appel qu’à un(e) de leurs collègues avec lequel/laquelle ils ont des affinités dans l’équipe. Or, il est possible que la personne avec laquelle nous avons des affinités ne soit pas la plus qualifiée quant à la résolution de ce problème particulier. Ce binôme va peut-être perdre son temps, car aucun des deux n’est expert en la matière, ou inspiré quant à la solution du problème. Il se trouve pourtant qu’un autre membre de l’équipe a sûrement déjà rencontré ce souci et/ou sait comment contourner ce genre de problème.

De plus, le stand-up du matin (aussi appelé « Daily ») ne permet pas aux développeurs de comprendre les points de blocages de leurs collègues car les mots ne sont souvent pas suffisants.

La petite histoire…
Alexandre et Johan nous racontent qu’afin de débloquer deux de leurs collègues coincés sur un développement, ils décident un matin d’essayer cette méthode. Cela a tellement bien fonctionné qu’ils ont décidé de ne travailler que de cette façon.
Ils nous avertissent tout de même que cette méthode n’est pas forcément applicable à toutes les équipes et tous les contextes.
Il faut que chaque participant soit dans le même état d’esprit qu’en « Pair Programming », que chacun se sente suffisamment à l’aise et qu’ils soient tous dans une approche de bienveillance, de respect et de considération.
L’équipe doit être capable de se remettre régulièrement en question afin d’améliorer continuellement sa pratique et la rendre la plus efficace possible.

Et la productivité ?

Vous vous demandez sans doute si le fait que toute une équipe soit « mobilisée » autour d’un unique « problème » ne diminuera pas la productivité ?

Il s’avère que non, car toutes les chances de trouver une solution au problème rapidement sont présentes par la convergence de connaissances grâce à la présence de tous les développeurs.

En outre, cette méthodologie de travail permet d’harmoniser les façons de coder en évitant les mauvaises pratiques de code. On gagne donc du temps sur la revue de code.

Retour d’expérience
Le « Mob programming » : on a testé et on continue !

Les bénéfices

  • Meilleure communication : tout le monde a le même niveau d’information.
  • Prise de décision efficace : c’est l’ensemble de l’équipe qui prend les décisions et qui peut en débattre.
  • Travail fini : l’équipe tend plus à aller droit à l’essentiel (mettre en place le meilleur design, effectuer les tests unitaires, …).
  • Réduction de la dette technique : c’est comme si nous faisions du Code Review continuellement.
  • Connaissance partagée : le niveau d’échange est très important que ce soit au niveau des bonnes pratiques, des raccourcis claviers, … Les profils juniors pourront bénéficier de l’expérience des seniors, et inversement, les seniors pourront aussi bénéficier de la connaissance de juniors sur les dernières nouveautés.
    Le niveau de l’ensemble de l’équipe va perpétuellement s’améliorer.

Et il y en a bien d’autres… !

Quelles sont les bonnes pratiques à appliquer dans la méthodologie « Mob programming » ?

  • Faire des pauses régulières afin de permettre à tous d’être au top de leur forme pour réfléchir.
  • « Exprime-toi ou rentre chez toi ! » : ceci force toutes les personnes présentes à intervenir pour exprimer leur idée mais aussi leurs remarques.
  • « J’ai une idée, je lâche le clavier » : permettre au « driver » d’énoncer son idée.
  • Switch entre « navigator » et « driver » : en échangeant les rôles, cela évite de se lasser. Il existe des outils d’aide tel que Mobster, un timer permettant de définir les temps de rotation, de pause, etc. A vous de trouver le bon rythme !
  • Absence de hiérarchie : #TousActeurs.

Par Vanessa S. et Pauline P.