用户故事, user story

故事story是粗略的勾勒的需求，它是信！号！卡！，指向真正的需求或者叫故事详情，怎么说都好。

而需求就是需求。

这里隐含了敏捷的一个要素，就是，延！迟！决！策！

当需求不是被细化的摆放着，而是粗略的STORY的时候，才能更好的表达延迟决策。首先我们并不在一开始就把所有的东西都想清楚，而是仅仅以STORY的方式跟踪记录我们未来要做的事情。当开发前，我们才去细化STORY故事，把他变成需求。或者，开发前，我们扔掉STORY，因为它已经不重要了。see。故事可以帮我们更好的做延迟决策。保证所有的事情是在开发前才定下来的，而且保证我们不会遗漏。所以这里，就是为什么敏捷要用STORY而不是需求去进行需求的管理。

作者: 马菲菲

链接: https://www.zhihu.com/question/26996772/answer/35078718

来源: 知乎

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

用户故事

https://www.tapd.cn/forum/view/43571

https://www.cnblogs.com/jetlian/p/3946359.html

http://www.scrumcn.com/agile/scrum/4823.html

http://www.scrumcn.com/agile/scrum/20026.html

https://blog.csdn.net/GitChat/article/details/78410016

用户故事 (User Story) 和验收标准 (Acceptance Criteria)

那么什么是用户故事呢？一个用户故事就是一个功能或者feature的需求 (requirement) ，被写出了也就一两行字，最多5行。一个用户故事通常是最简单的可能性需求，有且只能是一个功能或feature。最常见使用的标准格式的用户故事如下: 作为一个用户/客户角色，我想要达到的目标是什么，以及达到目标的原因e.g:作为社交工具微信的用户，我想要在聊天对话框中有一个拍照图标去自拍和发照片，那么我就可以和朋友一起相互发照片。

什么是验收标准？验收标准就是一系列可以接受的条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和相关人接受。这是用户故事完成很重要的一部分，它需要被产品负责人和业务分析人员认真的学习，因为错失一个很小的标准都会损失惨重。这是简单的编号或者编号列表。格式如下: 在我做某些动作 (action) 之前请赐给一些先决条件，然后期望结果发生。举个栗子: 1. 假设我正在和朋友聊天，我应该能够拍照2. 当我点击照片时，我应该可以在照片上添加一些文字，然后发给朋友3. 如果我的手机照相机有问题，一条错误信息，如"摄像头无法打开”…，相应的也应该出现因此，用户故事为任何功能或feature定义了需求，另一方面，验收标准为用户故事或需求定义了"完成标准的定义”。作为QA，理解用户故事非常重要，同时深刻理解验收标准，并且在测试开始前没有一点的疑惑。

https://www.jianshu.com/p/bde45187a78f