Premières impressions de Soft(ware)Ball

softwareball_v1.small.png

Après deux sessions de Soft(ware)Ball, il est temps de tirer les premières leçons de ce jeu.

La première session s'est déroulée en comité relativement restreint (7 participants) dans le cadre des ateliers d'Agile Toulouse avec

  • 10 minutes d'introduction
  • 30-35 minutes de jeu sur les 4 premières étapes de la séquence "Infinite Loops". L'objectif de cette phase était de clarifier les règles et d'appréhender les principes qui demandent parfois de "penser autrement", je suis donc souvent intervenu dans le déroulement du jeu.
  • environ 40 minutes sur la totalité (6 étapes) de la séquence "Event Driven". Cette fois, sans aucune intervention de ma part si ce n'est pour arbitrer.
  • 10-15 minutes de debriefing

Ma première leçon fut que le jeu était bien plus compliqué à appréhender que je ne l'avais imaginé. L'approche où on laisse découvrir le jeu aux participants en les faisant réellement jouer nécessite un minimum de deux heures. Pour faire une séance d'une heure, il faut être plus directif sur le démarrage.

Pour la deuxième session, lors de Agile France 2013, j'ai donc prévu une introduction plus rapide avec les 2 premières étapes de la séquence "Infinite Loops". Dans cette introduction de 15 minutes, je programme tout seul en utilisant des composants pris dans l'assistance. Les deux principaux objectifs de l'introduction sont de visualiser une séquence de programmation et de mettre en évidence la réutilisation des composants.
Grace aux nombreuses personnes présentes, on a pu composer deux équipes d'environ douze personnes chacune. Dans la deuxième partie de la session (30 minutes) j'ai donc laissé les deux groupes dérouler indépendamment la totalité de la séquence "Event Driven".
Les 10-15 minutes restantes ont permis là encore de faire un debriefing.

A l'issue de ces deux sessions, les points à revoir impérativement sont, à mon avis :

  • Le nommage des composants. Certains joueurs ont eu l'idée de contourner certaines difficultés de programmation en renommant tout simplement les composants. Là je pense qu'on peut faire simple. Les composants étant représentés par des personnes qui ont déjà un prénom (voire un nom si plusieurs joueurs ont le même prénom), il suffit de préciser que ce prénom/nom est ce qu'il est et qu'il ne peut pas être changé.
  • Les tentatives systématiques de la part des joueurs d'établir des associations implicites de type "composant<->numéro". La règle "un composant n'a pas de mémoire" visait à empêcher cela mais, à l'usage, elle est trop ambiguë. Une idée serait de la remplacer par quelque chose de plus explicite comme "un composant n'est pas allé à l'école : il ne sait ni lire, ni écrire, ni compter".
  • Les points A, B, C, etc. sur les fiches d'étape qui ne sont que des points géométriques destinés à montrer le parcours attendu du ballon. Certains joueurs les assimilent, à tort, à des noms de composants situés sur le point en question. Du coup, ils n'ont pas l'idée d'utiliser de nouveaux composants qui ne seraient pas sur ces points là. Une idée serait de matérialiser chaque point par un marquage au sol de façon à mieux marquer la différence entre un emplacement géométrique et un composant que l'on peut positionner sur un tel emplacement ou ailleurs. Une autre idée serait de simplement préciser la différence entre points et composants lors de la présentation du jeu.

