Emmanuel HUGONNET

1. lundi 12 octobre 2009
agiletour.org/fr/at2009_geneve.html
B6
Soigner sa schizophrénie MOA/MOE
Voyage au pays des spécifications exécutables
Emmanuel HUGONNET

2. Soigner sa schizophrénie
MOA / MOE
Voyage autour des
spécifications exécutables
Emmanuel Hugonnet Rémy Sanlaville
Architecture J2EE Expert Senior en Ingénierie Logicielle
Silverpeas Orange Labs
emmanuel.hugonnet@silverpeas.com remy.sanlaville@orange-ftgroup.com
Hervé Lourdin
Architecte Sénior / Coach agile
OCTO Technology
hlourdin@octo.com

3. Contrat de la session
Ce que vous verrez dans cette session
• Une introduction aux spécifications exécutables ?
• A quoi ca sert, pourquoi c'est utile…
• Vivre un exemple basé sur la fonctionnalité d'authentification
• Un panorama du domaine
• outils existants : approches, les avantages et inconvénients
• les père fondateurs
Ce que vous ne verrez pas dans cette session
• Une démonstration des outils
• cf. session Coding Dojo - Kata sur le pilotage par les tests
d'acceptances (ATDD)
• Une solution magique à tous vos problèmes

4. Double Personnalité
Double Audience
MOA MOE
"Stakeholders are the people
whose life you touch with your
software"
Dan North

5. Deux hémisphères
MOA MOE
Idées Architecture
Métier Technique
Valeur Artisanat
Ce qu’il faut faire Bien faire

6. Un problème de communication

7. Communication
MOA MOE
Client
Insatisfaction
Besoin
Couvert
exprime
décrit
comprend
délivre Gaspillage

8. Fonctionnalités
et leur utilisation
pour un logiciel
Source CHAOS

9. Communication
Définition de "terminé"
MOA MOE

10. ATDD cycle model by Jim Shore with changes suggested by
Grigori Melnick, Brian Marick, and Elisabeth Hendrickson

11. Ensemble tout devient possible
Atelier de spécifications
Bug Bash copyright by Hans Bjordahl — www.bugbash.net

12. ATDD cycle model by Jim Shore with changes suggested by
Grigori Melnick, Brian Marick, and Elisabeth Hendrickson

13. Given …
Un Langage
When … Commun
Then …
External
Domain Specific Language

14. Spécifier par l’exemple
Les histoires d’utilisateur sont décrites au
travers d’exemples : les scénarii
Les utilisateurs doiven
t utiliser des mots
de passe sécurisés
(une chaine de caractère
s dont la taille est
comprise entre 8 et 20
Et qui contiennent au m
oins une lettre, un
chiffre et un caractère s
pécial)

15. Atelier de Spécifications
Discussion
Que ce passe t'il si un utilisateur entre un mot de
passe non sécurisé ?
Pouvez vous me donner des exemples de mots de
passe sécurisés et non sécurisés ?
Quels sont les caractères spéciaux ?
Comment prend on en compte les espaces ?
Que fait on pour les mots de passe basés sur un
dictionnaire avec une substitution simple comme
‘p@ssw0rd’ ?
Comment gère t on les comptes existants ?
Comment savoir que cette fonction est "terminée" ?

16. Atelier de spécifications
Discussion
Que ce passe t'il si un utilisateur entre un mot de
passe non sécurisé ?
Pouvez vous me donner des exemples de mots de
passe sécurisés et non sécurisés ?
Quels sont les caractères spéciaux ?
Comment prend on en compte les espaces ?
Que fait on pour les mots de passe basés sur un
dictionnaire avec une substitution simple comme
‘p@ssw0rd’?”
Comment gère t on les comptes existants ?
Comment savoir que cette fonction est "terminée" ?

