Débutant
té

TDD : Té et Double-Décimètre

té Si l’utilisation de “Té et Double-Décimètre” pour expliciter l’acronyme TDD ne vous a pas surpris, ce Serious Game est pour vous.
Votre nouveau langage de programmation ? Une feuille, un crayon à papier et des points à placer au millimètre !

Préambule

Puisque cet article contient la description d’un Serious Game, précisons d’abord ce terme.
Un Serious Game est un jeu (oui, jusque-là, une traduction littérale suffisait) ayant une vocation pédagogique. L’idée est d’apprendre un concept, ses implications et ses ressorts de façon ludique. Plutôt qu’une longue formation théorique, un Serious Game est la mise en pratique d’un concept nouveau au sein d’un jeu.

Le Serious Game qui nous intéresse ici traite du TDD, ou Test Driven Development. Attelons-nous à l’éclaircissement de ce terme. Le TDD est un principe de développement stipulant que les tests doivent être écrits avant le code du logiciel à proprement parler.
Nous ne mettrons pas en avant tout de suite l’intérêt de ce principe, le Serious Game qui suit est là pour vous le faire découvrir.

Matériel

  • 2 feuilles A4 par groupe
  • 1 crayon à papier par groupe
  • 1 gomme par groupe
  • 1 règle graduée par groupe (ou tout autre moyen de mesurer au moins 10 cm)
  • 12 post-its par groupe

Règles

Ce Serious Game est praticable à partir de trois participants. Si vous êtes plus nombreux, formez plusieurs groupes de trois personnes, mais il est possible d’avoir un groupe de deux personnes si votre nombre vous y oblige. Si nécessaire, le facilitateur peut s’inclure dans un groupe.

Nous allons procéder en 7 itérations :

Tableau-tdd

L’objectif de chaque itération est de positionner quatre points sur le bord droit d’une feuille A4.
Les critères de validation de l’itération seront toujours les mêmes et reposent sur la distance de chaque point par rapport aux limites de la feuille.
Ainsi le premier point devra être placé à 4 cm du haut de la feuille, le deuxième à 10 cm du haut de la feuille, le troisième à 2 cm du bas de la feuille, et enfin, le quatrième à 7 cm du bas de la feuille. Pour chaque point, une erreur de 2mm est tolérée. Vous trouverez ci-contre la maquette sur laquelle vous appuyer pour votre “développement”.



Itération #1

Iteration-1Lors de cette itération, seuls les membres de l’équipe de qualification vont tester !
Dans chaque groupe, les participant vont se partager les rôles suivants :
– Une personne va devenir membre de l’équipe de qualification. Donnez-lui la règle graduée (ou équivalent).
– Une autre va jouer le rôle du développeur et va donc tracer les points dont nous avons besoin. Il lui faut une feuille A4, un crayon et une gomme.
– La dernière personne (s’il y en a une) se cantonne pour le moment au rôle de time keeper. Donnez-lui le chronomètre (ou équivalent).

Le time keeper déclenche le chronomètre et le développeur place ses quatre points sur le bord droit de sa feuille. Rappelez-vous, il ne teste pas. C’est donc la personne détenant la règle qui s’en charge. Si les points ne sont pas bien placés, elle annote la feuille afin d’expliquer pourquoi les points sont mal positionnés. Pour ce faire, elle note à côté de chaque point la distance réelle mesurée (ce sont vos anomalies). Attention, le testeur ne développe pas. Il ne doit donc pas positionner les points lui-même. Le développeur récupère alors sa feuille et modifie son développement. C’est toujours le testeur qui se charge de vérifier si les points sont bien placés. L’échange entre développeur et testeur se poursuit jusqu’à ce que les points soient bien placés. Le time keeper arrête enfin le chronomètre.

Notez, dans un tableau similaire à celui affiché plus haut, l’ensemble des temps des groupes ou une moyenne de ceux-ci.

Itération #2

Lors de cette itération, les membres de l’équipe de développement vont pouvoir tester leur développement à la fin de sa rédaction !
Dans chaque groupe, contrairement à l’itération précédente, donnez, dès le début, la règle graduée au développeur.
Le développeur retourne sa feuille à 180° pour utiliser l’autre bord cette fois.

Le time keeper déclenche le chronomètre et le développeur place ses quatre points, au jugé, sur le bord droit de sa feuille. Une fois ses quatre points placés, il peut utiliser la règle pour vérifier s’ils sont au bon endroit. C’est son test ! Il peut ensuite modifier la position de ses points en fonction de son test. La personne chargée de la qualification vérifie, en utilisant la règle, si les points sont bien placés. Comme lors de l’itération précédente, elle annote la feuille avec les éventuelles anomalies qu’elle a détecté. Le développeur corrige alors son travail et l’échange avec le testeur se poursuit jusqu’à ce que les points soient bien placés (généralement, il n’y a pas d’aller-retour entre testeurs et développeurs dans cette itération). Enfin, le time keeper arrête le chronomètre.

Notez dans votre tableau l’ensemble des temps des groupes ou une moyenne de ceux-ci.

Itération #3

Iteration-3Cette itération est une itération de refactoring. Le développement doit être refait mais les critères de validation restent les mêmes.
La personne qui était time keeper à l’itération précédente va en plus faire un peu de développement !

