Dans la peau du MĂ©chant 😈

Introduction

Il y a quelques jours j’ai participĂ© Ă  un meetup Evil mob programming : un coding dojo oĂč on peut vraiment ĂȘtre MĂ©chant. J’ai beaucoup aimĂ© cet exercice amusant et enrichissant. Ce retour d’expĂ©rience va vous permettre, j’espĂšre, de mieux comprendre le rĂŽle de chacun dans le dĂ©veloppement de nouvelles fonctionnalitĂ©s dans un projet.

Quel Ă©tait l’exercice ?

Du Mob Programming ?

Je vous invite Ă  lire cet article pour comprendre prĂ©cisĂ©ment le concept, ici je ne rentrerai pas dans les dĂ©tails. Le Mob Programming est une approche du dĂ©veloppement oĂč toute l’équipe travaille en mĂȘme temps sur le mĂȘme code, au mĂȘme endroit et sur un unique ordinateur : du Pair Programming Ă  plusieurs.
Le but de cet exercice est d’arriver Ă  produire quelque chose tous ensemble et de permettre Ă  tous de participer activement au dĂ©veloppement.

Différents rÎles

Trois rĂŽles sont utilisĂ©s dans cette pratique. Comme pour le Pair Programming, on retrouve un “Driver” et un “Navigator” :

  • Le “Navigator” est lĂ  pour donner la route Ă  suivre pour arriver Ă  une nouvelle fonctionnalitĂ© ou au terme de l’exercice dans le cas de notre kata. C’est lui qui communique avec le “Driver” pour lui donner la prochaine Ă©tape Ă  effectuer et le code qu’il va devoir produire.

  • Le “Driver” implĂ©mente ce que le “Navigator” explique Ă  l’oral. Tout le code qu’il produit vient du “Navigator”, c’est, pour rĂ©sumer, l’interprĂšte entre l’homme et l’ordinateur.

  • Le reste de l’équipe participe activement en donnant son point de vue sur les choix du “Navigator”. Elle ne communique pas directement avec le “Driver” pour garder un environnement productif.

Tout le monde y passe

Chacun, Ă  tour de rĂŽle, va pouvoir passer au clavier pour ĂȘtre le “Driver” ou avoir le rĂŽle de “Navigator”.

Dans notre cas, nous Ă©tions trĂšs nombreux (une quinzaine de “mobeurs”), nous changions de place toutes les 4 minutes. C’était un peu court Ă  mon goĂ»t, je pense que des rotations toutes les 8 Ă  10 minutes sont plus pertinentes si on fait l’exercice sur un plus gros laps de temps.

Mode “Evil” ?

Avant de dĂ©marrer l’exercice, nous avons tirĂ© une carte pour savoir si nous allions avoir le rĂŽle de “MĂ©chant” ou de “Gentil”. Les “Gentils” ont un comportement bienveillant, ils tentent de faire avancer la session. Les “MĂ©chants”, en revanche, doivent essayer de la saboter sans que personne ne s'en rende compte.

L’exercice proposĂ© ?

Nous avons travaillĂ© sur le kata “Tennis Refactoring” d'Emily Bache :

Nous sommes appelĂ©s Ă  reprendre le travail d’un collĂšgue qui a travaillĂ© pour une sociĂ©tĂ© de Tennis. Le contrat signĂ© avec le client est de 10h et notre collĂšgue n’a travaillĂ© que 8h30 sur le projet. Notre commercial nous demande de reprendre le projet pour le temps restant. Quand on dĂ©couvre le code, tous les tests passent et le travail est terminĂ© (le service est rendu). Nous devons profiter du temps qu’il nous reste pour retravailler le code existant pour le rendre plus lisible et pour pouvoir faire un retour Ă  notre collĂšgue sur sa façon de coder.

Comment s’est passĂ© la session ?

PremiÚres minutes de découverte

Nous avons pris le temps au dĂ©but de l’exercice de parcourir le code Ă©crit par notre collĂšgue pour comprendre ce qu’il a implĂ©mentĂ©. Les tests Ă©taient dĂ©jĂ  prĂ©sents, ils nous ont aidĂ© Ă  comprendre que le but est de donner le score en anglais en fonction du nombre de points marquĂ© par les deux joueurs de tennis.

Par exemple si le joueur “A” a marquĂ© deux fois et le joueur “B” a marquĂ© trois fois, le score est de 30-40. Le programme doit alors nous donner “Thirty-Forty”. En cas d’égalitĂ©, le score s’énonce de cette maniĂšre : Fifteen-All pour un 15-15. En cas d’avantage ou de fin de set, le score est “Advantage A” pour le score : Adv-40 et “Win for A” si le joueur “A” remporte le set.

On s’est assurĂ© que les rĂšgles Ă©taient bien comprises par tous avant de se lancer dans le refacto.

Les tests existants ne sont pas forcĂ©ment d'une grande qualitĂ©, nous aurions pu commencer par les modifier mais nous avons prĂ©fĂ©rĂ© nous attaquer Ă  l’implĂ©mentation.

À l’attaque du code

Maintenant que tout le monde est au point, il est temps de commencer. Les “MĂ©chants” peuvent commencer Ă  s’amuser en tentant de saboter le travail de l’équipe.

Exemple de sabotage

Pour cet exercice, j’ai eu la chance d’avoir le rĂŽle de “MĂ©chant”. Il est assez simple (et surtout bien amusant) de ralentir le travail de l’équipe. Je vous donne quelques exemples de sabotage avec une comparaison dans la vie rĂ©elle.

