用户故事传统上写为“作为[用户类型]我想要[功能]以便[某些好处]”。在书籍和在线资源中[用户类型]通常对应于人类的角色。然而，当描述系统内部的特征时，通常更容易将某些无人值守服务置于用户的位置，例如， “作为ServiceX，我希望定期刷新一些数据，以便我可以使用最新信息进行XYZ”。
这种形式使得直接编写易于理解的系统相关部分的验收测试。但这在概念上是对的吗？用户故事不应该基于功能给予 商业 价值，既然系统和服务对获取商业价值不感兴趣，他们不应该成为用户故事的参与者？
用户故事传统上写为“作为[用户类型]我想要[功能]以便[某些好处]”。在书籍和在线资源中[用户类型]通常对应于人类的角色。然而，当描述系统内部的特征时，通常更容易将某些无人值守服务置于用户的位置，例如， “作为ServiceX，我希望定期刷新一些数据，以便我可以使用最新信息进行XYZ”。
这种形式使得直接编写易于理解的系统相关部分的验收测试。但这在概念上是对的吗？用户故事不应该基于功能给予 商业 价值，既然系统和服务对获取商业价值不感兴趣，他们不应该成为用户故事的参与者？
系统肯定有兴趣获得商业价值。演员可以是由第三方编写的自动代理，它体现了第三方的意图。事实上，随着Web服务成为主要网站的一个更受欢迎的功能，这成为一种主要的交互形式，从而允许代表用户进行复杂的站点间交互，但仅涉及机器。
系统肯定有兴趣获得商业价值。演员可以是由第三方编写的自动代理，它体现了第三方的意图。事实上，随着Web服务成为主要网站的一个更受欢迎的功能，这成为一种主要的交互形式，从而允许代表用户进行复杂的站点间交互，但仅涉及机器。
我不明白为什么一个演员应该成为一个人 - 你的榜样是一个完全没有理由的理由。
像这样的方法论的事情并不是要坚持坚持定义的做法的细枝末节。即使最初提出“用户故事”概念的人认为他们应该只适用于人类，也没有法律强制你坚持他们的概念。
用户故事，敏捷，Scrum和所有其他方法的重点是 助攻 随着开发过程，而不是 是 发展过程。只要方法更好，方法才有价值，所以你应该如何使用它。您应该随意调整方法以适应您的独特情况。不要让方法比实际的代码开发更重要。
这是秘密。它们不是用户故事，但它们是用户场景。
该 用户 是进行交互的东西 - 机器还是人。
该 利益相关者 是从交互中获益的人或公司（它从来不是机器;无论如何都不是在AI开发的这个阶段）。通常有几个利益相关者对任何特定项目都有竞争需求。可以通过确定谁为项目付款及其原因来追踪主要利益相关者。
用户是 很少 主要利益相关者。通常，利益相关者希望用户做一些事情，以便他们（利益相关者）可以获得利益。
例如，Twitter投资者希望用户享受Twitter，这样他们就可以保留所有未来赚钱的选择。老板希望他们的秘书使用文字处理器，这样他们就可以更快地输入字母，并在最后一分钟改变主意。 StackOverflow希望对优秀帖子进行投票，以便他们获得广告收入。
这是一篇博文 我在这个主题上写的，包括一个模板，你可以用来分隔用户和利益相关者的关注。我把它作为练习让你想象当你，帖子的用户阅读它时谁会受益。