需求排期迭代规划教程：研发团队入门指南，避坑指南

我带过一个 12 人的研发团队，连续四个迭代都在第 9 天出问题：计划里写着 42 个故事点，到第 9 天实际完成 26 个，剩下 16 个里有 7 个卡在“等 UI 稿”，5 个卡在“等接口联调”，只有 4 个是真的没写完。当时我的第一反应是估得太乐观，于是花了两个月优化估算方法，从拍脑袋换成三点估算、再换成计划扑克，结果准时率只从 62% 爬到 68%。真正让准时率跳到 89% 的，不是估算，而是我把“需求进迭代前必须先通过就绪检查”这件事做成了硬门槛。

这篇教程想讲的就是这件事：需求排期与迭代规划，在大多数团队里被当成“把工作量填进日历”的行政动作，但它真正的价值是把不确定性切成可观测的小块，让团队在信息不全的情况下依然能做出一致、可解释、可调整的决策。下面我会先给结论，再还原真实场景，拆解七个高频误区，给出我自己在用的五条判断逻辑，最后按团队规模给出可执行的建议和取舍方案。文中所有数据，除明确标注来源的公开结论外，都是我过去几年在十几个团队里的一线观察记录，属于样本推演性质，你可以当成基准参考，不要当成行业统计。

一、先给结论：排期排的不是时间，是不确定性

如果你的团队每次迭代都要“最后三天冲刺”，问题大概率不在开发速度，而在排期这件事的输入和结构上。我先把结论摆出来，后面的所有章节都是为了支撑和细化这五条判断。

1. 排期的瓶颈在输入端，不在估算技巧

我统计过自己带过的 7 个团队、共 61 个迭代的数据：估算偏差超过 40% 的任务里，有 68% 在进入迭代时其实还没想清楚要做什么，验收标准是空的、设计稿是缺的、依赖方是没确认的。这类任务的“估算”本质上是在猜需求，精度再高的估算方法也救不了。

反过来说，凡是进入迭代前通过了完整就绪检查的任务，即使只用最粗糙的“大中小三档”估算，偏差也能控制在 25% 以内。估算方法决定的是误差分布的形态，需求就绪度决定的是误差的中心位置。先把中心位置摆正，再谈形态优化。

2. 迭代长度不是管理偏好，是被两个变量决定的

很多团队选两周迭代，理由只是“大家都这么干”。但迭代长度其实由两个变量决定：一是需求到达的节奏，二是你承受错误决策的周期。需求变化快的业务（比如面向 C 端的活动、增长实验），迭代越短越好，因为短迭代的沉没成本低；需求稳定、单次交付链路长的业务（比如底层平台、硬件联动、合规改造），硬套两周只会把大量任务拆成“半成品”，反而增加集成风险。

我见过一个做工业设备管理系统的团队，强行上两周迭代，结果每个迭代都有 30% 的任务是“写完但没法验证”，因为要等真实设备联调。后来改成四周迭代 + 每周一次内部同步，准时率从 55% 涨到 82%。迭代长度不是越短越好，是越贴合你的验证周期越好。

3. 缓冲要集中管理，不要摊进每个任务

新手最常见的做法是给每个任务加 20% 的缓冲，觉得这样比较“保险”。这是一个数学上就会失效的做法：缓冲被分散到 20 个任务里，每个任务的负责人都知道“我还有余量”，于是余量在第一天就被消耗掉，等到真正出问题时，缓冲已经不存在了。

正确做法是把缓冲提出来，变成迭代级别的一个显性池子，由一个人统一管理，只在真正发生风险时动用。我在两个 20 人左右的团队做过对照：分散缓冲的迭代，平均延期 3.4 天；集中缓冲的迭代，平均延期 1.1 天。同样的团队、同样的需求量，差别只在缓冲的位置。

4. 排期要输出三样东西，而不是一张时间表

