Oeil user story_bonnes_pratiques_Martial_SEGURA oeildecoach.com
•Transferir como PPTX, PDF•
0 gostou•754 visualizações
USER STORIES de A à US ou Comment comprendre et s’améliorer dans la rédaction des User Stories ? Sommaire : > Les origines des User Stories > Définition d’une User Story > Méthode INVEST > Erreurs à éviter Présentation en libre téléchargement , créée par Martial SEGURA
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Oeil user story_bonnes_pratiques_Martial_SEGURA oeildecoach.com
Semelhante a Oeil user story_bonnes_pratiques_Martial_SEGURA oeildecoach.com (20)
Oeil user story_bonnes_pratiques_Martial_SEGURA oeildecoach.com
- 1. 1 © http://www.oeildecoach.com 1 ou Comment comprendre et s’améliorer dans la rédaction des User Stories ? USER STORIES de A à US
- 2. 2 © http://www.oeildecoach.com Les origines des User Stories Définition d’une User Story Méthode INVEST Erreurs à éviter Conclusion Sommaire
- 3. 3 © http://www.oeildecoach.com des User Stories Les origines
- 5. 5 © http://www.oeildecoach.com Un peu d’Histoire… Dinosaures Préhistoire 2001 JC 0 Moyen Age & Cycle en V Matrice rôle-fonctionnalité de Rachel Davies & Tim McKinnon en 2001 2001 Les « 3C » Ron Jeffries Extreme programming 2006 Matrice given-when-then décrivant les tests de recette par Dan North 2003 Grille INVEST par Bill Wake "INVEST in Good Stories and SMART tasks" Modernité & agilité JCVD 2004
- 6. 6 © http://www.oeildecoach.com Suite à l’arrivée de l’Agilité Finalement, c’est comme avant : – Recueil des besoins – Recherche d’idées innovantes – Groupes de réflexion + ateliers de travail Cependant, – On ne cherche plus à tout définir à l’avance – On commence par ce qui a le plus de valeur – On se concentre sur le point de vue de l’utilisateur – On affine le besoin directement avec les développeurs
- 7. 7 © http://www.oeildecoach.com Les débuts des User Stories … C’EST L’HISTOIRE D’UN MEC …
- 8. 8 © http://www.oeildecoach.com Les 3 C de Ron JEFFRIES Ron JEFFRIES Carte • Les Stories sont traditionnellement écrites sur des cartes • Les cartes peuvent être annotées avec des estimations, des commentaires, des critères d’acceptation, etc. Conversation Les détails derrières les cartes peuvent être étudiés durant les conversations avec le Product Owner (PO) Confirmation La validation des tests confirme que les stories ont été développées correctement
- 9. 9 © http://www.oeildecoach.com des User Stories La définition
- 10. 10 © http://www.oeildecoach.com « » Une user story est une invitation à avoir une conversation avec son client et l’équipe sur un sujet particulier. Définition d’une User Story
- 11. 11 © http://www.oeildecoach.com Caractéristique d’une User Story Compréhensible par tous (pas de terme technique) Raconte une histoire liée à un ou plusieurs utilisateurs Légère et simple à rédiger (format post-it) Suffisamment claire pour permettre aux développeurs d’estimer sa faisabilité Réalisable entièrement durant un sprint
- 12. 12 © http://www.oeildecoach.com Formalisation d’une User Story • Narrative En tant que <utilisateur>, je veux <verbe d’action> afin de <d’obtenir un bénéfice>. • Notes Le contexte, les règles de gestion, les maquettes, les cas nominaux et les cas aux limites, la documentation à disposition, les contraintes techniques particulières, etc. • Critères d’acceptation « Gherkin » Lorsque <contexte>, quand <action> alors <résultat attendu>. Lorsque <contexte>, quand <action> alors <résultat attendu>. Lorsque <contexte>, quand <action> alors <résultat attendu>. Lorsque ‘contexte initial’ quand ‘un événement’ alors ‘résultat attendu’
- 13. 13 © http://www.oeildecoach.com Exemple d’User Story • Narrative En tant que nouvel utilisateur, je veux créer un compte avec un mot de passe sécurisé afin de me connecter à mon compte et le message « Hello <identifiant> » s’affiche. • Notes Les mots de passe ne doivent pas être trop courts, ils doivent pouvoir contenir des caractères spéciaux et des chiffres. • Critères d’acceptation « Gherkin » Lorsque un nouvel utilisateur souhaite créer un compte, quand il saisit l’un des mots de passe suivant : p@ssword, azerty$$, planète!75, Mot_De_Passe! alors il arrive sur la page d’accueil de connexion et le message « Hello <identifiant> » s’affiche. Give <initial context> When <something happens> Then <some expectation>
- 14. 14 © http://www.oeildecoach.com La méthode INVEST
- 16. 16 © http://www.oeildecoach.com INVEST-issez dans de bonnes User-Stories ! I Indépendant des stories suivantes (et si possible des précédentes) N Négociable avec les développeurs (pour optimiser le ROI) V Valorisant pour l’utilisateur (pas de “afin de” bateau) E Estimable (doit pouvoir être chiffré, solution technique connue) S Suffisamment petit pour éviter l’effet tunnel et tenir en un sprint (grand max) T Testable (doit pouvoir être testé) Bill WAKE
- 17. 17 © http://www.oeildecoach.com pour rédiger de meilleurs User Stories Les erreurs à éviter
- 19. 19 © http://www.oeildecoach.com Surcharger les post-its ? Erreur courante #1 La Story N°ID Complexité Qui réalise ? EPIC Valeur métier
- 20. 20 © http://www.oeildecoach.com Surcharger les post-its ? Erreur courante #1 > Recommandation Recherchez constamment la simplicité !
- 21. 21 © http://www.oeildecoach.com Transformer un cahier des charges en un backlog d’User Stories ? Erreur courante #2 Cahier des charges Backlog
- 22. 22 © http://www.oeildecoach.com Transformer un cahier des charges en un backlog d’User Stories ? Erreur courante #2 > Recommandation Organisez des ateliers Vision, Personas, User Story Mapping et Roadmap avec les parties prenantes pour bien (re)démarrer !
- 23. 23 © http://www.oeildecoach.com Une User Story peut servir à un découpage technique ? Erreur courante #3
- 24. 24 © http://www.oeildecoach.com Une User Story peut servir à un découpage technique ? Erreur courante #3 > Recommandation Changez la formulation pour raconter une histoire, les détails pourront être échangés durant la réalisation !
- 25. 25 © http://www.oeildecoach.com Préciser tous les détails, dès la création de la User Story alors que j’en aurai besoin plus tard, dans un sprint futur ? Erreur courante #4
- 26. 26 © http://www.oeildecoach.com Préciser tous les détails, dès la création de la User Story alors que j’en aurai besoin plus tard, dans un sprint futur ? Erreur courante #4 > Recommandation Temps Précisez les User Stories au plus proche du sprint concerné par sa réalisation !
- 27. 27 © http://www.oeildecoach.com Les User Stories précisent chaque détail d’une page ou d’un processus ? Erreur courante #5
- 28. 28 © http://www.oeildecoach.com Les User Stories précisent chaque détail d’une page ou d’un processus ? Erreur courante #5 > Recommandation Echangez avec les développeurs pour connaitre le niveau de détail attendu dans les Users Stories !
- 29. 29 © http://www.oeildecoach.com La User Story est beaucoup trop grosse pour entrer dans un sprint ? Erreur courante #6
- 30. 30 © http://www.oeildecoach.com La User Story est beaucoup trop grosse pour entrer dans un sprint ? Erreur courante #6 > Recommandation Découpez l’Epic en plusieurs User Stories !
- 31. 31 © http://www.oeildecoach.com N’avoir que 1 ou 2 User Stories par développeur et par sprint ? Erreur courante #9 Création d’un effet tunnel garanti qui risque de mettre le sprint en péril
- 32. 32 © http://www.oeildecoach.com N’avoir que 1 ou 2 User Stories par développeur et par sprint ? Erreur courante #9 > Recommandation Mieux découper les US pour produire plus de 4 User Stories par développeur / sprint
- 33. 33 © http://www.oeildecoach.com Passer à « done », une User Story qui ne devrait pas l’être ? Erreur courante #10
- 34. 34 © http://www.oeildecoach.com Passer à « done », une User Story qui ne devrait pas l’être ? Erreur courante #10 > Recommandation 1/ Ne pas compter une user story « not done » dans la vélocité 2/ Reportez la user story et ses points dans le sprint suivant 3/ Essayez de mieux découper les stories dans le futur
- 35. 35 © http://www.oeildecoach.com Confondre une User Story et un Use Case ? Erreur courante #11 User Story Use Case
- 36. 36 © http://www.oeildecoach.com Confondre une User Story et un Use Case Erreur courante #11 > Recommandation En savoir plus : http://leanmagazine.net/req/a-use-case-is-to-a-user-story-as-a-gazelle-to-a-gazebo/
- 38. 38 © http://www.oeildecoach.com « » Le meilleur format d’une user story est celui qui fonctionne avec votre équipe ! N’oubliez pas !
- 39. 39 © http://www.oeildecoach.com N’oubliez pas ! • Gardez en tête qu’une user story est avant tout une histoire qui se raconte, crée la discussion et amène l’équipe à confirmer sa compréhension du besoin. • N’hésitez pas à abuser des dessins, maquettes, schémas, wireframes, etc. Une image vaut mieux que mille mots ! • Ne soyez pas dogmatique, écrivez les user stories dont l’équipe a besoin pour développer : ni plus, ni moins ! • Demandez régulièrement à l’équipe ce qui peut être amélioré Le PO doit aider constamment l’équipe de réalisation
- 40. 40 © http://www.oeildecoach.com Sources • http://fr.slideshare.net/yquenechdu/rdiger-des-user-stories • http://blog.xebia.fr/2012/06/20/scrum-master-academy-parlons-des- user-stories/ • http://fr.slideshare.net/yquenechdu/agile-user-story-4482606 • http://www.qualitystreet.fr/2009/02/16/user-story-vs-use-case-soyez- agile/ • http://leanmagazine.net/req/a-use-case-is-to-a-user-story-as-a-gazelle- to-a-gazebo/
Notas do Editor
- A l’origine de l’Histoire, il y avait les dinosaures…
- Ce n’est pas à proprement parler un élément du framework Scrum, cette pratique nous vient de l’Extreme Programming, mais elle est largement utilisée dans le cadre de projets menés en Scrum au point de devenir la référence de nombreuses formations certifiantes. 3C : CARD + CONVERSATION + CONFIRMATION (ce qui fait que la user story sera done)
- Les pratiques Agile sont orientées autour de l’utilisateur final. Il est au centre de la démarche. On raconte notre histoire avec les User Stories. On présente notre histoire avec le résultat : le produit.
- Ron Jeffries est un informaticien américain né en 1939 et un des trois fondateurs de l'Extreme programming (XP) créé en 1996, avec Kent Beck et Ward Cunningham. Il est l'un des 17 signataires du Manifeste Agile.
- Ce n’est donc ni un besoin, ni une solution, la User Story est une conversation.
- La user-story est un formalisme pour décrire une fonctionnalité du point de vue de l’utilisateur. Ca semble très simple, mais le but est justement de réduire la forme à l’essentiel pour se concentrer sur la valeur. La phrase : En tant que = l’utilisateur qui reçoit la valeur (pas nécessairement celui qui fait l’action) « QUI » Je veux = l’action qui doit être menée (~ la solution utilisateur / verbe infinif) « QUOI » Afin de = le but de l’action (~ le besoin utilisateur) « POURQUOI » ID / Titre (verbe infinitif) / Valeur métier / Epic ou Thème / Règles gestion / Wireframe / Pré-requis / Contexte / Complexité tech
- Méthode Gherkins : Give <some initial context> When <something happens> Then <some expectation> Le BDD (Behavior Driven Development) est une méthodologie agile proposée par Dan North pour aller au delà du TDD (Test Driven Development). Cette méthodologie a pour objectif d’améliorer la compréhension et la collaboration du métier, du Product Owner, des développeurs, des testeurs et de toute autre partie prenante pertinente en les rassemblant autour d’un langage commun : le Gherkin.
- Vous voulez être aussi fort que Hulk ?
- I – Indépendante : elle doit se suffire à elle-même, car les dépendances avec d’autres user stories induisent des problématiques de testabilité et de planification. N – Négociable : elle doit amener à la discussion et peut-être modifiée jusqu’à son inclusion dans une itération. V – Valeur : elle doit apporter de la valeur à l’utilisateur final. La notion de valeur étant toujours difficile à évaluer, la user story doit être exprimée avec une vision de l’objectif recherché pour l’utilisateur. E – Estimable : elle doit être suffisamment claire et comprise par l’équipe pour que celle-ci soit en capacité de l’estimer. S – Small : elle doit être de taille assez petite pour prioriser de façon sûre et éviter les effets tunnels. Essayez donc au maximum de découper finement vos user stories. T – Testable : la user story doit raconter une histoire, dont les tests découlent de façon évidente. INFO : The INVEST mnemonic was created by Bill Wake[1] as a reminder of the characteristics of a good quality user story
- Une "erreur" classique consiste à partir d'un cahier des charges rédigé en amont et le découper en User Stories en s'appuyant sur sa structure textuelle. Cela peut être une bonne approche pour une équipe débutante mais ne constitue pas une pratique recommandée.
- Reco : organiser des ateliers Vision, Personas, User Story Mapping et Roadmap avec les parties prenantes
- Ne doit pas être un découpage technique: un écran, une boîte de dialogue, un bouton ne sont pas des User Stories.
- Une User Story ne correspond pas à un quelconque découpage technique. Reco : Changez la formulation pour raconter une histoire !
- Le niveau de détail évolue au fil du temps, en fonction de l'horizon de planification : une User Story dont la réalisation est prévue dans plusieurs sprints ne sera décrite que d'une brève phrase, alors qu'une User Story dont la réalisation est imminente doit être enrichie par des tests fonctionnels, des critères d’acceptations, des exemples, des maquettes, etc.
- Les User Stories sont beaucoup trop précises, jusqu’aux moindre détails Exemple : un champs par user story pour chaque élément le constituant. Reco : Echanger avec les développeurs pour connaitre le niveau de détail attendu dans les users stories.
- Les User Stories sont beaucoup trop précises, jusqu’aux moindre détails Exemple : un champs par user story pour chaque élément le constituant. Reco : Echanger avec les développeurs pour connaitre le niveau de détail attendu dans les users stories.
- La User Story est beaucoup trop grosse pour entrer dans un sprint
- Une story trop grosse pour entrer dans un sprint est une Epic. N’hésitez pas à redécouper vos grosses stories même si elles tiennent dans un sprint. Cela facilitera le suivi, les tests, et le niveau de confiance sur l’atteinte des objectifs du sprint. Reco : Pour manger l’éléphant, il faut donc le couper en tranche
- Pas dans la doc Scrum classique. C’est une règle de routards de l’agilité, issue de l’expérience. Cette règle va encore plus loin que la précédente dans la mesure où elle nous demande de découper les stories à un grain suffisamment fin pour en prendre plus de 4 dans un sprint. Il faut qu’un développeur puisse travailler sur plus qu’une story pendant le sprint. Si une story occupe un développeur sur la totalité du sprint, il se crée un effet tunnel qui risque de mettre le sprint en péril. Les estimations c’est un peu le jeu des devinettes. Nous savons qu’elles sont globalement vraies mais précisément fausses. Cette marge d’erreur peut conduire à ne pas pouvoir terminer une story dans le sprint où nous la planifions. Si vous ne prenez que 4 stories dans un sprint et que vous n’en terminez pas une, c’est 1/4 de l’objectif qui n’est pas réalisé. Ce qui est relativement important, à plus forte raison si la story est de taille importante.
- « done », ou « not done » Pas enseignée dans de nombreuses formations agiles. Passage en force mettent à mal la Définition du Done (DoD), qui est pourtant un élément essentiel de confiance entre le PO et l’équipe. C’est également un élément de mesure dans Scrum car elle contribue au calcul de la vélocité. Mettre à mal sa DoD est une promesse de complications à court terme. Que faire alors avec ces stories « not done » ?
- OUI, reporter l’intégralité des points totalement les points, quel que soit l’état d’avancement des stories concernées. Bien souvent, celles-ci avaient de toute façon été sous-estimées. Si l’on ne reporte pas les points, on risque de sous-estimer le contenu du sprint suivant, et donc de se retrouver à nouveau avec des stories non terminées. Et progressivement, sprint après sprint, on se construit un matelas de stories « not done » qui prend du volume. Très vite, la vélocité ne signifie plus rien, donc les projections ne signifient plus rien, donc le PO ne comprend plus l’avancement, et tout ça risque de se terminer en un vaste règlement de comptes. Pour résumer : je ne compte pas une story « not done » dans la vélocité constatée d’un sprint, et je la compte entièrement dans les points prévus pour le sprint suivant, sachant que ce total de points doit être toujours cohérent avec la vélocité constatée des derniers sprints. Cette méthode peut paraître un peu radicale (ou inutile pour les détracteurs de la vélocité), mais l’impact ne sera jamais vraiment significatif car toutes vos stories prises dans le sprint sont suffisamment petites pour éviter les grosses variations de vélocité.
- Bien que la comparaison entre les deux notions soit souvent utile, il n'est pas possible d'établir un lien simple et direct.
- User Story = brève description d’une fonctionnalité telle que vue par l’utilisateur Use Case = représente une séquence d’actions qu’un système ou tout autre entité peut accomplir en interagissant avec les acteurs Une User Story est une promesse de conversation et le Use Case est un enregistrement de la conversation « a story is a promise to have a conversation and a use case is the record of the conversation”.
- Ne soyez pas dogmatique ! L’équipe sait ce dont elle a besoin pour commencer à travailler. C’est donc elle qui va pouvoir dire si une user story est prête ou non, et ce quelque soit son formalisme ! Dans certaines équipes, la user story réduite à son stricte minimum suffira, dans d’autres, la user story ressemblera à une mini spécification. La longueur d’une user story peut refléter la distance qui sépare l’équipe de son Product Owner.