1. 角色、特征、利益 Role Feature Benefit Template

模板：

• As a < Who，User>，I want < What，Feature，Goal，>，So that < Why，Benefit>

• 作为 <用户角色>，我想要 <特征，目标>，以便可以<业务价值>

  用法：

• 用户故事一般不使用技术语言来描述

• 要使用用户可以理解的业务语言来描述
• 简单、关注业务价值
• 写在故事卡上
• 

另一种用户故事的表达模板

Given When Then Approach (Gherkin language)
模板：Given ，When the does ，thenhappens.

2. 3C卡片模型

定义：用户故事通过捕捉小规模场景来设想用户与系统是如何交互。每个用户故事由3C才能完成。

Card：以卡片的方式描述一个事情

• 描述的内容简洁、词汇含义统一，项目成员不会对同一内容有差异性理解；

• 这些卡片用于后续的沟通、对需求内容的组织和排列优先级；

  Conversation：简单描述完整的事情，引发讨论。

• 卡片的内容是由团队在沟通中获得，而非由同一个人输出或更新的，不然它与传统的需求分析方法无异；

• 项目成员需要一起就卡片内容进行讨论。在复杂逻辑中，梳理出清晰的需求脉络，并在这一过程中，达到共识和理解的统一。

  Confirmation：需要有确认方式（验收标准）

• 以始为终，先行确认以怎样的结果，来判断开发任务的完成；

• 它保证每个故事都是独立的、完整的逻辑，可以单独交付；
• 它为驱动测试驱动开发、行为驱动开发和持续集成提供可能。

3. 用户故事符合：INVEST和SMART

起源：

• 2003年：用于快速评估用户故事的INVEST清单源于Bill Wake的一篇文章，该文章还将首字母缩写SMART（具体的、可测量的、可实现的、相关的、有时间限制的）用于对用户情景进行技术分解所产生的任务。

• 2004年：INVEST首字母缩写是Mike Cohn的“用户故事”中推荐的技术之一，它在第2章中详细讨论了这个概念。

  INVEST原则

  

  Independent（独立的）

• 最好用户故事不要彼此依赖。

• 相互间如果依赖太强会导致：制定计划，确定优先级等估算困难

  Negotiable（可协商的）

• 故事卡片起提醒，团队基于此评估，而不是把故事卡片看做确定性的需求。

• 内容是可以协商，它不是合同

• 用户故事尽可能简短

  Valuable （有价值的）

• 对客户而言，是有价值的

• 避免仅对开发人员有价值的故事。

  Estimable （可评估）

• 团队可以估计用户故事的规模，确定其优先级、工作量，安排计划

• 便于需求澄清

  Small （小的）

• 用户故事应颗粒度足够小，以便在一个迭代可以完成

  Testable （可测试的）

• 需求是清晰，有验收标准，可验证的。

SMART原则

Specific（明确的）

• 特定的用户描述有助于向团队传达其目的，并有助于保持其独立性。

  Measurable（可测量的）

• 可估算的的（故事点），并且可以根据DoD来验收

  Achievable（能实现的）

• 团队应该能够在限定的迭代时间内达到完成、执行、实现的。如果故事不清楚，那么团队可以想PO寻求澄清、细化，或者将大的任务分解为小的任务

  Relevant（价值相关的）

• 为用户故事增加价值的任务。以增量方式为目标做出价值最大化贡献

  Timebound（有时间限制的）

• 所需的工作量和时间被合理安排在时间盒内

4. 用户故事的解聚 Disaggregation

• 当用户故事比较复杂，且无法插入在一个迭代内完成时，可将用户故事解聚为颗粒度更小的用户故事
• 符合INVEST的“S”
• 通常，这个解聚是结合用户故事地图一起使用。

• 根据数据处理或执行的操作进行解聚。例如，满足系统执行查找、插入、修改或删除数据等操作的不同行为的不同故事可以被相应地拆分。
• 根据小故事的轻重缓急进行解聚。例如，用户输入的验证可以与捕获和持久化用户输入分开处理。
• 基于横切关注点进行解聚，如应用程序日志、异常处理、连接池和安全性。例如，如果它太复杂和耗时，应用程序可以在未来的迭代中以这些方面为基础构建一个单独的故事。
• 根据功能和非功能特征进行解聚。例如，对单点登录特性或更高性能的增强可以作为独立的故事来满足，并保持独立于功能故事。

  注意！用户故事的解聚，类似WBS，但有很大不同

  | 敏捷故事地图 | 瀑布式开发／传统 WBS | | —- | —- | | 解聚 Disaggregation | 分解 Decomposition | | 组件故事和估计加起来不必是原故事的 100% | 工作包和估计加起来必须是总计的100% | | 初始节点是大的用户故事或史诗 | 顶端节点是高层级的可交付物 | | 通常用故事卡片在两个维度进组件故事的划分 | 用金字塔结构、树状结构 |

5. 用户故事分解（拆分）为任务 Decomposition

所谓任务，是指开发者为了所完成的故事，必须进行的工作，如下，将一个用户故事分解为7个任务
用户故事：“作为一个借阅者，我想根据名字来搜索一本书。”这样的故事可以分解为以下几个组成部分:

• Task 1：设计一个用户界面元素，该元素包含一个输入书名的文本框和一个触发搜索的按钮。
• Task 2：编写SQL存储过程，该存储过程接受输入作为图书名，并返回匹配结果（如果搜索不成功，则为空）。
• Task 3：编写一个服务，该服务调用存储过程，将图书名作为输入传递，并解析输出并格式化输出。
• Task 4 ：编写UI元素，该元素调用服务来执行搜索，并以HTML表的形式显示搜索结果。
• Task 5 ：执行集成测试，以查看不同部分之间的通信有没有任何错误。
• Task 6 ：编写代码，使不同用户会话（例如，不同计算机上的不同浏览器）可以进行多达10个并发搜索。
• Task 7 ：执行测试，以包括一些场景，比如图书名中的特殊字符，以及图书可搜索但已被另一个借阅者预订的位置。

6. 用户故事验收标准

• 编写验收标准
• 测试要点记录在故事卡背面，随时可以增加
• 这些测试可以用于演示故事已经完整、正确的实现