一张甘特图不是排期的产出。真正有用的排期输出三样东西：承诺（这个迭代我们一定交付什么）、预测（基于历史速率，我们大概率能交付什么）、选项（如果范围要压缩，先砍哪些、后砍哪些）。只有承诺没有选项的排期，一到变更就会变成吵架。

5. 排期必须可变，但变更要有成本标签

“排期定死不许改”和“随时可以插需求”是同一个错误的两种极端。健康的状态是：变更随时可以提，但每次变更都要带上成本标签，插一个需求，等于把哪两个需求挤出去，或者等于迭代目标从 A 变成 B。当变更的成本被显性化，插需求的人会自己先做一次取舍，这比任何审批流程都有效。

二、真实场景：三个我亲手处理过的排期现场

抽象的道理讲完了，接下来是具体的现场。这三个场景分别对应小团队、中型团队和交付压力最大的场景，我把当时的数字都记了下来，因为它们比任何方法论都更能说明问题出在哪。

1. 场景一：12 人团队，两周迭代跑成了三周

这是开头提到的那个团队，做的是一个面向中小企业的 SaaS 后台，前端 4 人、后端 5 人、测试 2 人、产品 1 人。团队规定两周一个迭代，但连续 6 个迭代的实际交付周期都在 18-21 天之间。我当时做了一件事：把每个迭代的时间去向拆开记录，连续记了 6 个迭代。

结果很刺眼：真正用于写代码和写测试的时间只占 46%，等待（等设计稿、等接口、等环境、等评审）占 27%，返工占 15%，会议和沟通占 12%。也就是说，团队不是“干得慢”，而是有一半时间在等和返工。而这个团队的排期表上，这些等待时间一格都没有。

更麻烦的是，等待时间是隐性的，所以每个迭代结束时，大家的感受都是“我们已经很努力了”，但结果就是没交付。当排期表只装“工作时间”，它一定会低估周期，因为真实的周期里有一半是等待。后来我们改成按“周期时间”而不是“工时”做预测，同时在排期时把已知的等待节点（比如设计稿交付日、接口联调窗口）显式标出来，第 7 个迭代的实际交付周期降到了 15 天。

2. 场景二：需求池 180 条，真正能排进迭代的只有 23 条

第二个团队是一个 40 人左右的研发部门，需求池里长期躺着 180 多条需求。产品经理每周都在喊“需求太多排不完”，但每个迭代真正能进开发的只有 20 多条。我去做了一次分类，按“是否可开工”把 180 条需求过了一遍。

结果是：能直接开工的 23 条，缺验收标准的 51 条，缺设计稿的 44 条，依赖外部团队未确认的 38 条，商业价值未定义、连产品自己也说不清为什么要做的 24 条。也就是说，需求池的 87% 是“看起来很忙但排不进去”的库存，它制造了强烈的资源焦虑，却没有产生任何实际排期压力。

这种结构会带来一个隐蔽的后果：排期会永远卡在那 23 条上，团队反复做“最容易做”的需求，而不是“最该做”的需求。而这个团队的管理层看到的数字是“需求满足率只有 13%”，于是决定加人。加了三个人之后，满足率涨到 16%，因为瓶颈根本不在人力。

3. 场景三：上线前三天砍需求，砍错了地方

第三个场景是一次真实的线上事故前夜。一个 60 人规模的团队要在一个固定日期交付大版本，上线前三天发现进度落后约 25%，于是开了个会砍需求。砍的结果是：砍掉了两个“性能优化”和一个“权限校验补全”，保留了三个“界面动效”和一个“运营活动页”。

上线后第二周，权限漏洞导致一个客户的越权访问被曝光，赔付和修复成本远超那三个动效的价值。事后复盘时，所有人都说“当时太急了”。但问题不在急，在于这个团队从来没有在排期阶段定义过“砍的顺序”，所以砍的时候只能凭现场感觉。

如果排期时就给每个需求标上“不可妥协项 / 可延后项 / 可放弃项”三档，砍需求的会只需要照着表砍，不需要在压力下重新做价值判断。这也是我后来坚持在每个迭代规划时都要求产品经理填一栏“如果只能交付一半，先交付哪一半”的原因。

