Stéphane TAVERA & Jacques COUVREUR

1. lundi 12 octobre 2009
agiletour.org/fr/at2009_geneve.html
C3
Spécifications et Planning :
éxecution dans un monde Agile
Stéphane TAVERA & Jacques COUVREUR

2. USER STORIES
PLANNING GAME
Spécifications et Planning : exécution dans un monde Agile
Agile Tour 2009 / Genève
Jacques Couvreur
Stéphane Tavera
jeudi, 15 octobre 2009

3. “To me, the most important single thing about XP and
Agile as a management process is the continuous,
visible, delivery of features as specified by the
customer.”
Ron Jeffries, 10/21/2005
jeudi, 15 octobre 2009
La lecture des 12 principes derrière le manifeste Agile
(http://agilemanifesto.org/principles.html) montre que cʼest le coeur des méthodes Agile :
- délivrer régulièrement un logiciel qui a de la valeur pour le client

4. Itératif
jeudi, 15 octobre 2009
Un développement itératif découpe le projet en itérations.
La taille dʼune itération est généralement de 2 à 4 semaines.
Cette taille doit être gardée fixe.

5. Incrémental
jeudi, 15 octobre 2009
Un développement incrémental implique de découper le logiciel
en fonctionalités “métier”.
Cʼest le contraire du découpage traditionnel en réalisations de couches techniques.
“Build the infrastructure as you need it”.

6. Standup meeting
Planning Poker
User Stories
Planning Game
jeudi, 15 octobre 2009
Un petit peu de vocabulaire.
SCRUM et XP implémentent tous 2 un mode de développement itératif et incrémental.

7. Des spécifications exhaustives...
jeudi, 15 octobre 2009
Des documents Word de plusieurs centaines de pages en début de projet,
dans un jargon incompréhensible.
Cela vous rappelle quelque chose ?

8. USER STORY | |
NOM (PL. -RIES)
UNITÉ DE FONCTIONALITÉ VISIBLE PAR LE CLIENT.
Kent Beck
“eXtreme Programming explained” 2nd edition
jeudi, 15 octobre 2009
Une User Story raconte ce que fera le système, dans le vocabulaire du client.
Mettre en place une nouvelle version dʼune base de données nʼest pas une User Story.

9. User Story
=
Use Case
jeudi, 15 octobre 2009
Dans certains cas, une User Story peut coller avec un Use Case.
Cependant, la User Story :
- a un vocabulaire “métier” vs un vocabulaire “système”
- cʼest lʼexpression dʼun but, pas la représentation idéale dʼune solution.
- représente généralement plusieurs Use Cases

10. jeudi, 15 octobre 2009

11. Information Radiator
jeudi, 15 octobre 2009
Un exemple dʼInformation Radiator.
Lʼinformation nʼest pas enfermée dans un “frigidaire” (un outil qui demande
une recherche explicite).
Au contraire, lʼinformation rayonne.

12. UNE FORMULATION POUR
VOUS AIDER
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at
the bank.
jeudi, 15 octobre 2009
Cette formalisation très “industrielle” a plusieurs avantage :
- lʼemphase est mise sur lʼutilisateur. Différents utilisateurs peuvent avoir
des besoins *trés* différents !
- cette contrainte de formalisation permet de détecter des User Stories faibles :
- trop vague, peu de valeur “métier”, imprécision du but recherché.
Il nʼest pas obligatoire de lʼemployer systématiquement.
Voir Behaviour Driven Development (BDD, cf références)
Voir la technique “Personae”.

13. L’essence d’une User Story ?
jeudi, 15 octobre 2009

14. “... possédant une suspension permettant de traverser un champ
labouré avec un panier d'œufs sans en casser un seul,...”
Pierre Boulanger
dirigea Citroën de 1935 à 1950
jeudi, 15 octobre 2009
Le besoin est exprimé, pas la solution.
Le test est implicite.
pour les plus curieux :
http://fr.wikipedia.org/wiki/Citroën_2CV

15. CCC
jeudi, 15 octobre 2009

16. Facile à manipuler,
affichable sur un
”information radiator”.
Card
jeudi, 15 octobre 2009
Attention à ne pas suivre à la lettre.
Card implique que ça doit tenir sur une carte.
Un outil collaboratif, en ligne, peut sʼavérer plus pratique.
Ce qui est important cʼest lʼabsence de détails ici.

17. Tous les détails ne sont pas présents dans la
User Story.
La connaissance est transférée du “métier”
vers l’équipe de développement pendant la
réalisation.
Conversation
jeudi, 15 octobre 2009
- le moyen le plus efficace de diffusion de lʼinfo est par le biais de dialogues, fréquents et réguliers.
- des idées dʼamélioration peuvent survenir pendant cette discussion.
Aucune interdiction de faire référence à des documents, qui eux vont contenir des précisions complémentaires.
(la solution idéale étant quand même dʼexprimer ces précisions par des tests dʼacceptation).

18. Confirmation
Quand pourra-t-on dire DONE/DONE ?
jeudi, 15 octobre 2009
Lʼexpression Done/Done signifie complétement terminée.
Pourrait-on vraiment mettre la User Story en production ?
La User Story doit donc contenir des pointeurs vers des tests dʼacceptation.
(cf le T. dʼINVEST)

19. Qualités d’une “bonne” User Story
jeudi, 15 octobre 2009

20. INVEST
jeudi, 15 octobre 2009

21. INDEPENDENT
Tellement plus facile à “manipuler” !
jeudi, 15 octobre 2009
2 User Stories peuvent nʼavoir de la valeur que livrées ensemble.
Par contre, elles doivent être “manipulées” dans lʼexercice de planification
comme étant indépendantes.

22. NEGOTIABLE
Laisser la possibilité d’ajuster.
jeudi, 15 octobre 2009
Attention aussi, à ce que chacun reste dans sa zone de responsabilité.
Une User Story ne devrait pas contenir de détails techniques dʼimplémentation (“je veux ce bouton à 45 pixels du bord droit”).
De plus, préciser complétement les choses avant la réalisation peut aboutir à :
- une divergence entre la réalisation et les specs
- fermer la porte à des idées dʼamélioration ou dʼadaptation

23. VALUABLE
Le “métier” décide !
jeudi, 15 octobre 2009
Même remarque : attention aussi, à ce que chacun reste dans sa zone de responsabilité.
Une User Story ne doit pas être exprimée par lʼéquipe de développement.
Exemple : “Changer de version de librairie pour tel ou tel composant”.

24. ESTIMATABLE
jeudi, 15 octobre 2009
“- Faites marcher le nouveau système
comme l’ancien.
- Mais, hé ! Je n’en ai aucune idée! “
Lʼéquipe de développement doit avoir les éléments dʼinformation suffisantes pour estimer la complexité de
réalisation.
?

25. SMALL
jeudi, 15 octobre 2009
Une User Story dont la complexité est trop importante doit être scindée en User Stories plus
petites.

26. TESTABLE
jeudi, 15 octobre 2009
Qualité fondamentale !
Peut-on vérifier la User Story par une suite de Tests dʼAcceptation ?
Attention à lʼexpression dʼun besoin avec des termes subjectifs.
RSPEC/Cucumber (dans le monde Ruby) est un fantastique exemple.
Un framework pour décrire (et exécuter) des tests dʼacceptation.
Je veux des beaux écrans.
?

27. “Prediction is hard,
especially about the future.”
Niels Bohr
jeudi, 15 octobre 2009

28. puisque le futur est si difficile à
prédire,
pourquoi ne pas regarder le
yesterday’s weather ... ?
jeudi, 15 octobre 2009
“Some country decides to build a sophisticated computer system to predict the weather. After spending more money than I can imagine, they come up with wonderful result - and proudly claim that the system is 70% accurate. Somebody
then figures out that in this country if you predict today's weather will be the same as yesterday's weather you will be 69.5% accurate.”
Se fier à des problèmes de difficultés similaires pour estimer.
Ne pas espèrer de changement “radical” dʼune itération sur lʼautre.

29. ESTIMATIONS
User Story estimées en Story Points (pour déduire la velocité de l’équipe)
Estimation des tasks en Heures (pour détecter les goulots d’étranglements)
jeudi, 15 octobre 2009
2 niveaux dʼestimation.
Les User Stories sont estimées en Story Points.
Les tasks sont estimées en heures.
Si vous pouvez mesurer le temps effectif passé sur chaque task,
la comparaison avec son estimation révèlera les goulots dʼétranglements.

30. Estimer = comparer
jeudi, 15 octobre 2009
Lʼutilisation dʼune échelle “à la Fibonacci” repose sur notre capacité à estimer des ordres de grandeur,
et notre incapacité à être plus précis.
A quelle distance se trouve le 1er arbre ?
A quelle distance se trouve le 1er immeuble ?
Questions délicates !
Les arbres au premier plan sont-il “à peu près” à la même distance ? OUI.

31. STORY POINT
• Unité de taille relative utilisée pour estimer la difficulté/complexité
d’une User Story.
• Utilisation d’une pseudo-échelle de Fibonacci. Par exemple : 1, 2, 3, 5 et 8
jeudi, 15 octobre 2009
Vos estimations en Story Point de chaque User Story
seront sans doute fausses, *individuellement*.
En moyenne, cependant, ces erreurs se compensent.
Après quelques itérations, vous devriez avoir *confiance* dans votre capacité à délivrer
X fonctionnalités en une itération.

32. PLANNING POKER
• Une conversation pour obtenir un consensus sur les estimation des User Stories.
Les participants sont les personnes en charge de la réalisation.
jeudi, 15 octobre 2009
Ce jeu est un déclencheur de conversations, de confrontations de points de vue sur le travail à
faire.

33. Pour y
voir
plus
clair
jeudi, 15 octobre 2009

34. CHAQUE JOUR
daily scrum ou standup meeting (XP)
1- Hier, j’ai travaillé sur ...
2- Aujourd’hui, je vais faire ...
3- Ce qui me retarde en ce moment, c’est...
jeudi, 15 octobre 2009

35. PENDANT L’ITERATION
Burndown chart
jeudi, 15 octobre 2009
Le principe est simple.
On note réguliérement le reste à faire (courbe rouge),
sur un graphe qui comporte tout le travail à faire pour cette itération et
la date de fin.
La courbe orange représente un développement linéaire et idéal.
Cette courbe est aussi un révélateur de dysfonctionnements :
cf http://alistair.cockburn.us/Earned-value+and+burn+charts

36. ENTRE CHAQUE ITERATION
RETROSPECTIVE
jeudi, 15 octobre 2009
La rétrospective est une activité indispensable dans lʼAgilité.
Inspect and Adapt !
http://agile-alchemist.com/

37. La velocité est la seule mesure
visible par votre client
jeudi, 15 octobre 2009

38.
“The mind is not a vessel to be filled but a fire to be kindled.”
Plutarch 46-119
jeudi, 15 octobre 2009

39. atelier
jeudi, 15 octobre 2009

40. ATELIER : PLANNING GAME
• Présentation
• 1/2 : création des user stories
• 1/2 : estimation
• conclusion
jeudi, 15 octobre 2009

41. • La vision : une maison d’été, livrée dans 1 an.
• Le nom : Le Pélican Rose
• Les personnaes :
• Jacques : aime les barbecues dans le jardin, le
cinéma, travaille de temps en temps à la maison,
du coup pas le temps de bricoler, branché high-
tech, domotique et énergies propres.
• Stéphanie : aime la mer, faire la cuisine, prendre
de longs bains mais ne passe pas beaucoup de
temps dans la chambre. Infirmière de profession,
c’est une obsédée de l’hygiène.
• Uminonaka : leur enfant, 1 ans 1/2. Dés qu’il
voit de l’eau il fonce dessus !
• Moreno : le pote d’enfance, qui s’installe de
temps en temps et fouille partout.
jeudi, 15 octobre 2009
« Umi no naka » veut dire dans lʼeau (de mer) en japonais...

42. ATELIER : CONCLUSION
Conversation Emergence
Story point Convergence
jeudi, 15 octobre 2009

43. Tous
ces changements !
jeudi, 15 octobre 2009

44. La valeur du planning dans un esprit XP n’est pas de
rechercher une précision absolue au départ du projet.
Les buts recherchés sont
- délivrer régulièrement selon les priorités “métier”
- avoir une vision réaliste et temps réel de l’avancement
- avoir confiance sur ce qui peut être effectivement délivré
(après quelques itérations)
jeudi, 15 octobre 2009
Abandon de la “fausse” précision dʼun calcul précis au niveau des tasks.
Le planning nʼest pas figé, mais peut être réaménagé en fonction
- des priorités “métier”
- de la montée en connaissance de lʼéquipe de développement

45. La conversation est omni-présente.
Elle permet de :
• faire émerger ce qui a vraiment de la valeur.
•diffuser efficacement la connaissance.
jeudi, 15 octobre 2009

46. REFERENCES
• http://agilemanifesto.org/principles.html
• http://www.mountaingoatsoftware.com/
• http://xprogramming.com/index.php
• http://xprogramming.com/xpmag/expCardConversationConfirmation
• Agile Estimating and Planning” and “User Stories Applied For Agile Software
Development”
http://www.mountaingoatsoftware.com/books
jeudi, 15 octobre 2009

47. REFERENCES
• http://dannorth.net/introducing-bdd
• Photos iStockPhoto, sauf
2cv http://image.blog.livedoor.jp/decobocobo/imgs/f/c/fc6424c1.jpg
• http://fr.wikipedia.org/wiki/Citroën_2CV
jeudi, 15 octobre 2009

48. merci aux sponsors !