Différence entre la user story et le cas d'utilisation
Je ne suis pas certain de comprendre ce qui différencie une user story d'un cas d'utilisation. Cela me semble être une ligne très fine. Qu'est-ce qu'un cas d'utilisation et en quoi diffère-t-il d'une user story?
Les termes sont souvent confondus aujourd'hui, mais pour les plus exigeants:
Le cas d'utilisation se réfère plus communément aux étapes procédurales qu'un utilisateur prend pour faire quelque chose:
Example: Knead the flour, add some salt, place in oven, wait 30 minutes.
L'histoire de l'utilisateur tente de capturer le récit de l'expérience de l'utilisateur. Cela inclut les étapes procédurales dans un cas d'utilisation, mais aussi les objectifs, la motivation, les incitations et parfois l'expérience émotionnelle de l'utilisateur.
Example: User is a baker, and needs to bake bread quickly and consistently
every morning at 5am. She is often tired and it's easy to make
mistakes at that hour. The user bakes bread by
[insert procedural steps here].
Bien qu'il existe des définitions raisonnablement formelles de chacun dans des contextes spécifiques (par exemple, dans UML, un cas d'utilisation peut être formellement modélisé , et les user stories sont un composant formel de la programmation Agile processus), je ne pense pas qu'il y ait une grande cohérence d'utilisation, j'ai donc essayé d'utiliser une définition vernaculaire ci-dessus.
Notamment, les entrées Wikipedia pour Cas d'utilisation et ser Story utilisent des qualificatifs de contexte et d'utilisation pour définir les termes, en raison de l'ambiguïté.
Les termes user story et use case ne sont pas des termes provenant de HCI. Les "cas d'utilisation" proviennent du génie logiciel. "User story" vient de la méthode Agile d'ingénierie logicielle.
From About Face: "Les cas d'utilisation ... sont une technique basée sur des descriptions exhaustives des exigences fonctionnelles du système, souvent de nature transactionnelle, se concentrant sur l'action de bas niveau de l'utilisateur et la réponse du système qui l'accompagne ... D'après notre expérience, le plus grand le défaut des cas d'utilisation traditionnels comme base pour la conception d'interaction est leur tendance à traiter toutes les interactions possibles des utilisateurs comme également probables et importantes. Cela indique leur origine en génie logiciel plutôt qu'en conception d'interaction. " Un cas d'utilisation prend un "acteur" et un "objectif", puis énumère les "tâches" qu'ils accomplissent pour atteindre l'objectif. En génie logiciel, un "acteur" n'a pas besoin d'être une personne; il peut s'agir d'une partie d'un système interagissant avec une autre partie d'un système. Ceci est utile pour aider à échafauder ou à compartimenter le code.
Je pense qu'une user story est essentiellement un cas d'utilisation, mais beaucoup, beaucoup plus court et plus précis. Définissez l'acteur, le but et le résultat. Je ne devrais pas être plus qu'un seul Post-It peut gérer.
La user story pour agile est logique, car le cycle de développement est plus court et plus rapide; au lieu de prendre toutes les décisions maintenant, vous faites ce que vous pouvez, puis revoyez vos décisions dans le cycle suivant. En revanche, la création d'un cas d'utilisation traditionnel prend plus de temps et d'efforts, mais vous avez une meilleure compréhension de vos fonctionnalités.
Pour ces peuples tl; dr, une réponse abrégée serait:
Use Case = Une instance où un utilisateur utiliserait une fonctionnalité.
User Story = Un exemple complet depuis le point de contact initial jusqu'à la fin de la tâche où un ensemble de fonctionnalités serait utilisé.