INFOTEL VOUS REMERCIE POUR VOTRE CANDIDATURE

Un chargé de recrutement prendra contact avec vous prochainement.

Le « Mob programming » : on a testé et on continue !

REX Mob Programming

Au sein d’un de nos centres de service, nous avons eu la volonté de tester cette pratique et de la mettre en place en l’adaptant à notre besoin et contexte. L’objectif principal étant ici de partager les connaissances techniques, les bonnes pratiques, l’expérience entre développeurs/projets et d’améliorer la qualité de code des projets.

Les participants

2 équipes distinctes, l’une essentiellement composée de juniors, l’autre plus expérimentée et disposant d’un Lead Technique.

Ces deux équipes, une fois mélangées, vont permettre d’avoir des niveaux d’expérience hétérogènes.

Bien qu’elles ne fassent pas partie des mêmes projets et ne travaillent pas sur la même stack technique, elles rencontrent souvent les mêmes problématiques : dette technique, manque de tests unitaires, …

  • Créneau : tous les vendredis à 16h00 pour une session d’une heure + 15/20 min de rétrospective post-session
  • Sujet en cours : une classe Java un peu « fourre-tout » d’un des deux projets

Objectifs globaux

  • Réduire la classe à sa seule méthode d’exécution
  • Refactoriser les méthodes ayant une complexité cyclomatique importante
  • Augmenter la couverture de code

Une fois les objectifs de ce sujet atteints, le prochain portera sur le deuxième projet.

Bonnes pratiques et bénéfices : tout savoir sur le « Mob Programming »

Déroulement de la 1ère session

  • 2 équipes de 6 développeurs
  • Roulements toutes les 10 minutes pour le pilote (« driver »)

Les deux équipes ont eu chacune une approche différente : l’une s’est dirigée sur la mise en place de tests unitaires et l’autre sur la refactorisation de méthodes.

Rétrospective (mise en place sur la 2ème session)

Passage de 2 à 3 équipes constituées de 4 développeurs chacune, afin que tout le monde puisse mieux participer sur l’heure de session.

Définition de sous-objectifs afin d’avoir des buts concrets, par équipe et par session. Cela permet aussi que les équipes « ne se marchent pas dessus ».

Sur chaque session, seul un développeur changera d’équipe afin que la connaissance des développements et du « en cours » ne se perde pas à chaque semaine.

Conclusion

Que du positif, tout le monde est dans un état d’esprit bon enfant et bienveillant !
Il y aura toujours des améliorations à apporter à chacune de nos sessions et nous ne pourrons en voir les résultats concrets qu’après un certain temps mais c’est bien parti !

To be continued…

Par Pauline P.