Bah ça me dérange dans le sens où, purement dans le model mental, je me retrouve avec un nom induisant une séquence. Si on peut le mettre dans l’ordre qu’on veux, je te propose d’appeler ça Confirmation Carte Conversation. Personnellement, il y a quelque chose qui cloche dans cet ordre là.
Apres je dis ça mais j’ai pas de meilleure propal donc…
Cest pour ça que ça s’appelle CCC
Hum… je vois nul part l’appelation CCC et à priori, c’est l’article à l’origine de l’idée : Essential XP: Card, Conversation, Confirmation
Hum…
Je suis d’accord avec le fait que le format US n’a rien d’obligatoire. On peut faire ce qu’on veut dans Scrum, le cadre ne prescrit pas de formalisation particulière. Toutefois, les User Stories sont très couramment utilisées car elles sont redoutablement efficaces. Le sujet dont il est question ici était User case ou User Story. J’exprimais que pour ma part je préfère les User Stories en argumentant pourquoi. Mais évidement, chaque équipe peut faire comme elle veut.
Pour les US technique, je suis d’accord que ce n’est pas TOP, mais c’est une pratique vue assez souvent et ça se gère assez facilement pour que je n’ai pas à me focaliser là-dessus, tout en tentant à ce qu’il y en ait le moins possible et que les aspects techniques soient embarqués dans les stories fonctionnelles.
L’objectif de sprint est bien sûr un sujet de discussion entre les membres de l’équipe oirs du sprint planning. Je constate qu’effectivement, le Scrum Guide a évolué en donnant plus de poids aux développeurs et moins au PO dans la discussion de cet objectif, en passant au PO l’objectif du produit. Merci de m’avoir alerté à ce sujet !
Concernant les architectures etc., je suis d’accord que c’est l’affaire des développeurs. Le rôle que j’attribue au PO n’est pas à ce niveau : il est dans la « profondeur » fonctionnelle, pas dans la manière de l’obtenir. Et, bien sûr, tout est négociable, les réunions d’affinage sont faites pour cela.
Conversation & Confirmation Then Cards Then Conversation & Confirmation
CA FAIT BEAUCOUP DE C TOUT CA 
En fait pour moi j’ai jamais mis de hiérarchie dans les 3C. Les 3 existent et sont imbriqués l’un avec l’autre, l’ordre n’a pas de sens dans ce cas là. C’est dans l’ordre qui semble le plus important au moment où ça arrive. Ou alors j’ai rapé le contexte de la discussion 
Oh, je dis pas le contraire. C’est juste que la littérature (et preuve en est de l’article que j’ai linké) exprime beaucoup moins, voir pas du tout, cette non hiérarchie.
Je me rend compte que le problème aussi dans tout ça, c’est qu’on documente à aucun moment la « conversation », partant du principe que l’utilisatrice sur site sera en mesure de répondre à nouveau à la question au besoin.
Pour moi la conversation doit être documentée, mais c’est je trouve toute la difficulté : de quelle manière ? Quand ? Par qui ? Où … ?
Et tu vas me dire, je te vois venir : les use cases !
… Et j’ai envie de dire oui
Bah au final, on est au même niveau en terme de raisonnement, à savoir que l’US est le « début » d’une UC.
Oui, d’ailleurs de souvenir c’était l’idée d’Alistair Cockburn dans son bouquin !
Writing Effective Use-Cases - Alistair Cockburn
A system-in-use story (or user story, as it is sometimes called) is a situated example of the use case in operation - a single, highly specific, example story of an actor using the system. It is not a use case, and in most projects it does survive into the official requirements document. However, it is a very useful device, worth my describing, and worth your writing.
When getting started on a new project, you as the writer of the use case may have either little experience with use case writing or may not have thought through the operation of the system. To get comfortable and familiar with the material, sketch out a vignette, a few moments in the day of the life of one of the actors, a system-in-use story.
In this short story, invent a fictional but specific actor, and capture, briefly, the mental state of that person, why they want what they want, or what conditions drive them to act as they do. As with all of use case writing, we need not write much - it is astonishing how much information can be conveyed with just a few words. The writer simply writes « how the world works, in this particular case », from the start of the situation to the end.
The system-in-use story anchors the use case. The use case itself is a dried-out form of the system-in-use story, a formula, with generic actor name instead of the actual name used in the system-in-use story.
The place of the system-in-use story is to envision the system in use. You might also use it to « warm up », before writing a use case, or to work through the details of action that you will capture in the use case. In a few organizations I have visited, system-in-use storys are presented at the beginning of the use case chapter, or just before the specific use cases they illustrate. The people who have done this have been happy with their choice. The system-in-use storys take little energy to write, little space, and lead the reader into the use case itself easily and gently. The system-inuse story is not the requirements, rather, it sets the stage for more detailed and generalized
descriptions of the requirements.Brevity is important, so the reader can get the story at a glance. Details and motives, or emotional content, are important so that every reader, from the requirements validator to the software designer, test writer and training materials writer, can see how the system should be optimized to add value to the user.
La conversation autour de la User Story donne un Example Mapping que tu écrits en gherkin qui devient ta doc vivante.
Du coup tu as toutes les règles et scénarios confirmant les règles.
Qu’est ce qu’il manque, je ne vois pas trop
La notion de UseCase a longtemps été bannie pas les coachs agiles. À tort ou à raison, je n’ai jamais compris.
Quand un nouveau metier me demande ce qu’est une US je prends souvent le Cas d’Utilisation comme exemple.
Par contre, si ton Use Case est un assemblage de plusieurs US, je le place comme un parcours qui te sert à documenter ce qui est possible dans ton produit.
Ah ? J’ai manqué un chapitre complet dans XP ?
Je ne me permettrais pas
Ah, tu pourrais, t’inquiètes pas, je le prendrais pas mal du tout. Mais à ce que je sache, jusqu’à récemment (Dan North, BDD, tout ça…), ce que tu décris n’étais pas un flux de travail standard. D’ailleurs, ça ne l’est de toute évidence toujours pas.
Je dirais bien que dans l’absolu, ce serait le mieux, histoire de ne créer aucun document relevant du « Muda ». Mais en l’occurrence, si je ne me base que sur XP à sa création, tout ce que tu décris n’existait pas, d’où ma remarque sur l’absence d’une formalisation de la conversation.
Après, si je veux continuer dans le côté taquin, tout bon Product Manager ou chercheur en UX dirait que la « Conversation », quand bien même elle est nécessaire, est sous optimal par rapport à de l’observation.
je ne me suis jamais posé la question dans ce sens
ça a toujours été la Carte qui fait l’objet de Conversations jusqu’à arriver à ce que la carte devienne une User Story INVEST sur laquelle tu fais un Example Mapping pour savoir comment tu vas Confirmer qu’elle est bien terminée
les multiples conversations qu’on peut avoir autour d’une carte sont les ateliers de refinement, pour découper, prioriser, sortir des cartes minimum qu’on habille de possibilités jusqu’à ce que le métier en a eu pour son argent
en effet, BDD n’a été inventé par Dan qu’en 2005 et cette pratique géniale a manqué cruellement de l’Example Mapping qui n’est arrivé que fin 2015…
depuis, je ne fais plus que ça, c’est devenu la « norme » dans mon entreprise.
est ce que c’est un standard ailleurs, je ne pense pas, mais je milite et communique dans ce sens.
après, je suis en phase, il manque quelque chose pour documenter ce qui est au dessus de l’US
l’US seule ne suffit pas en terme de documentation
moi, elle me sert à incrémenter un produit et sa documentation vivante
XP n’est pas suffisant, le monde évolue, il est saint de revenir aux bases, aux fondations pour éviter de dériver, mais de là à ignorer les