三、七个高频误区：新手几乎一定会踩

下面这七个误区，是我在带团队和做咨询时出现频率最高的。我把每个误区拆成“症状，为什么错，怎么改”三段，你可以对照自己的团队看看中了几个。我的经验是，一个团队通常同时中 3-4 个，而且它们会互相强化。

1. 误区一：把工时估算当成排期

症状：排期表上写的是“张三 3 天、李四 5 天”，加起来除以人数就是迭代周期。为什么错：工时是“如果一切顺利需要多久”，排期是“考虑到一切不顺利，什么时候能交付”。两者之间的差距，就是等待、返工、上下文切换和意外。怎么改：用工时做任务级估算，但用历史周期时间做迭代级预测，两个数字不要混用。

一个具体的操作细节：我在做任务估算时会问两个问题，“如果你今天一整天只做这一件事，需要多久”和“如果中间被拉去开会、被问问题，实际要多久”。第二个答案通常是第一个的 1.5-2 倍，这个倍数就是团队的真实上下文切换成本。把它显性化，比要求大家“专心”有效得多。

2. 误区二：用“人天”把每个人的日历填满

症状：迭代容量 = 人数 × 迭代天数，然后精确分配到 100%。为什么错：100% 负载等于零弹性，任何一次请假、任何一次线上问题都会直接变成延期。而且人在 100% 负载下的实际产出低于 80% 负载，因为没有任何空间处理协作和思考。

我的经验值是：规划时按 70%-75% 的容量排任务，剩下 25%-30% 留给线上问题、评审、技术债和缓冲。这不是“留余量偷懒”，而是承认协作成本客观存在。我做过一次对照：把容量从 95% 降到 72%，迭代交付量反而上升了 11%，因为团队不再频繁地在迭代中途被打断重排。

3. 误区三：需求优先级靠“谁喊得响”

症状：优先级排序会上，声音大的部门的需求永远排前面；或者所有需求都是“P0”。为什么错：当所有需求都是最高优先级时，优先级字段等于不存在，实际排序权就落到了最后一个提需求的人手里。

我更推荐的做法是只排“前三分之一”。把需求按价值/成本粗排出前 1/3、中 1/3、后 1/3 三档就够了，因为排期的现实是：你永远只会做到前 1/3。花三天时间给 180 条需求精确打分，得到的排序精度远不如花半天时间把前 20 条排清楚。

4. 误区四：迭代长度靠抄

症状：“业界都是两周，我们也两周”。为什么错：迭代长度的本质是“你愿意在多长时间内承受一次错误决策”。两周迭代意味着每两周可以做一次方向修正，但如果你的需求来源是季度规划、验证周期是四周，两周迭代只会让你每两周开一次没有新信息的会。

一个可用的判断方法：迭代长度 ≈ 最短的可验证反馈周期。如果一次改动要等真实用户用一周才能看出效果，迭代就别短于两周；如果需要灰度一周再观察一周，就考虑三到四周。反过来，如果是 A/B 实验类业务，一周甚至三天都合理。

5. 误区五：缓冲藏在每个任务里，而不是集中管理

症状：每个任务都加了 20%-30% 的“安全余量”。为什么错：分散缓冲在博弈中会失效。每个任务的负责人都倾向于在自己这一段多留一点，而一旦上游延期，下游的缓冲就被吃掉，但没有人会主动把缓冲还回来。最后总缓冲被用光两次。

集中缓冲的做法是：任务估算用 50% 置信度的值，把差额统一放进迭代缓冲池，由迭代负责人按风险优先级分配。我在两个 20 人团队做过 6 个迭代的对照，分散缓冲的平均延期是 3.4 天，集中缓冲是 1.1 天。缓冲不是不能有，是不能分散着有。

6. 误区六：只排开发，不排验收和发布

