1. Et si on Jouait au TDD ?
Librement inspiré du jeu
“99 tests balloons”*
François-Xavier Maquaire
This content is licensed under a Creative Commons Attribution 3.0 License.
fmaquaire@gmail.com
*Jeu créé par Michael McCullough : http://tastycupcakes.org/2009/06/99-test-balloons/

2. remercie pour l’organisation de
ses sponsors pour leur soutien

3. Persona
François-Xavier MAQUAIRE
Ils ne savaient pas que c’était impossible alors ils l’ont fait. Mark Twain.
FX
Partager
Echanger
Confronter
Communiquer
Jouer
S’amuser
34 ans
Thales Services Rennes
Agiliste depuis 2009
Coach et formateur (Scrum, Kanban)
Référant agile (Communauté Agile Thales Services)
Co-organisateur Agile Tour Rennes 2013
francois-xavier.maquaire@thalesgroup.com
J'ai trouvé dans l'agilité les valeurs autour de l'humain
dont j'ai besoin pour être performant : motivation,
montée en compétence, échanges, communication,
confiance, transparence, travail en équipe,
engagement et estime de soi ... l'agilité m'apporte tout
cela.

4. Introduction
• Cette session n’est pas :
o Un coding dojo
o Un retour d’expérience
o Animé par un expert du TDD 
• C’est un JEU !
• Objectifs ?
o Passer un bon moment
o…
o Voir la conclusion
05/11/10
www.agiletour.org

5. Le jeu
• Formons les équipes
oUn facilitateur par équipe
oUn nom d’équipe
oUn espace de démonstration par équipe
• Un tableau pour compter les points
• Un tableau pour le debrief
• Feedback Door

6. • Déroulement
Le jeu
o 4 itérations de 11 minutes
o Chaque itération
• Expression du besoin : 2’
• Production ~2’ = posé sur la table de démonstration
avant la fin de la durée définie
• Démo 2’
o
Pour chaque ballon présenté :
 2 point pour un ballon OK
 -1 point pour un ballon KO
• Debrief : 6’

7. On ne touche à rien
en dehors des
phases de réalisation
= chrono déclenché !
05/11/10
www.agiletour.org

8. Itération 1
• Je veux des ballons pour mon client de toute
urgence !
o Il m’a très clairement dessiné ce qu’il voulait, c’est
très simple …
• 30 secondes seulement de temps de production

9. 05/11/10
www.agiletour.org

10. Démo
• Le client accepte ou non les livraisons
• Le facilitateur de chaque équipe va reporter les
points
05/11/10
www.agiletour.org

11. Debrief
• 2’ chaque équipe discute des problèmes
rencontrés
• 2’ le facilitateur de chaque équipe remonte le
principal problème (non exposé par une autre
équipe)
• 2’ les messages que j’aimerais partager 
05/11/10
www.agiletour.org

12. Debrief Itération 1
• KISS !
o Nous avons tous tendance à vouloir nous faire plaisir …
et à utiliser ce que nous avons à disposition:
• un petit algorithme complexe par ici,
• une définition de besoin plaquée or par-là,
• bien souvent la problématique peut être traitée beaucoup
plus simplement
• Biais cognitif : biais de disponibilité
• Importance du « Afin de » dans le template d’une US (En
tant que, je souhaite, afin de)

13. Debrief Itération 1

14. Nouveau besoin client
• Un nouveau projet démarre
• A partir de maintenant, nous allons faire de
l’itératif, incrémental.
• Nous avons 3 itérations pour y arriver !
05/11/10
www.agiletour.org

15. Itération 2
• Prenons le temps de mieux regarder ce que veut
le client :
o Alternance de deux dessins sur des ballons de
baudruche
o Les ballons seront reliés entre eux par de la ficelle
• 2 minutes de temps de production

16. 05/11/10
www.agiletour.org

17. Alternance des dessins sur les ballons
reliés par une ficelle

18. Les dessins

19. Critères d’acceptance ?
05/11/10
www.agiletour.org

20. CA Dessin
3 cm
2,5 cm
4 cm
3
cm
1 cm
10 cm
1 cm
3 cm
4,5
cm
4,5 cm
4,5
cm
4,5 cm
3
cm

21. Démo
• Le client accepte ou non les livraisons
• Le facilitateur de chaque équipe va reporter les
points
05/11/10
www.agiletour.org

22. Debrief
• 2’ chaque équipe discute des problèmes
rencontrés
o Comment percevez-vous le décompte des points négatifs ?
• 2’ le facilitateur de chaque équipe expose le
principal problème (non exposé par une autre
équipe)
• 2’ les messages que j’aimerais partager 
05/11/10
www.agiletour.org

23. Debrief Itération 2
• Critères d’Acceptation (CA)
o Il faut rendre explicite les principaux éléments qui vont nous permettre de
dire si oui ou non, l’équipe produit ce que souhaite le PO.
o Il faut définir le niveau de qualité associé !
• Tests d’Acceptation
o Décrire les tests qui vont permettre de valider les CA permet de spécifier
par l’exemple et de lever les ambiguïtés.
o Plus long que d’écrire des CAs.
• Et si vous passiez au Test Driven Drawing ?

24. Debrief Itération 2

25. CODEZ ECOLO !
• « réduisez vos déchets en
commençant par écrire vos
tests »©
© : citation de Mathieu Cans 

26. Les dessins

27. Itération 3
• Discutons Critères d’Acceptation et Tests
d’Acceptation, afin de :
o Rendre explicites les critères d’acceptation avec le PO
o Travailler sur des Tests d’Acceptation
o Expérimenter le TDD
• 2 minutes de temps de production

