第4章 用户故事编写：卡片、INVEST与拆分技巧
在划定MVP范围时，用户故事是连接业务需求与技术实现的核心载体。它不只是一段文字，更是团队沟通、范围界定和验收对齐的契约。本章聚焦用户故事的标准化编写——从卡片格式、质量原则到实际拆分方法，帮助你在MVP阶段写出“可开发、可测试、可验收”的用户故事。
4.1 用户故事卡片标准格式
一张高质量的用户故事卡片应包含5个必要字段，确保信息完整且无歧义：
| 字段 | 说明 | 示例 |
|---|---|---|
| 标题 | 一句话概括用户期望的功能 | 回收站恢复文件 |
| 故事描述 | 遵循“作为…，想要…，以便…”模板 | 作为文件管理员，想要从回收站恢复误删的文件，以便减少数据丢失的损失 |
| 验收标准 | 列出通过/不通过的具体条件 | 1. 用户在回收站中可见所有已删除文件； 2. 点击恢复后文件返回原路径； 3. 同名文件自动编号重命名 |
| 业务规则 | 描述逻辑约束 | 回收站最多保留1000个文件；超过30天自动清空 |
| 估算值 | 以故事点或理想人天表示工作量 | 3 故事点 |
💡 实操建议：在MVP启动阶段，卡片至少应包含“标题”“故事描述”和“验收标准”三个字段，其余字段可在进入迭代计划时补充。避免在故事卡片中直接写入技术实现方案，如“用Redis缓存查询结果”。
4.2 INVEST原则详解
INVEST是检验用户故事质量的六维标准，缺一不可：
- I（Independent，独立的）：故事之间不应有强烈依赖关系。如果故事A必须在故事B之后才能开发，说明需要重新拆分或合并。
- N（Negotiable，可协商的）：故事是可讨论的。过于详细的需求描述（如“点击蓝色按钮后弹出模态框，宽度480px”）会扼杀团队的实现灵活性。
- V（Valuable，有价值的）：从用户视角体现业务价值。技术故事（如“重构日志模块”）应写明用户可感知的收益。
- E（Estimable，可估算的）：团队能够给出相对大小或工时估算。不确定性过大的故事（如“实现实时协作编辑”）需要先做技术预研故事。
- S（Small，小粒度的）：一个故事应在1-3天内完成。超过5天的故事必须拆分。
- T（Testable，可测试的）：有明确的验收标准，能通过功能测试验证。
🚫 常见陷阱：团队经常把大需求直接写成故事，例如“作为企业主，我想要一套完整的CRM系统”。这违反了S（Small）和E（Estimable）原则。必须将CRM拆分为“新建联系人”“跟进记录”“客户分群”等多个独立故事。
4.3 用户故事拆分技巧
针对MVP阶段的快速迭代需求，以下四种拆分策略覆盖90%的常见场景：
| 拆分策略 | 适用场景 | 拆分示例 |
|---|---|---|
| 按操作路径拆分 | 功能涉及多个步骤 | “下单流程”拆为： ① 用户可将商品加入购物车 ② 用户可在购物车修改数量 ③ 用户可提交订单 |
| 按业务规则拆分 | 功能的规则有优先级差异 | “审批流程”拆为： ① 单级审批（主管审批） ② 多级审批（主管+经理） ③ 会签（需全员通过） |
| 按数据维度拆分 | 功能的范围基于数据类型或规模 | “文件导出”拆为： ① 导出当前页为CSV ② 支持筛选结果导出 ③ 支持批量选择导出 |
| 按用户角色拆分 | 功能面向多个身份角色 | “查看报表”拆为： ① 管理员查看全公司报表 ② 经理查看团队报表 ③ 成员查看个人报表 |
✅ 黄金法则：拆分后的每个故事必须仍然满足INVEST原则。可以在拆分后对每个子故事重新用INVEST逐条核验。如果某个子故事“不可测试”或“价值不明显”，说明拆分粒度或方式有问题。
4.4 验收标准编写实例
验收标准是用户故事的终结条件，推荐采用“Given-When-Then”三句法：
故事：作为审批员，想要在审批页面查看附件预览
验收标准：
Given 审批员打开待审批工单
And 该工单包含PDF和JPG格式附件
When 审批员点击附件文件名
Then 系统应在页面内嵌预览窗口中打开附件
And 若为PDF，可显示前3页预览
And 若为JPG，显示原始分辨率图片
📐 检查清单：编写完成后，逐项核对：（1）是否覆盖了正常流程和异常流程？（2）每个条件是否只有唯一的通过/不通过判定？（3）是否存在不可操作的技术描述（如“调用某某API返回数据”）？
4.5 用户故事编写流程总览
下图展示了从原始需求到可执行用户故事的完整编写流程，以及INVEST原则在其中的质量检查位置：
📌 本章核心交付物：（1）一张填写完整的用户故事卡片模板（含标题、故事描述、验收标准、业务规则）；（2）一张INVEST检查清单，用于评审团队所有用户故事；（3）在实际需求中使用至少一种拆分策略将“大故事”拆成2-3个“小故事”。