症状：排期表上最后一项是“开发完成”，上线、验收、文档、数据埋点全部不在表里。为什么错：在多数团队里，从“开发完成”到“真正可用”之间还有 20%-35% 的工作量，包括联调、回归测试、验收反馈修改、发布准备。这部分不排进去，它就会自动侵占下一个迭代。

我的做法是在排期表里固定加三个节点：功能可用日（开发完成且能自测）、验收通过日（业务方确认）、可发布日（含发布清单和回滚方案）。这三个日期比“任务完成率”更能反映真实进度。

7. 误区七：排期一次定死，中途不许改

症状：迭代开始后需求冻结，任何变更都要走很重的审批。为什么错：冻结不会让变更消失，只会让变更转入地下，变成“顺便改一下”“这个 bug 顺手修了”，然后以更不可控的方式影响进度。

更有效的机制是“带成本的变更”：变更随时可以提，但必须同时说明挤掉哪个已排需求，或者明确迭代目标从 A 调整为 B。这个机制的关键不是阻止变更，而是让变更的发起者承担排序责任。实践下来，这个机制会让变更量下降 40% 左右，而且剩下的变更是真正重要的。

四、专业判断逻辑：我怎么判断一个排期靠不靠谱

经验告诉我，看一个团队的排期靠不靠谱，不需要看排期表本身，看五个地方就够了。这五条判断是我在做研发效能评估时最常用的，基本能在半小时内给出一个八九不离十的结论。

1. 判断一：看输入质量，不看估算精度

我会随机抽 10 条已排进迭代的需求，检查三件事：验收标准是否可验证、依赖是否已确认、设计是否已到可开发状态。如果 10 条里有 7 条以上通过，这个排期的输入质量是合格的；如果只有 3-4 条通过，无论排期表做得多漂亮，延期都是必然的。

这里有个反直觉的点：需求就绪度是可以量化的，而且它的提升不依赖任何工具或管理技巧，只依赖一个“不通过就不进迭代”的硬规则。我在团队里推行这条规则时，最大的阻力来自产品经理，因为这意味着他们要在需求还不完美时就先想清楚。但坚持两个迭代后，反对声音基本消失，因为他们发现自己的需求返工也变少了。

2. 判断二：看任务粒度，2 天内能否出结果

如果一条任务在排期表上写着“5 天”或“8 天”，它几乎一定会延期，因为你无法在中途判断它是完成了 60% 还是 30%。我的经验阈值是：绝大多数任务应该在 0.5-2 天内能出一个可验证的结果。

粒度太粗的另一个后果是风险发现太晚。一个 8 天的任务，风险通常在第 6 天才暴露；拆成 4 个 2 天的任务，风险在第 2 天就能看到。这不是为了“管得细”，而是为了让团队更早知道坏消息。

3. 判断三：看依赖，跨团队依赖有没有前置排期

跨团队依赖是排期里最容易被忽略、杀伤力最大的部分。我的检查方式是：把迭代内所有依赖外部团队的任务列出来，看每一个是否都有对方的明确交付日期，并且这个日期至少比你的需要时间早 3 天。

如果没有，这个依赖就不是“风险”，而是“已经发生的问题”。我在一个 150 人规模的团队见过最典型的情况：一个迭代内有 14 个任务依赖另外两个团队，其中只有 3 个确认了交付时间。这个迭代的结果不用猜。

4. 判断四：看缓冲位置和缓冲可见性

缓冲要满足两个条件才算有效：集中（不在每个任务里）和可见（有人知道还剩多少）。我会直接问迭代负责人一句“这个迭代的缓冲还剩多少”，如果对方答不上来，那缓冲机制大概率是假的。

一个健康的信号是：迭代过半时缓冲还剩 50% 以上。如果过半就只剩 20%，说明估算普遍偏乐观，或者这个迭代本身就在赌。

5. 判断五：看变更成本是否可度量

我会翻迭代的变更记录，看每一次变更是否带了两样信息：挤掉了什么、迭代目标有没有变。如果变更记录只有一句“新增需求：xxx”，那这个团队的排期实际上是一个许愿池，不是计划。

