lundi 12 octobre 2009
      agiletour.org/fr/at2009_geneve.html




                      C3
       Spécifications et Plann...
USER STORIES
                                  PLANNING GAME
                    Spécifications et Planning : exécution dan...
“To me, the most important single thing about XP and
                      Agile as a management process is the continuous...
Itératif




jeudi, 15 octobre 2009
 Un développement itératif découpe le projet en itérations.
 La taille dʼune itération...
Incrémental




jeudi, 15 octobre 2009
 Un développement incrémental implique de découper le logiciel
 en fonctionalités “...
Standup meeting




                                    Planning Poker

                                                  ...
Des spécifications exhaustives...




jeudi, 15 octobre 2009
 Des documents Word de plusieurs centaines de pages en début d...
USER STORY |                                                            |
                                   NOM (PL. -RIE...
User Story
                                              =
                                          Use Case
jeudi, 15 oc...
jeudi, 15 octobre 2009
Information Radiator




jeudi, 15 octobre 2009
 Un exemple dʼInformation Radiator.
 Lʼinformation nʼest pas enfermée dans...
UNE FORMULATION POUR
                                                    VOUS AIDER

                             As a cus...
L’essence d’une User Story ?




jeudi, 15 octobre 2009
“... possédant une suspension permettant de traverser un champ
  labouré avec un panier d'œufs sans en casser un seul,...”...
CCC
jeudi, 15 octobre 2009
Facile à manipuler,
                                                                     affichable sur un
                ...
Tous les détails ne sont pas présents dans la
                                                                            ...
Confirmation
                                                                                Quand pourra-t-on dire DONE/DO...
Qualités d’une “bonne” User Story



jeudi, 15 octobre 2009
INVEST
jeudi, 15 octobre 2009
INDEPENDENT
          Tellement plus facile à “manipuler” !
jeudi, 15 octobre 2009
2 User Stories peuvent nʼavoir de la va...
NEGOTIABLE
                                                                                                               ...
VALUABLE

                                                    Le “métier” décide !


jeudi, 15 octobre 2009
Même remarque ...
ESTIMATABLE

jeudi, 15 octobre 2009
                                                               “- Faites marcher le no...
SMALL


jeudi, 15 octobre 2009
Une User Story dont la complexité est trop importante doit être scindée en User Stories plu...
TESTABLE

jeudi, 15 octobre 2009
Qualité fondamentale !
Peut-on vérifier la User Story par une suite de Tests dʼAcceptation...
“Prediction is hard,
  especially about the future.”




                                  Niels Bohr
jeudi, 15 octobre 20...
puisque le futur est si difficile à
                                                         prédire,
                     ...
ESTIMATIONS



          User Story estimées en Story Points (pour déduire la velocité de l’équipe)

          Estimation ...
Estimer = comparer




jeudi, 15 octobre 2009
 Lʼutilisation dʼune échelle “à la Fibonacci” repose sur notre capacité à es...
STORY POINT



     •    Unité de taille relative utilisée pour estimer la difficulté/complexité
          d’une User Story...
PLANNING POKER



     •    Une conversation pour obtenir un consensus sur les estimation des User Stories.
          Les ...
Pour y
                          voir
                          plus
                          clair


jeudi, 15 octobre 2...
CHAQUE JOUR


                         daily scrum ou standup meeting (XP)
                         1- Hier, j’ai travaill...
PENDANT L’ITERATION




                         Burndown chart


jeudi, 15 octobre 2009
 Le principe est simple.
 On note...
ENTRE CHAQUE ITERATION


                                        RETROSPECTIVE


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



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




jeudi, 15 octobre 2009
atelier
jeudi, 15 octobre 2009
ATELIER : PLANNING GAME


                                     •   Présentation

                                     •   ...
•   La vision : une maison d’été, livrée dans 1 an.

                                                                •   L...
ATELIER : CONCLUSION



                         Conversation    Emergence

                         Story point    Conver...
Tous
                         ces changements !




jeudi, 15 octobre 2009
La valeur du planning dans un esprit XP n’est pas de
                rechercher une précision absolue au départ du projet....
La conversation est omni-présente.
                Elle permet de :
           • faire émerger ce qui a vraiment de la val...
REFERENCES

                         •   http://agilemanifesto.org/principles.html

                         •   http://ww...
REFERENCES


                         •   http://dannorth.net/introducing-bdd

                         •   Photos iStockP...
merci aux sponsors !
Prochain SlideShare
Chargement dans…5
×

Spécifications et Planning : éxecution dans un monde Agile

2 713 vues

Publié le

Stéphane TAVERA & Jacques COUVREUR

Publié dans : Technologie, Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
2 713
Sur SlideShare
0
Issues des intégrations
0
Intégrations
61
Actions
Partages
0
Téléchargements
107
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Spécifications et Planning : éxecution dans un monde Agile

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 10. jeudi, 15 octobre 2009
  11. 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. 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. 13. L’essence d’une User Story ? jeudi, 15 octobre 2009
  14. 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. 15. CCC jeudi, 15 octobre 2009
  16. 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. 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. 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. 19. Qualités d’une “bonne” User Story jeudi, 15 octobre 2009
  20. 20. INVEST jeudi, 15 octobre 2009
  21. 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. 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. 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. 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. 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. 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. 27. “Prediction is hard, especially about the future.” Niels Bohr jeudi, 15 octobre 2009
  28. 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. 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. 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. 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. 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. 33. Pour y voir plus clair jeudi, 15 octobre 2009
  34. 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. 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. 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. 37. La velocité est la seule mesure visible par votre client jeudi, 15 octobre 2009
  38. 38.      “The mind is not a vessel to be filled but a fire to be kindled.” Plutarch 46-119 jeudi, 15 octobre 2009
  39. 39. atelier jeudi, 15 octobre 2009
  40. 40. ATELIER : PLANNING GAME • Présentation • 1/2 : création des user stories • 1/2 : estimation • conclusion jeudi, 15 octobre 2009
  41. 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. 42. ATELIER : CONCLUSION Conversation Emergence Story point Convergence jeudi, 15 octobre 2009
  43. 43. Tous ces changements ! jeudi, 15 octobre 2009
  44. 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. 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. 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. 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. 48. merci aux sponsors !

×