Un avis ? Un commentaire ?
Cet espace est pour vous.
Dans l’article précédent, nous parlions d’un de nos jeux permettant de clôturer un projet en faisant le point dans la bonne humeur. Aujourd’hui ça continue ; l’hiver (ou l’été, ça dépend d’où vous nous lisez…) sera ludique ou ne sera pas !
Dans certaines organisations, il existe une dette technique importante concernant les tests unitaires. Mettre en œuvre une reprise de cette dette demande du temps et du budget, et il est important que les décideurs comprennent précisément l’intérêt d’un tel chantier. Le problème : les tests unitaires sont généralement dans la partie invisible de l’iceberg.
Le jeu présenté ici va permettre de répondre à cette problématique. Il va être question de développer une application sans tests unitaires, puis avec ; une application constituée non pas de classes, de méthodes et de bases de données, mais de cartes à jouer !
De 2 à N, la seule limite étant l’espace et le nombre de jeux de cartes dont vous disposerez !
Une personne doit endosser le rôle de maître du jeu. A vue de nez, ce sera vous !
Le jeu se joue en 2 sessions de 10 tours, qui simulent 10 sprints.
Au début de chaque session, l’application est composée de 4 cartes tirées au hasard dans le jeu (on part rarement de rien…) Il n’est pas important de conserver ces 4 cartes au cours de la partie, cela constitue simplement un point de départ.
Le maître du jeu lance un chronomètre, ce qui va constituer un levier de pression en cas de bavardage entre les participants !
A chacun des 10 tours, une règle est lue par le maître du jeu. La règle du tour est lue par le maître du jeu uniquement pendant le tour N. Elle peut être répétée à volonté au cours du tour, mais en aucun cas après. Le maître du jeu peut être assez tranchant sur ce point : « Vous devriez vous en souvenir ! ». On passe au tour suivant dès que les « développeurs » considèrent qu’ils ont terminé.
Bien sûr, toutes les règles doivent être respectées à l’issue des 10 tours.
Une autre phrase peut être retenue à toutes fins utiles, par exemple si les joueurs se posent des questions sur la meilleure implémentation à fournir : « Je me fiche des détails techniques, je veux juste que l’application corresponde à toutes mes règles métier. »
Il n’y a pas de temps limite, mais le maître du jeu est invité à presser et stresser les développeurs. La durée visée est de 10 minutes par session.
Tous les membres de l’équipe des participants ont le même rôle. C’est à eux de valider à l’issue des 10 sprints que l’application fonctionne comme demandé.
Les règles de la première session sont les suivantes :
A la fin de la session, les participants comptent le nombre de règles qu’ils ont et n’ont pas respectées.
Après cela, le maître du jeu peut éventuellement interroger les joueurs. Quelques idées de questions :
NB : si des joueurs vous rétorquent que des règles se contredisent, vous pourrez leur présenter a posteriori une solution possible :
| Coeur | Pique | Trèfle | Carreau |
|
1 K Q Q V V 9 9 |
1 K K Q |
1 1 |
1 |
La deuxième session se déroule comme la première, à la différence que cette fois, le maître du jeu mettra à disposition des joueurs chaque RG énoncée. Ainsi, au tour 4, les joueurs auront accès aux RG 1, 2, 3 et 4.
Les règles de la deuxième session sont les suivantes :
Les règles des deux sessions sont les mêmes, seuls les signes changent ! Une solution possible pour la deuxième session est donc :
| Pique | Carreau | Coeur | Trèfle |
|
1 K Q Q V V 9 9 |
1 K K Q |
1 1 |
1 |
Prévoyez un temps d’échange après la deuxième session. Les mêmes questions qu’après la première session pourront être posées. Vous verrez les parallèles s’établir entre les vérifications des joueurs et les tests unitaires (beaucoup plus rapides soit dit en passant !)
Un bon préambule avant d’organiser en pratique la résolution de la dette technique.
Bon jeu et bons échanges autour des tests unitaires !
Nos autres jeux :
Cet espace est pour vous.
