Doit un acteur d'une histoire d'utilisateur un être humain?

Question

Histoires d'utilisateurs sont traditionnellement écrits comme l'expression « En tant que [Type d'utilisateur] Je veux [fonction] de sorte que [certains avantages] ». Dans les livres et les ressources en ligne [Type d'utilisateur] correspond généralement à un rôle d'un être humain. Cependant, lors de la description des caractéristiques de fonctionnement interne du système, il est souvent plus facile de mettre un service sans surveillance en place d'un utilisateur, par exemple « En tant que ServiceX je veux des données régulièrement actualisées que je peux faire XYZ en utilisant les informations les plus récentes ».

Cette forme rend facile d'écrire des tests faciles à comprendre pour l'acceptation des parties correspondantes du système. Mais est-ce conceptuellement droit? Ne doivent pas user stories être basées sur des fonctionnalités donnait entreprise valeur, et que les systèmes et les services ne sont pas intéressés à acquérir des valeurs d'entreprise, ils ne devraient pas être acteurs d'histoires utilisateur?

Answer 1

La plupart des systèmes sont certainement intéressés à acquérir une valeur commerciale. Un acteur pourrait être un agent automatisé écrit par un tiers, et qui incarne cette intention de tiers. En fait, cela devient une forme dominante d'interaction en tant que services Web deviennent une caractéristique plus populaire des principaux sites Web, permettant ainsi des interactions inter-sites complexes au nom des utilisateurs, mais impliquant uniquement des machines.

Answer 2

Je ne vois pas pourquoi un acteur devrait être réduit à un être humain -. Votre exemple est une très bonne raison pour qu'il ne soit pas

La chose avec la méthodologie comme celui-ci est de ne pas se raccrocha au sujet de coller aux menus détails de la pratique définie. Même si les gens qui à l'origine est venu avec le concept de « user stories » pensée qu'ils ne devraient appliquer à l'homme, il n'y a pas de loi en place, vous obligeant à tenir strictement à leurs concepts.

Le point d'histoires d'utilisateurs, agile, scrum, et toutes les autres méthodes est de aider avec le processus de développement, pas être le processus de développement. Une méthodologie est seulement valable aussi longtemps que cela rend le processus mieux, de sorte que de la façon dont vous devriez l'utiliser. Vous devriez vous sentir libre d'adapter la méthodologie en fonction de votre situation particulière. Ne laissez pas la méthodologie devenir plus important que le développement de code réel.

Answer 3

Voici le secret. Ils ne sont pas des histoires d'utilisateurs, mais ils sont des scénarios utilisateur.

utilisateur est la chose à faire l'interaction -. La machine, ou une personne

parties prenantes est la personne physique ou morale obtenir le bénéfice de l'interaction (il n'est jamais une machine, pas à ce stade dans le développement AI de toute façon). Il y a généralement plusieurs intervenants ayant des besoins en concurrence pour un projet donné. Le principal intervenant peut être dépisté en travaillant qui paie pour le projet et pourquoi.

L'utilisateur est rarement le principal intervenant. En général, l'un des intervenants à un utilisateur de faire quelque chose pour eux, les parties prenantes, peuvent obtenir le bénéfice.

Par exemple, les investisseurs Twitter veulent utilisateurs de profiter de Twitter afin qu'ils puissent garder toutes leurs options pour faire de l'argent à l'avenir. Bosses veulent que leurs secrétaires d'utiliser le traitement de texte afin qu'ils puissent obtenir des lettres tapées plus rapidement et changer d'avis à la dernière minute. StackOverflow veut de grands postes à upvoted afin qu'ils puissent obtenir leurs recettes publicitaires.

Voici un blog que j'ai écrit sur la sujet, y compris un modèle que vous pouvez utiliser pour séparer les préoccupations des utilisateurs et des parties prenantes. Je laisse comme un exercice pour vous d'imaginer qui en profite lorsque vous, l'utilisateur du poste lire, il.