Dix ans de programmation théâtrale
Pendant la décennie 2010, j'ai eu la joie de participer en tant que speaker à de nombreuses conférences sur les méthodes agiles en France et à l'étranger. Passer la sélection d'un CFP était probablement plus facile car j'ai eu la chance d'être là au bon moment, quand ces conférences ont pris de l'ampleur. 📈
J'ai eu aussi la chance de proposer un format qui a étonnamment bien fonctionné. Au fil du temps, j'ai décliné ce format en quatre ateliers. Ils ont représenté la moitié de mes interventions au cours des dix années. Et tout ça n'a pu exister que grace à un étrange hasard 🍀 : pendant l'été 2010, je suis tombé sur une vidéo où Brian Marick présentait un atelier intitulé "Programming for business users".
✨ De l'idée aux ateliers
2010, c'est les débuts du "Software Craftsmanship". Chicago y joue un rôle central. C'est normal d'observer ce qui s'y passe. C'est comme ça que je découvre cette vidéo d'un atelier organisé chez Obtiva. L'élément clef de l'atelier, c'est de visualiser le fonctionnement d'un logiciel en faisant jouer à des personnes le rôle des divers objets qui interagissent.
2010, c'est aussi le moment où le TDD "mockist" décolle. Il ne m'en faut pas plus pour créer un atelier "Stub et Mock montent sur scène" que je vais faire jouer lors des Agile Tours de l'automne 2010. Je reprends exactement le même format que Brian Marick mais avec un scénario de TDD. Cela me permet de montrer l'intérêt de diverses doublures de test (Stub, Spy, Fake) pour répondre à des besoins précis.
Puisque ça fonctionne bien, autant continuer. L'atelier suivant sera "Si t'es pas SOLID, t'es pas Agile". Le format est similaire mais avec un élément nouveau : une balle que les objets s'envoient et qui matérialise le cheminement de l'exécution du programme. Le but de l'atelier est de visualiser les principes SOLID et voir comment ils simplifient la conception d'un logiciel.
Avec un regard de 2025, on pourrait se dire "ok, mais quel rapport avec les méthodes agiles ?" Il faut comprendre que, à l'époque, agile et craft sont encore très liés. Le Software Craftsmanship a été popularisé en réaction à la montée de Scrum qui oubliait un peu trop souvent qu'un logiciel c'est fait avec du code mais les deux communautés sont encore largement liées. Les sujets "craft" sont très nombreux dans les confs agiles.
Ces deux ateliers ont bien fonctionné mais ça me laisse un goût d'inachevé. J'ai documenté le déroulement de "Si t'es pas SOLID, t'es pas Agile" mais je crois que personne n'a jamais utilisé ce document. En tout cas, si quelqu'un l'a utilisé, je ne l'ai jamais su. Il me faut trouver autre chose, un format un peu plus simple et un peu plus reproductible. Il faut que ces ateliers deviennent des serious games.
🎲 Des ateliers au jeu
Comme on a déjà des joueurs qui se lancent un ballon, on n'est pas très loin d'avoir un jeu. Il manque :
- des scenarios prédéfinis où on va donner des objectifs de circulation de balle aux joueurs (on appelle ça des user stories)
- des règles claires qui indiquent comment les objets humains peuvent effectuer des actions (on appelle ça un langage de programmation)
C'est la naissance de SoftwareBall 🏉
Le format de jeu avec scénarios a l'avantage de pouvoir cibler des thèmes. Très rapidement, mes ateliers SoftwareBall sont constitués d'un scénario simple sur le thème du refactoring, suivi d'un scénario un peu plus compliqué sur le thème de l'inversion de dépendances.
Le format serious game a aussi l'avantage de pouvoir être facilement repris par d'autres personnes. J'ai eu l'occasion de faire jouer à SoftwareBall en France, en Belgique et aux Pays-Bas mais le jeu a pris son envol. J'ai eu la surprise et l'immense joie d'en voir des videos ici ou là 🤩
Au final, je n'ai qu'un seul regret avec SoftwareBall : malgré quelques tentatives, il n'a jamais été pris dans une conf "tech". C'était probablement un format trop bizarre. Les formats ateliers y sont très rares et les formats atelier sans ordinateur encore plus.
🎭 Du jeu au théâtre
Mais c'est pas grave. Le format atelier a moins de chance d'être sélectionné ? Le format le plus courant c'est la conférence "classique" avec une personne qui parle sur scène ? Ok. Voyons ce qu'on peut faire. Le déroulement de "Stub et Mock montent sur scène" était, malgré les interactions avec l'assistance, globalement assez linéaire. En fait, on pourrait assez facilement le transformer en pièce de théâtre.
C'est la naissance de Doublures en folie. 🤪
Le principe est assez basique. Je demande à des personnes dans la salle d'être volontaires pour monter sur scène et faire la lecture d'une saynète d'environ 20 minutes. Il y a 2 personnages principaux, Codeur et Test, et 5 personnages secondaires : SUT, Stub, Spy, Chrono et Fake. On conclut sur un debriefing en interrogeant nos pratiques de test.
Cette saynète n'a été jouée que quatre fois mais j'ai toujours eu des bons retours. La meilleure critique ?
C'est comme si on regardait Bob l'éponge sous acide 🧽💊🤯
J'ai aussi fait une traduction en anglais Doubles on stage pour un usage unique à XP Days Benelux. Comme l'atelier durait 1h30, on est allé plus loin : les participants ont, en petits groupes, écrit et interprété une suite à la saynète.
Cette fois, je ne suis pas passé loin de la conf "tech". Je l'ai proposée à Devoxx dans un format 30 minutes intitulé "Doublures en folie : le TDD outside-in comme si vous y étiez". J'ai eu un retour encourageant "Wow. C'est ok du côté logistique, et vraiment original." qui s'est terminé par un refus. 🤷♂️
Le bilan de tout ça est quand même extrêmement positif. Je suis persuadé que ce format "code interprété par des humains" aurait encore beaucoup à offrir mais ça reste pas mal de boulot pour des résultats assez incertains. En tout cas, je dois remercier Brian Marick de m'avoir étrangement influencé.