制定子任务拆分规则，核心是先定“拆到什么程度算完成”的粒度标准，再定按什么维度拆，最后把命名、字段、责任人和完成标志固化成可检查的条目。本文给出一套可直接落地的拆解约定，覆盖粒度判断、维度选择、填写规范、角色分工、完整示例与上线检查。文中会自然提及ONES作为工作项层级与字段约定的承载方向，具体配置以团队实际核验为准。
要点总览（TL;DR）
- 粒度标准用三条硬指标判断：一个人、一个工作周期、一个可验收产出，三条同时满足才算拆到位。
- 拆分维度按任务形态选：有明确产出按交付物拆，流程顺序强按动作步骤拆，质量门禁类按验收条件拆；一个父任务只用一个主维度。
- 日常填写靠统一约定：命名用“动词+对象+结果”，必填负责人、完成标志、依赖关系和预估工作量，父子状态联动写进规则。
- 拆分由任务负责人执行、技术或业务负责人复核粒度、规则维护人按迭代周期更新文档，拆解结果在计划或迭代评审中确认。
- 规则上线前做抽样、一致性和可维护性三项检查，不通过时优先修订粒度标准和维度说明，再全面推行。
先定粒度：一条子任务拆到什么程度算合适
粒度标准是整套规则的地基。没有它，拆分只能凭个人经验，同一类任务在不同人手里会拆出深浅不一的层级。建议用三条硬指标判断一条子任务是否拆到位：一个人、一个工作周期、一个可验收产出。三条同时满足，说明粒度合适；任何一条不满足，就继续拆或合并。
三条硬指标的具体含义如下：
- 一个人：子任务有唯一负责人，不需要多人协作才能推进。如果必须两人以上共同完成，说明它更像一个父任务，应继续拆分或改为协作型工作项。
- 一个工作周期：子任务能在团队约定的一个工作周期内完成，通常是一个迭代或一周左右。超出周期的，按阶段或交付物再切。
- 一个可验收产出：子任务结束时能拿出可检查的产物，例如一段可运行的功能、一份评审通过的文档、一组通过的测试用例。产出说不清楚的，说明完成标志还没定。
完成标志（Definition of Done）是判断“还能不能继续拆”的直接工具。给子任务写下完成标志后，如果发现标志里包含多个互不依赖的检查项，通常意味着它还能拆；如果完成标志只有一句话且指向单一产物，说明粒度已经到位。完成标志应写成可核验的状态描述，例如“接口联调通过并附测试记录”，而不是“完成开发”这类无法判断的表述。
实际拆分中，过粗和过细是两类高频问题，可以用信号识别并及时纠正：
| 信号类型 | 典型表现 | 处理方式 |
|---|---|---|
| 过粗 | 子任务跨多个角色；完成标志含多个不相关产物；预估工作量明显超过一个工作周期 | 按交付物或阶段继续拆，直到满足三条硬指标 |
| 过细 | 子任务只需几分钟；多个子任务必须按固定顺序连续执行才有意义；子任务之间频繁互相阻塞 | 合并为一条子任务，把步骤写进完成标志或执行说明 |
需要提醒的是，粒度标准应写成团队约定并附上判断示例，避免只留一句口号。标准越具体，后续复核和一致性检查越容易执行。
选拆分维度：按交付物、动作步骤还是验收条件切
粒度解决“切多深”，维度解决“往哪个方向切”。同一父任务用不同维度拆，得到的子任务结构差别很大。常用维度有三种，选择依据是任务本身的产出形态和依赖关系。
| 拆分维度 | 适用任务 | 示例 |
|---|---|---|
| 按交付物拆分 | 有明确产出的开发、设计、文档类任务，产出之间相对独立 | “上线用户中心改版”拆为“登录页改版”“个人资料页改版”“接口适配” |
| 按动作步骤拆分 | 流程固定、顺序依赖强的任务，前一步的输出是后一步的输入 | “完成数据迁移”拆为“梳理源数据”“编写迁移脚本”“试运行校验”“正式迁移” |
| 按验收条件拆分 | 质量要求高、需要分项验证的任务，不同验收项可独立检查 | “通过安全合规评审”拆为“权限模型核查”“日志审计核查”“数据加密核查” |
按交付物拆分最常用，因为它天然对应可验收产出，子任务之间耦合低，便于并行推进和分配负责人。按动作步骤拆分适合流程性工作，但要注意步骤之间的强依赖会让并行度下降，拆出的子任务数量也不宜过多。按验收条件拆分适合质量门禁类任务，每个子任务对应一项可独立验证的检查，便于把验证责任落到具体人。
同一父任务混用多种维度是常见风险。例如一半子任务按页面拆、另一半按测试阶段拆，会导致层级混乱、责任重叠，检查时也难以判断是否遗漏。统一原则是：一个父任务只选一个主维度，其他维度的关注点写进子任务的完成标志或检查项，而不是再拆出一层子任务。如果确实需要跨维度组织，应提升到更高层级分别建父任务，保持每层拆分口径一致。
规则落地：命名、字段与责任人的统一约定
粒度与维度是判断标准，日常填写还需要一套统一约定，否则规则只存在于文档里。建议把以下内容写成团队的子任务填写规范，并在工作项模板中固化。
命名格式：动词+对象+结果。例如“完成登录页改版并提交评审”“编写迁移脚本并通过试运行”。命名要能让人不看描述就大致判断产出，避免“处理一下”“跟进”这类无法验收的表述。同一父任务下的子任务命名保持同一句式，便于快速浏览。
必填字段。每条子任务至少包含以下字段，缺一不可：
- 负责人：唯一责任人，对完成标志负责。
- 完成标志：可核验的产出描述，写清交付物和验证方式。
- 依赖关系：标明前置子任务或外部依赖，没有则显式写“无”。
- 预估工作量：以团队统一单位填写，用于判断是否超过一个工作周期。
父子层级与状态联动约定。明确父任务与子任务的状态关系，例如父任务在所有子任务完成前保持“进行中”，子任务全部关闭后由负责人确认父任务完成。层级深度建议限定为父任务加一层子任务，超过两层时回到粒度标准检查是否拆得过细。状态联动规则要写进约定，避免父任务被提前关闭或长期挂起。
规则文档的存放位置与更新机制。规则文档放在团队共同可访问的位置，与工作项模板放在一起，确保填写时能直接对照。文档标注版本号、维护人和最近更新日期，每次调整粒度标准或必填字段时同步更新，并在团队例会上说明变更点。
在工具承载上，ONES Project 支持编写需求、自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人，适合把上述字段约定和责任人分配落到具体工作项上；其任务工时统计也可用于估算任务持续时间，辅助判断子任务是否超过一个工作周期。子任务层级、父子状态联动和依赖关系的具体配置方式，建议在选型或配置时结合实际版本核验。
角色分工：谁拆、谁确认、谁维护规则
规则能否执行，取决于每个环节是否有人负责、有交付物可查。建议按以下分工组织拆分过程：
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 任务负责人 | 按粒度标准和选定维度拆分子任务，填写命名、完成标志、依赖和预估工作量 | 子任务清单及字段完整的子任务条目 |
| 技术或业务负责人 | 复核子任务是否满足三条硬指标，检查维度是否统一、有无遗漏或重复 | 复核意见与调整后的子任务清单 |
| 规则维护人 | 维护拆分规则文档，收集执行中的问题，按评审周期更新标准 | 规则文档及版本更新记录 |
| 团队评审 | 在计划或迭代评审中确认拆解结果，对争议条目当场裁定 | 评审结论与待办调整项 |
任务负责人是拆分的第一责任人，拆分动作应在任务进入迭代前完成，而不是在执行中临时补拆。技术或业务负责人负责粒度复核，重点看子任务是否都能由一个人在一个工作周期内完成、完成标志是否可验收。规则维护人通常由团队负责人或项目管理角色兼任，评审周期建议与迭代节奏对齐，例如每个迭代回顾时收集一次规则执行问题。
拆解结果的确认动作要固定下来：在计划会或迭代评审中，逐条检查子任务清单是否满足粒度标准、维度是否统一、依赖是否标注完整，确认后子任务才进入执行状态。评审记录保留调整原因，作为后续规则优化的输入。
示例：一条需求拆成可执行子任务的完整过程
以下为演示情景，用于说明拆解过程，不代表真实项目数据。
父任务描述：“为订单模块增加批量导出功能，支持按时间范围筛选并导出为表格文件。”拆分前的问题是该任务被当作一条工作项直接排入迭代，负责人一人承担，完成标志只写“导出功能上线”，无法判断进度，也无法分项验收。
选定维度：该任务有明确产出且各部分相对独立，选择按交付物拆分。
拆出的子任务清单：
- 完成后端导出接口开发并提交联调——完成标志：接口按约定返回表格文件，联调记录附在任务中。
- 完成前端筛选与导出入口开发——完成标志：时间范围筛选和导出按钮可用，交互走查通过。
- 编写导出功能测试用例并执行——完成标志：用例覆盖筛选边界和文件内容校验，执行记录通过。
- 更新操作手册中导出功能说明——完成标志：手册章节评审通过并发布。
每条子任务都有唯一负责人、可核验的完成标志和明确的依赖关系，例如前端入口依赖后端接口联调完成，测试执行依赖前后端开发完成。预估工作量均控制在一个工作周期内。
拆分后的检查：对照父任务描述逐项核对，确认筛选、导出、文件格式三个要点都有对应子任务，没有遗漏；检查子任务之间是否存在重复覆盖，例如测试用例与开发自测的边界是否写清；再确认所有子任务完成后父任务的完成标志能够成立。检查记录随父任务保留，作为评审依据。
完成检查：规则上线前要验证的几件事
规则写好后，先做一轮小范围验证再全面推行。以下检查项可逐条核对：
| 检查项 | 做法 | 通过标准 |
|---|---|---|
| 抽样检查 | 随机抽取若干已完成或进行中的父任务，逐条核对子任务是否满足三条硬指标 | 抽样条目中满足粒度标准的比例达到团队约定阈值，不满足的能说明原因并已调整 |
| 一致性检查 | 让两名成员对同一类任务分别拆分，比较子任务数量和结构 | 两人拆出的子任务在数量和覆盖范围上接近，差异可解释 |
| 可维护性检查 | 查看规则文档是否有明确维护人、版本号和更新记录 | 文档有负责人，最近一次更新有记录，变更内容可追溯 |
检查不通过时，调整方向应指向规则本身而非执行人。抽样不通过，通常是粒度标准写得太抽象，需要补充判断示例；一致性差，说明维度选择缺少适用说明，应在规则中明确不同任务类型的默认维度；可维护性不足，则需要指定维护人并设定固定评审周期。规则经过一轮验证并修订后，再在团队内正式推行，后续按评审周期持续收集问题、更新标准。
常见问题
团队规模较小，也需要把拆分规则写成文档吗？
建议至少保留一份简短的书面约定，规模小可以压缩内容，但粒度标准和必填字段两项不宜省略。人数少时口头约定容易随人员变动丢失，新成员加入后拆分口径会迅速分化。可以只写一页：三条粒度硬指标、默认拆分维度、子任务必填字段和负责人。规则维护人可由团队负责人兼任，评审周期与迭代回顾合并进行即可。
子任务拆到两层还不够细，可以继续往下拆吗？
先回到粒度标准判断，而不是直接增加层级。如果一条子任务仍无法由一个人在一个工作周期内完成，或完成标志里包含多个互不依赖的检查项，说明它确实需要继续拆；如果只是执行步骤较多但产出单一，更适合把步骤写进完成标志或执行说明。层级加深会提高维护成本，父子状态联动和进度汇总也更难核对，建议把层级控制在父任务加一层子任务，超出时检查是否拆得过细。
拆分规则推行后，成员仍然按习惯随意拆，怎么处理？
先确认规则是否具备可执行性：粒度标准有没有配判断示例，维度选择有没有写清不同任务类型的默认切法，必填字段是否已在工作项模板中固化。规则抽象、填写成本高时，执行走样很常见。可以把复核动作固定到计划会或迭代评审中，逐条检查子任务是否满足粒度标准、维度是否统一，评审记录保留调整原因。持续收集执行中的争议条目，按评审周期修订规则，比反复口头强调更有效。
不同类型任务的拆分维度不同，如何避免团队内口径混乱？
在规则中按任务类型给出默认维度，例如开发、设计、文档类默认按交付物拆，流程性任务默认按动作步骤拆，质量门禁类默认按验收条件拆。成员遇到未覆盖的任务类型时，先按默认维度尝试，确实不适用的在评审中提出并补充进规则。关键是同一父任务只用一个主维度，其他关注点写进完成标志，跨维度的组织需求提升到更高层级分别建父任务。
用工具承载拆分规则时，需要重点核验哪些配置？
重点看三处：工作项是否支持父子层级及父子状态联动，子任务必填字段（完成标志、依赖关系、预估工作量）能否自定义并设为必填，任务间依赖关系能否设置和展示。ONES Project 支持编写需求、自定义需求状态与多种属性，可将需求和相关任务规划至迭代并分配负责人，任务工时统计可用于估算任务持续时间，辅助判断子任务是否超过一个工作周期。子任务层级、父子状态联动和依赖关系的具体配置方式，建议结合实际版本核验后再定规则。