可度量的变更成本还有一个额外好处：它能沉淀成数据。当你连续记录三个月的“变更挤出量”，你就能算出团队的“需求吞吐弹性”，每增加 10% 的临时需求，会挤掉多少计划内需求。这个数字在向上汇报时非常有说服力。

6. 一个组织规模视角的补充：平台化工具能解决什么、不能解决什么

上面五条判断，在 10 人团队里靠白板和口头约定就能跑起来。但当组织超过 100 人、有多个产品线和多个依赖方时，靠人肉维护的排期表会开始失真，不是因为大家不认真，而是因为信息同步的成本超过了个人能承载的极限。

我参与过一次 150 人规模研发组织的排期机制改造，用的是 PingCode 这类面向中大型企业的研发管理平台。这类平台真正的价值不在“画甘特图”，而在三件具体的事：把需求就绪状态做成可查询的字段，让“能不能排”变成客观判断而不是开会争论；把跨团队依赖显性化成可追踪的关联项，依赖方延期会自动反映到你的迭代视图上；把变更记录结构化，让“变更挤出量”这类指标可以自动统计，而不需要有人每周手工汇总。

但我要说清楚边界：平台解决的是信息可见性和一致性问题，解决不了“需求没想清楚”和“没人愿意做取舍”这两个根本问题。我见过太多团队上了工具之后，把没想清楚的需求更快地排进了迭代，结果只是把混乱加速了。所以正确的顺序是：先立规则（就绪检查、缓冲集中、变更带成本），再用工具固化规则。反过来做，工具只会帮你更快地生产混乱。

五、案例与数据观察：三个团队的排期改造前后对比

下面三个案例来自我实际参与过的团队，时间跨度从 2021 年到 2024 年。为了保护信息，我隐去了公司名，只保留规模和关键指标。所有数字都是团队自己统计的口径，我在文中注明了统计方式，你可以按同样口径在自己团队复现。

1. 案例 A：40 人研发团队，先修输入再修流程

这个团队做企业级数据产品，研发 40 人，分 4 个小组。改造前的问题是：迭代准时率 58%，需求平均在迭代内被改动 1.8 次，跨组依赖经常在联调阶段才暴露。改造动作只有三个：需求就绪检查（六个必填项）、迭代容量降到 72%、跨组依赖必须提前一个迭代确认。

三个迭代后，准时率到 81%；六个迭代后到 89%。需求改动次数从 1.8 次降到 0.7 次。注意，这个团队没有换工具、没有加人、没有改迭代长度（一直是两周）。唯一的变化是把“什么需求能进迭代”这件事的判定权，从会议争论变成了检查清单。

2. 案例 B：150 人跨部门组织，靠平台固化规则

这个团队有 5 条产品线、3 个共享技术组，改造前最大的问题是“没人知道全貌”。每个产品线自己的排期是清楚的，但共享技术组的容量被五方争抢，谁先抢到谁用。结果是共享组变成瓶颈，平均排队 6 天。

改造分两步：第一步建立共享组的统一需求入口和配额规则（每条产品线固定配额 + 可借用池）；第二步用 PingCode 把配额规则和依赖关系统一到同一个视图里，让每个产品线能自己看到“我还能借多少、我的依赖排在谁后面”。改造后，共享组平均排队时间从 6 天降到 2.3 天，跨产品线的排期冲突会议从每周 3 次降到每周 0.5 次。

这里我要强调一个判断：150 人组织的排期问题，往往不是“排得不准”，而是“排得不可见”。当所有信息都在五个不同的表格里，任何一次协调都变成了信息搜集劳动，最后只能靠会议解决。平台在这类场景的价值是把信息搜集成本降到接近零。

3. 案例 C：一个反例，6 人团队上重流程，反而变慢

这个案例我特意放进来，因为它证明了方法有边界。一个 6 人的创业团队，看到大厂的研发流程很好，于是引入了完整的需求评审、就绪检查、迭代规划会、每日站会、回顾会、速率统计。结果是：每周会议时间从 2 小时涨到 7 小时，交付速度下降约 20%。

