📚 课程目录第4章需求拆解方法

需求拆解方法：从 Epic 到 Task 的精细化拆解

大型产品需求若不做层级拆解，极易陷入“做什么都知道，先做哪个不知道”的僵局。本章以电商订单履约优化为贯穿案例，系统讲解 Epic → Feature → Story → Task 四层拆解方法，辅以拆分原则、依赖关系图和拆分检查表，确保需求既能对齐商业目标，又能被开发团队无歧义执行。

1. 拆解层级定义

层级	定义	粒度	电商示例
Epic	跨迭代的大型用户价值集合，通常对应一个产品里程碑或战略目标	2~6 个月	“优化订单履约全链路体验”
Feature	Epic 分解出的独立交付能力，可跨团队协作	2~4 周	“订单实时物流状态追踪”
Story	从用户视角描述的功能增量，可独立验收	2~5 人天	“用户可在订单详情页查看物流轨迹图”
Task	开发/测试的具体工作单元，不可再分	4~16 小时	“实现地图组件按坐标渲染物流轨迹”

粒度参考：衡量拆解是否到位，可反问“这个故事能否在下一次迭代交付并产生用户价值？”——若否，应继续拆解至 Story 层。

2. 拆分原则

INVEST 原则：每个 Story 必须独立（Independent）、可协商（Negotiable）、有价值（Valuable）、可估算（Estimable）、短小（Small）、可测试（Testable）。
单一职责：一个 Story 只解决一个用户问题，避免“及/和/同时”等连接词。
依赖显性化：跨 Feature 或跨 Story 的依赖必须记录在统一矩阵中，不得隐含在代码注释或口头沟通里。
可验收优先：拆解前先定义验收标准，再反推拆分粒度；验收标准不可测时继续拆分。
垂直切片：每个 Feature 应当包含前端、后端、数据库、基础设施的一整条价值链，而非只切给一个团队。

3. 依赖关系图

下图以“订单实时物流状态追踪” Feature 为例，展示 Epic → Feature → Story → Task 的分层依赖，以及跨 Feature 的外部依赖线。菱形说明框标注了必须满足的前置条件。

4. 拆分检查表

每次需求拆解完成后，使用以下检查表逐项核对，避免遗漏或过度拆分。

检查项	通过标准	不通过时的调整方向
Epic 可量化	Epic 有明确的商业指标（如履约时长降低 20%）	补充关键结果（OKR）或删除不可衡量 Epic
Feature 边界清晰	每个 Feature 有独立价值且无重叠用户场景	合并或拆分 Feature 至无歧义
Story 满足 INVEST	独立、可协商、有价值、可估算、短小、可测试	重新拆分直到满足所有条件
Task 可执行	Task 对应单一技术任务，估算 < 1天	继续拆解直至 4~16 小时
依赖已标识	所有跨层、跨 Feature 依赖均录入矩阵	新增依赖记录或插入前置 Story
验收标准关联	每个 Story 至少有一条可测验收标准	按产品需求补充 Gherkin 场景

常见陷阱：团队常把“一个 Story 多条验收标准”误认为拆解到位。实际上若验收标准涉及多个用户意图，应拆为多个 Story。例如“用户可查看轨迹图”与“用户可分享轨迹给客服”是不同价值，应分开。

5. 案例实战：订单实时物流状态

用户故事（原始）

作为 下单用户  
我希望 在订单详情页实时查看物流轨迹  
以便 掌握包裹当前位置并预估到达时间

拆解结果

层级	内容	估算（人天）
Epic	优化订单履约全链路体验	—
Feature	Feature 1：订单实时物流追踪	10
Story 1.1	用户可在订单详情页查看物流轨迹图	3
Task 1	集成地图 SDK 并初始化组件	0.5
Task 2	对接物流轨迹 JSON 接口，解析并渲染	1
Task 3	实现每 60 秒轮询更新轨迹点	0.5
Story 1.2	用户可收到预计到达时间推送	2
Task 4	计算剩余里程和预计分钟数	0.5
Task 5	首页消息中心显示到达提醒	0.5

PRD 片段（需求描述）

## 功能描述
用户进入“我的订单 → 订单详情”页面，顶部显示物流状态条（已揽收/运输中/派送中/已签收），  
下方为高德地图组件，实时渲染物流轨迹点（绿色点表示在途，红色点表示异常停留）。  
点击轨迹点弹出信息窗：时间、地点、操作描述。

## 非功能要求
- 地图组件首屏加载时间 ≤ 2s（弱网环境≤5s）  
- 轮询间隔 60s，误差 ±5s  
- 日均 10 万 QPS 下单并发不影响地图渲染性能

## 验收标准 (Gherkin)
场景：用户打开订单详情页查看轨迹  
  假设：订单已发货且物流接口正常  
  当：用户点击“查看物流”按钮  
  则：页面展示地图组件  
  并且：地图上至少显示 1 个轨迹点  
  并且：轨迹点信息窗显示正确的时间和地点

原型说明

状态条区域：订单详情页标题下方，使用四阶段进度条组件，当前阶段高亮，已完成阶段显示对勾图标。
地图组件：占页面高度 50%，默认以发件地或最近轨迹点为中心，缩放至可看到全部轨迹点+100px 边距。提供全屏按钮。
轨迹点样式：绿色圆点 + 连接线（表示正常运输）；若某点停留超过 2 小时，圆点变为橙色并显示“运输异常”标签。
错误/空状态：无轨迹点时显示“暂无物流信息，请稍后查看”；接口超时显示重试按钮。
交互说明：点击轨迹点弹出信息窗；下拉刷新重新请求接口；右滑返回订单列表。

验收要点

测试用例 ID	前置条件	操作	期望结果
AC-1.1-01	订单已发货，物流接口返回 3 个轨迹点	进入订单详情页，点击“查看物流”	地图显示 3 个绿点，连接线连续，信息窗打开显示正确数据
AC-1.1-02	物流接口超时（5s 无响应）	同上	显示“获取物流信息失败”错误页，含重试按钮
AC-1.1-03	订单尚未发货	同上	显示进度条为“待发货”，地图区域提示“暂无物流信息”
AC-1.2-01	预计到达时间计算结果 > 0 且尚未推送	关闭 App 30 分钟后再打开	消息中心出现“您的包裹预计 30 分钟后到达”提醒

交付物模板：在 PRD 的“需求拆解”章节，附上以上表格和依赖关系图。原型说明以嵌入式批注方式链接至 Figma 或 Sketch 组件。验收要点作为 Story 的 Definition of Done，须经 QA 签字。