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
4 commentaires:
Hello,
Une problématique effectivement récurrente.
Voici dans ce billet, une vue synthétique comparant use cases et user stories:
http://www.qualitystreet.fr/2009/02/16/user-story-vs-use-case-soyez-agile/
Je voudrais ajouter quelques détails.
Un Use Case n'est pas UML. Dans UML il n'y a que l’ « UC diagram » (qui est la première étape vers la construction d'un UC complet). La description détaillée d'un UC est très bien documentée dans le livre "Writing Effective Use Cases" d'Alistair Cockburn (et ceci ne fait pas partie d'UML). Cependant, il est possible d'utiliser UML pour mieux représenter les interactions entre les acteurs et le système ou les activités d'un système lors d'un événement). Et, bien sure, on n’est pas obligés d’utiliser les 13 diagrammes UML pour ceci.
Je voudrais ajouter que les UC peuvent être très détaillés . . . mais pas obligatoirement.
Il est tout à fait possible (et en plus recommandable) de ne décrire que quelques lignes par UC au début du projet et les affiner au fur et à mesure qu’on en a besoin (ou qu’ils passent dans un sprint). Ceci pour avoir une approche ‘itérative et incrémentale’.
Concernant les tests. Du fait qu’un UC détaillé décrit un ou plusieurs scenarii nominaux et des scenarii alternatif et d’erreur, on peut dire que le test est créé au même temps que la description.
Concernant la charge et la complexité. Un UC peut être classifié vis-à-vis des autres UCs par rapport à sa complexité ; et cette complexité peut être donnée par le risque, la technicité, la priorité, le ROI, etc.
Je crois que les deux approches servent à découvrir le système tout au début ; quoique pas de la même manière.
La principale différence que je vois entre les deux, c’est la granularité de la fonction qu’ils décrivent. Un User story peut décrire quelque chose de très fin (« En tant qu’utilisateur, je veux que l’icone clignote quand je reçois un mail ») tandis qu’un UC décrit un service offert à un acteur, un service de plus haut niveau et qui a de la valeur ajoutée pour celui qui l’exécute.
David Garduno
Merci David pour ces compléments d'info.
Par contre, tu sembles dire en fin de commentaire que les user stories n'ont pas de valeur ajoutée.
Bien au contraire, tout est basé sur ce point.
Il y a bien de la valeur ajoutée dans (« En tant qu’utilisateur, je veux que l’icone clignote quand je reçois un mail »), si c'est l'utilisateur qui le demande.
Tu as raison Laurent concernant la 'valeur ajoutée'.
On peut plutôt définir un UC comme un "Processus Métier Élémentaire": Tâche effectuée par une personne en un lieu et un temps donnés, en réponse à un événement, et qui ajoute une valeur commerciale mesurable et laisse les données dans un état cohérent.
Définition tirée de la formation La modélisation efficace des exigences avec les cas d’utilisation de Valtech Training
David GARDUNO
Enregistrer un commentaire