用户故事传统上写成表达"作为[用户类型]我想要[功能]以便[一些好处]"。在书籍和在线资源中，[用户类型]通常对应于人类的角色。然而，在描述系统内部特性时，通常更容易将一些无人值守的服务代替用户，例如"作为 ServiceX，我希望定期刷新一些数据，以便我可以使用最新信息进行 XYZ"。

这种形式使得为系统的相关部分编写易于理解的验收测试变得简单。但这在概念上正确吗？用户故事不应该基于赋予商业价值的功能，并且由于系统和服务对获得商业价值不感兴趣，它们不应该成为用户故事的参与者吗？

我不明白为什么演员必须是人——你的例子是一个很好的理由。

采用这种方法论的目的是不要拘泥于固定实践的细枝末节。即使最初提出"用户故事"概念的人认为它们应该只适用于人类，但没有任何法律可以强迫你死守他们的概念。

用户故事、敏捷、Scrum 和所有其他方法的全部意义在于协助开发过程，而不是成为开发过程。一种方法只有在使过程变得更好的情况下才有价值，所以这就是你应该使用它的方式。您应该随意调整方法以适应您的独特情况。不要让方法变得比实际的代码开发更重要。

这就是秘密。它们不是用户故事，而是用户场景。

用户是进行交互的事物 - 机器或人。

利益相关者是从交互中受益的个人或公司(它绝不是一台机器；反正在人工智能开发的这个阶段也不是)。对于任何给定的项目，通常有几个利益相关者具有相互竞争的需求。主要利益相关者可以通过找出谁为项目付款以及为什么付款来追踪。

用户很少是主要的利益相关者。通常，利益相关者希望用户做某事，以便他们，利益相关者，可以获得利益。

例如，Twitter 投资者希望用户喜欢 Twitter，以便他们可以保留未来赚钱的所有选择。老板们希望他们的秘书使用文字处理器，以便他们可以更快地输入字母并在最后一刻改变主意。 StackOverflow 希望对优秀的帖子进行投票，以便他们获得广告收入。

这是我写的关于这个主题的博客文章，包括一个模板，您可以使用它来区分用户和利益相关者的关注点。我把它留作练习，让您想象一下，当您(该帖子的用户)阅读它时，谁会受益。

系统肯定对获得商业价值感兴趣。参与者可以是由第三方编写的自动化代理，它体现了第三方的意图。事实上，这正在成为一种主要的交互形式，因为 Web 服务成为主要网站更受欢迎的功能，因此允许代表用户进行复杂的站点间交互，但只涉及机器。