原因很简单：6 个人的沟通路径只有 15 条，所有人都知道所有事，流程带来的信息同步收益几乎为零，但流程的执行成本是实打实的。小团队需要的是规则，不是流程；需要的是清单，不是会议。后来他们把流程砍到只剩“需求就绪清单”和“每周一次 30 分钟同步”，速度恢复并超过了改造前。

4. 从这三个案例里能提炼出的三个数字

第一，规划容量控制在 72%-75% 是一个比较稳的区间。低于 65% 会让管理层觉得资源浪费，高于 85% 会让延期成为常态。这个区间在三个团队里都验证过。

第二，需求就绪度每提升 10 个百分点，迭代准时率大约提升 6-9 个百分点。这是一个经验换算，不是严格因果，但在多个团队里方向一致。

第三，跨团队依赖确认提前一个迭代，可以把依赖导致的延期减少 60% 以上。这是投入产出比最高的一项改动，几乎不需要任何工具投入。

六、行动建议：按团队规模和阶段给出不同做法

同样的方法论，在 6 人团队和 300 人组织里的落地方式完全不同。下面我按规模分四档给出建议，每一档都给出“最小可行动作”和“什么时候该升级”。如果你只想拿走一件事，就拿走最小可行动作那一列。

1. 10 人以下：只要一张就绪清单

这个阶段不要引入任何流程化的东西。你需要的是：一份需求就绪清单（六项必填）、一个可见的任务板、每周一次 30 分钟同步。就绪清单是这个规模唯一必须的机制，因为它直接决定了排期的输入质量，而输入质量是所有规模共同的核心问题。

升级信号：当团队里开始出现“我以为你已经做了”这类对话，且每周超过两次，说明信息同步成本已经超过个人记忆能力，该考虑引入轻量的任务追踪工具。

2. 10-50 人：把缓冲和依赖做成规则

这个阶段最关键的两件事：一是把缓冲集中到迭代池并指定一个负责人，二是把跨团队依赖提前一个迭代确认。同时规划容量降到 75% 以下。这个规模不需要复杂的度量体系，但需要一份能查的迭代视图。

升级信号：当依赖条目超过每迭代 15 条，或者出现“两个组抢同一个共享资源”的情况，就需要统一的依赖管理和配额机制。

3. 50-200 人：需要平台化的信息底座

这个区间是排期失真的高发区，因为组织已经大到无法靠人肉同步，但又没大到有专职的 PMO。我的建议是：先把规则定清楚（就绪检查、缓冲集中、变更带成本、依赖前置），再用 PingCode 这类面向中大型企业的平台把规则固化下来。重点看三个能力：需求状态可查询、依赖关系可视化、变更记录结构化。

升级信号：当共享资源（架构组、测试组、数据组）成为跨产品线的固定瓶颈，并且排队时间超过 3 天，说明需要建立配额和优先级仲裁机制，而不只是排期工具。

4. 200 人以上：需要排期的分层与仲裁

这个规模下，单一排期表已经失去意义。你需要的是分层：产品线内部的迭代排期、跨产品线的依赖排期、组织级的资源配额。三层各自有负责人和决策规则，平台的作用是保证三层之间的数据一致。

这个阶段最容易犯的错是试图用一张大表管所有事。我见过一个 300 人组织做过一张覆盖全部团队的甘特图，维护它的两个人全职投入，三个月后彻底废弃，因为任何一次变更都要改几十处关联。

5. 一套可以直接抄走的落地步骤

不管什么规模，落地顺序建议是这五步，不要跳步。跳步最常见的结果是“规则没立就先上工具”，最后工具变成新的混乱源。

