2.2 迭代与增量：区间接续发车

2.2 迭代与增量：区间接续发车

瀑布的直达票反馈太慢，于是有了切段跑法。但"迭代"与"增量"这两个词在会议室里常年被混用，排期时张冠李戴的代价不小。本节先把这两个词掰开，再看切段之后时刻表怎么排、汇总什么时候做，以及切段跑法自己的新毛病。

先把两个混用的词掰开

增量是按功能切块：先交付能用的最小集合，再一块块往上加。好比货运列车分批发运——第一批先送生活物资，第二批补生产资料，每批都是完整可用的货物，客户从第一批起就有东西用。增量回答的问题是"先做哪些功能"。

迭代是按时间切片：每轮都把需求、设计、编码、测试整条线走一遍，产出对需求理解更准的一版，哪怕这版还上不了线。好比列车试运行——每绕圈跑一趟，都对线路和操作的理解校准一次。迭代回答的问题是"每轮把理解推进多少"。

两者可以被同一个项目同时使用：按增量切功能块，块内按迭代推进认知。敏捷（下一节）就是两者叠加的制度化产物。

图 2-1：增量与迭代的切段方式对比

排期怎么排：一个可复算的例子

切段跑法把"总工期"变成"段长 × 段数 + 汇总成本"。排期时最常犯的错是只算前一半。下面用云梯平台的真实排期记录演示：

[演算] 云梯结算平台 · 切段排期

任务：计费核心、对账报表、司机端、仓库端 四个增量批次。

各批开发估算：计费 15 人日 · 报表 10 人日 · 司机端 12 人日 · 仓库端 12 人日
  开发合计 = 49 人日

切段新增成本（瀑布没有的部分）：
  每批联挂整备（接口回归 + 集成验证）= 2 人日 × 4 批 = 8 人日
  末批全量回归 = 3 人日
  新增合计 = 11 人日（约占总估算 22%）

结论：
  排期写 49 人日 + 11 人日 = 60 人日，而不是 49 人日。
  跳过联挂的排期看似省 18%，实际会在末批全量回归时
  以缺陷风暴的形式连本带利还回来。
​

这组数字传递的信息很朴素：切段的自由不是白拿的，汇报时要把"联挂整备"当成和写代码同级的正经工作量报出去，否则它一定会以事故形式现身。

切段跑法的新毛病

切段解决了反馈太晚，也带来了瀑布没有的问题：

• 架构漂移：每批各走各的，公共代码各自复制，几批之后对不上。对策是先花一小段做架构基线（接口、目录约定、公共组件），并坚持每批联挂；
• 集成推迟症："先各做各的，最后再集成"——这等于把瀑布的集成大爆炸原样保留。集成要按批进行，不能攒；
• 回归负担上升：每叠一批，历史功能的验证面就大一圈，没有自动化回归的团队会在这里被拖垮。这也是第 6 章自动化检测线存在的原因。

⚠️ 迭代还有一个体面话术级别的坑：把迭代当"分期交付的瀑布"。表面每两周一个迭代，实际需求、设计、开发、测试在迭代内还是串行接力，测试总在最后一两天——这叫瀑布套壳，反馈并没有真的提前。判断方法很简单：看测试是不是从迭代第一天就开始跑。

批次切多大：一笔权衡账

切段粒度本身也是笔账。批次切太大，反馈变慢，逼近瀑布的老毛病；切太小，联挂与回归的固定开销占比飙升。一个粗略的权衡演算：设每批的联挂整备成本固定为两个人日，批切得越小批数越多，整备总额线性上涨；批切得大，单批内的理解偏差返工按批的规模超线性增长。云梯试过两种极端——首批按功能点切成八个迷你批，联挂吃掉两成人日；后来归并为四个批次，联挂占比回落到约一成八，且每批仍小到两周能验收。经验值是让单批工作量落在团队一两个迭代能消化的区间，再用首批的实际联挂数据校正。

排错的三个现场

切段跑法的现场问题多而具体，挑三个高频的给处置：其一，第二批发现第一批的接口设计不够用——这是常态而非事故，处置是走变更闸口改契约、同步更新第一批的回归用例，而不是在第二批里偷偷绕接口直连；其二，两批并行改同一个公共模块，合并天天冲突——说明模块边界没跟上切分，先把公共模块的归属定下来（归先发批或单拎出来），再继续并行；其三，客户只想等全部完工一次验收——那是商务问题不是工程问题，别在工程侧硬掰，可谈"内部按批验收、对外按合同交付"的双轨记录。

两个高频疑问

问：迭代和增量必须二选一吗？ 不是，而且多数成熟团队是叠加使用：增量定"交付什么批次"，迭代定"每批内部怎么推进认知"。真正要避免的是只取其形——把迭代当成"分期"，把增量当成"攒到最后一起上"，两种都退化回瀑布。

问：需求不稳定的项目适合切段吗？ 恰恰最合适，但要在切段前先立架构基线——需求不稳时变的常是表层功能，底层的领域模型与接口契约越稳，批次的排列组合就越自由。基线先行，之后每一批的需求变化都在既有结构上安置，而不是推倒重画。

批次之间的依赖：先画再跑

切段之后还有一张隐性地图值得先画：批次依赖图。哪些批可以并行、哪些批必须串行、哪些批共享数据结构，画在一张图上，排班立刻从"感觉都行"变成"看得见的顺序"。云梯的四个批次里，对账报表依赖计费核心的数据结构，司机端只依赖接口契约——于是计费与司机端并行，报表顺延，总工期反而比四批全串行短了近三分之一。依赖图还要标注共享点：两批同时要动的那张表、那份配置，就是合并冲突的预定爆发点，提前约定归属与合并顺序，冲突就从惊吓变成日程。切段是放大器——放大反馈，也放大无序；图先画好，放大的才都是好东西。

验收前移：每批都要有"收货人"

切段跑法还有一个常被忽略的杠杆：让每批都有明确的收货人。批一交付时，请仓库主管实际操作并对账签字，而不是攒到项目末尾一起验收。收货人前移的好处是双向的——团队在第二批就能听到第一批的真实使用反馈，纠偏发生在还便宜的时候；客户则因为持续见到可用的东西，焦虑与变更冲动同步下降。云梯的对比很鲜明：无收货人的批次，交付后返工请求平均要等一个多月才集中爆发；有收货人的批次，反馈在交付当周就到，且大多是能让下一批立刻受益的细节。验收不是终点的仪式，是每一批的交接棒。

本节要点回顾

• 增量按功能分批、每批可用；迭代按轮次推进、每轮校准认知，两者常叠加使用。
• 切段引入新增成本：联挂整备与全量回归要写进排期，占比可达两成。
• 架构基线是增量的安全带，先立约定再分批，防止各批漂移。
• 集成必须按批进行，攒到最后等于把瀑布的集成大爆炸带回来。
• 瀑布套壳的识别标志：测试不在段首开跑，而是堆在段尾。

切段之后每段怎么防风险、怎么验证，下一节的两种"带检修坑位"的线路各有绝活。