用户故事
1 目的
用户故事是对功能或质量需求的简短、明了的陈述，这些需求对于向特定的涉众 1提供价值至关重要。
2 描述
用户故事捕获了特定相关方的需求，并使团队能够使用简短、简单的文档定义对相关方有价值的功能。它们可以作为识别需求的基础，并允许优先考虑、估算 2和规划解决方案。用户故事通常是描述谁需要由该故事解决的问题，用户试图实现的目标以及可能对理解范围至关重要的任何其他信息的一两个句子。以关注相关方价值为导向，用户故事鼓励通过与相关方进行进一步讨论来探索要求并分组功能需求以供交付。
用户故事可以用来：
- 了解涉众的需求，并优先开发解决方案，
- 作为估计和规划解决方案交付的基础，
- 作为生成用户验收测试的基础，
- 作为衡量价值交付的一种度量，
- 作为跟踪相关要求的单位，
- 作为进一步分析的基础，以及
- 作为项目管理和报告的一个单位。
3 元素
.1 标题（可选）
故事标题描述了涉众希望与系统一起进行的活动。通常，它类似于用例标题的主动语态动词目标短语。
.2 价值主张
用户故事没有必须遵循的结构。
最流行的格式包含三个元素：
- 谁：用户角色 3或个人。
- 什么：一个必要的行为、特性或品质。
- 为什么：当故事被实施时，用户获得的好处或价值。
例如，“作为一个<身份>，我需要<行为>，这样<结果>。”“给定…当…然后” 是另一种常见的格式。
.3 会话
用户故事帮助团队探索并理解故事中描述的功能以及它能给相关方带来的价值。 故事本身并没有包含所有关于需求的信息，随着故事的完成，需要进一步建模来补充这些信息。
.4 接受标准 4
用户故事可以通过开发详细的验收标准来支持（参见《验收与评价标准》）。验收标准界定了用户故事的范围，并帮助团队理解解决方案需要提供什么，才能为涉众创造价值。如有必要，可以使用其他分析模型来补充验收标准。
4 考虑因素
.1 优势
- 便于涉众理解。
- 可以通过多种提取技术来开发。
- 专注于涉众的价值。
- 通过共同定义和探索用户故事，对业务领域的共享理解得到增强。
- 与小型、可实施且可测试的功能片断相关联，这有助于快速交付和频繁的客户反馈。
.2 限制
一般来说，用户故事是为了在短期内捕获并优先考虑需求而设计的工具，并不是为了长期保存知识或提供详细的分析。忽视这一原则可能会导致以下问题：
- 这种对话式的方法可能会让团队感到挑战，因为他们没有提前准备好所有的答案和详细的规格说明。
- 需要上下文和可视化；如果故事没有通过验证或用更高级别的分析和可视化的图表进行补充，团队可能会失去对大局的认识。
- 可能无法提供足够的文件来满足治理、未来工作基础或涉众期望。可能需要额外的文档。