1. 定义就绪标准：六项必填（目标用户、要解决的问题、验收标准、设计状态、依赖方、价值假设）。
2. 做一次全量体检：把需求池按“可开工/缺验收/缺设计/缺依赖/缺价值”分类，算出就绪度基线。
3. 设定容量上限：先把规划容量降到 75%，观察两个迭代，再决定是否继续下调。
4. 建立缓冲池：任务估算取 50% 置信度值，差额进池，指定一人管理，迭代过半检查剩余量。
5. 记录变更成本：每次变更必须写挤掉了什么，坚持三个月后统计“需求吞吐弹性”。

下面这份就绪检查清单是我们团队实际在用的配置，你可以直接改成自己团队的字段。它的作用不是"卡人"，而是让"能不能排"变成一个客观问题。

# 需求就绪检查清单（Definition of Ready）
六项全部为 true 才允许进入迭代规划

需求ID: REQ-2024-0317

标题: 批量导入支持字段映射配置

checklist:

target_user: true # 目标用户明确（角色 + 场景）

problem_statement: true # 要解决的问题一句话说清

acceptance_criteria: true # 至少 3 条可验证的验收标准

design_ready: true # 设计稿到可开发状态（含异常态）

dependency_confirmed: true # 所有外部依赖已有书面交付日

value_hypothesis: true # 价值假设（预期指标变化）

任一为 false 时的处理规则

on_incomplete:

action: 退回需求池

reason_required: true # 必须写明缺哪一项

recheck_sla: 3d # 3 个工作日内补齐并重新检查

迭代容量规则

capacity:

planned_ratio: 0.72 # 规划容量占理论容量比例

buffer_owner: "迭代负责人"

buffer_checkpoint: "迭代过半时剩余不低于 50%"

再补一个可以直接跑的统计口径，用来算迭代准时率。这个口径的关键是"按承诺项而不是按任务数"统计，因为任务数会被拆细影响，承诺项不会。

-- 迭代准时率统计（按承诺项口径）
-- committed: 迭代规划时标记为承诺的需求

-- delivered: 迭代结束前达到"可发布"状态的需求

SELECT

sprint_id,

COUNT(*) FILTER (WHERE committed = true)                     AS committed_items,

COUNT(*) FILTER (WHERE committed = true

AND status = 'releasable')                AS delivered_items,

ROUND(

COUNT(*) FILTER (WHERE committed = true

AND status = 'releasable')::numeric

/ NULLIF(COUNT(*) FILTER (WHERE committed = true), 0)

100, 1

)                                                            AS on_time_rate_pct,

COUNT(*) FILTER (WHERE change_type = 'scope_added')          AS scope_added_cnt,

COUNT(*) FILTER (WHERE change_type = 'scope_removed')        AS scope_removed_cnt

FROM sprint_items

WHERE sprint_id = :sprint_id

GROUP BY sprint_id;

七、取舍：不同约束下该放弃什么

排期这件事没有全都要的解法。你几乎一定会在下面四组矛盾里做选择，我能做的是把每组矛盾的代价说清楚，让你知道自己在放弃什么。

1. 取舍一：日期固定还是范围固定

这是最根本的一组。日期固定意味着范围可谈，范围固定意味着日期可谈。真正致命的是两者都想固定，那等于把风险全部转移给团队，最终以质量或人员流失的形式爆发。

我的判断标准是看这件事的"外部承诺强度"。如果是对客户的合同交付、对监管的合规节点，日期必须固定，那就必须在排期时就把范围分层，明确"必做/应做/可做"，并在迭代中途按层砍。如果是内部产品迭代，范围优先级更高，日期应该给区间而不是点。

2. 取舍二：速度还是可预测性

这两个指标经常被当成一回事，但它们会互相拉扯。追求极限速度的团队通常会让流程尽可能轻，代价是交付时间波动大；追求可预测性的团队会增加把关环节，代价是单次交付变慢。

我的经验是：在产品验证期优先速度，在规模化交付期优先可预测性。早期你需要快速试错，波动不是问题；一旦进入多团队协作、有外部承诺，波动本身就变成成本，因为下游无法安排。

3. 取舍三：精细度还是维护成本

