C’est quoi la différence entre un use case et une user story?
La réponse n’est pas simple pour moi. Bien que la différence de concept semble claire, dans les faits, c’est plus complexe.
On révise:
Definition wikipedia:
User Story
« Une user story (histoire utilisateur) est une exigence logicielle formulée en une ou plusieurs phrases dans le langage de tous les jours ou celui lié au métier l’utilisateur. Les user stories sont utilisées dans le développement logiciel dit Agile comme spécifications (en même temps que les tests d’acceptance). Le formalisme est limité à un carte de type post-it. »
Use Case
« Un use case (cas d’utilisation) dans l’ingénierie logicielle et système est une description du comportement d’un système en réponse à une requête externe au système lui-même. En d’autres termes, le use case décrit « qui » fait « quoi » avec le système en question. La technique des use case est utilisée pour définir les exigences de comportement d’un système en détaillant les exigences fonctionnelles avec un approche scénarios. »
Wikipedia en propose même la comparaison:
« Bien que les use cases et user stories proposent tous les deux une solution de définition des exigences utilisateur en terme d’interactions entre celui-ci et le système, il y a des différences majeures entre eux.
Les user stories proposent un format léger et facile à comprendre de l’information. Elles sont la plus part du temps formulées dans le langage de tous les jours de l’utilisateur et contiennent peu de détail. Elles doivent aider le lecteur à comprendre ce que le logiciel doit faire.
Les use cases, eux, décrivent un process et le détaillent pas à pas, ils sont plus formels. Un use case doit fournir le niveau détail suffisant pour être compris seul. Un use case est décrit comme « une description générale des interactions entre le système et un ou plusieurs acteurs, les acteurs pouvant être des personnes ou d’autres systèmes. »»
(Traduction par mes soins, donc soyez indulgents et surtout vigilants.)
Bon, avec tout ça, on est bien avancé !
- Use case, forte connotation procédurale, merci UML
- User story, pas assez formel, mais bien testé.
Dans son livre dédié à Scrum[1], Claude Aubry propose (en §13.5.5) une facette intéressante sur ce débat :
« La technique des user stories n’est pas une technique de spécification », ce en quoi il a tout à fait raison, puisque les exigences dans scrum sont définies et détaillées lors de la réunion de planification du sprint et non pas avant: cqfd.
Et « il est préférable de dialoguer… » combiné avec « rédiger des tests fonctionnels et les passer… »
On voit là bien l’approche radicalement différente, qui est plus dans le processus global de construction du projet que dans l’élément même du use case ou de la user story.
Un autre point indiqué par Claude est le fait que par définition un use case ne peut être utilisé dans un backlog, puisqu’il ne rempli pas les conditions d’entrée dans un sprint. Encore une fois, je suis entièrement d’accord, mais c’est plus discutable, en tout cas, il faut un peu plus d’expérience « agile » pour comprendre ce point. Je vais essayer d’expliquer plus clairement ce point là : Ne peuvent entrer dans un sprint que des éléments suffisamment fins au regard de la vélocité de l’équipe (Aï, aï, j’en ai perdu en route). Comme nous l’avons vu précédemment, une user story est par définition succincte et utilise un format léger, cela entraine une granularité assez fine et donc une complexité/charge relativement petite la plus part du temps. Dans le cas où une user story ne serait pas assez « fine », alors elle ne pourrait être à considérer dans le prochain sprint.
Pour les use cases, la notion de complexité/charge n’intervient jamais dans leur création. En conséquence leur niveau de granularité n’est pas adapté aux sprints. Bien sur, il est possible de découper les use cases en scenarios, puis en diagrammes d’états et ainsi avoir une granularité suffisante pour être utilisé dans un backlog. Mais on perd la vision utilisateur dans ce cas.
Je rajouterai pour ma part et pour vous aidez à faire le choix, les quelques idées et conseils suivants :
Pour moi, la vraie différence est dans la construction du logiciel lui-même.
Les use cases décrivent un système entier et déjà pre-pensé (cahier des charges, appel d’offres,…).
Les use cases ne supportent pas très bien le mode itératif, ou alors comme l’avait évoqué Pascal Roques lors de sa présentation sur la modélisation Agile (SigmaT 8), il ne faut pas avoir peur de jeter son modèle à la poubelle et ne pas chercher désespérément à le maintenir.
Les use cases à eux seuls ne servent à rien, il faut toute la suite des 13 schémas UML et outils associés.
C’est trop orienté architecture, et moi je m’en fiche de savoir si mon logiciel est en java ou en C# avec un poisson givré, un patron-java ou un flexible dans…, Je veux qu’il marche !
Les user stories sont faites pour décrire simplement la manière dont l’utilisateur pourra utiliser son logiciel. On pourra lui ajouter pleins de nouvelles fonctions super utiles, les user stories se complètent les unes aux autres, pas besoin d’un processus lourd, d’un outil de modélisation, le backlog est là (je parle de post-it, au mieux un fichier, pas d’outils de gestion de projet). Les user stories ont par définition aussi cette notion d’utilité et/ou de priorité que n’ont pas les use cases.
Je préfère l’utilisation des user stories dans le contexte de démarrage de nouveaux projets. L’aspect « quelle solution me propose mon logiciel pour faire ça » me plait pas mal, le logiciel orienté service à son utilisateur ! Plus facile pour discuter avec le client du client (SSII et sous traitance obligent) lors d’un atelier sans qu’il ait eu besoin d’apprendre UML.
Encore un point, on ne peut pas tous définir en use case :
« En tant qu’utilisateur, je veux que l’icone clignote quand je reçois un mail », vous traduisez ça comment en use case ? C’est, à la limite, une des 2000 exigences du use case « Recevoir un message »
Et puis si vous ne savez toujours pas quoi prendre, reste la solutio Mac ou Windows ?
o « Je veux acheter un nouvel ordinateur, c’est bien Max ? »
o « bein, t’as quoi pour l’instant ?
o « un pc ! »
o « Ah, et t’as du temps à perdre »
o « non ! »
o « alors reste sur pc »
Si vous avez l’habitude des use cases, gardez les, sinon
Osez le changement.
[1] Scrum, Le guide pratique de la méthode agile la plus populaire, par Claude Aubry, Edition Dunod, sur Amazon
