Dans la littérature actuelle, je n’ai que très rarement entendu parler de Use-case, et ça me laisse perplexe.
Une écrasante majorité de personne semblent utiliser des User stories (à plus ou moins bon escient et divers degrés de compréhension de l’outil). J’imagine que l’adoption massive de Jira comme outil de gestion de flux explique ce choix (?) de process: le fait que ce système ait pour unité première de structuration les dites User stories force le langage des entreprises et par extension de l’écosystème du développement logiciel.
Pour autant, le Use-case (dont le but est sensiblement le même que l’User-story) est un outil de description des capacités d’un produit/service qui, à mon humble avis et expérience, est non seulement méconnu mais surtout sous-utilisé.
Je ne ferais pas ici la description de ce qu’est un use-case (je vous invite à aller voir ici) mais j’ai plus envie de vous expliciter quelques points sur « pourquoi » cette approche est intéressante:
L’ensemble des scénarios exposés dans un Use-case expose les scénarios alternatifs et d’erreurs. Trop souvent, ces derniers sont oubliés dans le contexte des user-stories,
Ces scénarios alternatifs exposent une vision d’ensemble du système et de ses acteurs. A contrario, l’user-story ne se concentre que sur l’utilisateur et son but,
Ces scénarios, quand bien même ils ne sont pas implémentés, offrent des heuristiques quand au parcours et l’expérience de l’utilisateur et son contexte, de manière cohérente, et pas seulement une capacité,
Si vous n’avez jamais jeté un œil à cet artefact et à ce qu’il implique pour votre process de développement de produit/service, étudiez au moins la question de ce qu’il est et de ce qu’il pourrait vous apporter.
Des gens parmi vous utilisent ils des use-cases formalisés ? Si oui, vous ont il été
bénéfiques ? Dans quels contextes ?
La user story, c’est juste une formulation proposée pour avoir un focus sur le besoin (je veux que) de l’utilisateur (En tant que) , et sur le changement espéré (afin que) quand on rédige l’accroche de nos items de backlog.
Le use case, c’est un scénario qui répondre à ce besoin
Un item de backlog peu avoir plusieurs uses case, ca en donne aussi la portée.
(une fois que ces uses cases fonctionnent, alors on peut dire qu’on a fini l’item de backlog)
Si ce n’est pas complet on ajoute un case.
Ou on choisit d’avoir un autre item de backlog qui aure une US assez proche, mais dont les uses cases sont différents. Différence qu’on essayera quand même d’exprimer dans la nuance qu’on apporte dans l’intitulé de la US.
Maintenant, je reconnais tout à fait le fait que bcp d’équipes se content de rédiger juste la US et considèrent que les uses cases se définissent sur le tas.
Hum, je suis pas sûre qu’on ait la même définition de use-case. Le use-case regroupe un ensemble de scénarii mais n’est pas qu’un seul scénario. J’ai également du mal à voir comment un item de backlog peut contenir plusieurs use-cases. L’inverse est vrai, mais un PBI multi-UC, je n’en ai pas encore rencontré.
À la lecture que j’en fais, ces Use-cases ressemblent beaucoup à l’analyse fonctionnelle traditionnelle à travers laquelle nous faisons la capture des besoins selon les fonctions (et pas les fonctionnalités, c’est différents) que devront répondre le produit ou l’incrément.
As-tu été voir du côté des diagrammes de bête à corne ou pieuvre ? Quand ma patronne m’a dit qu’elle avait l’impression que nous n’arrivions pas à bien saisir l’entièreté des besoins de nos utilisateurs ou que nous étions victime de la vue tunnel, j’ai essayé d’adapter ces approches plus traditionnelles en début de parcours. Ça permet de créer la vision forte du produit ou de l’incrément dont l’équipe a besoin, mais après, il faut quand même découper pour ne pas se retrouver avec un cycle en V standard.
L’autre avantage, c’est que ça permet de saisir très tôt où on va, mais il faut traiter ça un peu comme un spike et time-boxer ça, car de toute façon, il y a fort à parier que les choses vont changer pendant l’exécution et aussi parce que si on investit trop de temps là-dessus, on tombe carrément dans le Waterfall.
Cela dit, si c’est bien fait, évolutif et bien découpé, j’avoue que l’extrant de cet exercice ressemblent drôlement à ce que vous décrivez.
Je ne vois pas trop, je crois, ce que ça donnerait les use case par rapport à des critères d’acceptation détaillés avec pour chaque cas d’usage (un bout de scénario en fait), des comportements souhaités (contexte, action, réaction). Un cas pouvant avoir plusieurs comportement. Tu saurai nous donner des exemples ?
J’aime bien les Use Cases. Et j’aime bien les User Stories.
Je vois les User Stories (vous saviez qu’on appelait ça « System-in-use Story » ? Et que ça pouvait prendre la forme d’une simple histoire de quelqu’un, capturant les émotions et comportements de la personne déjà avant les années 2000 ? Maintenant vous sachez) comme une première partie de la Use Case, un échauffement. Une promesse de discussion entre le PO ou équivalent et les faiseurs, les développeurs.
S’ensuit après la création des use cases. Je trouve que ça s’est vachement perdu.
C’est bien ce qui me chagrine. Plutôt que de vouloir cracher des « spécifications détaillés » qui font souvent l’impasse sur les chemins alternatifs et les chemins d’erreurs en forçant au chausse pied un comportement, ce serait quand même pas mal qu’on réintroduise un peu d’analyse systémique dans le schmilblik… =/
