评估需求分解颗粒度，核心是判断“分解到什么层级、每层承载多少信息”是否与团队的决策和交付节奏匹配。做法是先确定评估目标，再定义层级与颗粒度指标，统一统计口径与时间窗，按公式计算并抽样核对，最后结合业务复杂度解读。评估对象是业务需求、产品需求、系统需求与子需求之间的层级与父子关联，需求层级和验收标准字段可以在ONES需求管理中承载，便于后续取数。
要点总览（TL;DR）
- 评估颗粒度先明确三个判断：能否估算排期、能否验收、能否追溯，评估对象限定在业务需求到子需求的层级与父子关联。
- 用五个指标组合衡量：层级深度、子需求数量分布、验收点密度、变更回流率、追溯完整率，单指标只反映一个侧面。
- 可复算的关键是统一分子分母、时间窗和取数来源，分母为零时标注“不适用”，并抽样核对不少于20条或10%的需求。
- 判定采用历史区间对比与趋势观察，不设通用达标线；指标偏离时回到需求样本确认是业务复杂度变化还是分解习惯变化。
- 颗粒度合适与交付顺利之间没有因果关系，跨团队比较需限定同类型需求与同口径范围，建议每季度复核口径。
评估目标：颗粒度要回答哪几个问题
颗粒度评估服务于三个具体判断，每个判断对应一类决策。
第一，能否估算与排期。一条需求如果大到无法给出工作量区间，或者小到排期成本高于实现成本，都会让计划失真。评估要回答：现有分解层级下，团队能否对每条需求给出相对稳定的估算。
第二，能否验收。验收依赖可核对的验收标准。评估要回答：每条需求是否带有足够明确、可逐条核对的验收点，验收时是否需要回到上级需求重新澄清范围。
第三，能否追溯。评估要回答：从子需求能否找到所属父需求，从父需求能否看到验收依据，变更发生时能否定位受影响的范围。
评估对象限定在需求层级本身：业务需求、产品需求、系统需求与子需求之间的层级关系与父子关联。执行任务拆解属于研发执行环节，跨研发对象的需求追溯与覆盖管理属于另一类管理动作，两者不纳入本次评估。明确这条边界，可以避免把任务工时、代码提交等执行数据混入颗粒度结论。
指标与范围：用哪些指标衡量分解颗粒度
颗粒度是“层级深度”和“每层信息量”的组合，单一指标只能反映一个侧面。下表给出五个指标及其衡量侧面，指标之间互为补充。
| 指标 | 含义 | 衡量的侧面 |
|---|---|---|
| 层级深度 | 需求从业务需求到最底层子需求经过的平均层数与层数分布 | 分解是否过深或过浅 |
| 子需求数量分布 | 单条父需求下子需求条数的中位数与分位数 | 单条父需求的承载宽度 |
| 验收点密度 | 单条需求承载的验收标准条数 | 每条需求的信息量与可验收程度 |
| 变更回流率 | 子需求变更导致父需求调整的比例 | 分解边界是否稳定、层级间耦合程度 |
| 追溯完整率 | 子需求能关联到父需求与验收依据的比例 | 层级结构的数据完整性 |
层级深度和子需求数量分布共同描述“分解到多细”；验收点密度描述“每条需求装了多少内容”；变更回流率描述“这种切分是否经得起变化”；追溯完整率是前四项指标可信的前提，追溯缺失时其他指标的分母本身就不完整。
统计对象范围需要事先写清：纳入哪些需求类型（例如只统计产品需求与系统需求，或包含业务需求）、是否包含已取消和已合并的需求、是否只统计进入开发的需求。范围一旦确定，同一轮评估内保持不变，跨轮对比时也要沿用同一范围。
数据口径与证据：分母、时间窗与取数来源
可复算的前提是每个指标的分子分母都有明确定义。下表给出建议口径，团队可按自身层级命名调整，但调整后需在评估说明中记录。
| 指标 | 分子 | 分母 | 单位 |
|---|---|---|---|
| 平均层级深度 | 各条最底层需求到根需求的层数之和 | 纳入统计的最底层需求条数 | 层 |
| 子需求数量中位数 | —（取父需求下子需求条数的中位数与P25、P75） | 纳入统计的父需求条数 | 条 |
| 验收点密度 | 纳入统计需求的验收标准条数之和 | 纳入统计的需求条数 | 条/需求 |
| 变更回流率 | 发生变更且触发父需求调整的子需求条数 | 统计期内发生变更的子需求条数 | % |
| 追溯完整率 | 同时具备父需求关联与验收依据的子需求条数 | 纳入统计的子需求条数 | % |
时间窗按评估目的选择：观察迭代内的分解习惯，用单个迭代或连续三个迭代；观察结构性变化，用季度。时间窗决定变更回流率的统计范围，也决定层级深度是否受阶段性重构影响。单位统一写在结果旁，避免把“层”和“条”混用。
取数来源集中在需求管理系统：层级字段提供父子关系，状态变更记录提供变更事件，验收标准字段提供验收点数量。取数时同步导出需求ID清单，便于抽样复核。
缺失值与异常值需要预先约定规则。父需求下没有子需求时，该父需求计入子需求数量分布的分母，子需求条数记为0，但不计入平均层级深度；验收标准字段为空按0条计，并单独统计空值比例；同一需求在统计期内多次变更，变更回流率按需求条数计一次，不按变更次数重复计。异常值如单条父需求下子需求超过统计分布P95数倍，保留在数据中并单独标注，不直接剔除。
抽样核对抽取不少于20条需求或总量的10%，人工核对层级归属、验收点条数与变更记录是否与系统数据一致，核对结果作为指标可信度的证据附在评估结论后。
计算与评估步骤：从取数到判定
评估按五步执行，每步留下可复查的记录。
- 确定评估范围与时间窗。写明需求类型、状态范围、起止日期，形成一句话的范围说明。
- 按口径导出数据。导出层级关系、子需求清单、验收标准条数、变更记录四类数据，保留导出时间与筛选条件。
- 逐指标计算并记录分母。每个指标同时记录分子、分母和结果，分母为零时标注“不适用”，不填0。
- 与基线或历史区间对比。基线可以是上一季度同口径结果，也可以是连续多个迭代的均值区间，重点看偏离方向和幅度。
- 抽样核对并形成结论。核对通过后，把指标值、样本核对结果和解读写入评估说明。
判定采用区间对比与趋势观察，不设通用达标线。可行的判定方式是：为每个指标记录历史区间，当本轮结果落在区间内视为稳定；明显偏离区间时，回到需求样本查看具体是哪些需求拉动了指标，再判断属于业务复杂度变化还是分解习惯变化。层级深度和验收点密度适合看趋势，变更回流率和追溯完整率适合看区间与异常清单。
在ONES中，需求可按业务需求、产品需求、系统需求与子需求建立父子关联，验收标准作为需求字段维护，状态变更留有记录，这些数据可以直接支撑上述取数与核对动作。
例子：一次颗粒度评估的完整演算
以下为演示情景，数字仅用于说明计算方法。
某迭代纳入统计的父需求共20条，子需求共60条，最底层需求到根需求的层数分布为：2层30条、3层24条、4层6条。
平均层级深度 =（2×30 + 3×24 + 4×6）÷ 60 =（60 + 72 + 24）÷ 60 = 156 ÷ 60 = 2.6层。
子需求数量分布：20条父需求中，2条没有子需求，子需求条数分别为0、0、1、1、2、2、2、3、3、3、3、4、4、4、5、5、6、6、8、10。中位数为3条，P25为2条，P75为5条。无子需求的2条父需求计入分母，子需求条数记0。
验收点密度：60条子需求验收标准合计150条，密度为150 ÷ 60 = 2.5条/需求。另有4条子需求验收标准为空，空值比例4 ÷ 60 ≈ 6.7%。
变更回流率：统计期内发生变更的子需求18条，其中5条触发父需求调整，回流率为5 ÷ 18 ≈ 27.8%。
追溯完整率：60条子需求中同时具备父需求关联与验收依据的54条，完整率为54 ÷ 60 = 90%。
解读：平均2.6层、中位数3条子需求，说明该迭代分解以三层结构为主，宽度集中在2至5条。验收点密度2.5条/需求偏低，结合6.7%的空值比例，提示部分需求在验收标准上信息不足。变更回流率27.8%需要与历史区间对比，若明显高于以往，说明子需求切分边界不稳定，变更容易向上传导。追溯完整率90%意味着约6条子需求缺少父需求关联或验收依据，这部分数据会影响其他指标的准确性，应先补齐再复算。
边界处理：若某次评估中所有父需求均无子需求，子需求数量分布的分母仍为父需求条数，中位数记为0；平均层级深度因分母为零标注“不适用”，不计算为0层。
解读与限制：指标说明什么、不能说明什么
颗粒度偏细的信号通常是层级深度增加、子需求数量中位数上升、验收点密度下降，可能原因是团队按执行动作切分需求，或为便于排期把需求拆到接近任务粒度。颗粒度偏粗的信号是层级浅、单条需求验收点密集、变更回流率偏高，可能原因是需求边界按业务模块而非可交付单元划分。两类信号都要回到具体需求样本确认原因，指标本身只指出方向。
指标受业务复杂度与需求类型影响。合规类、平台类需求的验收点天然多于界面调整类需求，跨团队不可直接比较绝对值，比较应在同类型需求、同口径范围内进行。跨季度对比时若层级命名或统计范围发生变化，需要先做口径对齐再比较。
单指标不能代表分解质量。层级深度正常但追溯完整率低，说明结构数据不可信；验收点密度高但变更回流率也高，说明验收标准写得细而边界没切稳。评估结论应组合至少三项指标，并附抽样核对结果。
颗粒度合适与交付顺利之间没有因果关系。交付还受依赖管理、资源投入、外部变更影响，颗粒度指标只能说明需求结构是否便于估算、验收和追溯。建议每季度复核一次口径与统计范围，每轮评估保留抽样样本，便于下一轮对比时判断指标变化来自真实改进还是口径调整。
常见问题
团队刚开始做颗粒度评估，没有历史基线怎么办？
没有历史基线时，可以先做一次“现状盘点”，把本轮五个指标的结果作为第一版基线，同时记录口径、统计范围和时间窗。接下来连续两到三个迭代用同一口径复算，观察指标是否稳定，稳定后的区间就可以作为后续对比的参照。另一种做法是横向取同类型需求分组比较，例如把平台类和界面调整类分开统计，组内比较比跨组比较更有解释力。需要注意的是，第一版基线本身可能受分解习惯影响，不宜直接当作“合理值”，它只是后续观察变化的起点。
子需求数量中位数和平均层级深度，哪个更能反映颗粒度问题？
两个指标回答的问题不同。平均层级深度反映分解的纵向深度，适合观察是否出现层级过深或过浅；子需求数量中位数反映单条父需求的横向承载宽度，适合观察切分是否均衡。实践中建议一起看：层级深但宽度窄，可能是逐层细化；层级浅但单条父需求下子需求很多，可能是把多个可交付单元压在一层。两者都偏离历史区间时，再结合验收点密度和变更回流率判断问题出在切分边界还是验收标准。单独用其中一个指标下结论，容易把结构问题误判为习惯问题。
变更回流率偏高，是否说明需求分解一定有问题？
不一定。变更回流率衡量的是子需求变更向上传导到父需求的比例，它偏高的原因至少有三类：子需求切分边界不稳定，变更容易牵连父需求；业务本身处于探索期，需求范围在迭代内持续调整；父需求定义过粗，子需求变更时不得不回改父需求。判断时需要结合变更记录的具体内容，看回流集中在少数需求还是普遍分布。如果集中在少数需求，更可能是个别需求边界没切清；如果普遍偏高，则要检查分解规则和父需求的验收标准是否足够明确。指标只提示方向，原因需要回到样本确认。
追溯完整率低时，其他指标还能用吗？
可以看，但要降低结论强度。追溯完整率反映子需求能否关联到父需求和验收依据，它偏低意味着其他指标的分母可能不完整，例如缺少父需求关联的子需求在层级深度统计中可能被遗漏，缺少验收依据的子需求会让验收点密度偏低。建议先补齐关联数据再复算一轮，把两轮结果并列记录。如果短期内无法补齐，可以在评估说明中标注数据完整度，并把追溯完整率作为独立结论呈现，避免用不完整的数据推导颗粒度是否合适。
不同团队的需求分解颗粒度可以直接比较吗？
直接比较绝对值的参考意义有限。颗粒度受业务复杂度、需求类型和团队分工方式影响，合规类、平台类需求的验收点天然多于界面调整类需求，层级命名和统计范围也可能不同。如果要做跨团队比较，先对齐三件事：统计的需求类型与状态范围、层级命名与层数计算方式、时间窗长度。对齐后再比较趋势和分布形态，例如两个团队的子需求数量分布是否都集中在2至5条，比比较中位数具体数值更有意义。跨团队比较的结论适合用于发现差异和讨论分解规则，不适合直接作为团队绩效判断。
