第3章 验收标准与用户故事的关联：从用户故事提取验收要点

用户故事以简洁的自然语言描述了用户需求，但它本身不具备可测试性。验收标准必须从用户故事的构成要素中系统提取，才能建立从“需求描述”到“可验证条件”的完整链路。本章提供一套从用户故事结构化拆解到验收要点输出的标准化操作流程，确保每个故事都能产出可执行、可度量的验收条目。

3.1 适用场景

• 用户故事评审会（Backlog Refinement）：团队需要对即将进入冲刺的用户故事预先定义可测试条件。
• 验收标准缺失或模糊：现有用户故事缺少验收条件，需要补全可测条目。
• 跨角色对齐需求边界：PO、开发、测试三方需对“故事完成”的定义达成一致。
• 需求拆分与细化：大粒度的史诗故事拆解为小故事后，需要重新生成对应的验收要点。

3.2 前置条件

• 已有编写完成的用户故事，遵循标准格式：
  作为<角色>，我想要<功能>，以便<商业价值>。
• PO已明确故事的业务优先级和核心价值。
• 团队具备基本的用户场景分析能力（角色、流程、异常路径）。
• 已确定故事的最小可行范围（MVP边界），不包含镀金需求。

3.3 操作步骤

以下六步从用户故事中逐层提取验收要点，每步产出可独立校验的条件条目。案例基于以下用户故事展开：

1. Step 1 · 识别用户故事的角色与场景
   从故事中提取“角色”与“触发场景”，明确验收的主体和环境。
   案例输出：角色=已登录注册用户；场景=订单提交前浏览评价页。
2. Step 2 · 拆解功能路径与交互触点
   将故事中的“功能”分解为端到端的操作步骤，形成用户流程。
   案例输出：进入订单确认页 → 点击评价入口 → 加载评价列表 → 浏览评价详情 → 返回下单。
3. Step 3 · 标记正常路径与分支路径
   区分主流程（Happy Path）和备选流程（如无评价、加载失败、权限不足）。
   案例分支：商品无评价时显示“暂无评价”；评价图片加载失败时显示占位符。
4. Step 4 · 提取每个路径的验证条件
   对每个路径定义可通过观察或测量判定的具体条件。
   案例条件：评价列表在2秒内加载完成；默认按时间倒序排列；每条评价包含评分、文字、图片。
5. Step 5 · 补充边界与异常规则
   增加输入边界、并发、数据状态等极端情况下的验收规则。
   案例规则：评价超过100条时分页加载；无网络时显示离线提示；同一用户重复点击不触发重复请求。
6. Step 6 · 聚合去重形成验收要点清单
   将以上条件去重、归类、按优先级排序，输出结构化验收标准列表。
   案例清单：包含12条验收要点，覆盖功能、性能、异常、边界四大类。

3.4 输入输出物

3.5 责任边界

• Product Owner：提供用户故事的业务上下文、角色定义、价值描述，确认验收要点是否覆盖核心业务目标。
• Scrum Master / 流程引导者：组织六步提取工作坊，确保团队遵循流程，避免跳过分支路径或边界分析。
• 开发团队：从技术可行性角度判断验收条件是否可构建、可测试，补充技术约束类要点。
• 测试团队：从可测性角度评审每个验收要点是否具备明确的通过/失败判定标准，补充遗漏的异常场景。

3.6 记录材料

推荐使用以下模板记录每轮故事提取的输出，保持团队间信息一致：

【用户故事ID】US-0037
【故事原文】作为注册用户，我想要在提交订单前查看完整评价，以便做出购买决策。
【提取日期】2025-03-20  【提取参与者】PO/DEV/QA

=== 验收要点清单 ===
[功能] F-01: 订单确认页显示“查看评价”入口，点击后进入评价列表
[功能] F-02: 评价列表默认按时间倒序排列，最新评价置顶
[功能] F-03: 每条评价展示评分(1-5星)、评论文本、图片(最多9张)
[功能] F-04: 无评价时显示“该商品暂无用户评价”
[性能] P-01: 评价列表首次加载 ≤2秒（正常4G网络）
[性能] P-02: 分页加载时翻页响应 ≤1秒
[异常] E-01: 图片加载失败时显示灰色占位图标
[异常] E-02: 无网络时显示“网络异常，请稍后重试”
[边界] B-01: 单商品评价数 >100 条时自动分页，每页20条
[边界] B-02: 同一用户30秒内重复点击不触发重复请求

3.7 异常处理

3.8 验收标准（本章自检）

• 每个用户故事产出至少1条功能类验收要点和1条异常/边界类要点。
• 验收要点可直接用于测试用例编写，无需补充额外的业务解释。
• 所有要点均标注来源用户故事ID，实现双向可追溯。
• 要点清单包含功能、性能、异常、边界四个分类，缺一不可。
• PO、开发、测试三方在要点清单上达成一致并签字确认。