第1章 认知用户故事：INVEST原则、角色-功能-价值结构、与PRD条目的核心差异
用户故事（User Story）最早由 Ron Jeffries 在 1997 年提出，是极限编程（XP）中用于捕捉功能需求的口语化表述。它并不追求完整、精确的规格，而是强调“从用户视角出发，用简短的自然语言描述一个对用户有价值的功能”。标准的用户故事模板为：
作为<角色>，
我想要<功能>，
以便<价值>。这种“角色-功能-价值”三要素结构，是用户故事区别于传统 PRD 条目的核心特征之一。下面我们逐一拆解。
1.1 用户故事三要素：角色 · 功能 · 价值
- 角色（Role）：谁在使用？明确用户类型（如“注册用户”“运营管理员”“访客”）而非系统模块名称。
- 功能（Function）：想做什么？用主动动词描述具体行为（如“上传图片”“查看订单状态”）。
- 价值（Value）：为何要做？回答“解决了什么痛点”或“带来了什么收益”（如“节省审批时间”“避免重复填写”）。
关键原则：缺少价值的故事只是“任务”，缺少角色的故事只是“系统功能”，缺少功能的故事只是“愿景”。
1.2 INVEST 原则：好故事的六条黄金法则
Bill Wake 在 2003 年总结的 INVEST 原则，用于判断用户故事是否写得到位。每个字母代表一个维度：
| 字母 | 含义 | 检查问题 |
|---|---|---|
| I | Independent（独立的） | 该故事是否可以独立开发、测试、交付？ |
| N | Negotiable（可协商的） | 实现细节是否留有讨论空间？还是写死了具体方案？ |
| V | Valuable（有价值的） | 用户或业务方能感知到明确收益吗？ |
| E | Estimable（可估算的） | 团队能否基于足够信息给出工作量估算？ |
| S | Small（小的） | 能在一次迭代（1-2周）内完成吗？ |
| T | Testable（可测试的） | 验收条件是否清晰，可以设计自动化测试？ |
常见误区：很多团队把用户故事写成“系统应该…”，缺少角色和价值；或者写得过于具体（类似技术任务），违背了可协商原则。
1.3 用户故事 vs PRD 条目：核心差异
PRD（Product Requirements Document）中的条目通常采用结构化条目（如用例、功能列表、规则说明），而用户故事更轻量、更聚焦用户场景。下表对比两者关键区别：
| 对比维度 | 用户故事 (User Story) | PRD 条目 |
|---|---|---|
| 格式 | 口语化三句式：角色+功能+价值 | 结构化描述：编号、标题、详细规则 |
| 颗粒度 | 较小，通常一个故事对应一次迭代 | 粒度不固定，可粗可细，常含多个子场景 |
| 目的 | 促进团队沟通与理解用户意图 | 作为合同或规格说明书，约束实现 |
| 验收标准 | 通常写在故事卡片背面或单独的条件列表中 | 内嵌在需求条目中或独立章节 |
| 可变更性 | 鼓励协商，实现细节由团队决定 | 变更需要走正式审批流程 |
| 归属 | 产品负责人（PO）负责维护优先级 | 通常由产品经理撰写，项目经理管控 |
理解这些差异，是后续“将 PRD 条目转写成用户故事”的基础。转写并非简单替换句式，而是需要识别出真正的用户角色、剥离设计方案、把价值显性化。
⚠️ 易犯错误：将用户故事写成“作为系统，我想要增加列表，以便展示数据” —— 角色不应是系统，价值不应是技术名词；正确的写法应该是“作为访客，我想要查看最新文章列表，以便快速了解平台动态”。