# 用户故事 User stories
## 定义
在与客户或产品所有者协商后，团队将要完成的工作分为功能增量，称为“用户故事”。
一旦实施，每个用户故事都将为整个产品的价值做出贡献，而与实施顺序无关；INVEST公式包含有关用户故事性质的所有这些假设和其他假设。
为了使这些假设切实可行，将用户故事具体化为一种物理形式：索引卡或便签，上面写有简短的描述性句子以提醒其价值。这强调了用户故事的“原子性”本质，并鼓励直接进行物理操纵：例如，有关调度的决定是通过物理上围绕这些“故事卡片”来做出的。
## 常见陷阱
- 一个典型的错误是，在将敏捷方法局限在开发团队中或在非敏捷需求阶段之后采用的团队中，首先要采用叙述性格式的需求文档并直接根据其结构派生用户故事：例如一个故事对于文档的每个部分
- 正如3 C模型所强调的那样，用户故事不是文档；而是 该术语包含将产品的版本V转换为版本V'所需的所有知识，对于特定目标而言，该知识更有价值
- 与用户故事相对应的详细程度不是恒定的，而是随着时间的推移而随着“计划范围”而变化的；例如，计划在下一个迭代中使用的用户故事要比在下一个发行版本中才能实现的故事更好地理解
- 用户故事不是用例；尽管比较和对比这两个概念通常很有用，但它们并不等效，也不允许一对一映射
- 用户故事通常不与技术或用户界面组件相对应：尽管有时可能是谈论例如“搜索对话框故事”的有用捷径，但屏幕，对话框和按钮不是用户故事
## 预期收益
对于大多数敏捷团队而言，用户故事是增量软件交付的主要工具，并具有以下优点：
- 减轻延迟反馈的风险，尤其如此
- 如果增量很小
- 如果软件频繁发布到生产环境
- 对于客户或产品所有者，可以改变主意，以决定尚未实施的任何用户故事的详细信息或计划优先级
- 为开发人员提供清晰明确的验收标准，并在他们完成工作时提供持续的反馈
- 促进在定义“什么”（客户或产品所有者的省）和“如何”（技术团队的省）之间的职责分离，并利用每个人的技能和创造力
## 潜在成本
一般而言，增量开发，尤其是在用户故事中体现的“纳米增量”策略，对项目的测试策略有重大影响，尤其是除了所有要求强制进行自动化测试之外。
这源于所谓的“ 二次增长 ”问题：在实现功能F1之后，测试该功能是正常的。功能F2实施后，回归的风险要求重新测试F1和测试F2。因此，假设进行增量开发的测试顺序为：F1，F1 + F2，F1 + F2 + F3等–随着要素数量的平方增加，因此随着项目规模的增加而很快变得难以管理。测试自动化（特别是单元测试和验收测试）减轻了这种影响，尽管确实要付出一定的代价。
## 起源
用户故事源于极限编程，他们在1998年的第一个书面描述仅声称客户“使用用户故事（如用例）”定义项目范围。它们不是作为一种独特的实践提供的，而是被描述为“计划游戏”中使用的“游戏作品”之一。
但是，进一步编写的大部分推力都围绕着用户故事“不同于”用例的所有方式，试图以更实际的方式回答“极限编程”（以及更广泛的敏捷）项目中的“如何处理需求”。多年来，这推动了对用户故事的更复杂说明的出现。
- cf. 该角色的功能效益模板，2001年
- cf. 在3 C'S模型，2001年
- cf. 该INVEST清单，2003
- cf. 当时给定模板，2006
## 使用迹象
- 团队使用视觉计划工具（发布计划，故事地图，任务面板），这些显示器上的索引卡或便签可反映产品功能
- 代表用户故事的卡片上的标签很少或根本没有引用技术元素（“数据库”，“屏幕”或“对话框”），但通常指的是最终用户的目标
## 技能水平
如果在团队中广泛分布支持有效使用用户故事的技能，则敏捷团队将受益。但是，具有“需求分析”背景或具有“分析师”角色历史的人很有可能会获得这些技能。
作为个人贡献者：
初学者
- 能够从另一种形式化的需求（叙述性文档，用例）开始，并将其转换为用户存储
- 至少知道一种表达用户故事的标准格式
- 能够通过示例说明用户故事（包括用户的目标，现有上下文，用户的行为和预期结果）
中级
- 能够将开发工作的功能目标划分为用户故事（可能是史诗），确保不留空白
- 知道几种表达用户故事的格式，可以选择最合适的一种
- 能够以可以直接用作自动接受测试的术语表达用户故事的接受标准
- 知道或可以识别相关的用户角色和人群，并在用户故事中适当地引用它们
- 可以使用INVEST清单或等效清单评估用户故事，并根据需要重新描述或划分用户故事
高级
- 能够根据用户故事解释所谓的“非功能需求”
- 能够将用户故事链接到项目目标的更高级别描述（例如，项目章程），并为每个用户故事的相关性和业务价值提供依据
作为一个团队集体：
初学者
- 团队围绕用户故事组织项目活动
- 团队可以“及时”获得实施用户案例所需的信息，例如可以访问产品所有者或领域专家
中级
- 团队将所有活动形式化为用户故事，每个团队成员可以随时回答“您目前正在处理什么用户故事”的问题
高级
- 任何时候，团队的任何成员都可以回答以下问题：“积压中最重要的用户故事是什么，为什么？”
## 进一步阅读
- 《用户故事》，作者：Mike Cohn
- 数字软件研究了迭代软件开发的经济学
## 学术出版物
- “敏捷需求工程实践：一项实证研究”讨论了对16个软件开发组织的敏捷需求实践的调查，并概述了有关敏捷需求和用户案例的一些先前文献。（这项研究对敏捷采取了温和的对抗态度，得出了一些奇怪的结论，例如在需求工程实践中对测试驱动的开发进行排名。）
点击看敏捷名词地铁线路全图