28. Démo
• Le client accepte ou non les livraisons
• Le facilitateur de chaque équipe va reporter les
points
05/11/10
www.agiletour.org

29. Debrief
• 2’ chaque équipe discute des problèmes
rencontrés et des points positifs
o Comment avez-vous perçu le fait de commencer par produire les
moyens de tester ?
• 2’ le facilitateur de chaque équipe expose le
principal problème (non exposé par une autre
équipe) et/ou la principale amélioration
• 2’ les messages que j’aimerais partager 
05/11/10
www.agiletour.org

30. Debrief Itération 3
• TDD et qualité : définir la cible nécessaire et
suffisante …
• Impact sur l’expression de besoin
• Pas ou peu de valeur métier produite sur une
itération, c’est grave docteur ?
• Communication ?

31. Debrief Itération 3

36. Test Driven Development
Restructuration du code
Reprendre le code pour
le simplifier et le rendre
aisément maintenable
Le test est au rouge
TDD
Ecriture des Tests (design
de l’application)
Passage des Tests
Les tests restent au
vert
Le test est au vert
Ecriture du code
Modification du code
Passage des Tests jusqu’à
réussite complète

37. Test Driven Developpement (TDD)
3. Développement
logiciel
4. Exécution
automatique
des tests
2. Automatisation
des tests
Sprint #1
1. Conception
des tests
#2
#n

38. Itération 4
• Dernière itération !
o Itératif
o Incrémental
o Résultat final !
• 2 minutes de production

40. Bleu = non soumis à des tests d’acceptation

41. Démo
• Le client accepte ou non les livraisons
• Le facilitateur de chaque équipe va reporter les
points
05/11/10
www.agiletour.org

42. Debrief
• 2’ chaque équipe discute des problèmes
rencontrés, ou des bonnes pratiques perçues
o Connaissant le produit final, auriez-vous adopté la découpe
(incrémentale)proposée dans le jeu ?
• 2’ le facilitateur de chaque équipe expose le
principal problème (non exposé par une autre
équipe) ou l’adoption d’une bonne pratique.
• 2’ les messages que j’aimerais partager 
05/11/10
www.agiletour.org

43. Debrief Itération 4
•
•
•
•
•
Importance de la Vision
Itératif, incrémental
Importance des outils, de l’automatisation
ROI TDD, ROI automatisation
TDD et qualité

44. Debrief Itération 4

45. • Le TDD quand on commence on se demande
comment faire.
• Quand on sait faire, on se demande comment on
a pu s'en passer.

46. REX sur le TDD
Thales Grenoble Mathieu Cans
Passage du test traditionnel à l’approche full
mock de JB-Rainsberger
Couverture de ~80% de tests Unitaires
:Enfin !
Chute de la complexité par classe
05/11/10
www.agiletour.org

47. Pyramide de test de Mike Cohn
•Nombre faible : 1 à 5%
Le plus automatisé possible
Outil : Selenium
Au moins un par user
story : 5 à 15%
Automatisés
Outil : FitNesse ou
GreenPepper
Au moins un
par classe ou
module :
80 à 90 %
Automatisés
Outil : JUnit
Tests
IHM
Tests
Fonctionnels
Tests Unitaires
Ref : Succeeding with agile Mike Cohn
Source : http://blog.mountaingoatsoftware.com/the-forgotten-layer-of-thetest-automation-pyramid

48. REX ATDD
Thales Grenoble Mathieu Cans
• Une fois le TDD full mock bien en place
• C’est l’ATDD qui a été visée : spécification par
l’exemple
o Bénéfices
• Compréhension partagée (fonctionnels / techniques)
• Mesure de l'avancement
• Non régression
• Documentation vivante.
Le point négatif de l’outil FitNesse est l'utilisation
d'un wiki moins rapide qu'un fichier WORD pour
décrire les fonctionnalités, même si le format wiki
permet d’illustrer les tests avec des images ou
schémas

49. Conclusion/Objectifs
• ScrumMaster/coach :
o découvrir/imaginer les différents potentiels et variantes de ce jeu
• Product Owner / Business Analyst :
o ne jamais oublier l’importance des Critères d’Acceptance
• Equipiers :
o comprendre qu’il faut sans cesse clarifier les Critères d’Acceptance
• Tous :
o KISS
o Différence entre CA et TA ?
o ROI Automatisation si itératif, incrémental
o Importance de la Vision
o Envie d’en apprendre plus sur le TDD, ATDD, BDD
05/11/10
www.agiletour.org

50. Références
l’approche full mock de JB-Rainsberger
http://www.jbrains.ca/permalink/the-worlds-best-intro-to-tdd-demo-video
05/11/10
www.agiletour.org

51. ROTI (Return On Time Investment)
pour cette session
• Excellente
« Voilà une super session dont je vais bénéficier.
Ça valait plus que le temps que j’y ai passé »
• Bonne
« Voilà une session au-dessus de la moyenne.
J’ai passé un bon moment et j’ai gagné plus de temps
que j’y ai passé »
• Juste moyenne
« Je n’ai pas perdu mon temps, sans plus »
• Utile
« Ça ne valait pas à 100% le temps que j’y ai passé.
J’ai donc perdu du temps. »
• Inutile
« Je n’ai rien gagné, rien appris. J’ai vraiment perdu
mon temps. »

52. MERCI ! Merci à celles et ceux qui
sont venus jouer !!!
Un grand merci aux 4 personnes
qui ont joué le jeu du perfection
game et qui m’ont donné un
feedback aussi positif qu’agréable
qui vient récompenser tant de
préparation 
05/11/10
www.agiletour.org