Rex sur le « Mob programming », le développement en équipe par l’équipe
Je vais vous faire part d’un retour d’expérience que j’ai eu dans un projet informatique chez un client leader européen : l’organisation de travail en « Mob programming ». Dans cet article, je vous présente le contexte projet, le « Mob programming » en tant que tel, son organisation et ses bénéfices.
Pour les anciens, rien à voir avec la « mob », deux-roues à moteur deux temps, le « Mob programming », mot tiré de l’anglais « mob » qui signifie « foule », s’articule en une organisation de travail de développement informatique en équipe, sur un seul poste. Il peut s’apparenter à une extension du « pair programming ».
Pour le décrire en quelques mots plus précisément : Le « Mob programming » est une organisation en équipe sur du développement logiciel. L’ensemble de l’équipe travaille sur la même tâche, au même moment, sur le même poste. Chaque développeur va, à tour de rôle, réaliser le développement sur la machine partagée, avec l’écran visible par tous.
Contexte projet
L’ensemble de l’équipe agile du projet informatique devait réaliser une tâche importante : migrer l’ancienne base de données vers une nouvelle. Toutes les données et les requêtes de la base de données devaient être migrées, testées et validées pour pouvoir les déployer en production.
Dans l’équipe de développement, le contexte était tel que les connaissances techniques pour chaque domaine du projet étaient essentiellement concentrées par un membre spécifique. Chaque membre de l’équipe développement étant expert de son propre domaine sur le projet, nous devions alors trouver une solution pour monter en compétences sur les connaissances fonctionnelles et techniques du projet pour réaliser cet objectif.
Le « Mob programming » nous convenait bien car nous sommes une équipe de 6 développeurs / tech-lead. Il a été choisi pour nous permettre de travailler ensemble, dans le but de produire vite, propre, tout en nous permettant de monter en compétences sur les fonctionnalités du projet.
Organisation pour être en mode « Mob programming »
Il y a eu deux grands moments de travail en mode « Mob Programming » : le nettoyage du code du projet, suivi du début de la migration des requêtes.
Ces deux grands sujets, la tâche de nettoyage et la tâche de migration, avaient été analysées précédemment par les tech-leads, et divisées en sous tâches. Notre travail consistait alors à gérer ces sous tâches définies, et potentiellement, celles qui n’avaient pas été remarquées.
D’un point de vue organisationnel, comme nous devions travailler ensemble sur un seul poste, le contexte sanitaire nous a permis de télé-travailler et de partager facilement notre écran. Nous n’avions pas besoin de réserver une salle avec des équipements spécifiques. Seule, notre connexion à internet était suffisante.
Nous nous étions mis d’accord aussi sur un planning hebdomadaire. Sachant que les autres tâches de chacun devaient aussi continuer, le planning devait nous permettre d’être au moins à 50% en mode « Mod programming », tout en assurant les autres tâches liées à notre travail.
Le « Mob programming »
Lorsque nous travaillions sur une tâche, un seul membre de l’équipe partageait son écran et réalisait le développement souhaité. Les autres membres étaient en mode observateur/interlocuteur. Nous échangions nos réflexions, nos questions et nos points de vue. Les discussions étaient souvent très animées par notre lead-tech, qui avait un côté très pédagogue, et aussi, très certainement, un côté très posé.
Le transfert de connaissances techniques et fonctionnelles du projet s’opérait à ce moment-là. Le code était ainsi modifié et validé par l’ensemble de l’équipe. Il respectait ainsi toutes les règles qualité de développement, et il était directement commité puis automatiquement déployé sur un environnement de tests destiné à l’équipe QA.
Nous étions développeurs et observateurs/interlocuteurs simultanément. Pour être honnête, je trouve que le moment où j’étais en mode observateur/interlocuteur était plus facile cognitivement. Les solutions techniques m’arrivaient plus rapidement et facilement, je comprenais plus facilement les fonctionnalités impactées, que lorsque je devais partager mon écran et produire en même temps la réflexion et le développement.
Nous avons réalisé l’intégralité du travail de nettoyage en mode « Mob programming ». Cela nous a permis de bien rentrer dans le vif du sujet pour supprimer le code mort, tout en commençant à monter en compétences sur les fonctionnalités du projet.
Ensuite, nous avons commencé, toujours en mode « Mob Programming », le développement de la migration vers la nouvelle base de données. Le contexte étant différent de celui du nettoyage, nous devions nous mettre d’accord sur les différents aspects du développement afin de créer des sortes de routines de code, fiables et acceptées par tous, tout en montant en compétences sur les différentes fonctionnalités que nous voyions ensemble.
Nous avons travaillé en « Mob Programming » pendant environ 1 mois et demi ; ensuite nous nous sommes mis d’accord pour modifier notre organisation et travailler de manière plus autonome, tout en continuant de communiquer via un outil collaboratif, et surtout partager notre travail grâce aux Pull Requests.
Bénéfices du mode « Mob programming »
En conclusion, je trouve que le travail en « Mob programming » est très efficace pour produire un code propre, accepté par l’ensemble de l’équipe de développement, commité de suite et poussé pour être pris en compte par la chaîne de déploiement continu. Nous avons également utilisé cette organisation pour assurer une montée efficace en compétences fonctionnelles et techniques sur le projet individuellement.
Nous avons aussi la chance d’être peu nombreux dans l’équipe de développement. Nous sommes 6 ; cette méthode me semble idéale pour ce nombre. Chaque membre pouvait ainsi s’exprimer facilement et donner son point de vue. Je pense que cette organisation demande à chacun d’être respectueux et une communication sereine afin de réaliser des choix collégiaux et acceptés par tous.
Comme tout projet en production, il nous arrivait d’être sollicité individuellement, sur des sujets de priorités hautes, de problèmes à résoudre rapidement, pendant cette période de « Mob programming ». Parfois nous n’étions pas au complet pendant les sessions. Ainsi, cette organisation requiert, de la part de chacun de l’équipe, une forte disponibilité.
Et enfin, je trouve que cette organisation, en plus de pouvoir produire du code propre, nous a permis de se connaitre un peu plus humainement ; de voir aussi comment chacun réfléchit et travaille. Je trouve que, dans cette période sanitaire peu idéale, cette organisation nous a permis de nous souder autour du projet.
