用户故事的主角必须是人类吗？
用户故事传统上写作“作为[用户类型]，我想要[功能]，以便[一些好处]”。在书籍和在线资源中，[用户类型]通常对应于人类的角色。然而，在描述系统内部的功能时，通常更容易用一些无人值守的服务来代替用户，例如“作为一个 ServiceX，我希望定期刷新一些数据，以便我可以使用最新的信息执行 XYZ 操作”。
这种形式使得为系统的相关部分编写易于理解的验收测试变得简单。但这在概念上正确吗？用户故事不应该基于提供商业价值的功能，并且由于系统和服务对获得商业价值不感兴趣，因此它们不应该成为用户故事的参与者？
User stories are traditionally written as expression "As a [User Type] I want [feature] so that [some benefit]". In the books and online resources [User Type] typically correspond to a role of a human being. However, when describing features of system internals, it is often easier to put some unattended service in place of a user, e.g. "As a ServiceX I want some data to be regularly refreshed to that I can do XYZ using most recent information".
Such form makes it straightforward to write easy-to-understand acceptance tests for related parts of the system. But is this conceptually right? Shouldn't user stories be based on features giving business value, and since systems and services are not interested in gaining business values, they should not be actors of user stories?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不明白为什么演员必须是人类——你的例子就是一个很好的理由，证明演员不必是人类。
像这样的方法论的重点并不是要拘泥于既定实践的细节。即使最初提出“用户故事”概念的人认为它们只适用于人类，也没有任何法律强迫您严格遵守他们的概念。
用户故事、敏捷、Scrum 和所有其他方法的全部要点是协助开发过程，而不是成为开发过程。方法只有在使流程变得更好的情况下才有价值，因此您应该如何使用它。您应该随意调整该方法以适应您的独特情况。不要让方法论变得比实际的代码开发更重要。
I don't see why an actor should have to be a human - your example is a perfectly good reason for it not to be.
The thing with methodology like this is not to get hung up about sticking to the minutiae of the defined practice. Even if the people who originally came up with the concept of "user stories" thought that they should only apply to humans, there's no law in place forcing you to stick rigidly to their concepts.
The whole point of user stories, agile, scrum, and all other methodologies is to assist with the development process, not to be the development process. A methodology is only valuable as long as it makes the process better, so that's how you should use it. You should feel free to adapt the methodology to suit your unique circumstances. Don't let the methodology become more important than the actual code development.
系统肯定对获得商业价值感兴趣。参与者可以是第三方编写的自动化代理，它体现了第三方的意图。事实上，随着 Web 服务成为主要网站的更流行的功能，这正在成为交互的主要形式，从而允许代表用户进行复杂的站点间交互，但仅涉及机器。
Systems most certainly are interested in gaining business value. An actor could be an automated agent written by a third-party, and which embodies that third-party's intent. In fact, this is becoming a dominant form of interaction as web services become a more popular feature of major web sites, thus allowing complex inter-site interactions on behalf of users but involving only machines.
这是秘密。它们不是用户故事，而是用户场景。
用户是进行交互的对象——机器或人。
利益相关者是从交互中受益的个人或公司（它从来都不是机器；无论如何在人工智能开发的现阶段都不是）。对于任何给定的项目，通常有多个利益相关者具有相互竞争的需求。通过弄清楚谁为项目付费以及为什么付费，可以追踪主要利益相关者。
用户很少是主要利益相关者。通常，利益相关者希望用户做某事，以便他们（利益相关者）能够获得利益。
例如，Twitter 投资者希望用户喜欢 Twitter，这样他们就可以保留未来赚钱的所有选择。老板们希望他们的秘书使用文字处理器，这样他们就可以更快地输入字母，并在最后一刻改变主意。 StackOverflow 希望优秀的帖子得到点赞，这样他们就可以获得广告收入。
这是我就该主题撰写的一篇博客文章，其中包括您可以使用一个模板来区分用户和利益相关者的关注点。我把它作为一个练习，让你想象一下，当你（帖子的用户）阅读它时，谁会受益。
Here's the secret. They're not user stories, but they are user scenarios.
The user is the thing doing the interacting - the machine, or a person.
The stakeholder is the person or corporation getting the benefit from the interaction (it's never a machine; not at this stage in AI development anyway). There are usually several stakeholders with competing needs for any given project. The primary stakeholder can be tracked down by working out who's paying for the project and why.
The user is rarely ever the primary stakeholder. Usually a stakeholder wants a user to do something so that they, the stakeholder, can get the benefit.
For instance, Twitter investors want users to enjoy Twitter so that they can keep all their options for making money in the future. Bosses want their secretaries to use word processors so that they can get letters typed faster and change their minds at the last minute. StackOverflow wants great posts to be upvoted so that they can get their advertising revenue.
Here's a blog post which I wrote on the subject, including a template you can use to separate the concerns of user and stakeholder. I leave it as an exercise for you to imagine who benefits when you, the user of the post, read it.