子任务拆分规则的核心，是把一项可执行工作项按“可独立完成、可独立验收、可独立指派”三个条件拆成下一层工作项，并为每个子任务写清输入、动作、输出和完成标志。本文给出一套可直接照做的五步流程、颗粒度判断与停止条件、角色分工、完整示例和检查清单，适用于已经进入执行阶段的工作项拆分。
要点总览（TL;DR）
- 子任务拆分按三个准入条件判断：可独立完成、可独立验收、可独立指派，缺一项就调整拆法。
- 操作上走五步：确认父项边界、识别交付物、按交付物切分、补齐输入输出与完成标志、做覆盖性检查。
- 拆分深度以能否指派和验收为准，父项下一层通常即可执行；单个子任务由一人在数小时到数个工作日内完成，超出则继续拆或回看父项边界。
- 拆分由父项负责人主导、执行者参与、验收角色确认完成标志，结果在正式指派前定稿。
- 拆完用覆盖性、独立性、清晰性、颗粒度、依赖与顺序五项检查，不通过时按对应方式修订。
子任务拆分规则的核心答案与操作步骤
拆分子任务时，先判断父项是否具备拆分前提：父项本身应当是一项边界清楚、有明确交付物的工作项。拆分后的每个子任务需要同时满足三个准入条件，缺一项就说明拆法还需要调整。
- 可独立完成：子任务有明确的起点和终点，执行者不需要等待其他未定义的工作才能开始。
- 可独立验收：子任务有可观察的产出，验收人依据完成标志就能判断是否做完，不必等父项整体结束。
- 可独立指派：子任务能落到一个明确的负责人，职责范围不与其他子任务大面积重叠。
满足三个条件后，按以下五步完成拆分。每一步都明确输入、动作、输出和完成标志，便于边做边核对。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确认父项边界 | 父项描述、背景说明、相关干系人诉求 | 写清父项要交付什么、不包含什么，明确起止范围 | 父项边界说明 | 能用一句话说清父项交付物，且干系人对范围无异议 |
| 2. 识别交付物 | 父项边界说明 | 列出父项完成时必须产出的成果，区分主交付物与支撑材料 | 交付物清单 | 每项交付物都有名称和可判断的完成形态 |
| 3. 按交付物切分 | 交付物清单 | 以交付物为切分依据，把能独立产出某项成果的工作划为一个子任务 | 子任务清单 | 每个子任务对应明确的交付物，子任务之间边界不重叠 |
| 4. 补齐输入输出与完成标志 | 子任务清单 | 为每个子任务写明输入、动作、输出、完成标志和负责人 | 填写完整的子任务条目 | 每个子任务的完成标志可被第三方验证 |
| 5. 做覆盖性检查 | 父项边界说明、子任务清单 | 逐项核对子任务之和是否覆盖父项全部交付物，检查遗漏与重复 | 检查结论与修订后的子任务清单 | 父项每项交付物都能找到对应子任务，且无重复承担 |
颗粒度上，单个子任务通常由一人在数小时到数个工作日内完成。超出这个范围，先判断是继续拆一层，还是父项边界本身定得过宽、需要回到第一步重新界定。这个区间是经验参考，团队可以结合自身评审周期调整。
拆分到什么程度：层级、颗粒度与停止条件
拆分深度以“能否指派和验收”为准，不以固定层数为目标。常见做法是父项下拆一层子任务即可进入执行；确有复杂子任务包含多个可独立验收的产出时，再向下拆一层。出现第三层以下时，应回看父项边界是否定义错误，把本应属于另一个父项的工作误放了进来。
判断颗粒度是否合适，可以看三个信号：
- 能否一人完成：一个子任务需要多人分头推进且彼此等待，说明还应继续切分。
- 能否在一个评审周期内验收：子任务跨越多个评审周期才有可检查的产出，通常偏粗。
- 是否还有未定义的依赖：子任务内部仍存在“等某件事确定后才能做”的空白，说明输入没有补齐，或切分点选错了。
停止拆分的条件同样明确：子任务已经能指派给具体负责人；能写出可验证的完成标志；不再同时包含多个交付物。三条同时成立即可停止，不必追求更细。
拆得过细会带来实际代价。子任务数量膨胀后，状态维护、进度同步和评审组织的成本上升，工作项状态容易与实际进展脱节；执行者被切碎的任务牵着走，反而失去安排工作顺序的空间。拆分的目标是让执行和验收更清楚，而不是把工作切成待办清单。
角色分工与各环节交付物
拆分由父项负责人主导，执行者参与，验收角色确认完成标志。三方各承担一段责任，拆分结果在进入执行前完成一次确认。
| 角色 | 主要动作 | 交付物 | 确认时点 |
|---|---|---|---|
| 父项负责人 | 确认父项边界与交付物，组织切分，对拆分结果整体负责 | 父项边界说明、子任务清单 | 拆分开始前确认边界，拆分完成后确认清单 |
| 执行者 | 参与切分讨论，确认子任务可执行、所需输入能够获得 | 子任务的输入说明与工作量判断 | 子任务指派前 |
| 评审或验收角色 | 检查完成标志是否可验证，确认验收方式 | 完成标志确认意见、依赖记录 | 子任务进入执行前 |
拆分结果的确认放在子任务正式指派之前，由父项负责人汇总三方意见后定稿。执行过程中如需调整，按变更处理：新增或合并子任务要说明对父项交付物的影响，修改完成标志要经原验收角色确认，涉及父项边界变化的，回到第一步重新界定并同步相关干系人。
拆分完成后，子任务需要承载负责人、状态和验收记录。ONES Project 支持将需求和相关任务规划至迭代并分配负责人，提供任务工时统计用于估算任务持续时间，并通过看板、燃尽图等工具呈现当前进度；这些能力可以让拆分结果进入统一的工作项体系，减少拆分清单与执行记录分离带来的状态失真。涉及测试验收的子任务，ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，便于把验收环节接在对应工作项之后。
示例：把一项工作项拆成可执行子任务
以下为演示情景，用于展示填写字段与检查方式，不代表真实项目数据。
父项：完成用户登录模块的改版上线。交付物包括改版后的登录页面、登录接口调整、回归测试报告和上线说明。父项边界明确为“登录方式与页面交互改版”，不包含账号体系重构。
| 子任务 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 登录页面改版 | 交互稿、现有页面代码 | 按交互稿实现页面结构与样式 | 可运行的新版登录页面 | 页面在测试环境可访问，交互稿中的状态均有对应实现 | 前端负责人 |
| 登录接口调整 | 接口约定文档、现有接口代码 | 按约定调整参数与返回结构 | 更新后的接口及说明 | 接口按约定返回，联调环境调用通过 | 后端负责人 |
| 回归测试 | 测试用例、测试环境 | 执行登录相关用例并记录结果 | 回归测试报告 | 用例执行完毕，结果与预期一致或差异已记录 | 测试负责人 |
| 上线说明编写 | 变更内容清单、发布流程 | 整理变更点与回滚方式 | 上线说明文档 | 文档经父项负责人确认，覆盖全部变更点 | 父项负责人 |
覆盖性检查：四项子任务分别对应页面、接口、测试报告和上线说明，与父项交付物一一对应，没有遗漏，也没有两个子任务重复承担同一产出。
常见错误拆法是把父项直接按动作切成“设计、开发、测试、上线”，其中“开发”一项同时包含页面和接口两个交付物，无法由一人独立完成，也无法单独验收。修正方式是回到交付物清单，按页面和接口分别切分，使每个子任务对应一项可验收的产出。
拆分完成检查清单
拆分结束后逐项核对以下条目，全部通过再进入指派与执行。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 覆盖性 | 子任务与父项交付物的对应关系 | 父项每项交付物都有子任务承担，无遗漏 |
| 独立性 | 每个子任务能否单独指派与验收 | 每个子任务有明确负责人和可验证的完成标志 |
| 清晰性 | 输入、动作、输出、完成标志是否齐全 | 四项字段均有具体内容，完成标志可被第三方判断 |
| 颗粒度 | 是否存在过粗或过细的子任务 | 单个子任务可由一人在数小时到数个工作日内完成，层级在约定范围内 |
| 依赖与顺序 | 跨子任务的先后关系 | 依赖已记录，前置条件在对应子任务的输入中写明 |
某项不通过时按对应方式处理：覆盖性不通过，补充遗漏的子任务或修正父项边界；独立性不通过，重新选择切分点，把混合的交付物分开；清晰性不通过，补齐缺失字段并请验收角色确认完成标志；颗粒度不通过，过粗的继续拆一层，过细的合并回同一交付物；依赖未记录，在输入中写明前置子任务及其产出。
检查通过后，把子任务连同负责人、完成标志和依赖关系放入团队统一的工作项管理入口，后续的状态更新与验收记录在同一处维护，拆分清单才能持续作为执行依据使用。
常见问题
父项本身描述很模糊，还能直接拆子任务吗？
不建议直接拆。父项描述模糊通常意味着交付物还没定清楚，此时拆出的子任务容易边界重叠或遗漏。先回到第一步，把父项要交付什么、不包含什么写成一句话，并和相关干系人确认范围；边界清楚后再识别交付物、按交付物切分。若父项范围本身过大，也可以先把它调整为更聚焦的工作项，再进入拆分。
子任务拆到第二层还不够细，可以继续往下拆吗？
可以，但要先判断原因。如果某个子任务确实包含多个可独立验收的产出，再拆一层是合理的；如果拆到第三层以下仍觉得粗，更可能是父项边界定得过宽，把本属于另一个父项的工作放了进来。此时回到第一步重新界定父项范围，比继续加深层级更有效。层级本身不是目标，能指派、能验收才是停止信号。
拆分过程中执行者提出某个子任务做不了，怎么处理？
先区分是输入缺失还是切分点选错。输入缺失的，补齐前置条件并在子任务的输入字段中写明；切分点选错的，回到交付物清单重新划分，把混合在一起的产出分开。若调整涉及父项交付物或边界变化，由父项负责人按变更处理，同步相关干系人，并请原验收角色确认修改后的完成标志。
子任务之间的先后依赖应该记在哪里？
依赖关系写在受影响子任务的输入字段中，注明前置子任务及其产出，例如“待接口调整完成并提供接口说明后开始”。这样执行者在领取任务时就能看到前置条件，不必另行查找。检查清单中的“依赖与顺序”一项专门核对这类记录是否齐全，前置条件未写明的视为不通过。
拆分结果放进工具后，如何避免清单和执行记录脱节？
关键是让子任务在统一的工作项体系中承载负责人、状态和验收记录，而不是把拆分清单留在文档里单独维护。ONES Project 支持将需求和相关任务规划至迭代并分配负责人，提供任务工时统计用于估算任务持续时间，并通过看板、燃尽图等工具呈现当前进度；涉及测试验收的子任务，ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，便于把验收环节接在对应工作项之后。
