Mon argument en faveur des use-cases

Communauté Scrum Life
, ,
1

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 ?

1 « J'aime »
2

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.

3

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é.

4

À 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.

5

Ce n’est pas exactement la même chose, mais ces outils que je ne connaissais pas ont l’air intéressant en terme d’heuristiques. Je prend note. :+1:t4:

6

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 ?

7

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.

1 « J'aime »
8

Non et c’est moi qui suis à côté de la plaque, j’étais en parallèle sur un travail au boulot sur les cas de tests d’une user story

1 « J'aime »
9

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… =/

1 « J'aime »
11

J’arrive après la guerre mais…

Ce qu’il faut comprendre, c’est que le formalisme des use-cases aide fondamentalement à générer ces critères d’acceptations détaillés. Le fait d’avoir un référentiel temporel sur lequel s’appuyer (flux nominal et alternatifs/d’erreurs) permet d’avoir une vision claire des comportements potentiels du système à implémenter. C’est une méthode d’analyse (comme n’importe quelle autre), et les critères d’acceptations n’en sont qu’une résultante. Ces critères ne se génèrent pas ex-nihilo.

1 « J'aime »
12

Une réaction un peu tardive…
J’ai travaillé avec des Use Case et j’ai beaucoup aimé : c’est très structuré, très méthodique, et effectivement, on ratisse large, en long et en travers, en anticipant tout ce qu’on peut faire ou pas dans l’application.
Et puis, j’ai découvert les User Stories. Aujourd’hui, je préfère les US car elles reflètent quelques fondamentaux de l’agilité :

  • partir d’un vrai besoin (afin de…) , avec un vrai utilisateur (en tant que…), et pas d’une idée extrapolée par le concepteur (si ceci alors cela) ;
  • réduire la quantité de code développé autant que possible en se focalisant sur ce qui est réellement utile. Statistiquement, en cycle en V, près de 50% de ce qui est développé n’est jamais utilisé. L’agilité, justement cherche à éviter ce gâchis. Donc, on « oublie » exprès certaines possibilités car on n’a pas identifié à qui ça peut servir ou parce que ce dont des cas rarissimes et ils ne valent pas l’effort, le coût et le temps de les développer.

Maintenant, on peut toujours compléter certaines US avec des mini Use Cases, mais seulement si c’est pertinent au niveau de la valeur ajoutée / effort consommé.

13

Une US peut tout aussi bien être extrapolée par sa conceptrice. Je ne suis pas sûr de comprendre le propos.

Je ne comprends pas le propos ici non plus. Ce qui est implémenté suite à l’analyse d’un Use-Case est totalement à la main de l’équipe. Si l’équipe ne souhaite que développer le flux nominal, on ne développe que ça.

14

Lorsque la conceptrice rédige une Use Case, elle se projette dans le cas qu’elle décrit. Donc, elle va au-delà des besoins exprimés par les utilisateurs car elle se pose aussi des questions comme « que ce passe-t-il si… ». Du coup, pour bien rédiger le cas, elle dépasse le besoin, ce que j’appelle extrapoler.

Quand tu parles de l’équipe, tu entends qui, l’équipe de développement ou l’équipe Scrum (si on fait du Scrum) ? Pour ma part, je pense que c’est au PO de décider cela au niveau fonctionnel. L’US me semble ainsi plus adaptée pour rédiger au plus près du besoin. Pendant l’affinage, l’équipe de dev. posera ses questions et fera ces propositions, qui pourront enrichir l’US.

15

J’avais bien compris cette partie là. Je ne comprend cependant toujours pas ce qui, mécaniquement, empêche une US d’être extrapolée.

D’une part, je pense qu’il faudrait qu’on éclaircisse ce que tu appelles une US dans son côté formel. Personnellement, je ne comprend pas ce que l’on peut « enrichir » dans une US.

A côté de ça, je parlais bien de ce qui est implémenté, à savoir l’/les incrément(s) listé dans le sprint backlog, et qui sont entièrement à la main de l’équipe de développement. Le PO ne peut que convaincre l’équipe du bien fondé de la chose. Et si l’équipe décide qu’elle n’implémentera que le flux nominal, ou même (dans le cadre d’un sprint court) seulement une étape du flux nominal pour le dé-risquer techniquement, c’est tout à fait possible.

Pour être plus clair, ce n’est pas parce qu’on a analysé et exploré un domaine qu’il est bon et/ou nécessaire de mettre en place tout ce qui ressort de la dite analyse.

16

Les US ont une structure formelle assez précise : En tant que… je veux… afin de… pour la User Voice et Etant donné que… lorsque… alors… pour les critères d’acceptation.
Il n’est pas interdit de compléter ces infos avec des schémas, des maquettes ou toute autre information utile. En principe, l’équipe définit tout cela dans sa DOR (Définition Of Ready).
Ces informations ne devraient pas être extrapolées, elles devraient découler directement des ateliers / interviews… réalisés avec les utilisateurs. C’est le PO qui détermine, sous sa seule et entière responsabilité, ce qu’il met dans le backlog produit, sous forme d’US, et qu’il les priorise.

