[Scrum敏捷开发之] User Story三要素详解
User Story的三个组成部分：
- 价值声明
- 设想
- 验收标准
其格式通常如下所述：
As a...[Who]...I want to...[What Functionality Desired]...in order to...[Why It's Important].
"Who" 指直接使用产品或者使用产品输出信息的人。重要的是，如果这个用户在项目章程中没有明确定义，那么将由PO在得到stakeholders一致同意的情况下添加进章程。这确保了在将术语“End User”放入值语句的[Who]部分时，有一个清晰的理解。通常“End User”太模糊了。它应该是一个描述性的标题，如“研究图书馆员”或“战斗机副驾驶”等。
"What" 应该是正在构建的组件的最重要方面。通常因为产品特性服务于多个用户和并且有不同的需求和期望，所以不同的用户描述看起来是相互竞争的。当新产品特性或组件创建了多种类型的值或输出时，请确保将值语句中的值作为优先级。当新的产品特性或组件创建了多种类型的价值或输出时，请确保将优先级最高的放到价值声明中。优先级很重要，因为一个为所有角色做所有事情的产品，最终会无法对任何角色提供好的服务。
最重要的是，“What”或“功能需求”应该以业务术语中陈述，比如：
I want to Login Using My User Name and Password --- WRONG!
I want to access my account --- RIGHT!
"Why It's Important" 部分的定义是大多数User Story的败笔。这对于经验不够丰富和刚开始接触Scrum的团队来说是真实存在的。最容易犯的错误就是简单地用另一种方式重申“What”。正确的姿势应该如下：
比如： "I want to log in to access my account." 如上所述，其中恰当的 "What" 为 "access my account." 那么“Why”呢：
- 为了查看通知
- 为了分配任务
- 为了查看心仪球队的排名
这一点至关重要，“Why”关乎Feature和功能，其他不那么重要的则属于假设。
其他要点:
- 设想包含一系列
- 由用户故事创建的不太重要的价值
- 捕捉关于“为什么User Story重要”的一些细节
- 识别从前到后所有任务/工作/组件等可能存在的约束条件
- 识别所有的标准/影响/参考的架构等
- 这个User Story为什么重要的其他原因
- 可以限定验收标准以及价值声明
- 唯一不需要列在这里的信息是由DoD定义的标准规程
- 验收标准-并不是重申价值声明
- 需要清晰的定义最主要的测试用例
- 必须指定产品增量应该满足的性能或负载要求
- 必须全面详细的描述用以结束完成该Story的所有测试
最后，需要注意的是，所有的User Story都应该是模块化的，因为它们捕获了业务功能。如果描述正确的话，不应该发生由于技术上的依赖关系而产生冲突。
Product Backlog中的User Stories由Product Owner负责维护，一旦转移到Sprint Backlog，那么将由研发团队维护。研发团队可以更新Story的备注，但是不可以更改价值声明/设想以及验收标准，除非得到 PO和团队成员的一致同意。
所有的用户故事由项目的DoD来支配。虽然DoD关注的是结束一个故事的流程，实际上它也是用户故事隐含的“第四要素”，DoD捕捉用户故事中定义的完成该故事的所有需求，比如：
- Standard approvals,
- Stakeholder评审
- Prototyping (if required)
- Documentation (for sustainability, reporting, etc.)
- Design constraints (for compliance, integration, etc.)
这样，DoD有助于将声明和描述模块化到一个用户故事中。但它也提供了一套关于质量控制和可持续性的清晰的期望。
