2.4 敏捷开发：公交化小班次

2.4 敏捷开发：公交化小班次

前面几种线路仍在回答"项目怎么组织"，敏捷把问题换成了"反馈能多快回来"。它把大版本拆成固定节奏的小班次——每班次都交付能跑的增量，让需求理解在短时间内反复校准。本节讲清敏捷的制度内核、仪式清单的真实用途，以及它对团队成熟度常被回避的前提要求。

公交化发车的运行逻辑

2001 年发布的敏捷宣言只有四句价值观：个体与互动 高于 流程与工具；可工作的软件 高于 详尽的文档；客户合作 高于 合同谈判；响应变化 高于 遵循计划。注意措辞——右边不是被否定，只是左边更重要。敏捷反对的不是计划，是用早期计划否认后续学习的价值。

落到运行上，敏捷把交付切成固定长度的小班次（Scrum 里叫 Sprint，通常一至四周），每个班次产出"完成的、可用的"增量，班次节奏雷打不动。班次内滚动三件事：班次计划会定本班拉哪些货；每日站会对齐障碍；班次评审与回顾收尾并调整下一班。角色收敛为三个：产品负责人定优先级、Scrum Master 排流程障碍、开发团队交付。

仪式不是例会表演，每个仪式都在防一类具体事故：

一张班次时刻表：云梯迭代七实录

用云梯平台的迭代七看一个班次怎么转。团队六人，班次十天：

迭代七 · 时刻表（工作日）
  D1 上午   班次计划会：从待办拉入 8 个故事，共 42 点
  D1 下午   拆任务：每个故事拆到 1 天以内的子任务
  D2-D9    每日站会 15 分钟，只说三件事：
           昨天做了什么 · 今天打算做什么 · 有什么挡路
  D3       站会暴露障碍：司机端联调环境不稳定
           Scrum Master 当天协调运维搭桩，未过夜
  D5       班次中点检查：完成 19 点，进度正常
  D8       冻结新拉入：剩下的点不再新增，专注收尾
  D9       班次评审：仓库主管试操作对账报表，提出
           汇总列要支持按仓库分组 —— 记入待办，本班不做
  D10      班次回顾：本班返工 11 点，其中 7 点源于
           验收标准写得含糊 —— 下一班先改验收标准的模板

用户故事示例（验收标准前置）：
  标题：仓库管理员按导出对账单
  作为 仓库管理员，我想 一键导出某月对账单，
  以便 月底与承运商核对。
  验收标准：
    1) 可按仓库与月份两个条件过滤
    2) 导出文件包含运费、补贴、扣罚三列，金额保留两位
    3) 数据量 5 万行以内时导出耗时不超过 30 秒
​

注意这个故事写法的关键：验收标准在开工前就写清。迭代七的回顾发现了什么？返工的大头是验收标准含糊——开发按自己的理解做完，评审时对不上，返做。敏捷缩短的是反馈回路，但回路里跑的仍是人与人的理解对齐，标准越清楚，回路越省油。

敏捷的前提与变质形态

敏捷对小班次节奏有个隐性要求：每个班次末尾真的能拿出可用增量。这背后是自动化测试、持续集成、一键部署这一整套基础设施——没有它们，"班次末交付可用软件"会迅速退化成"班次末演示幻灯片"。这也是为什么 DevOps（下一节）常被称作敏捷的续集：敏捷定了发车间隔，DevOps 修建让间隔成为可能的信号系统。

三种常见变质，见到要能叫出名字：

• 形式敏捷：站会、看板、燃尽图一样不少，但需求变更仍然走月度委员会——班次内的响应速度和瀑布没差别；
• 甲方版瀑布套壳：合同按瀑布条款签，执行方内部跑敏捷，演示与验收错位，双方都累；
• 无纪律的敏捷：把"响应变化高于遵循计划"读成"不用做计划"，班次中途随意插需求，速度掉到无法预测。

⚠️ 判断一个团队是不是真敏捷，别数仪式，看两点：产品负责人是否真有权力当场定优先级；班次末的增量是否真的可部署。两点缺一，其余都是布景。

用速度做预测：一笔诚实的账

班次节奏稳定后，"速度"（每班完成的故事点）就成了预测工具。用它要讲方法：单看最好一班或最差一班都会误导，靠谱的预测用最近三班的区间。云梯迭代四到六的速度分别是 38、45、42 点，下一班按 38 到 45 区间承诺，取 40 点排货并预留浮动——这种"区间承诺"让产品负责人与客户对"什么时候做完哪一批"的对话从吵架变成查表。反过来，速度波动超过两成的班次，先别急着预测，回去查波动来源：是需求中途插入、还是任务拆分颗粒度飘了？速度是体温计，不是油门，踩它不会变快。

多个班组之后：规模化的一瞥

三个以上班组同跑一条产品线时，敏捷要多补一层"班次对齐"：各班同天开班、同天收班，收班当天开一次跨班对齐会——只对三件事，互相依赖的接口、共享资源的冲突、下班的共同风险。更复杂的规模化框架（多团队编排、大范围敏捷）各有仪式体系，选型逻辑与本节一致：先确认基础班次跑得健康，再谈扩编。基础不稳就上规模框架，等于给颠簸的列车加挂更多车厢。

两个高频疑问

问：故事点估不准，敏捷是不是就废了？ 故事点追求的从来不是准，是稳定可比——同一类工作在团队内的一致计量。它的用途是看趋势与容量，不是对外承诺工时。对外要报日期时，用速度区间折算（如上）；对内谈工作量时，用点数比较。两个用途混用一个单位，扯皮就开始了。

问：班次里插急单，接不接？ 先问三句：这单是不是真的必须本班发（还是"越快越好"）；班内哪个已承诺项可以让位（让位而不是硬塞）；让位的影响谁拍板认账。三问都过，产品负责人当班调整班次待办并记录——敏捷响应变化，但响应本身就是一次正式的计划变更，不是悄悄加塞。

本节要点回顾

• 敏捷的核心是固定节奏的小班次，每班交付可用增量，让理解偏差在短周期内收敛。
• 四个仪式各防一类事故：范围失控、障碍延迟、期望漂移、重复踩坑；仪式失效都有典型长相。
• 用户故事的要点是验收标准前置，标准含糊是返工的最大来源。
• 小班次节奏依赖自动化基建，没有基建的敏捷会退化成演示驱动开发。
• 识别真敏捷看两处：产品负责人有实权、增量真可部署。

敏捷定了发车间隔，下一节看让间隔可以兑现的信号系统——DevOps。