评估任务颗粒度，先要明确评的是可执行工作项，再统一口径：以单个任务为计数单位，用任务规模、层级深度、子任务数量、完成周期和返工率等指标，在固定时间窗内看分布而非只看平均值，并结合完成标准做定性核验。颗粒度没有通用达标线，需要按团队历史基线和任务类型分层解读。
要点总览（TL;DR）
- 评估对象是可执行工作项：以单个任务为计数单位，WBS 与需求层级不纳入统计。
- 核心指标包括任务规模、层级深度、子任务数量、完成周期和返工率，每项都要写清公式、单位与统计时间窗。
- 计算时输出中位数与分位数，按任务类型和团队分层对比，再用完成标准、验收人、依赖说明做定性核验。
- 颗粒度没有通用达标线，以团队历史基线的 P25–P75 区间作参考，偏离区间且定性核验支持时才列为调整对象。
- 评估结论用于调整拆解规范、改进估算和优化任务模板，不宜直接作为个人绩效依据。
评估目标：颗粒度要回答什么问题
任务颗粒度评估要回答的核心问题是：当前拆出来的任务，是否足够支撑独立执行、可靠估算和过程跟踪。这个问题不能停留在“任务该多细”的讨论上，而要转化为可验证的判断——一个任务能否由一名成员在约定周期内独立推进，能否给出相对可靠的规模估计，能否在任务系统中被清楚跟踪到完成。
评估对象限定为可执行工作项，也就是任务系统中承担具体执行动作的那一层记录。项目交付范围的工作分解结构（WBS）、需求层级与需求分解不在本文评估范围内，它们解决的是交付范围和需求组织问题，与单个任务是否拆得合适属于不同层面的问题。把这两类对象混在一起统计，会让层级深度、子任务数量等指标失去可比性。
评估结论的用途是调整拆解方式、改进估算习惯、优化任务模板，而不是给个人打分。颗粒度指标反映的是团队拆解与跟踪的状态，同一名成员在不同任务类型下的颗粒度差异可能很大，把指标直接对应到个人绩效，容易把拆解规范的改进问题变成对个人的评价问题，反而削弱数据质量。
一份可用的评估目标说明应包含三部分：评估对象（可执行工作项及其边界）、评估用途（调整拆解规范与估算方法）、不纳入范围（WBS、需求层级、个人绩效判定）。写清楚这三点，后续的指标选择和取数才有统一前提。
指标与范围：用哪些指标衡量颗粒度
衡量颗粒度需要一组互补指标，单一指标容易失真。任务规模反映单个任务的工作量大小，层级深度和子任务数量反映拆解结构，完成周期反映任务从开始执行到结束的实际跨度，返工率反映拆解是否清晰到一次做完。这些指标共同描述颗粒度，任何一项单独使用都只能说明局部。
| 指标 | 计算口径 | 单位 | 统计时间窗 | 分层维度 |
|---|---|---|---|---|
| 任务规模 | 单个任务的计划工时或故事点；同一评估内固定一种单位，不混用 | 人时或点 | 按迭代或固定自然月 | 任务类型、团队 |
| 任务层级深度 | 任务在父子结构中的层级数；需约定根任务是否计入 | 层 | 与样本范围一致 | 任务类型、团队 |
| 子任务数量 | 单个任务的直接子任务数；未拆子任务记为0 | 个 | 与样本范围一致 | 任务类型、团队 |
| 任务完成周期 | 任务从进入执行状态到进入完成状态的时间差 | 小时或天 | 按完成时间归入窗口 | 任务类型、团队 |
| 返工率 | 完成后被重新打开或退回的任务数 ÷ 窗口内完成任务数 | 百分比 | 按完成时间归入窗口 | 任务类型、团队 |
每个指标都要写清分子、分母和时间窗。以返工率为例，分子是统计窗口内完成、且完成后被重新打开或退回的任务数，分母是同一窗口内完成的任务总数，两者都按完成时间归入窗口，避免用创建时间造成跨期错配。任务完成周期同理，需要先统一“完成”对应的状态，再计算时间差。
统计范围要分层。探索型、运维型、交付型任务的合理颗粒度差异明显：探索型任务本身带有不确定性，拆得过细会频繁返工；运维型任务往往由事件触发，规模小而数量多；交付型任务适合按可独立验收的单元拆分。把三类任务混在一起算平均值，得到的数字无法指导任何一类任务的拆解改进。团队之间、迭代之间也应分别统计，再决定是否合并观察。
数据口径与证据：数据从哪里来、怎么保证可比
颗粒度评估的数据主要来自任务系统：任务字段提供规模与类型，父子关系提供层级结构，状态变更时间提供完成周期，工时或点数记录提供规模口径，重新打开或退回记录提供返工数据。取数前先确认这些字段在团队内是否被稳定使用，字段填写的随意程度直接决定指标的可信度。
口径统一是可比的前提，重点处理四件事。第一，任务完成的定义要一致，明确哪个状态算完成、哪些状态属于完成后的重新打开。第二，工时填报规则要一致，是执行前填计划工时还是执行后补填实际工时，评估颗粒度应使用计划口径，并说明未填工时的任务如何处理。第三，层级计数方式要一致，根任务是否计入深度、子任务是否单独进入样本，都要在评估前写定。第四，统计窗口要一致，按完成时间归窗还是按创建时间归窗，全篇保持一种。
定性证据与定量指标并行使用。检查任务描述是否包含完成标准、是否有明确验收人、是否说明依赖关系，这三项能补充说明任务是否拆到了可独立执行的程度。一个规模适中但描述只有一句话、没有完成标准的任务，颗粒度在形式上合格，在执行上仍然偏粗。定性核验可以抽样进行，按任务类型各抽若干条，记录检查结果。
缺失值要按规则处理，不能默认填零。未填计划工时的任务，规模指标标记为缺失并单独统计缺失比例；未拆子任务的任务，子任务数量记为0，这是真实值而非缺失；跨团队口径差异明显的字段，先分层展示，暂不合并计算。分母为零的指标标记为“不适用”，不写成0，避免把“没有数据”误读为“表现良好”。
在任务系统中落实这些口径，需要任务层级、子任务、计划工时和状态变更记录能够被稳定记录和导出。ONES 的任务管理支持任务与子任务的层级组织，并记录工时与状态流转，团队可以在同一套字段口径下按迭代、按任务类型取数，减少手工整理造成的口径漂移；评估前把完成状态映射和工时填报规则在系统里固定下来，后续每次评估都能复算。
计算与评估步骤：从取数到判定
评估按四步推进，每一步都有明确产出，便于他人复算。
第一步，确定统计时间窗与任务样本范围。选定一个或几个完整迭代作为窗口，明确样本是窗口内完成的任务，还是窗口内处于执行状态的任务，二者选其一并全篇沿用。样本范围同时写明包含哪些任务类型、是否包含子任务。产出是一份样本清单和窗口说明。
第二步，按公式计算各指标并输出分布。对任务规模、层级深度、子任务数量、完成周期分别计算中位数、P25、P75、P90，返工率计算整体比例并按任务类型拆分。平均值可以作为参考，但要与中位数并列展示，少数超大任务会把平均值拉高，掩盖多数任务的真实分布。产出是指标分布表。
第三步，按任务类型与团队分层对比，识别异常颗粒度。把每层的分布与团队自身历史基线比较，找出明显偏离的任务：规模处于P90以上且完成周期长的任务，通常偏粗；规模很小、子任务数量为0但返工率高的任务，可能拆得不够清楚或本身不该独立成任务。产出是异常任务清单及初步判断。
第四步，结合定性证据核验，形成判定结论。对异常任务抽样检查完成标准、验收人和依赖说明，确认定量判断是否成立，再给出该团队或该类任务的颗粒度调整建议。产出是评估结论与行动项。
样本过少时只做描述性展示。可以约定一个最小样本量，例如单层任务数低于30条时，只报告中位数和样本数，不下达标结论。分母为零的指标标记为不适用。这两条规则要在评估开始前写定，避免看到结果后再调整判断标准。
例子：一次颗粒度评估的完整演算
以下为演示情景，数据为假设值，用于说明计算过程，不代表任何真实团队的表现。
设定：某团队一个为期两周的迭代，窗口内完成任务40个，其中交付型25个、探索型10个、运维型5个。任务规模统一使用计划工时，单位为人时。层级深度按根任务计为第1层。
| 指标 | 交付型（25个） | 探索型（10个） | 运维型（5个） |
|---|---|---|---|
| 计划工时中位数 | 12人时 | 20人时 | 3人时 |
| 计划工时P90 | 32人时 | 40人时 | 6人时 |
| 层级深度中位数 | 2层 | 1层 | 1层 |
| 子任务数量中位数 | 3个 | 0个 | 0个 |
| 完成周期中位数 | 3天 | 6天 | 1天 |
| 返工率 | 8%（2÷25） | 30%（3÷10） | 0%（0÷5） |
逐项看结果。交付型任务计划工时中位数12人时、P90为32人时，说明多数任务规模适中，但有少数任务明显偏大；这些P90以上的任务完成周期也偏长，属于偏粗的候选，应检查是否还能拆出可独立验收的单元。探索型任务层级深度中位数为1层、子任务数量为0，返工率30%，结合定性抽查若发现任务描述缺少完成标准，说明这类任务拆得偏粗，问题不在规模而在完成条件不清。运维型任务规模小、周期短、返工率为0，颗粒度与任务性质匹配，不需要按交付型的标准要求拆分。
这个示例的局限需要说明：样本仅40个任务，运维型只有5个，其返工率0%不足以作为稳定结论；计划工时依赖填报质量，未填工时的任务未纳入；返工率只统计了完成后重新打开的情况，评审阶段退回未计入。实际评估中应扩大窗口、补充缺失值说明，并对定性抽查结果单独记录。
解读与限制：指标能说明什么、不能说明什么
颗粒度指标反映的是拆解与跟踪状态，不能直接证明交付质量或人员绩效。任务规模小、返工率低，可能说明拆解清晰，也可能说明任务本身简单或完成标准定得宽松；任务规模大、周期长，可能说明拆得偏粗，也可能说明任务性质决定其无法再拆。指标提供的是需要进一步核验的线索，结论要结合定性证据和任务背景给出。
不同任务类型的合理颗粒度不同。探索型任务允许较粗的初始拆解，随着信息明确再细化；运维型任务以响应速度为先，通常不需要多层子任务；交付型任务适合按可独立验收的单元拆分。用一套阈值要求所有任务类型，会把合理的差异误判为问题。
达标线的设定以团队自身历史基线为参照。做法是选取若干历史迭代，计算各指标的中位数和分位数，把P25到P75之间的区间作为常规参考区间，偏离区间且定性核验也支持判断的任务列为需要调整的对象。基线随团队人员、任务结构变化而更新，不设一成不变的通用标准。行业里流传的“任务不超过几天”之类说法，缺少统一口径支撑，不宜直接当作达标线使用。
评估结果落到三个行动方向：调整拆解规范，把完成标准、验收人、依赖说明写进任务模板；改进估算，对规模处于高分位的任务在拆解阶段就要求补充拆分说明；优化任务模板，按任务类型设置不同的必填字段，让颗粒度要求在创建任务时就被提示。评估本身按固定周期重复进行，用同一口径对比前后变化，才能判断拆解规范调整是否有效。
常见问题
任务颗粒度评估应该多久做一次，用多长的统计窗口比较合适？
频率和窗口要匹配团队的交付节奏。常见做法是按迭代或按固定自然月统计，每次评估使用一个或几个完整迭代作为窗口，并保持窗口口径前后一致，这样前后两次结果才能对比。
如果团队迭代周期短、任务量少，单次窗口内样本可能不足，可以连续取几个迭代合并统计，但要在结论中注明合并范围。评估频率建议与拆解规范的调整周期对齐，例如每季度评估一次、调整一次规范，避免频繁评估带来的填报负担影响数据质量。
任务没有填计划工时，还能参与颗粒度评估吗？
可以参与，但要按缺失值规则处理。规模指标对未填工时的任务标记为缺失，单独统计缺失比例，不用零或平均值填补；层级深度、子任务数量、完成周期和返工率这几项不依赖工时，仍可正常计算。
如果缺失比例较高，规模指标的结论要谨慎使用，同时把工时填报规则作为改进项。评估颗粒度应使用计划口径，执行后补填的实际工时适合用于估算偏差分析，两类数据分开统计。
子任务数量多，是不是就说明颗粒度合适？
不能这样判断。子任务数量只反映拆解结构，拆得多不代表拆得清楚。一个任务拆出很多子任务，但每个子任务缺少完成标准和验收人，执行中仍然会反复确认、频繁返工。
实际评估时把子任务数量与返工率、完成周期放在一起看：子任务多且返工率低，说明拆解有效；子任务多但返工率高，需要检查完成条件是否写清；子任务为零且规模偏大的任务，则要确认是否还能拆出可独立验收的单元。
不同任务类型能用同一套颗粒度标准吗？
不建议。探索型任务带有不确定性，初始拆解可以粗一些，随信息明确再细化；运维型任务由事件触发，规模小、周期短，通常不需要多层子任务；交付型任务适合按可独立验收的单元拆分。
可行做法是按任务类型分别建立历史基线，各自设定参考区间，再在类型内部比较。跨类型合并统计得到的平均值，无法指导任何一类任务的拆解改进。
评估发现某些任务偏粗，接下来应该改什么？
先区分偏粗的原因，再决定动作。规模处于高分位且完成周期长的任务，通常需要在拆解阶段补充拆分说明，把可独立验收的单元拆出来；规模适中但返工率高的任务，问题多在完成标准不清，应把完成标准、验收人、依赖说明写进任务模板。
规范调整后按同一口径重复评估，对比前后分布变化，判断调整是否有效。评估结果用于改进拆解方式和估算习惯，落到具体字段和模板上，比笼统要求“拆细一点”更容易执行。