⟩ InterfĂ©rer avec le “Navigator”

Pour rappel, c’est uniquement le “Navigator” qui donne la route Ă  suivre pour mener le dĂ©veloppement. Il est possible de rendre son rĂŽle pĂ©nible : parler plus fort que lui, parler Ă  sa place au “Driver”, enlever la concentration du groupe avec des blagues, des trolls, 


Comparable Ă  :

  • un collĂšgue qui pose des questions qui n’ont rien Ă  voir avec le sujet,

  • un tĂ©lĂ©phone qui sonne en plein milieu de la session,

  • “Jo l’rigolo” avec ses blagues de Kaamelott.

⟩ Se lancer dans un refacto compliquĂ©

Tout le monde n’a pas la mĂȘme logique et ne code pas de la mĂȘme maniĂšre, il est donc facile d’imposer un choix qui peut paraĂźtre simple mais qui finalement ne mĂšne Ă  rien. Cela fait perdre du temps et peut donner un sentiment de frustration aux autres membres de l’équipe.

Comparable Ă  :

  • quelqu’un qui veut mettre en pratique la derniĂšre nouveautĂ© du langage de programmation sans mĂȘme l’avoir comprise,

  • partir dans un dĂ©veloppement sans s’assurer que les autres comprennent ce que l’on fait.

⟩ Ne pas Ă©couter le reste de l’équipe

Quand on est “Driver” ou “Navigator”, on a une plus grande responsabilitĂ©. Il faut donc faire au mieux pour que ce qu’on fait soit compris de tous. Si on n’écoute pas les autres, on peut facilement nuire au travail de l’équipe. Par exemple, un “Driver” qui n’en fait qu’à sa tĂȘte peut dĂ©truire tout le travail d’un autre ou rendre le code parfaitement incomprĂ©hensible.

Comparable Ă  :

  • un dĂ©veloppeur qui n’en fait qu’à sa tĂȘte et ne veut pas Ă©couter le point de vue des autres,

  • l’équipe qui n’écoute pas ceux qui connaissent le mĂ©tier.

Ce qui fait avancer le développement

Certains avait le rĂŽle de “Gentils” et devaient, malgrĂ© les embĂ»ches des “MĂ©chants”, faire avancer le dĂ©veloppement. Voici ce qui permet le bon avancement de la fonctionnalitĂ©.

⟩ Des experts mĂ©tiers

Certaines personnes connaissaient dĂ©jĂ  le kata et ont pu facilement donner une direction Ă  suivre pour arriver au bout du dĂ©veloppement. Si on compare avec le monde rĂ©el, il est important de faire participer un expert mĂ©tier qui connaĂźt parfaitement ce qui est attendu. MĂȘme s’il ne sait pas coder, il sera bien utile pour produire un code comprĂ©hensible.

Il est important de toujours garder contact avec les experts mĂ©tier qui savent ce qu’il faut au final.

⟩ De l’écoute

Un “Gentil” veillait particuliĂšrement Ă  ce que les rĂŽles soient respectĂ©s : seul le “Navigator” Ă©change avec le “Driver”. Il recentrait Ă©galement les personnes sur une unique tĂąche, pour ne pas avoir plusieurs conversations en mĂȘme temps.

Il faut apprendre Ă  mettre son orgueil de cĂŽtĂ©, tout le monde peut avoir une bonne idĂ©e et doit avoir la chance de s’exprimer.

⟩ De la bienveillance

Il y avait tout type de profil dans l’assistance. Il faut veiller Ă  ne pas rabaisser les autres mobeurs et adopter une communication non violente. Cela fait progresser tout le monde et fait grandir l’équipe plus rapidement.

Conclusion

Ce Mob Programming n’était qu’un exercice, un jeu pour mieux comprendre comment fonctionne une Ă©quipe. Avant de mettre en place ce type d’approche, il faut se demander si c’est pertinent et ce que ça va apporter. Plusieurs essais peuvent ĂȘtre nĂ©cessaires avant de trouver la bonne configuration : nombre de personnes prĂ©sentes, durĂ©e des rotations, 


Je me suis bien amusĂ© lors de cette session, je vous encourage Ă  organiser ou participer Ă  ce type d’évĂ©nement qui permet de faire Ă  la fois du team building et dĂ©couvrir une nouvelle façon de coder Ă  plusieurs. En plus, si on peut ĂȘtre un “MĂ©chant”, on y prend encore plus de plaisir. 😈


Vous avez trouvé cette publication utile? Cliquer sur
Ippon
Ippon est un cabinet de conseil en technologies, créé en 2002 par un sportif de Haut Niveau et un polytechnicien, avec pour ambition de devenir leader sur les solutions Digitales, Cloud et BigData.

Ippon accompagne les entreprises dans le dĂ©veloppement et la transformation de leur systĂšme d’information avec des applications performantes et des solutions robustes.

Ippon propose une offre de services Ă  360° pour rĂ©pondre Ă  l’ensemble des besoins en innovation technologique : Conseil, Design, DĂ©veloppement, HĂ©bergement et Formation.

Nous avons rĂ©alisĂ©, en 2017, un chiffre d’affaires de 31 M€ en croissance organique de 30%. Nous sommes aujourd’hui un groupe international riche de plus de 320 consultants rĂ©partis en France, aux USA, en Australie et au Maroc.
FRANCE Website LinkedIn