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. 😈