bdd - 用户故事的演员必须是人吗？

Question

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

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

Answer 1

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

像这样的方法论就是不要拘泥于坚持既定实践的细枝末节。即使最初提出“用户故事”概念的人认为它们应该只适用于人类，但没有任何法律可以强迫你严格遵守他们的概念。

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

Answer 2

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

Answer 3

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

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

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

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

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

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