La règle du jeu est très simple, assimilée en un tour :
Un scénario utilisateur est convenu. Le but du jeu est de produire dans le temps imparti le code satisfaisant ce scénario. Le code est écrit "test-first". Les membres de l'assemblée passent chacun leur tour au clavier, pour écrire (et faire passer) un nouveau test. Ils sont aidés pour cela d'un co-pilote, qui au tour suivant deviendra le pilote, etc. Chaque binôme amène donc une nouvelle fonctionnalité, et chaque participant se retrouve à devoir :
- Refactorer le code le cas échéant;
- Ecrire le prochain test qui nous fait progresser vers l'objectif;
- Faire passer ce test;
L'atmosphère est très très légèrement électrique, avec une blague qui part de temps en temps, en rythme soutenable. Le codeur, frappé comme tous les autres par la Babel technologique, s'empêtre avec les semis-modes emacs alors que lui, sa vie c'est vi. (Il faudrait régler ce problème d'environnements multiples). Pendant que le binôme sèche un peu sur un test à écrire, les prochains consultent frénétiquement de la doc ou le Net pour trouver une implémentation ou la référence d'une classe ou méthode ruby.
Pour les nouveaux venus que l'exercice allècherait, quelques conseils :
- Le code est revu par 5 à 8 personnes au moment où vous l'écrivez. S'agit pas de bâcler.
- C'est considéré comme looser d'écrire un test qui passe tout de suite. En général son auteur efface le test; mais çà compte pour un tour.
- Ne laissez pas faire ceux qui essaient de monopoliser le clavier en tirant sur leur tour de test. Parmi leur tactiques :
--- "Attends, là je n'ai pas créé un nouveau test, j'ai juste modifié un test existant" (sous-entendu : c'est encore à mon tour);
--- "Là, j'ai juste ajouté un assert, pas un test."
Faire passer le test à l'aide d'un Fake It peut paraître subtil mais c'est aussi légèrement abusif : est-ce vraiment un cadeau à faire à celui qui vous a courageusement assisté pendant 5 minutes ? Si la bonne implémentation est introuvable c'est un cadeau empoisonné. Si la bonne implémentation va complètement de soi, c'est un coup bas !
Qu'est-ce qu'on gagne ?
L'intérêt d'un tel jeu ? Il est triple :
- C'est un jeu ou l'on gagne toujours -- c'est incroyable ce qu'on apprend en jouant à ce jeu, sur tous les tableaux : techniques, mais aussi style de programmation, langages, formes.
- C'est un jeu collaboratif. Si on n'innove pas, si on ne communique pas, si on n'organise pas, le jeu stagne. Ca ne vous rapelle rien ?
- C'est un jeu productif. Combien de temps vous faut-il pour coder le jeu de la vie (coder, pas hacker) ? Je pense qu'une équipe Randori-Round Robin peut faire çà en 2 fois une heure. En tout cas c'est au delà de ce que je pourrais m'imaginer tout seul.
En fait, je peux tout à fait m'imaginer une session de ce type appliquée à la réalisation d'un programme professionnel. Je serais curieux de voir le même problème confié à une équipe "Randori" et à une équipe traditionnelle spécialisée. Je me demande quelle est la part d'over head. Mettons qu'en "Randori" le code demandé soit produit plus rapidement et qu'il soit de meilleure qualité... (ces deux attributs se renforcent mutuellement à mon sens) La porte serait ouverte pour tous les changements de stratégies de développements dans le milieu professionnel ! Personnellement celui qui consisterait à remplacer la vie de bureau par un coding fest me paraît on ne peut plus intéressant.
Posted by Christophe at March 22, 2005 08:20 PM