用户故事的演员必须是人吗?

Vag*_*lov 13 bdd acceptance-testing user-stories

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

这种形式使得直接编写易于理解的系统相关部分的验收测试.但这概念上是对的吗?用户故事不应该基于具有商业价值的功能,并且由于系统和服务对获取业务价值不感兴趣,他们不应该成为用户故事的参与者吗?

Spu*_*ley 8

我不明白为什么一个演员应该成为一个人 - 你的榜样是一个完全没有理由的理由.

像这样的方法论的事情并不是要坚持坚持定义的做法的细枝末节.即使最初提出"用户故事"概念的人认为他们应该只适用于人类,也没有法律强制你坚持他们的概念.

用户故事,敏捷,争球,和所有其他方法的全部意义在于协助与发展的过程,而不是成为发展的过程.只要方法更好,方法才有价值,所以你应该如何使用它.您应该随意调整方法以适应您的独特情况.不要让方法比实际的代码开发更重要.


Mar*_*tos 4

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