4. 产品待办列表构建
产品待办列表（Product Backlog）不是一张“待办事项清单”，而是一棵有层级、有优先级、可逐步细化的需求树。在 Jira 中，这棵树通常由四种工作项类型构成：Epic（史诗）、Story（用户故事）、Task（任务）和 Bug（缺陷）。理解它们的层级关系，是保证需求可追踪、可估算、可交付的前提。
一、四类工作项的定位与层级
Epic 是大粒度的价值容器，通常对应一个业务主题或一条完整用户旅程，跨越多个 Sprint 才能完成。例如“支持企业客户批量导入订单”就是一个 Epic。Story 是 Epic 之下可独立交付的用户价值单元，必须能在单个 Sprint 内完成，并遵循“作为……我希望……以便……”的句式。Task 是 Story 之下的技术执行项，它本身不直接对用户产生可感知价值，例如“为导入接口增加字段校验”。Bug 则是对既有预期行为的偏离，它既可以挂在 Story 下（该故事验收未通过），也可以独立存在于 Backlog 中（线上缺陷）。
层级关系可以概括为：Epic → Story → Task，而 Bug 是横向插入的异常项，可关联到任意层级。在 Jira 中，这通过“父级链接（Parent Link）”和“问题链接（Issue Link）”实现：Story 通过 Parent Link 归属 Epic，Task 通过 Parent Link 归属 Story，Bug 则通过“relates to / blocks”链接与相关 Story 建立关系。
二、用户故事拆分：从 Epic 到可交付 Story
拆分不是“把大故事切成小故事”这么简单，核心是沿价值维度切分，而非沿技术层次切分。常见的错误是按“前端、后端、数据库”拆成三个 Story，结果每个都无法独立交付用户价值。正确的做法是让每个 Story 都满足 INVEST 原则：独立（Independent）、可协商（Negotiable）、有价值（Valuable）、可估算（Estimable）、小（Small）、可测试（Testable）。
以下给出四种可操作的拆分方法，并配以同一 Epic 的示例。
方法一：按用户角色拆分。Epic“支持企业客户批量导入订单”可拆为：作为普通操作员，我希望上传 CSV 文件导入订单；作为财务审核员，我希望导入前预览并校验金额字段。两个 Story 面向不同角色，各自可独立验收。
方法二：按业务规则/数据变体拆分。同一 Epic 可拆为：导入标准格式订单、导入含折扣码订单、导入跨境订单（含税率计算）。每条规则对应一个 Story，便于分别估算和测试。
方法三：按操作步骤拆分（CRUD 或工作流阶段）。可拆为：上传文件并解析、字段映射与校验、确认导入并生成结果报告。注意每个 Story 仍需交付可感知的中间价值，例如“上传并解析”完成后用户至少能看到解析结果预览。
方法四：按验收标准拆分（SPIDR 法）。Spike（探针）、Path（路径）、Interface（接口）、Data（数据）、Rules（规则）五个维度中任选其一。例如先做一个 Spike Story：“调研 CSV 解析库在 10 万行下的性能表现”，时间盒 2 天，产出技术结论而非可交付功能。
三、Story 到 Task 的分解与 Jira 落地
Story 进入 Sprint 后，团队在 Sprint Planning 中将其拆为 Task。Task 的粒度建议控制在 4～16 小时，超过 16 小时说明还可以继续拆。例如 Story“上传 CSV 并解析”可拆为：
- Task：设计上传接口的请求/响应结构（4h）
- Task：实现文件类型与大小校验（6h）
- Task：实现 CSV 解析与编码识别（8h）
- Task：编写解析结果的单元测试（6h）
在 Jira 中，创建 Task 时通过“Parent Link”字段选择所属 Story，即可在 Story 详情页的“子任务”区域看到全部 Task。Task 完成后，Story 的完成度可通过子任务完成率辅助判断，但Story 是否完成仍以验收标准为准，不能仅凭 Task 全部关闭就标记 Story 为 Done。
四、Bug 的挂载策略与优先级判断
Bug 的挂载位置决定了修复的排期逻辑。建议遵循以下规则：
| Bug 场景 | 挂载位置 | 优先级依据 |
|---|---|---|
| 当前 Sprint 内 Story 验收未通过 | 关联该 Story，作为阻塞项 | 最高，必须在本 Sprint 修复 |
| 已上线功能的缺陷 | 独立 Backlog，链接相关 Story | 按影响范围与严重程度排期 |
| 回归测试发现的旧功能问题 | 关联对应 Task 或 Story | 视是否阻塞发布决定 |
五、Backlog 精化（Refinement）的节奏
层级建好之后，Backlog 需要持续精化。建议每周安排一次 1 小时的 Refinement 会议，只做三件事：把下个 Sprint 候选的 Story 拆到可估算粒度、为每个 Story 补充验收标准、识别需要提前做的 Spike。Epic 不需要在早期就拆到 Story 级别，保持“Epic 粗、近期 Story 细”的滚动式规划即可。判断一个 Story 是否“就绪（Ready）”的简单标准是：团队能在 5 分钟内给出估算点数，且测试人员能写出至少 3 条验收用例。若做不到，说明拆分还不够充分，应继续细化后再拉入 Sprint。