Au delà de ces points bloquants, on peut aussi imaginer des améliorations de la dynamique de jeu.

  • Le nombre de joueurs dans l'équipe est, pour moi, une question récurrente. Pas assez de joueurs et on peut difficilement, par manque de composants, programmer "dans les règle de l'art" une étape un peu complexe. Inversement, la présence de trop de joueurs ne facilite pas la communication. La taille idéale, c'est, je pense, 9 ou 10 personnes dans l'équipe (arbitre non compris). Pour l'instant, je reste dans l'idée qu'il vaut mieux trop de joueurs que pas assez.
  • Quand il y a plusieurs équipes, on pourrait peut-être imaginer une "mi-temps" au bout de 15 minutes. Durant cette mi-temps, chaque équipe viendrait faire une démonstration de sa dernière étape validée. Cela permettrait de faire une véritable pause dans la partie et alimenterait aussi un "brassage des idées".
  • Dans la conclusion de la session, certains joueurs évoquent leur partie comme l'apprentissage d'un "nouveau langage". Je me demande s'il ne faudrait pas formaliser ce langage dès le départ en donnant la liste des verbes autorisés, ou, du moins, en précisant le types de verbes autorisés. On remplacerait ainsi les interdictions ("un composant ne parle pas", "un composant ne sait ni lire, ni écrire, ni compter") par des autorisations ("un composant voit et entend ce qu'il se passe et peut effectuer des mouvements pour agir sur son environnement"). Peut être faut-il préciser l'ensemble de ces règles ?

A suivre...

Merci à tous les participants de ces deux sessions qui ont permis de mettre en évidence les faiblesses du jeu dans sa version actuelle et qui m'ont donné quelques pistes d'amélioration !

Retrouvez toutes les ressources pour jouer à Soft(ware)Ball sur http://www.softwareball.org/.

sebfauvel

Je pense effectivement qu'il serait bien de définir plus "formellement" le langage de programmation. Cela limite la créativité mais évite pas mal de questions sur ce que l'on peut faire ou non et qui n'apportent pas grand chose.

Un autre problème que j'ai perçu à force d'être reprogrammé, c'est que l'on ne sait plus très bien qui fait quoi. Une petite fiche attachée autour du coup avec le programme écrit dessus pourrait être sympa.

J'ai trouvé le debrief un peu rapide. Tu as montré rapidement un pattern sur la fin (après insistance du public). J'ai trouvé cela très intéressant mais il manquait la notion d'impact que cela avait sur le coût.

Pour le problème de nombre, c'est effectivement une difficulté. Il faudrait peut être dès le début séparer les composants (qui n'aurait pas le droit d'intervenir) des programmeurs. Ensuite, pour pouvoir s'adapter à des équipes de différentes tailles, tu peux préparer des programmes nécessitant plus ou moins de composants en fonction de la taille de l'équipe. Le nombre de programmeur reste dans une fourchette stable (entre 3 et 5).

En tout cas, cela m'a donné plein d'idées pour montrer certaines choses. Bravo pour la créativité. J'espère que tu ne m'en voudras pas, si je me resserre de ton atelier à mes propres fins.

sebfauvel 29 mai 2013 - 16:30
Oaz

Merci pour ton retour et n'hésite pas à réutiliser les principes du jeu à toutes fins utiles ! Je suis d'ailleurs preneur de tout retour d'expérience qui va dans ce sens !

Je garde l'idée de la petite fiche attachée autour du cou.
En fait cette fiche pourrait, par la même occasion matérialiser la programmation atomique d'un composant : on a le droit d'écrire une nouvelle fiche (ce qui coûte des verbes) ; on a le droit de la dupliquer à l'identique (ce qui ne coûte rien) mais on n'a pas le droit de modifier une fiche existante.
En fait, l'ensemble des fiches écrites jusqu'à l'instant présent est le stock de code disponible et pour réaliser une exécution, il suffit de prendre les fiches utiles à l'étape en cours et les faire jouer par les composants "physiques".
Cela résoudrait peut être aussi un peu le problème posé par la nécessité d'avoir un grand stock de composant -et donc un grand nombre de joueurs- que l'on ne reprogramme pas "au cas où".

Pour le debriefing, en fait, j'étais assez réticent à montrer une solution -et je le suis encore- car ce n'était pas, à mon avis, l'objectif du jeu.
Par le passé, j'ai fait un atelier "Si t'es pas SOLID, t'es pas agile" dont l'objectif était justement de montrer les principes SOLID et donc de donner des solutions. Cet atelier est le "papa" de Soft(ware)Ball car il y avait déjà le ballon, la programmation des composants humains, etc.
Là, je pense qu'il fallait vraiment être orienté "jeu" et pas "leçon", mais c'est juste mon avis...

Oaz 29 mai 2013 - 23:13

Fil des commentaires de ce billet

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.