Le time keeper déclenche le chronomètre et le (premier) développeur va effacer le deuxième point le plus haut de la deuxième itération. Il masque les éventuelles traces de gommage à l’aide d’un post-it. Le time keeper/2e développeur va replacer le point masqué par le post-it. Il dessine donc sur le post-it. Comme lors de l’itération précédente, ce n’est qu’une fois son point placé une première fois au jugé qu’il teste et donc utilise la règle pour d’éventuels ajustements. Il transmet ensuite la feuille et le crayon au testeur. Un cycle anomalies-corrections entre le time keeper et le testeur, tel que décrit dans les autres itérations, s’entame alors.

Notez dans votre tableau l’ensemble des temps des groupes ou une moyenne de ceux-ci.

Itération #4

Test-AutoCette fois, nous allons utiliser des tests “automatisés”. Utilisez le verso de votre feuille de développement

Le time keeper déclenche le chronomètre et le premier développeur va placer au jugé ses quatre points sur la feuille de développement. Il utilise ensuite la deuxième feuille A4 pour créer son test automatique. Pour ce faire, il utilise la règle pour placer des repères (par exemple des flèches) sur le côté gauche de la deuxième feuille. Ces repères sont placés aux mêmes distances des bords que ce qui est spécifié sur la maquette. La différence est qu’ils sont à gauche de leur feuille. Le développeur utilise ce test (et non plus la règle graduée) pour corriger le placement de ses points sur la première feuille. Un cycle anomalies-corrections entre le développeur et le testeur, tel que décrit dans les autres itérations, s’entame alors.

Notez dans votre tableau l’ensemble des temps des groupes ou une moyenne de ceux-ci.



Itération #5

Cette itération est une itération de refactoring. Le développement doit être refait mais les critères de validation restent les mêmes.

Le time keeper déclenche le chronomètre et le premier développeur va effacer les trois premiers points (en partant du haut de la feuille) placés lors de la 4e itération. Il masque les éventuelles traces de gommage à l’aide de post-its. Le time keeper/2e développeur va replacer les points masqués par le post-it. Il dessine donc sur les post-its. Comme lors de l’itération précédente, ce n’est qu’une fois son point placé une première fois au jugé qu’il teste et donc utilise le test automatique réalisé à l’itération précédente (ie. la 2e feuille A4) pour d’éventuels ajustements. Un cycle anomalies-corrections entre le time keeper et le testeur, tel que décrit dans les autres itérations, s’entame alors.

Notez dans votre tableau l’ensemble des temps des groupes ou une moyenne de ceux-ci.

Itération #6

Lors de cette itération nous allons simuler le fonctionnement du Test Driven Development. Le développeur s’apprête à dessiner sur le bord non utilisé de chacune des deux feuilles.

Le time keeper déclenche le chronomètre et le développeur va d’abord créer son test automatisé. Il prend la feuille de test (celle avec les repères créés lors de l’itération 4) et crée les 4 repères sur le côté gauche. Comme tout à l’heure, ils vont servir de “détrompeurs” pour le placement des points de l’autre feuille. Ces repères doivent donc être placés conformément à la maquette fournie mais sur le côté gauche. Il va donc utiliser la règle pour placer lesdits repères. Le développeur utilise ce test nouvellement créé pour faire son développement (ie. placer ses 4 points sur la feuille de développement). Un cycle anomalies-corrections entre le développeur et le testeur, tel que décrit dans les autres itérations, s’entame alors.

Notez dans votre tableau l’ensemble des temps des groupes ou une moyenne de ceux-ci.

Itération #7

Cette itération est une itération de refactoring. Le développement doit être refait mais les critères de validation restent les mêmes.

Le time keeper déclenche le chronomètre et le premier développeur va effacer tous les points placés lors de la 6e itération. Il masque les éventuelles traces de gommage à l’aide de post-its. Le time keeper/2e développeur va replacer les points masqués par le post-it. Il dessine donc sur les post-its. Cette fois, à la façon du Test Driven Development, il va utiliser le test automatisé, les repères préalablement construits, pour appuyer son développement. Il lui suffit d’accoler les deux feuilles et de placer ses points, sur les post-its de la feuille de développement en face des repères de la feuille de test. Un cycle anomalies-corrections entre le time keeper et le testeur, tel que décrit dans les autres itérations, s’entame alors.

Notez dans votre tableau l’ensemble des temps des groupes ou une moyenne de ceux-ci.



Debriefing

Engagez les participants à un debriefing du Serious Game. Quel a été leur ressenti ? Insistez bien sur les frustrations et les soulagements que certaines itérations ont apportés. Vérifiez, à l’aide du tableau les coûts de construction des tests automatisés. Sont-ils rentables ? Facilitent-ils certaines phases ? Le TDD accélère-t-il le développement ? Accélère-t-il le refactoring ?
Bref, les participants ont la parole ! Si tout s’est passé correctement, l’intérêt du TDD doit commencer à faire du chemin dans l’esprit des joueurs.

Variantes

Vous pouvez changer plus régulièrement les rôles au sein des groupes. Il arrive parfois que les développeurs n°1 se spécialisent rapidement dans le placement de point et fassent moins d’erreurs que prévu.
Une autre solution à ce problème est de changer les critères de validation (et donc la maquette) aux itérations 2, 4, et 6.

Nombre de vue : 92

AJOUTER UN COMMENTAIRE