Dans le vidéo User Story INVEST vous comparez brièvement la stratégie INVEST avec le Story Mapping.
Pourriez-vous rentrer plus en détail sur la différence entre les deux et comment choisir la bonne stratégie au quotidien.
L’user story mapping est un atelier orienté DISCUSSION afin de créer des cartes permettant de se rappeler se qui a été dit lors de l’atelier (INVEST permet également la discussion)
User-story mapping permet de décomposer de grosse story en plus petite au fur et à mesure de la discussion (je pense également qu’avec INVEST on va faire cela)
Une bonne histoire contient le Pourquoi, le Qui et le Quoi (comme dans INVEST)
Au final la seule différence que vous dites :
L’user story mapping permet de visualiser TOUT le logiciel en entier (avec toutes ces US) tandis que INVEST permet d’avoir une vision sur 2,3,4 sprints. Puis via le feedback on adapte.
Au final pour moi les deux reprennent les mêmes concepts, mais n’étant pas expert j’aimerai votre avis.
Je pense qu’il y a une confusion entre le but (avoir des éléments répondant à la typologie INVEST) et les moyens (utiliser le mapping). On peut gesticuler autant qu’on veux pour essayer d’atteindre ce but, mais une des routes les plus « sûre » est d’utiliser le mapping. Pour résumer, on obtient des US INVEST grâce au mapping. (ça me coûte énormément ce que je viens d’écrire parce que perso, y’a énormément de trucs dans les deux que j’aime pas)
Merci pour la réponse, je comprends mieux comment on pourrait les utiliser.
ça me coûte énormément ce que je viens d’écrire parce que perso, y’a énormément de trucs dans les deux que j’aime pas
Pourrais-tu développer, ou donner des liens qui décrivent les faillent de ces systèmes
Hello, perso je trouve que le story map ne donne pas des US INVEST, ça n’engage que moi
j’utilise plus le story map pour avoir une vision moyen terme, à 6 mois et surtout prioriser ce qu’on va traiter dans les 6 à 10 prochaines semaines
quand on tire une carte, on cherche à l’affiner, pour qu’elle finisse en une suite de 1 à 3 cartes INVEST
je dis pas que tous les sujets font 3 cartes maxi, mais je ne veux pas aller plus loin dans le découpage, si on n’a pas atteint l’objectif
si avec 1 à 3 cartes, on a traité le plus important de cette carte priorisée dans le story map, ça me va, on verra avec le métier quand on a terminé, si il faut encore dépenser de l’argent sur cette carte
le côté INVEST strict, je l’ai avec l’atelier de 3 Amigos où l’on pratique l’Example Mapping
et pareil, on cherche à avoir la carte la plus petite possible, on se donne encore le droit de la découper
on cherche le rapidement testable, en 3 jours de devs maxi
il y a quelques années, j’ai découvert l’usage de l’Event Storming et plus récemment l’Event Modeling qui permet tellement de chose en plus, je le place entre le Story Map et les 3 Amigos en gros
J’ai d’une part beaucoup de mal avec l’utilisation que le monde agile a aujourd’hui de la dénomination de user-story. En ce qui me concerne, les US ne sont pas, et ne seront jamais des spécifications fonctionnelles. Donc parler d’elles comme une unité fonctionnelle pérenne dans le cadre d’une gestion de backlog est pour moi absurde.
D’autre part, j’ai toujours du mal avec l’aspect indépendant de INVEST. C’est un non sens sémantique. Un système est toujours un agrégat de partie interdépendante, qu’elles soient gérés en interne ou externe. J’ai personnellement une préférence sur l’approche Use-Case en terme de découpage de ce qui peut ou doit être fait parce qu’on met au contraire en lumière les interdépendances plutôt que d’essayer de s’en accommoder au mieux, quitte à ce que l’architecture en pâtisse.
le terme Use-Case a longtemps été décrié par les agilistes et l’est encore ici et là.
moi, j’aime bien aussi, c’est plus concret pour le métier, il arrive mieux à le prioriser surtout quand tu lui découpe une carte en Use Cases, et que tu lui demande de les prioriser avec ce qui arrive le plus souvent dans la vraie vie, ce qu’il veut absolument avoir à très court terme
je pars toujours du principe qu’un projet peut s’arrêter d’un moment ou à un autre, du coup la priorisation est la clé
également, j’ai horreur de la notion de User Story Mapping, vous l’aurez compris, je pense que ça ne donne pas des US priorisées, mais des fonctionnalités ou mieux des cas priorisés
et là, on sait plus facilement écrire le verbatim des US avec ça
j’ai souvent des échanges assez fou entre Feature Map vs Story Map, je préfère le côté Feature Map que je n’ose pas appeler Use Case Map, faut pas déconner non plus