17. Les scénarii
Etant donné un nouvel Etant donné un nouvel
Utilisateur Utilisateur
Lorsqu'il crée un compte Lorsqu'il crée un compte
avec un mot de passe avec un mot de passe non
sécurisé sécurisé
Alors le message 'SUCCESS' Alors le message 'FAILURE'
apparait apparait
Et lorsqu'il essaye de se Et lorsqu'il essaye de se
connecter sur ce compte connecter sur ce compte
Alors le message 'Hello Alors il n'y parvient pas et
$login' apparait le message 'FAILURE'
apparait

18. Exemples
• Exemples de mots de passe sécurisé
– p@ssw0rd
– d1ction n@ire
– dictionnaire_01
• Exemples de mots de passe non sécurisés
– Trop court: p@sw0r
– Trop long: dictionnaire_01_ dictionnaire_01
– Sans chiffre: p@ssword
– …

19. L’information circule

20. ATDD cycle model by Jim Shore with changes suggested by
Grigori Melnick, Brian Marick, and Elisabeth Hendrickson

21. Scénarii Distillés

22. Exemples

23. ATDD cycle model by Jim Shore with changes suggested by
Grigori Melnick, Brian Marick, and Elisabeth Hendrickson

24. Développer
ATDD / BDD : bien faire ce que je dois faire
Le métier pilote le développement
TDD : bien faire les choses
Émergence du design

25. On commence au Rouge

26. Il manque la Fixture
Fixture: code de liaison entre le test (les tableaux) et le code du sysème testé (SUT)

27. Ecriture de la Fixture

28. Prêt à Développer

29. Première Etape

30. TDD – Ecriture du Test

31. TDD – Ecriture du Code

32. Vérification Fonctionnelle

33. Fonctionnalité Terminée

34. Les tests d'acceptance
sont le scanner du projet
Les exemples
permettent de
prouver
"scientifiquement"
la théorie du
développeur

35. Enfin les tests : l’exploration
Aspect Métier
Te
e s
nc ts
Support du Développement
a Ex
e pt pl
cc or
at
d'A
Critique du Produit
s oi
re
st s
Te
Di
Sc spo
s Sé ala nib
ire n cu bi ili
ta o rit lité té
U ni rati é
t s tég …*
es d'In ité
T
et
Aspect Technologique

36. Rendre les spécifications
exécutables
Différentes approches
– Proche du code
• JBehave, Rspec, Easyb…
– Format moins technique
• Wiki : Fitnesse/SLIM, GreenPepper…
• HTML : Concordion, Robotframework…
– De nouveaux outils en cours de maturation
• Twist, JBehave 2…

37. Les Pères Fondateurs
• JBehave : Dan North, Chris Matt
• Test Driven Development: Kent Beck
• FIT: Ward Cunningham
• Example Driven Development: Brian
Marick
• User Stories: Mike Cohn
• Domain Driven Design: Eric Evans
• Test Obsessed: Elisabeth Hendrickson

38. Bilan
Une meilleure communication entre les
différents acteurs du projet
• Discuss : tous ensemble
• Distill : définition par l'exemple
• Develop : pilotage par l'exemple - "FAIT"
• Demo : Validation
Bref, une seule équipe

39. Perspectives
Emergence d'une nouvelle génération
d'outils pour relever de nouveaux défis
• Intégration au cycle de vie du projet (SCM)
• Facilité de prise en main par la MOA
• Meilleure Intégration avec les outils de
développement
• Rapports plus complets (couverture des
exigences, évolution dans le temps…)

40. ROTI
(Return On Time Invested)

5 doigts : Excellente
Super c'est exactement ce qu'il me fallait !

4 doigts : Bonne
Très intéressant,

3 doigts : Juste Moyenne
Intéressant, sans plus. Je n’ai pas perdu mon
temps.

2 doigts : Utile
Bof ! J'ai perdu du temps.

1 doigt : Inutile
Je n'ai rien appris. J’ai vraiment perdu mon temps

41. merci aux sponsors !