迭代执行中，任务周期忽长忽短、阻塞反复出现，往往说明任务颗粒度与团队节奏不匹配。调整的依据应来自实际数据：统计每个可执行工作项从进入进行中到完成的周期、阻塞次数与返工次数，据此判断哪些任务该拆细、哪些该聚合。调整只作用于后续迭代的新任务，进行中的清单保持稳定，再用两到三个迭代观察周期分布、阻塞率和返工率是否改善。ONES可用于承载工作项字段与迭代统计，帮助团队把基线数据沉淀下来。
要点总览（TL;DR）
- 先用最近两到三个已完成迭代的数据建立基线：按完成周期分档统计任务数量，记录每个任务的阻塞次数、阻塞时长、阻塞环节和返工次数，并把任务自身问题与外部依赖分开。
- 从基线中识别失配信号：周期跨多个状态反复停留、阻塞集中在同一环节、返工多且验收标准模糊的任务适合拆细；周期极短、流转频繁的任务适合聚合。
- 调整只作用于后续迭代的新任务，进行中的任务不重拆；用拆解参考线、依赖确认项和完成定义把新标准固化到任务模板或检查项中。
- 拆细会增加管理开销，统计基线依赖历史记录习惯，参考线需随团队规模与迭代长度调整；标准变动应设固定窗口，避免频繁推翻。
- 用两到三个迭代对照周期分布、阻塞率、平均阻塞时长、返工率和流转次数，区分其他因素影响；未达预期时按信号回退或转向依赖管理。
先量出当前颗粒度：完成周期、阻塞与返工的基线
调整颗粒度前，先回答一个具体问题：当前每个任务从开始到完成通常要多久，中间被卡住几次。没有这组数据，拆与合只能凭印象，调整后也无法判断是否有效。基线统计以可执行工作项为对象，统计口径统一为“从进入进行中状态到进入完成状态”的时长，排除排队等待和未启动的时间，避免把计划延迟混入执行周期。
统计分三步完成。第一步，取最近两到三个已完成迭代的全部工作项，按完成周期分档，例如半天以内、半天到一天、一天到三天、三天以上，统计每档的任务数量与占比。第二步，逐项记录阻塞信息：阻塞发生次数、每次阻塞持续时长、阻塞发生在哪个环节（开发、测试、评审、依赖方响应等）。第三步，记录返工次数，即任务完成后因验收不通过或缺陷回退而重新打开的次数。
记录时要把任务自身问题与外部依赖分开。任务描述不清、验收标准缺失导致的反复，属于任务本身的问题；等待接口就绪、等待环境、等待其他团队交付导致的停滞，属于外部依赖。两类阻塞的处理方向不同，混在一起统计会误导后续判断。基线表可按以下结构填写：
| 周期分档 | 任务数量 | 占比 | 平均阻塞次数 | 平均阻塞时长 | 返工任务数 | 主要阻塞环节 |
|---|---|---|---|---|---|---|
| 半天以内 | ||||||
| 半天到一天 | ||||||
| 一天到三天 | ||||||
| 三天以上 |
这张表的价值在于呈现分布，而非单个任务的极端值。如果三天以上的任务占比明显偏高，说明整体颗粒度偏粗；如果半天以内的任务占大多数且流转频繁，则可能拆得过碎。基线数据同时是后续验证的对照，因此统计口径一旦确定，调整期间不要随意更改。
颗粒度失配的典型信号：哪些任务该拆、哪些该合
基线表出来后，按信号分类处理，比逐条凭感觉判断更可靠。以下五类信号对应不同的处理方向。
- 周期明显超出迭代节奏、跨多个状态反复停留的任务。例如一个任务在开发中、待测试、测试中之间来回切换超过两次，且总周期超过迭代长度的三分之一。这类任务通常包含多个可独立验收的交付点，适合按交付点拆分。
- 阻塞频率高且阻塞点集中在同一环节的任务。如果某类任务的阻塞大多发生在等待接口联调或等待数据准备，说明任务把“依赖就绪”和“功能实现”捆在了一起。拆解时应把依赖确认前置为独立步骤，功能实现部分单独成项。
- 返工次数多、验收标准模糊的大颗粒任务。返工集中出现在验收环节，往往因为任务范围过大、完成定义不清，评审时各方理解不一致。处理方向是缩小单任务范围，并为每个任务写明可检查的完成条件。
- 被拆得过碎、频繁流转但单个体量极小的任务。如果大量任务周期在半天以内，且状态流转次数远高于同类任务，管理开销可能已经超过拆分带来的透明度收益。这类任务适合按同一交付物聚合，减少无意义的流转。
- 需要排除的其他原因。需求本身未澄清、依赖方未就绪、环境不稳定，也会造成周期长和阻塞多。判断时先看同类任务在依赖正常时是否仍然偏长；如果只是个别外部因素导致，优先解决依赖问题，不急于改颗粒度标准。
把信号整理成清单，逐条标注处理方向（拆细、聚合、补充完成定义、先解决依赖），作为下一节调整动作的输入。清单同时记录判断依据，便于后续复盘时区分颗粒度问题与其他原因。
调整动作：按信号改写拆解标准并保持清单稳定
调整的核心原则是：新标准只应用于后续迭代的新任务，已在进行中的任务不重拆。进行中的任务重拆会打乱清单、影响进度跟踪，也会让成员对状态变更产生抵触。具体动作分四步。
第一步，为不同周期档位设定拆解深度参考线。参考线来自基线数据，而非统一规定。例如基线显示一天到三天的任务阻塞率最低、返工最少，就可以把“单个任务预期完成周期不超过一天到一天半”作为拆解参考；超过参考线的任务在计划阶段就要求拆到可独立验收的交付点。参考线随团队规模与迭代长度调整，两到三人的小团队与十人以上团队适用的深度不同。
第二步，对高频阻塞任务前置依赖确认。拆解时增加一个检查项：该任务依赖哪些外部输入，是否已确认可用时间和责任人。依赖未就绪的任务不进入进行中，或先拆出一个“依赖确认”工作项单独跟踪。对反复出现的阻塞环节，在任务描述中写明阻塞预案，例如备选方案、升级路径和对接人。
第三步，对返工多的任务补充完成定义。每个任务在进入开发前写明验收条件，条件要可检查，例如“接口返回指定字段且通过联调用例”，避免“功能可用”这类模糊表述。完成定义随任务一起评审，减少验收阶段的反复。
第四步，用模板或检查项固化标准。把拆解参考线、依赖确认项、完成定义要求写进任务模板或拆解检查清单，新建任务时逐项确认。标准固化在工具里比写在文档里更容易执行。在ONES中，可以为工作项类型配置必填字段，例如预期周期、依赖说明、验收条件，并在迭代视图中按这些字段筛选和统计；迭代结束后直接查看周期分布与阻塞记录，减少手工汇总。这样调整动作有承载点，基线数据也能持续积累。
调整的代价与适用前提
拆细颗粒度会带来额外成本，判断是否值得做需要先看清代价。任务拆得越细，任务数量越多，创建、评审、状态流转和进度同步的管理开销随之上升；对小型团队，这部分开销可能占掉可观的协作时间。聚合过碎任务同样有代价：单个任务体量变大后，并行度下降，阻塞时影响面也更集中。
统计基线依赖历史数据量和记录习惯。如果团队此前没有记录阻塞时长和返工次数的习惯，前两个迭代的数据可能不完整，基线参考价值有限。这种情况下可以先统一记录口径，积累一个迭代再开始调整，避免用残缺数据下结论。
颗粒度参考线与团队规模、迭代长度相关。迭代周期短、成员少的团队适合更细的拆解和更短的周期参考线；迭代周期长、跨职能协作多的团队，参考线可以适当放宽，但需要更强的依赖管理。标准频繁变动会干扰清单稳定性，调整应设定固定窗口，例如每个季度评估一次，期间只做个别修正，不整体推翻。
效果验证：用两到三个迭代对照判断是否改善
调整是否有效，用调整前后的同口径数据对照判断。观察窗口设为两到三个完整迭代，第一个迭代用于适应新标准，后两个迭代的数据作为主要判断依据。对照指标如下：
| 指标 | 统计口径 | 观察方向 |
|---|---|---|
| 周期分布 | 各周期分档任务占比，与基线同口径 | 超出参考线的任务占比下降 |
| 阻塞率 | 发生至少一次阻塞的任务数 ÷ 总任务数 | 高频阻塞环节的任务占比下降 |
| 平均阻塞时长 | 阻塞总时长 ÷ 阻塞次数 | 依赖前置后单次阻塞时长缩短 |
| 返工率 | 完成后重新打开的任务数 ÷ 完成任务数 | 验收阶段返工减少 |
| 流转次数 | 单任务平均状态变更次数 | 过碎任务聚合后流转次数下降 |
判断时注意区分因果与相关。周期缩短可能来自需求总量减少、人员增加或外部依赖改善，不一定是颗粒度调整的功劳。验证时尽量保持迭代长度、团队构成和需求类型稳定；如果这些条件同时变化，结论只能作为参考，需要再观察一个迭代确认。
未达预期时按信号回退：如果拆细后管理开销明显上升而阻塞率未降，说明问题主要不在颗粒度，应回到依赖管理和需求澄清；如果聚合后周期反而拉长，恢复原有拆解深度。每次调整记录改动内容和观察结果，形成团队自己的颗粒度参考线，两到三个迭代后若指标稳定改善，再把标准固化到任务模板中。
常见问题
团队此前没有记录阻塞时长和返工次数的习惯，还能直接开始调整颗粒度吗？
可以先统一记录口径，积累一个迭代的数据再开始调整。缺少阻塞时长和返工记录时，基线只能反映周期分布，无法判断阻塞是任务本身造成还是外部依赖造成，据此拆合容易误判。建议先在任务模板中增加阻塞说明和返工标记字段，用一个迭代把记录习惯建立起来，第二个迭代再取数据做基线。
进行中的任务确实明显过粗，是否也要拆开？
原则上不重拆进行中的任务，以免打乱清单和进度跟踪。如果某个进行中任务已经阻塞严重或范围明显超出预期，可以把它标记出来，在任务描述中补充剩余交付点和依赖说明，等当前迭代结束后再按新标准重新拆解到后续迭代。这样既保留清单连续性，也让问题任务有明确处理路径。
小团队迭代周期短，颗粒度参考线应该怎么定？
参考线来自团队自己的基线数据，而非统一数值。迭代周期短、成员少的团队，单个任务的预期完成周期参考线通常更短，拆解可以更细；但任务数量增加带来的创建、评审和状态流转开销也更明显，需要观察流转次数是否同步上升。建议先以基线中阻塞率和返工率最低的周期档位作为参考，再根据两到三个迭代的验证结果微调。
调整后周期缩短了，如何确认是颗粒度调整起的作用？
尽量保持迭代长度、团队构成和需求类型稳定，再做前后对照。如果这些条件同时发生变化，例如人员增加或需求总量减少，周期缩短可能来自其他因素，结论只能作为参考。可以同时看阻塞率和返工率：颗粒度调整通常先影响这两项，再传导到周期；若只有周期变化而阻塞与返工没有改善，需要再观察一个迭代确认。
颗粒度标准多久评估一次比较合适？
建议设定固定评估窗口，例如每个季度评估一次，期间只做个别修正，不整体推翻标准。频繁变动会让任务清单和成员习惯反复被打断，也让前后数据失去可比性。每次评估时把改动内容、观察指标和结果记录下来，逐步形成团队自己的颗粒度参考线；两到三个迭代指标稳定改善后，再把标准固化到任务模板中。
