Introduction au Mob Programming chez PMSIPilot

Le Mob Programming est une technique de travail qui propose de développer une feature en équipe à la manière d’un pair-programming démultiplié !

Concrètement toute l’équipe se retrouve autour d’un PC avec vidéo-projecteur et chacun a tour de rôle sera chargé de coder en étant guidé par les réflexions de l’équipe.

Ainsi l’ensemble des avis peuvent être entendus et débattus au fur et a mesure que la feature prend forme (validation d’un pattern, d’une librairie , d’une interface, …).
On évite donc les allers-retours autour d’un développement et les risques d’effets tunnels.

Je ne rentrerai pas plus dans les détails de l’organisation et je préfère vous rediriger vers ce très bon article http://blog.soat.fr/2014/05/le-mob-programming-presentation/.

Mise en place dans l’équipe PMSI

De notre coté nous avons décidé de tester le MobProg pour résoudre une problématique spécifique.
En effet, nous devions attaquer un projet nouveau avec une stack technique assez complète qu’aucun des membres de l’équipe ne maîtrisait totalement…

Au menu des festivités :

  • AngularJs,
  • ES2015 (et finalement TypeScript),
  • Sf2,
  • Pomm2,
  • et des libs internes à implémenter.

L’idée était donc d’avancer en groupe sur le bootstrap du projet afin que chacun d’entre nous puisse être pleinement impliqué dans la mise en place de ces briques.

L’objectif était de passer 10 jours (1ère quinzaine d’aôut) en Mob-Programming et d’avoir à la fin la première page de l’application : une liste d’ ”items” récupérés en base

Donc du frontend via Angular/ES2015, du backend via Symfony, de l’accès à la base via Pomm2 et l’intégration de librairies internes (pmsipilot-ui, lib d’authentification SSO, …).

Nous avons donc démarré à 3 développeurs au rythme d’une rotation par heure pour 10 jours .

La première question fut la gestion des PC. Nous avons choisi mon ordinateur pour la saisie mais seul 1 autre collègue possédait un portable et nous avions donc constamment 1 personne sans ordinateur autour de la table.
Nous avons donc géré avec 2 ordinateurs mais le mieux est que chacun ait un PC notamment pour le travail de recherche en ligne ( Finalement nous aurions du prendre 1 portable de l’entreprise mais, pris dans notre expérience, nous n’y avons même pas pensé :) )

Au niveau du rythme nous avions tablé sur des journées entières mais assez rapidement nous avons du réduire le scope.
Un autre projet nous a demandé plus de temps que prévu (ah la magie du support… ) et j’ai eu le droit à quelques fameuses réunions de dernière minute qui finissent par prendre toute l’après-midi…
Tout n’était pas parfait donc mais nous avons quand même réussi à garder ce rythme d’½ journée et à avancer sans trop de problème.

Lors de phases en rapport avec nos dépendances internes nous avons pu solliciter l’un de nos collègues qui est donc venu autour de la table pour nous présenter ces briques et nous guider dans leur configuration.

Finalement nous avons pu terminer notre quinzaine avec une page fonctionnelle et surtout avec la certitude que chaque membre de l’équipe avait touché aux différentes bases du futur logiciel et se sentait impliqué et concerné par l’ensemble des points abordés.

Pour finir, voici quelques enseignements que nous avons tirés de cette première expérience:

  • Chaque participant doit avoir un PC à sa disposition sans quoi cela crée un isolement qui peut le sortir des discussions et réflexions en cours (pas d’accès aux supports informatiques).
  • Attention à rester à l’écoute des autres services, la seconde journée nous avons totalement “squizzé” notre équipe support qui nous alertait sur Slack :/
    • Avertissez les autres services (agenda, avertissement sur un channel)
    • Gardez un oeil sur les channels de communication.
    • Réservez du temps pour les autres projets (réunion, support,…) et pour varier le rythme (le pair est parfois plus frustrant)
  • Attention à ne pas transformer le mob en réunion de planification (discussion sans dév).
    • Si on n’arrive pas à démarrer le développement c’est que la spéc manque de clarté, donc on appelle le P.O. ou on décale la feature
  • Attention à respecter le rythme de saisie et les habitudes de chacun :
    • éviter les remarques lors de la saisie, le driver est responsable de cette partie, l’essentiel est qu’il respecte les coding standard.

En bonus, un petit time-lapse d’une de nos sessions plus récente (avec un nouveau collègue et un ordinateur par personne cette fois ci ! ) :

`

 

Bertrand Jamin

 

One thought on “Introduction au Mob Programming chez PMSIPilot

Laisser un commentaire