Programmation en binôme : l’expérience de Michelin

Ne fonctionner ainsi qu’à temps partiel ? Intervertir les rôles au cours de la journée ? Conserver le même partenaire plusieurs jours de suite ? Dans le domaine de la programmation en binôme, tout n’est pas encore gravé dans le marbre chez Michelin. En tout chez l’une des équipes basées au siège américain.

Cette dernière est récemment revenue sur les expérimentations qu’elles a menées en la matière, dans le cadre d’une démarche de modernisation applicative. Avec l’appui d’une société tierce, un binômage a été mis en place pour une durée de 16 semaines. Il a impliqué, au total, 8 ingénieurs, 2 product managers, 2 designers et 2 architectes.

Chaque binôme d’ingénieurs comprend un « pilote » et un « navigateur ». Le premier écrit le code et les tests. Le second fait office de guide-correcteur. Ils peuvent, en cas de désaccord, faire appel à un tiers (« ancre »), qu’il s’agisse d’un architecte ou d’un autre ingé.

Michelin a opté pour une rotation régulière des binômes – généralement tous les jours. L’idée était que les ingénieurs puissent se familiariser avec l’ensemble de l’application. La « mise en relation » se faisait après le débrief du matin, par l’intermédiaire d’un outil spécialisé : Parrit , puisant notamment dans les historiques Jira.

Microsoft Teams, pas pleinement satisfaisant

Au chapitre outils, le tableau blanc Miro a été choisi sur la partie design ; la stack Git + Hugo, pour la documentation d’architecture. Des modules de développement collaboratif tels que Code With Me et Visual Studio Live Share ont aussi été mis à contribution.

Reflet de l’empreinte des solutions Microsoft chez Michelin, Teams a constitué le centre névralgique de collaboration. Mais il a, pendant un temps, cohabité avec Zoom.

Le schéma initial était le suivant : une réunion « globale » et plusieurs breakout rooms (salles pour petits groupes). Un problème s’est néanmoins présenté : le nombre limité de gestionnaires de salles (une seule personne à la fois peut gérer les rooms liées à une réunion). Cela a compliqué, en particulier, la mise en œuvre de l’assistance entre binômes, fondée sur le basculement entre salles. On s’est donc rabattu sur la version web de Zoom. Jusqu’à finalement trouver une solution, fondée sur le principe d’un canal par binôme.

Upskilling… et fatigue

Comme attendu, le modèle a permis d’améliorer la « connaissance d’ensemble » de l’application. Il a bénéficié tout particulièrement aux ingénieurs front-end, qui ont pu prendre en main le back-end. La démarche a d’autant mieux fonctionné que l’équipe comptait plusieurs nouveaux.

La qualité du code s’en est aussi trouvée renforcée – a fortiori lorsque chaque membre au sein d’un binôme avait son rôle bien défini. Le flux d’information et la dynamique d’équipe aussi, accompagnant le ruissellement du modèle DevOps.

Une fois toute l’équipe montée en compétence sur l’ensemble de l’app, il faudra réévaluer l’intérêt de la programmation en binôme, reconnaît-on chez Michelin. Ne serait-ce qu’au regard de la fatigue engendrée. On parle là autant de la charge mentale à l’amorçage que du décalage horaire (deux personnes basées hors USA) et de l’empreinte des réunions dans l’emploi du temps (jusqu’à la décision de les caler exclusivement en début et en fin de journée).

Travailler en tandem induit par ailleurs une forme de restriction des tâches individuelles. Certains participants à l’expérimentation ont fait remarquer qu’ils auraient apprécié d’avoir davantage de temps « à eux » pour réviser le code, se documenter… L’un d’entre eux a même quitté l’entreprise avant la fin des 16 semaines. Nouveau dans l’équipe, il avait besoin d’acquérir certaines compétences en back-end. Le travail d’apprentissage en duo l’a mis mal à l’aise, explique Michelin. Qui souligne aussi la difficulté à maintenir l’équilibre au sein des binômes, les « dynamiques de pouvoir » prenant parfois le dessus.

Illustration principale générée par IA