L'art du maniement des exigences agiles

8 883 vues

Publié le

Sessions B2B (Back to Basic) sur le Story Mapping et les User Story présentée au Scrum Day France 2015

0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
8 883
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5 386
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

L'art du maniement des exigences agiles

  1. 1. Alexandre Boutin Du Story Mapping aux User Story L’art du maniement des exigences agiles
  2. 2. MERCI À NOS SPONSORS et partenaires
  3. 3. Alexandre BOUTIN Conférencier Co-Auteur Formateur / Coach’Agile Fédéré « Touiteur » Blogueur www.agiletoyou.com www.agilex.fr @agilex Associatif
  4. 4. Voici un produit
  5. 5. Voici des itérations
  6. 6. Comment faire ?
  7. 7. Quelques idées
  8. 8. Résultat obtenu
  9. 9. Ce que l’on voudrait Faire grossir le produit Comme une goutte d’eau
  10. 10. Comment faire ?
  11. 11. Objectifs du Story Mapping – Rendre visible le flux de production de valeur – Montrer les relations entre les fonctionnalités principales et leur décomposition – Aider à vérifier la complétude du besoin fonctionnel – Fournir un support simple à la priorisation – Permettre de s’assurer de la cohérence des Releases planifiées Crédit photo : Alexandre Boutin
  12. 12. Autre points de vue
  13. 13. Construire un Story Mapping • Décrire comment chaque utilisateur va utiliser le produit au fil du temps – Classer les usages de gauche à droite, dans l’ordre qui vous vient à l’esprit lorsque quelqu’un vous demande « Que fait cette personne avec votre produit ?» « Que fait-elle ensuite ? » Temps
  14. 14. • Décomposer les usages • Garder la cohérence en vertical Temps Construire un Story Mapping
  15. 15. L’approche Story Mapping Quelles sont toutes les choses que vous avez fait aujourd’hui pour être présent dans cette salle ? – Commencez au moment de votre réveil – Finissez à maintenant 18
  16. 16. Quelques exemples Crédit photos : Alexandre Boutin
  17. 17. Trucs et astuces • Ne pas être trop strict sur l’organisation temporelle • Alterner entre la discussion sur les usages et leur décomposition • Créer une nouvelle colonne s’il y a beaucoup d’éléments dans la décomposition • Ecrire lisiblement  • Ne pas hésiter à réécrire un postIt et à jeter le précédent
  18. 18. Le Story Mapping se pratique avec les utilisateurs Le Story Mapping concentre les énergies et génère des discussions riches sur le produit Crédit photo : Alexandre Boutin
  19. 19. Vérifier la complétude • Chaque type d’utilisateur doit pouvoir « sortir » du Story Mapping avec de la valeur produite Crédit photo : Jeff Patton « User Story Mapping » What-About ? Game
  20. 20. Un Story Mapping prend de la place • Pour un projet raisonnablement complexe, il faut souvent plusieurs murs Crédit photo : Alexandre Boutin Crédit photo : Alexandre Boutin
  21. 21. • Ajouter un axe supplémentaire Temps Nécessité Prioriser avec le Story Mapping - +
  22. 22. • Faire glisser les fiches vers le bas et définir des versions Temps Nécessité V1 Prioriser avec le Story Mapping V2+
  23. 23. Prioriser par les bénéfices Les produits à usage interne génèrent des économies financières ou aident à améliorer les services supports aux utilisateurs. Les produits à usage externe génèrent des revenus financiers, augmente la fidélisation ou l’engagement des utilisateurs Les bénéfices du produit sont spécifiques à ce produit et à chaque utilisateur. Un objectif générique comme “gagner plus d’argent” n’est pas exploitable. Le modèle de valeur du produit, utilisé pour la priorisation, est basé sur ces bénéfices spécifiques. Les bénéfices sont la raisons d’être du produit. Ils sont identifiés en regardant comment travaillent les utilisateurs, en imaginant d’autres façons de le faire ou en créant un nouvel usage.
  24. 24. Quelques exemples Crédit photo : Alexandre Boutin
  25. 25. Trucs et astuces • Faire descendre plus de la moitié des PostIt • Rassurer les utilisateurs et stakeholders • Préciser que ce qui est descendu sera fait … mais plus tard • Préciser que moins il y a de choses dans la V1 et plus vite le produit sera mis en production • Adopter une approche minimaliste • MVS : Minimum Viable Solution (qui peut être validée)
  26. 26. Pour aller plus loin Jeff Patton
  27. 27. Quel rapport avec notre problème ?
  28. 28. Bénéfices du Story Mapping • Le découpage est réalisé de façon cohérente avec les participants • Les éléments identifiés sont indépendants (ou presque) • Les éléments de plus haute priorité sont identifiées • Le sous ensemble identifié (MVP) est complet et offre de la valeur aux utilisateurs
  29. 29. Du Story Mapping aux User Story User Story 1 User Story 2 User Story 3 Elément du Story Mapping
  30. 30. Une User Story est à usage multiple Une User Story c’est : – Un besoin utilisateur – Une description du Produit – Un élément de planification – Un support à l’échange – Un mécanisme pour retarder la conversation Kent Beck utilise le terme user story dans son livre “Extreme Programming Explained“1er Edition, 1999
  31. 31. Une User Story est un outil pour faciliter la conversation entre différentes personnes Utilisateur Comment décrire ce que j’attends vraiment ? Comment puis-je comprendre les utilisateurs et leurs besoins ? Ergonome Quels détails de cette fonctionnalité dois-je expliciter ? Business Analyst Sur quels éléments dois-je travailler aujourd’hui ? Développeur Comment puis-je vérifier que le produit satisfait l’utilisateur ? Testeur Comment savoir la valeur que produisent mes équipes ? Manager Quels sont les éléments qui feront de mon produit un succès commercial ? Marketing
  32. 32. Les « 3C » de Ron Jeffries C C C C C Carte Conversation ConfirmationExtrait de “Extreme Programing Installed” de Ron Jeffries
  33. 33. Une Story commence simplement Commencer avec un titre Ajouter une description succincte en utilisant ce format très pratique : En tant que [type d’utilisateur] Je veux [faire quelque chose] Pour [atteindre un but spécifique] Ajouter des choses utiles comme des notes, des règles de gestion, ou des visuels Carte
  34. 34. Partager les User Story Seul dans son bureau, le Product Owner rédige toutes les User Story nécessaires au projet La conversation est un élément fondamental de l’écriture des User Story Claude Aubry : « Scrum : le guide pratique de la méthode agile la plus populaire » Edition 3
  35. 35. Une Story évolue avec le temps Conversation Utilisateurs EquipiersSponsors Experts
  36. 36. Une Story se termine • Plusieurs techniques – Critères d’acceptation – Tests d’acceptation Confirmation Voici ce que nous pensons vous montrer lorsque nous aurons fini d’implémenter cette Story, êtes-vous d’accord ? Equipiers
  37. 37. Exemple de Critères d’acceptation • Le pied de l’arbre est enterré • Un engrais naturel est déposée au fond du trou • La terre est tassée après la plantation • La plantation est abondamment arrosée
  38. 38. Critères d’acceptation à éviter • Le trou fait 60 cm de diamètre et 80 cm de profondeur • L’arbre est planté droit • La pelouse est tondue autour de l’arbre • Le panier pour récolter les fruits est acheté
  39. 39. Une User Story est orientée utilisateur • La mise à disposition d’une User Story impacte l’utilisateur • Raisonner « Valeur pour l’utilisateur » et non « Moyen de le faire » Qu’est ce qui est important : Le moyen de faire le trou ou l’arbre ?
  40. 40. 2 erreurs classiques Confondre Livrable et Résultat Points gagnés ≠ Valeur utilisateur Conformité objective User Story ≠ Contrat
  41. 41. Story fonctionn elle Correction de bug Story technique Rembt de dette technique Les types de story Ajoute de la valeur Rétablit la valeur Visible des stakeholders Visible des équipiers Definition of Done
  42. 42. Quel rapport avec notre problème ?
  43. 43. Bénéfices des User Story • Elles apportent de la valeur aux utilisateurs • L’effort pour s’accorder sur une Story est raisonnable (conversation) • Elles sont indépendantes fonctionnellement • Elles sont petites et peuvent être terminées en 1 itération
  44. 44. Soyez sensible à l’altitude * * Extrait de “Writing Effective Use Cases” d’Alistair Cockburn “Sea level” Je peux raisonnablement espérer réaliser cela en 1 seule opération fonctionnelle “Fish level” Un élément qui ne veut pas dire grand-chose unitairement. J’en ferais plusieurs pour réaliser une opération fonctionnelle “Kite level” Objectifs à long terme, souvent sans aucune fin précise. Je vais effectuer plusieurs opérations fonctionnelles dans mon contexte professionnel Trop abstraite Trop détaillée Pensez feedback utilisateur à ce niveau
  45. 45. Un peu de concret Fruits naturels En tant que jardinier du dimanche Je veux manger des fruits naturels Pour me faire du bien Fruits de mon jardin En tant que jardinier du dimanche Je veux récolter les fruits de mon jardin Pour les manger Planter un arbre fruitier En tant que jardinier du dimanche Je veux planter un arbre fruitier Pour récolter des fruits prochainement Creuser un trou En tant que jardinier du dimanche Je veux creuser un trou Pour planter un arbre Avoir une pelle En tant que jardinier du dimanche Je veux une pelle à bout carré Pour creuser un trou de 80 cm
  46. 46. Faire petit pour aller vite et prendre tôt du feedback « Size Matters » Planter un arbre fruitier En tant que jardinier du dimanche Je veux planter un arbre fruitier Pour récolter des fruits prochainement
  47. 47. Bien découper une User Story User Story Trop Grosse User Story 3 User Story 1 User Story 2 Couche 1 Couche 2 Couche 3 User Story 1 (Orientée Utilisateur)
  48. 48. Etapes pour découper une Story INVEST DECOUPERSPIKE EVALUER
  49. 49. Techniques de découpage
  50. 50. S’entrainer à l’écriture de User Story
  51. 51. Alexandre Boutin Du Story Mapping aux User Story L’art du maniement des exigences agiles

×