Post on 25-Dec-2014
description
transcript
Et si on Jouait au TDD ?
Librement inspiré du jeu “99 tests balloons”*
François-Xavier Maquaire
*Jeu créé par Michael McCullough : http://tastycupcakes.org/2009/06/99-test-balloons/
This content is licensed under a Creative Commons Attribution 3.0 License.fmaquaire@gmail.com
remercie pour l’organisation de
ses sponsors pour leur soutien
FX
François-Xavier MAQUAIRE
Ils ne savaient pas que c’était impossible alors ils l’ont fait. Mark Twain.
34 ansThales Services RennesAgiliste depuis 2009 Coach et formateur (Scrum, Kanban)Référant agile (Communauté Agile Thales Services)Co-organisateur Agile Tour Rennes 2013francois-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.
Persona
PartagerEchangerConfronterCommuniquerJouerS’amuser
Introduction• Cette session n’est pas :
o Un coding dojoo Un retour d’expérience o Animé par un expert du TDD
• C’est un JEU !• Objectifs ?
o Passer un bon momento … o Voir la conclusion
www.agiletour.org05/11/10
Le jeu
• Formons les équipesoUn facilitateur par équipeoUn nom d’équipeoUn espace de démonstration par équipe
•Un tableau pour compter les points•Un tableau pour le debrief•Feedback Door
Le jeu• Déroulemento 4 itérations de 11 minuteso 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’
www.agiletour.org05/11/10
On ne touche à rien en dehors des phases de réalisation = chrono déclenché !
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
www.agiletour.org05/11/10
Démo
• Le client accepte ou non les livraisons
• Le facilitateur de chaque équipe va reporter les points
www.agiletour.org05/11/10
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
www.agiletour.org05/11/10
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)
Debrief Itération 1
KISS !!!!
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 !
www.agiletour.org05/11/10
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
www.agiletour.org05/11/10
Alternance des dessins sur les ballonsreliés par une ficelle
Les dessins
Critères d’acceptance ?
www.agiletour.org05/11/10
CA Dessin
10 cm1 cm
4,5 cm
3 cm
1 cm
2,5 cm
4,5 cm
3 cm
3 cm
3 cm
4 cm
4,5 cm
4,5 cm
Démo
• Le client accepte ou non les livraisons
• Le facilitateur de chaque équipe va reporter les points
www.agiletour.org05/11/10
Debrief
• 2’ chaque équipe discute des problèmes rencontréso 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
www.agiletour.org05/11/10
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’Acceptationo 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 ?
Debrief Itération 2
Critères d’acceptance !
+ niveau de qualité !
CODEZ ECOLO !
• « réduisez vos déchets en commençant par écrire vos tests »©
© : citation de Mathieu Cans
Les dessins
Itération 3
• Discutons Critères d’Acceptation et Tests d’Acceptation, afin de :o Rendre explicites les critères d’acceptation avec le POo Travailler sur des Tests d’Acceptationo Expérimenter le TDD
• 2 minutes de temps de production
Démo
• Le client accepte ou non les livraisons
• Le facilitateur de chaque équipe va reporter les points
www.agiletour.org05/11/10
Debrief
• 2’ chaque équipe discute des problèmes rencontrés et des points positifso 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
www.agiletour.org05/11/10
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 ?
Debrief Itération 3
Tests d’acceptance =
maitrise de la qualité
Test Driven Development
TDD
Le test est au vert
Ecriture du code
Modification du code
Passage des Tests jusqu’à réussite complète
Le test est au rouge
Ecriture des Tests (design de l’application)
Passage des Tests
Restructuration du code
Reprendre le code pour le simplifier et le rendre aisément maintenable
Les tests restent au vert
Test Driven Developpement (TDD)
1. Conceptiondes tests
2. Automatisationdes tests
3. Développementlogiciel
4. Exécutionautomatiquedes tests
Sprint #1
#2
#n
Itération 4
• Dernière itération !o Itératifo Incrémentalo Résultat final !
• 2 minutes de production
Bleu = non soumis à des tests d’acceptation
Démo
• Le client accepte ou non les livraisons
• Le facilitateur de chaque équipe va reporter les points
www.agiletour.org05/11/10
Debrief
• 2’ chaque équipe discute des problèmes rencontrés, ou des bonnes pratiques perçueso 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
www.agiletour.org05/11/10
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é
Debrief Itération 4
VISION !
• Le TDD quand on commence on se demande comment faire.
• Quand on sait faire, on se demande comment on a pu s'en passer.
REX sur le TDDThales Grenoble Mathieu Cans
www.agiletour.org05/11/10
Passage du test traditionnel à l’approche full mock de JB-Rainsberger
Couverture de ~80% de tests Unitaires :Enfin !
Chute de la complexité par classe
Pyramide de test de Mike Cohn
•Nombre faible : 1 à 5%Le plus automatisé possibleOutil : Selenium Tests
IHM
Au moins un par user story : 5 à 15%AutomatisésOutil : FitNesse ou GreenPepper
Au moins un par classe ou module : 80 à 90 %AutomatisésOutil : JUnit
Tests Fonctionnels
Tests Unitaires
Ref : Succeeding with agile Mike Cohn
Source : http://blog.mountaingoatsoftware.com/the-forgotten-layer-of-the-test-automation-pyramid
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’exempleo 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
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 KISSo Différence entre CA et TA ?o ROI Automatisation si itératif, incrémentalo Importance de la Visiono Envie d’en apprendre plus sur le TDD, ATDD, BDD
www.agiletour.org05/11/10
Références
www.agiletour.org05/11/10
http://www.jbrains.ca/permalink/the-worlds-best-intro-to-tdd-demo-video
l’approche full mock de JB-Rainsberger
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. »
MERCI ! Merci à celles et ceux qui sont venus jouer !!!
www.agiletour.org05/11/10
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