你也许听说过，在敏捷工作方式里，团队一般采用用户故事卡片的形式来描述需求。用户故事是指用户通过系统完成一件有价值目标的事情。

1.Why：为什么要用“用户故事”描述产品需求

采用用户故事卡片的形式来描述需求，可以帮助产品负责人和团队逐渐形成以用户为中心的思考方式，而不是单纯地以功能为中心来思考产品。

2.Who：哪些人创建用户故事

产品负责人创建初始的用户故事，然后将用户故事卡片带到Backlog梳理会议上与团队成员一起讨论，再由团队成员来补充和创建新的用户故事。这样做比团队从零开始创建用户故事的效率要高。

对于那些创新型的特性，也许产品负责人对要做什么也没有把握，这个时候可以召集团队一起进行头脑风暴来创建用户故事。

3.When：什么时候创建用户故事

团队的第一个Backlog条目就可以以用户故事的形式创建。此外，产品负责人在与团队做Backlog梳理和迭代计划的时候，会发现并创建新的用户故事或者修改已有的用户故事。

4.How：怎么创建用户故事

用户故事的模板如图8-15所示。一般来说，用户故事包含三个要素。

• 角色：谁要使用这个功能。
• 功能：需要完成什么样的功能。
• 目的：这个功能可以达到什么目的。
  
  

图8-15用户故事的模板

图8-16是我做过的电子看板工具产品的一个用户故事的例子。

图8-16用户故事示例图

很多团队学习了用户故事后，开始僵硬地采用用户故事的形式来描述需求。比如：“作为一个开发者，我想要后台给我提供×××接口，以便于我调用相关的素材来完成前台页面的展现。”

这个需求只是从开发者的角度来描述的技术任务，并没有从真实的用户角度来描述，所以它没有体现出产品给用户带来的价值。

很多团队区分不出用户的角色，所有用户故事的开头都是“作为一个用户”，导致用户故事流于形式。

如果团队不清楚用户是谁，应该回顾其创建的用户画像，进而明确当前这个用户故事是为哪类用户提供价值需求的。

问：需求和用户故事是什么关系？敏捷里所有的需求都用用户故事来描述吗？

答：用户故事是从用户使用产品系统的角度对需求进行描述的方式，但不是所有的需求都必须以用户故事的形式来描述。如果需求与用户的使用无关，就不需要采用用户故事的形式来描述。比如，有些产品需要满足某些法律标准、政府规定、行业规范等，这些需求不涉及用户如何使用产品系统，因此不必采用用户故事的形式来描述。

问：那么对于那些涉及用户使用产品系统的需求，需要永远选择用户故事的方式来描述吗？

答：在团队没有养成以用户为中心的思考习惯之前，最好采用用户故事的方式来帮助团队固化思维方式。但是，在团队形成习惯之后，就不需要每个需求都用用户故事来描述，尤其是那些产品体验已经被优化的需求，因为团队对目标用户及其使用目的都已经非常清楚。

只用一句话描述用户故事还不够，团队还需要创建验收条件来定义用户故事的边界和范围，相当于用户故事的“完成的定义”。验收条件有如下三个作用：

• 触发团队从用户的角度思考如何使产品满足用户的诉求；
• 作为创建测试用例的输入；
• 把握需求的范围，去除不必要的需求场景。
  
  

一个网站产品的用户通过设置邮箱密码完成注册，这个产品的用户故事是：“作为一个新用户，我希望设置邮箱密码，以完成邮箱注册的流程。”

其验收条件如下：

• 密码至少8个字符，不超过12个字符；
• 密码至少包含一个数字、一个字母，支持数字、字母和特殊字符的组合；
• 区分大小写；
• 支持键盘上可以输入的特殊字符，除了“-”“[]”“|”“/”之外。
  
  

这几条验收条件非常清晰，可以直接作为测试用例设计的输入。

验收条件是用户故事的重要组成部分。我建议产品负责人为每个用户故事预先准备好自己能够想到的验收条件，并将用户故事带到团队中一起讨论，团队会补充和丰富验收条件，这样做会更高效。通常，团队在讨论验收条件的时候会涌现出新的用户故事。

用户故事需要满足以下原则，如果用一个英文单词来描述，可简写为“INVEST”。

1.I（Independent）：独立的

团队应尽量避免用户故事之间相互依赖，因为团队在对用户故事排优先级或做迭代计划时，用户故事之间的相互依赖会使工作量的估算变得更加困难。

我们可以通过下面两种方法减少用户故事之间的依赖性：

• 将相互依赖的用户故事合并成一个大篇幅的、独立的用户故事；
• 重新拆分用户故事。
  
  

但是，团队是不可能完全避免依赖的，因为团队构建的是一个系统。但是团队可以尽量减少依赖。

2.N（Negotiable）：可协商的

用户故事是对产品功能的简短描述，不是详尽的、面面俱到的细节描述，需求的细节将在团队的讨论过程中涌现出来。用户故事开启了产品负责人与利益干系人、客户以及团队关于需求讨论的对话，但是它并不是需求的全部。

问：讨论出的细节需要文档化吗？

答：为了便于团队记忆，讨论结束后最好将细节记录下来，附在用户故事的描述里。细节可能包括如下几个方面。

• 需求的业务流程，比如用户操作的第一步、第二步、第三步等。
• 需求的数据边界定义，比如，如何处理数据区间。
• 需求涉及的算法。算法貌似是解决方案的范畴，其实不一定，因为算法决定了用户数据的处理方式和结果。
• 涉及UI交互的，需要有低保真原型图。一图胜过千言万语，原型图可以有效地表达需求。但是由于这时还没有开始用户体验设计，所以用一张简单的设计图表达出需求的UI以及简单的用户交互即可。
  
  

3.V（Valuable）：对用户或客户有价值的

用户故事应该清晰地体现出产品对用户或客户的价值。这也是为什么用户故事要按照“作为一个<角色>，我想要<功能>，以便于<目的>”的格式来书写，而“以便于”正是体现价值的部分。

4.E（Estimable）：可估算的

开发团队需要估算用户故事的规模，以确定优先级、工作量，并安排计划的执行。如果团队发现有些用户故事无法估算，说明团队对需求的理解还不清晰，或者是涉及的技术具有不确定性。

5.S（Small）：小

用户故事的规模要尽量小，至少要确保其在一个Sprint内能够完成。用户故事的规模越大，在安排计划执行和工作量估算等方面的风险就会越大。凭经验来看，如果团队采用的估算单位是天，那么对一个用户故事进行拆分，最好在1~5天完成；如果团队采用的估算单位是虚拟的故事点，那么一个用户故事最好拆分到13个点以内完成。但是，也不能单纯为了追求“小”而导致用户故事不能独立产生价值。

6.T（Testable）可测试的

用户故事必须是可测试的。团队通过以下方法能使用户故事达到可测试的条件。

• 测试人员与开发人员一同参与用户故事的讲解和讨论，从而让测试人员能第一时间理解需求，并从测试的角度提问和思考。通常产品负责人和开发团队思考的是需求的正常场景，而测试人员能够有效地补充需求的异常场景。
• 明确每个用户故事的验收条件，并将其作为测试的输入。
  

您好，看到这个帖子很受启发，请问这是哪本书中介绍的知识，想买来系统看看，谢谢