L’équipe Scrum décide ensemble, lors des sprint plannings, ce qui va « rentrer » dans le sprint. Mais ce sera obligatoirement des éléments issus du backlog produit + éventuellement des « stories techniques » si l’équipe a décidé que ces US techniques ne passent pas par le backlog produit (moi je préfère les cas où tout est dans le BL produit).
On est donc loin d’une équipe de développement qui décide seule de ce qu’elle va faire pendant le sprint. Le sprint est le résultat d’un accord commun où le rôle du PO est prédominant : c’est lui qui définit un objectif de sprint (qui peut éventuellement être discuté) et c’est lui qui propose des US qu’il juge aptes à réaliser cet objectif. L’équipe Scrum va cadrer cette proposition en fonction de sa vélocité et, le cas échéant, en ajoutant des US techniques si elles n’étaient pas dans le BL du produit. Dans ce cas, pour respecter la vélocité, il y aura moins d’US fonctionnelles.
Le niveau de profondeur du développement (cas nominal et autres cas) n’est pas du tout à la main des développeurs mais entièrement à la main du PO. Il est déterminé par les critères d’acceptation et discuté lors des réunions d’affinage.

17

Sprint Backlog

Le Sprint Backlog est composé de l’Objectif de Sprint (le « pourquoi »), de l’ensemble des éléments du Product Backlog choisis pour le Sprint (le « quoi »), ainsi que d’un plan d’action pour la réalisation de l’Increment (le « comment »).

Le Sprint Backlog est un plan élaboré par et pour les Developers. Il s’agit d’une image très visible et en temps réel du travail que les Developers prévoient d’accomplir durant le Sprint afin d’atteindre l’Objectif de Sprint. Par conséquent, le Sprint Backlog est mis à jourtout au long du Sprint selon ce qu’on en apprend.

Il devrait être suffisamment détaillé pour que les Developers puissent inspecter leur progression durant le Daily Scrum.

Je vois pas une seule fois marqué Product Owner ici. Pas plus que je ne vois d’US.

1 « J'aime »
18

Je suis en désaccord avec une grande partie de ce qui a été dit, et je vais décortiquer pour expliquer mon point de vue. Parce que j’aimerais comprendre ce qui amène à ce genre de conseil qui me semble totalement éloigné de la théorie et même de la pratique sur ce qui fait une équipe « Scrum ». Une vraie !

Les US ont une structure formelle assez précise : En tant que… je veux… afin de… pour la User Voice et Etant donné que… lorsque… alors… pour les critères d’acceptation.

Elles n’ont pas de structures formelles obligatoires. Elles suivent la règle des 3C : Cards / Conversation / acceptance Criteria. C’est ça qui fait une US. Et evidemment, que cela raconte une histoire.

C’est le PO qui détermine…

C’est sa responsabilité, oui. Mais il peut déléguer. Et non, pas forcément sous forme d’US. Encore heureux que certaines équipes font des choses différentes !
Aussi, US technique, ça n’a pas trop de sens, mais ça… C’est une autre « histoire » :stuck_out_tongue:

c’est lui qui définit un objectif de sprint (qui peut éventuellement être discuté)

C’est faux. C’est l’équipe qui la définit. Et il doit être absolument discuté. C’est un anti-pattern très récurrent et très embêtant. Les meilleures équipes que j’ai vu, c’est les devs qui proposaient plus que le PO, qui lui donne l’objectif produit.

Le niveau de profondeur du développement (cas nominal et autres cas) n’est pas du tout à la main des développeurs mais entièrement à la main du PO. Il est déterminé par les critères d’acceptation et discuté lors des réunions d’affinage.

Si c’était vrai, cela veut dire que la 11eme pratique du Manifeste Agile est fausse. " Les meilleures architectures, les meilleures spécifications de besoins, et les meilleures conceptions émergent d’équipes auto-organisées. "
Or, et ma conviction est forte dessus, ce n’est pas le cas. Une US est forcément négociable !! C’est une promesse de discussion entre les devs et le PO.

3 « J'aime »
19

Ah moi j’avais cards conversation confirmation.

Mais c’est un détail

1 « J'aime »
21

Je me dis qu’il manque Context dans ces fameux 3C. En plus de ça, la formulation du tryptique me gêne parce qu’elle sous entend que la carte vient toujours avant la conversation ce qui est un non sens. D’autant plus si on prend l’implémentation originel d’xp qui encourageait à créer les cards avec l’utilisateur, rendant la limite entre les deux quasi indistinguable.

22

CCC est un cycle on passe et repasse plusieurs fois sur la même carte.
On prend une carte vide ou pas
On Converse avec des concernés
On met à jour la carte pour confirmer ce dont on vient de conversationner (whaou le mot)

Les 3 mots se mettent dans l’ordre que tu veux et généralement celui plus facile à prononcer.

Ton utilisateur, (le vrai , ou le PO qui en est l’émissaire) fait partie des concernés.

1 « J'aime »