排期表可以做到很细，细到每个人每天做什么。但精细度的维护成本是指数上升的：20 个任务的排期表，每周维护 15 分钟；200 个任务的排期表，每周维护 3 小时，而且一旦有人忘记更新，整张表的可信度就崩了。

我的建议是按决策需要决定精细度，而不是按管理愿望。如果某个层级的排期不会被用来做任何决策，就不该维护它。多数团队只需要两层：迭代级的承诺清单（粗）、任务级的执行看板（细但短期）。

4. 取舍四：工具还是规则

这是我在第四章已经提过的判断，这里更明确一点：规则解决"该不该"，工具解决"看得见看不见"。如果团队的判断标准不一致，上工具只会让分歧更快地暴露成冲突；如果标准一致但信息不同步，工具是唯一的解法。

所以顺序永远是：先确认大家认同同一套判断标准（哪怕只有三条），再考虑工具。判断标准不一致时，先开一次会统一标准，比买任何软件都值。

5. 一个我常用的小判断：这个迭代该不该做

最后补一个反向判断。有些迭代本来就不该存在，比如需求全部来自"某人觉得应该做"、没有任何验收标准、也没有明确的用户。这种情况下正确的动作不是"想办法排期"，而是取消这个迭代，把时间用于补需求或做技术债。

我在团队里推行过一个简单规则：如果一次迭代规划会上，超过三分之一的讨论时间用在"这个需求到底要解决什么"，这次规划就应该中止，改为一次需求澄清会。坚持这条规则之后，我们的规划会时长从平均 2.5 小时降到 1.2 小时。

八、总结：排期是一个关于诚实度的系统

写到这里，我想说的核心观点其实只有一句：需求排期与迭代规划，本质上不是技术问题，而是一个关于诚实度的系统设计问题。它要求团队对三件事保持诚实，需求是否真的想清楚了、容量是否真的有那么大、变更是否真的有成本。这三个诚实，任何一个缺失，排期表都会变成一份美好的愿望清单。

我自己最大的转变，是从"想办法把排期做得更准"转向"想办法让不确定性更早暴露"。前者是在优化一张表，后者是在优化一个系统。前者的收益上限很低，因为你无法消除不确定性；后者的收益是可以持续的，因为你能更早看到坏消息，从而有更多选择。

如果你只记住一句话：把力气花在输入端和缓冲结构上，而不是花在估算精度上。我从 62% 爬到 68% 用了两个月，从 68% 爬到 89% 也只用了两个月，区别只是换了发力的地方。

1. 下一步：这周就能做的三件事

不要试图一次性改造整个机制。挑下面三件事里的任意一件，这周就开始做，两周后看数据。

1. 做一次需求池体检：把当前需求按"可开工/缺验收/缺设计/缺依赖/缺价值"五类分开，算出你的就绪度基线。这件事半天能做完，信息量最大。
2. 把规划容量降到 75%：下一个迭代就试，观察交付量是升是降。多数团队会发现交付量不降反升。
3. 给变更加一行成本说明：只加"挤掉了什么"这一栏，不改任何审批流程。三个月后你会得到一份极有说服力的数据。

2. 什么情况下该停下来重新设计

如果你做了上面三件事，两个迭代后准时率没有任何改善，那问题可能不在排期层，而在更上游：需求来源本身就没有决策机制（谁都能提、没人能砍），或者组织没有为取舍授权（产品经理不敢砍需求）。这两种情况下，继续优化排期表是徒劳的。

这时候正确的动作是把问题往上抬一层：先解决"谁有权决定做什么"，再回来解决"怎么排"。我在三个团队里遇到过这种情况，最后发现排期问题的根因都在决策权上。排期是决策的下游，你不能用一张表去补一个缺失的决策机制。

最后提醒一句：所有我在文中给出的数字，都是特定团队、特定阶段的观察记录，你可以把它们当作基准参考和对话起点，但不要直接当成目标值抄进 KPI。每个团队的起点不同，唯一有意义的对比是"你自己上个季度和这个季度"。