To have User Stories really Ready thanks to Example Mapping - Scrum Life 18
Вставка
- Опубліковано 14 лют 2018
- I'm talking to you today about one of my favorite subjects: the Example Mapping!
This workshop allows you to really analyse a US and make sure we understand each other. I can't tell you better than "it's a blast!"
So I invite you to look at this Scrum Life - certainly a little long - to discover the principle, see it in action, and stock up on tips to get the most out of it.
The links referenced in the video:
- Slides "Introduction to Executable Specifications": www.slideshare.net/JeanPierre...
- Article on the Meetup where I presented the Example Mapping with practical workshop: jp-lambert.me/retour-sur-la-a... -g% C3% A9n% C3% A9rale-le-25-septembre-2017-atelier-example-a4ec60401d56
- Slides of my presentation to the meetup on the Example Mapping: www.slideshare.net/JeanPierre... Examples
- Cucumber blog article which presents the Example Mapping: bit.ly/example-map
- Scrum Life 12 about the breakdown of the US: • "Impossible de découpe...
- Scrum Life 5 about the Definition of Ready: • Le Definition of Ready...
Follow me and contact me on social networks and on my blog!
- jp-lambert.me
- Twitter: / jpierrelambert
- Instagram: / jpierrelambert
- LinkedIn: / jp-lambert
- Facebook: / jplfanclub
Thanks to Edvin Candon for the credits and thanks to all the subscribers! 427 subscribers at the time of publication !!!
Découvrez toute la communauté Scrum Life ! 👉 sl.run/j0s7JT
Excellent. Jamais vu aussi bien expliqué. Je vais expérimenter.
Nous sommes tes plus grands fans! ;-)
Salut Jean-Pierre,
Je suis en train de manger toutes tes vidéos. Pour te répondre c'est simple, oui, ca donne super envie d'essayer
++
Tellement clair et cool, merci pour la vidéo 👏
Comme toujours une super vidéo de Jean-Pierre ! Je m'empresse de la partager à tous nos PO ;)
Tu parles de meetup dans ta vidéo, si jamais il y en a d'autres qui se préparent je viendrai volontiers !
Super JP. Je l'ai déjà testé et c'est une méthode de conversation efficace entre les membres de l'équipe Scrum
Super Vidéo. Et ne s'applique pas que dans un contexte AGILE/Scrum
JP nous régale de façon systématique avec tous ces beaux contenus.
Merci !!
Bonjour JP, merci pour cette nouvelle idée d'atelier et ce retour d'expérience ! A tester :)
Merci beaucoup. J'ai récemment eu à bosser dans une team dont les dév et le PO n'avaient pas du tout la même notion du degré de précision que les US devaient afficher. Je testerai cette méthode pour permettre à mes prochaines équipes de s'aligner plus facilement, et de mieux se comprendre !
Envoyez-nous des photos de vos Example Maps !!!
Merci JP
Super près comme d habitude
Je cherchais une présentation en FR de cet atelier... Je vais pouvoir me.lancer désormais 😁
Et voilà. J'ai kiffé une fois de plus.
👌
Superbe vidéo, merci beaucoup pour la découverte. J'en entends parler depuis longtemps par-ci par-là, et beaucoup dans vos vidéos les plus récentes mais je n'avais pas encore pris le temps de creuser.
Me voilà satisfait !
Une question qui m'est venu à l'esprit, est-ce que les exemples ne sont pas au final les critères d'acceptation, ou au moins un début de critères d'acceptation qui mériterait d'être creusé un peu plus et étoffé ?
Merci pour la vidéo. Je vois déjà plusieurs cas d'utilisations, en plus ça résout pour moi le support de description des éléments de design.
Merci pour le partage, c'est clair. A expérimenter sur les US les plus complexes
Tiens-nous au courant de ce que ça donne !
-- JP
C'est parfait, merci )
Je t'en prie ! Vas-tu utiliser l'atelier ? Qu'est-ce que tu penses retirer de l'utilisation de cet atelier ?
-- JP
Génial ! Merci beaucoup
Super ! Qu'est-ce qui t'inspire le plus dans cet atelier ? Qu'est-ce qui va te servir le plus ?
-- JP
Merci JP! je vais tester ça :)
Sourcier, n'hésite pas à venir nous faire un retour d'expérience dans les commentaires :)
Oh oui, essayons !
Notre Scrum master m'a envoyé ta vid pour préparer le grooming de thalleur [16h], j'étais content de retrouver ta chaîne, depuis le temps - je vais m'y remettre, je pense - c'est donc mon arme principale pour la tâche que je vais commencer, là - merci à toi JP, à 1 de ces quatres :D
Bon courage !!! Et tiens-nous au courant de ce que ça donne. L'Example Mapping est une valeur sûre ! 😊
-- JP
@@ScrumLife Ça s'est passé super merci - on avait le Scrum Master ac nous - j'ai pris beaucoup de notes sur les tickets au fil de la conversation, pour le coup, j'ai hâte de voir si ça aide 👌😀
merci :)
Merci Jean-Pierre. J’ai vu plusieurs exemples d’example mapping mais je ne l’ai jamais implémenté, sûrement or peur qu’en découpage de backlog cela prenne trop de temps et donc que les participants rechignent à venir la deuxième fois.
Avec ton expérience, les sessions durent combien de temps ? Limites-tu dès le départ le scope de ce qui va être étudié ?
Merci, c'était intéressant et instructif! Cependant je suis sceptique par rapport au fait d'avoir la doc uniquement sur ces cartes. Au fur et à mesure du temps la doc va se résumer en un paquet de carte et ça risque d'être compliqué de retrouver les règles de gestion (par exemple en cas de pet en production). Pas de moteur de recherche, pas de partage électronique... Pour moi c'est la seule limite au fait de ne pas saisir ces règles sur confluence ou JIRA.
Par contre bravo pour toute ses vidéos, grâce à toi je deviens un meilleur product owner jour après jour.
Il faut faire une distinction nette entre documentation en amont du développement (c'est à dire le backlog produit en Scrum, typiquement JIRA pour ceux qui l'utilisent) et la documentation en aval du développement (doc d'API, vue haut niveau d'architecture, manuel utilisateur, tests automatiques...).
Un développement n'est pas complétement terminé sans la 2e catégorie -- dont la forme et contenu sont très contextuels.
C'est généralement une mauvaise idée d'utiliser des éléments de la première catégorie en remplacement d'éléments manquants de la deuxième catégorie.
Dit autrement, quand on creuse dans JIRA pour retrouver une règle métier, on ne devrait pas se dire "ouf heureusement qu'on a l'historique dans JIRA !" mais plutôt se dire "oh là là mais comment ça se fait que cette info critique sur le produit ne soit pas dans la doc ???"
Dès lors qu'on a une construction saine du produit, on devrait pouvoir jeter les éléments de backlog dès lors qu'ils sont implantés. De fait, remplacer intégralement JIRA par des cartes, physiques et éphémères, ne devrait poser aucun problème (pour les éléments de backlog, pas forcément pour les bugs qui ont d'autres contraintes).
Mais évidemment à la condition de bien travailler et d'avoir fait la doc. Parfois il suffit de faire les tests automatiques pour avoir une doc suffisante. Mais ils doivent être là.
-- JP
@@ScrumLife Bonjour JP, merci beaucoup d'avoir pris le temps de me faire une réponse. Nous avons des documents en aval du développement mais uniquement les documents d'architecture, manuel d'exploitation et manuel d'installation. Par contre tout ce qui est dans JIRA reste dans JIRA et sert malheureusement de spec définitive. C'est imbittable à retrouver au bout d'un certain temps surtout lorsque sur une fonction on a eu 5 ou 6 JIRA qui surchargent ou contredisent la même règle fonctionnelle... C'est un peu mieux depuis qu'on a mis en place confluence.
Cet outil a l'air très pratique pour préparer les story. Je le voie aussi comme un outil pour identifier les dépendances entre plusieurs stories. Est ce qu'il pourrait être utilisé ainsi ?
Salut Jean-Pierre et merci pour cette vidéo. Le sujet d'une bonne user story est effectivement un défi et je vais m'empresser de suggérer cette méthode à mon équipe. Seul bémol de mon côté, mon équipe n'est pas dans la même pièce (plusieurs continents en fait) donc difficile d'utiliser des fiches... par contre on pourrait penser à un outil en ligne (genre Mural) pour faire cet exercice. Par rapport à ta remarque sur le fait qu'on n'a pas besoin d'utiliser Confluence / Jira: dans mon cas, nous sommes dans une industrie régulée et nous devons passer des "compliance audits" et utilisons donc un outil (Jira dans ce cas) pour enregistrer le fait qu'on a bien documenté les besoins et le testing associé. Je ne pense pas que ça soit un problème du moment que pour arriver à une user story dans Jira nous avons utilisé la méthode que tu décris (avec Mural par exemple) comme aide pour le brainstorming? Merci!
Est-ce que dans votre cas les spécifications exécutables ne suffisent pas ? (le Cucumber, FitNesse, etc.)
@@ScrumLife Nous n'avons pas encore fait le "switch" vers Cucumber, on y reflechit... Je connais pas FitNesse, as-tu une référence sur ça? Merci!
@@froggy58400 salut, il existe divers outils au-delà de Cucumber pour répondre à la même problématique. FitNesse est l'un d'eux. J'avais écrit cette article il y a quelques années qui dressait un petit comparatif, j'espère que tu le trouveras utile, n'hésite pas à revenir vers moi : jp-lambert.me/comparatif-outils-de-rédaction-de-spécifications-exécutables-acd83266f273
-- JP
Merci Jean-Pierre :)
J'ai envie de m'abonner une nouvelle fois à ta chaine :D.
Pour ceux qui n'aiment pas les cartes/post-it (s'il y en a ?! :D) et qui sont attachés au numérique, un petit outil ultra simple : www.teamuplabs.com/examplemap.
Attention, il ne fait pas tout et la souplesse des cartes (je gribouille, je déplace, je change ...) n'a rien de comparable ... mais au vu des features qui vont être développées, l'écart sera moins flagrant (www.teamuplabs.com/blog/2017/12/02/intro-roadmap-stats.html).
@+
Franck
Super, ça éclaire pas mal de chose et je vais le tester chez moi. Est-ce qu'en interne, ça peut remplacer un cahier des charges ??
Bien sûr ! Attention tout de même à la dimension contractuelle qui peut accompagner un cahier des charges.
Hello !
Je profite du temps que j’ai pour faire de la veille et forcément en allant sur los 3 amigos je me devais de regarder et comprendre ce qu’est l’example mapping.
Et la il me vient une question, car 5 ans avant, cette vidéo n’a pas été confronté au Covid, au distanciel.
J’ai l’impression que la force de cet atelier est le fait de le faire en physique, en présenciel.
Jean-Pierre l’as tu expérimenté à distance ? Est-ce tout aussi pertinent ou cela perd-il de son « charme » ?
Vous n'avez pas parlé de critères d'acceptation (je dis bien critères d'acceptation et pas test d'acceptaion) dans votre exemple.
C'est quoi la différence réel entre critères d'acceptation et règles métier. Et c'est quoi la différence réel entre regles métier et règles de gestion. Par fois les PO ajoutent des règles de gestions dans le bloc commentaires sur "Jira" sans préciser s'ils s'agit de règles de gestion ou critères d'acceptation.
J'espere que vous faites une video sur les critères d'acceptaion et les règles métier/gestion et comment ca se prépare, avec des exemples si possibles.
j'aime bien vos vidéos, vous parlez vrai et concret pour expliquer les choses :)
Merci Jean-Pierre,
10m22s : "C'est pas la peine de s'embêter à les recopier dans un confluence" > pour les implémenter oui pas faux (j'aime bien l'idée de se refiler les cartes physiques) mais c'est bien utile pour le travail en remote et aussi pour transformer la spec en doc pour l'après (l'exploit). nope ?
Salut Baptiste,
Tout d'abord si l'équipe est à distance, probablement que de toutes façons elle utilisera un tableau blanc numérique plutôt que des fiches bristol. Dans ce cas le problème n'existe pas.
Dans le cas d'un remote partiel, une photo des cartes en sortie d'atelier fera très bien le travail pour permettre à tout le monde de les consulter depuis n'importe où.
Enfin, pour transformer la spec en doc après... C'est un relent de l'approche traditionnelle. Si besoin d'une doc, sa rédaction doit faire partie du travail d'implémentation. Sans partir de "la spec" (peu importe sa forme, en l'occurrence un Example Mapping) car l'équipe va encore découvrir des choses pendant l'implémentation. Il faut nécessairement écrire la doc après coup, car on ne sait pas avant le contenu de la doc. Toute la difficulté est de faire la doc *juste*après pour que ça ne devienne pas de la dette !
Qu'en penses-tu ?
-- JP
@@ScrumLife merci de ton retour JP,
C'est effectivement ce qu'on fait dans l'équipe ( la doc juste après l'implémentation ) pour notamment les raison que tu évoques. On se sert tout de même beaucoup des specs ( on part presque d'un couper coller ) puis on modifie et on ajoute en effet ce qu'on a découvert.
Pour la pertinence de confluence comme aide au développement on s'y est bien fait. Cela permet une collaboration également auprès coup et même asynchrone suite la modification de la spec. Auparavant nous utilisions un repo versionné stockant du markdown mais le métier était alors trop écarté et donc les validations approximatives.
Pour la petite histoire, nous avons effectivement oublié certaines parties à documenter ( le début du cycle du produit ) et oui je confirme c'est une sacrée dette ;)
Merci du partage,
La question est aussi de réussir à quitter le monde de la spec à outrance en amont du développement pour réussir à la faire émerger. C'est souvent très difficile car les habitudes sont ancrées, mais aussi parce que pour aller au bout de cette démarche il faudrait supprimer ou changer substantiellement des rôles et métiers dans l'entreprise ! Plus de "métier" -- mais des experts intégrés dans les équipes par exemple. Comment faire en sorte que cela soit accepté ? Que cela ne soit pas vu comme l'inverse d'une promotion ? On touche du doigt les problèmes de la culture française au passage...
-- JP
C’est un sujet très intéressant. Quand tu animes un atelier comme ça, tu vas traiter combien de user stories ? Comme dans un commentaire précédent, j’ai peur que si on doit traiter un grand nombre de stories, l’atelier soit très long
Une séance de Backlog Refinement peut durer entre 2 et 3 heures, et avoir lieu toutes les 2 - 3 semaines (pour des Sprints de 2 semaines). Les premières séances sont plus longues :
- le temps que toutes les personnes s'habituent à ce type de travail et trouvent des "automatismes" de communication
- le temps de raffiner une liste de US qui date ... d'il y a très longtemps :-)
Merci, très intéressant. ça me donne bien envie d'essayer. Par contre dans mon cas le physique sera impossible, je fais partie d'une équipe qui est séparée entre le nord de la France et le nord du Maroc. Tu as des outils qui nous permettraient de nous en sortir ? merci.
Bonjour Jérémy,
Je vous invite à essayer draft.do
L'outil vous permettra de reproduire tout à fait librement des tableaux de post-it (et bien plus encore). C'est gratuit (dans une certaine mesure) et très intuitif !
Merci :)
Bonjour JP merci pour cette vidéo. Je suis convaincu par cette méthode, aurais-tu un serious game pour m'aider à sensibiliser mon équipe sur cette approche ? En vous remerciant d'avance :D
Salut, j'ai structuré un atelier autour de l'exemple Mapping : jp-lambert.me/atelier-boostez-vos-backlog-grooming-refinement-avec-lexample-mapping-3ad7c67ec541
Est-ce que cela t'aide ?
Tiens-nous au courant !
-- JP
Salut JP, dans la vidéo, tu poses directement les cartes de règles métiers comme si le P.O les avait déjà préparé à l'avance. C'est peut-être pour les besoins du montage parce que tu es seul :)
J'ai participé à un atelier mardi sur le sujet. L'émergence des cartes bleus et vertes étaient issues de la discussion entre les 3 amigos. Le P.O ne venant finalement qu'avec une carte jaune de départ qui correspond à l'US qu'il veut décortiquer.
Est ce que c'est bien le principe ?
Je veux bien avoir ton avis j'ai prévu d'en faire un la semaine prochaine.
Merci beaucoup JP.
Cela confirme l'approche que j'avais en tête. On a les 2 cas donc on adaptera en fonction de si l'US est déjà relativement claire ou si c'est un nouveau sujet émergeant avec beaucoup d'inconnus.
Bonne continuation pour tes vidéos, t'es au top.
Une autre question sur le sujet, tu définirais à combien le nombre de personnes maximum qui doivent composer une équipe Scrum et participer à ce genre d'atelier ?
Le nombre maximum de personnes dans une équipe Scrum : 9 (d'après le "Scrum Guide"). Quant au nombre de personnes maxi pour ce genre d'atelier, je rejoins la réponse de JP Lambert.
Oui.
Carrément ! Qu'est-ce qui te fais le plus apprécier cet atelier ?
Scrum Life Je suis étudiant en deuxième année de DUT Informatique, et on apprend la gestion de projet Agile. C’est quelque chose qui m’intéresse vraiment, et que j’essaie de mettre en place dans mon projet perso. Notre enseignante s’appuie souvent sur vos vidéos pour nous présenter certains concepts avec d’autres mots que les siens. En fait, ma réponse était surtout une réponse de la part de toute la classe, on a tous répondu "Oui" en coeur à votre question en fin de vidéo 😂 Mais comme vous ne pouviez pas l’entendre, je l’ai écrit 👍🏻
Petite question : pourquoi ne pas intégrer l'UX designer dans la rédaction des US ? j'ai l'impression qu'il/elle aurait pourtant toute sa place.. merci !
Bonjour, bien sûr qu'il faut l'intégrer ! "Les 3 amigos" est une image et un mindset plus qu'une règle : impliquer toute personne utile pour avoir une vision complète du sujet !
Merci de nous forcer à préciser ce point.
-- JP
Popin ? Mary Popin ?
🤣
Oui.... à pondérer.
En fait les exemples, enfin les règles, ce sont les spécifications sous-systèmes, le "comment ca doit fonctionner".
Et là dans les exemples Il y a ici design system (icones) et de l UX (affichage en popin) mais pas d equipe UX/UI ici!!!
il n y a pas un travail préalable PO avec UX designer avant? Le PO il arrive en freestyle ici!!!
L ux c est pas le boulot des dev, mais les dev donnent l avis sur la manière de faire évidemment. Pas trop d accord en fait, ou pas applicable dans toutes les boites.
Merci pour ton commentaire. Dans Scrum, l'UX est le boulot des "dev" dans le sens Scrum, c'est à dire les "Developers" qui ne sont pas forcément des développeurs logiciel mais les gens qui développent le produit.
De manière plus général, pour être vraiment agile, une équipe doit éviter les convergences prématurées et donc de prendre des décisions structurelles trop tôt. Une maquette est une décisions structurelle Or, la solution étant découverte pendant le sprint, la maquette ne peut être faite avant et doit donc être faire pendant le sprint, on parle de pair design souvent.
De mon expérience, c'est applicable partout (dans le sens où je n'ai pas vu toutes les entreprises du monde, mais j'en ai encore jamais vu où ce n'était pas possible), par contre il faut "juste" se donner les moyens de le faire et avoir la volonté aussi.
Qu'est-ce que tu verrais comme contexte qui ne le permettrait pas ?
-- Constantin
ok, j avais pas le définition "dev" au sens scrum, donc mon propos est à pondérer
Je travaille dans un entreprise industrielle, plutôt hiérarchique, on se met au scrum, le role de PO est venu à moi. Rien que la clarification de ce qu on doit faire prend énormément de temps (entretien avec les users, le PM, l ingénierie système et la latence du à la pose de réunion), du coup les affinages se font avant le sprint ou on dev. Par référence à votre vidéo sur la doc scrum, on est donc obligé de faire des docs un peu détaillées pour ne pas oublier. Autre chose que je souhaite dire, dans notre projet il y a deux equipes l embarqué et le débarqué, Il y a aussi l aspect complexite a prendre en compte, même si on découpe les taches pour quelles soient petites, elle sont souvent liés a d'autre, soit au niveau technique soit au niveau UX, a un moment il faut quand meme avoir une vision globale du rpoduit pour avoir un ensemble coherent, quand se fait ce travaille? je ne veux pas d une appli 'rustines'. Merci deja d avoir repondu
Merci pour ces précisions @@juggus8717 .
En fait dans ce que tu décris, pour avoir la vision globale et ne pas avoir à s'attendre (ou alors moins d'une équipe à l'autre), il faut peut-être repenser l'orga pour que chaque équipe soit le plus indépendante possible, c'est à dire, que chaque équipe contienne les compétences pour aller d'un bout à l'autre de la chaine de production. Dans ce que tu décris, chaque équipe devrait être indépendante sur l'UX, l'embarqué et le débarqué et que chaque équipe ait un périmètre.
Difficile de préconisé plus précisément sans en connaître plus bien sûr, mais même si ça paraît compliqué ou impossible, je suis prêt à parier que ça ne l'est pas :)
Et si tu penses que ça peut être utile on pourrait même en discuter en visio.
-- Constantin
@@ScrumLife
Oui exacte, je mène plusieurs combats :), l indépendance des équipes en est un, mais certaines personnes aiment bien garder le control égotiste de la connaissance.
J ai vu d autres de vos vidéos, je ne pense pas que ce soit impossible, il faut suffisamment de gens convaincus pour donner l impulsion, mais il faut les trouver, et les échéances arrivent :) Merci pour la proposition