去年十一月，我去看一个零售中台团队的迭代评审。会议室坐了十二个人，投屏上是 Jira 看板，Doing 列躺着四十多张卡，其中三张的停留时间已经超过 11 天。站会倒是标准得很，早上九点四十，一圈下来不到十五分钟，谁也不多说一句。
Velocity 也漂亮，连续八个迭代都在 30 到 34 点之间，折线画出来跟用尺子量过一样。
评审结束我问了一句：线上最近一次发版是什么时候？PO 愣了一下，说双十一前发过一次，下一次大概排到春节后。
那一刻我大概明白，这个团队的问题不在于敏捷做得不够好，而在于一件事——工程侧的钟和组织侧的钟，根本不是一个转速。他们按周优化，公司按季度拍板。
先说一个很多人没留意的变化
现在大家嘴里的敏捷，和 2001 年 2 月犹他州 Snowbird 那 17 个人签的东西，早不是一回事了。2020 年 11 月 Scrum Guide 改版，删掉了“自组织”（self-organizing），换成“自管理”（self-managing）；“角色”这个词被拿掉，改成 accountabilities；“Dev Team”也砍了，统一叫 Developers。这几处改动看着像文字游戏，潜台词其实挺直白：原来那套假设——团队自己知道该拆什么活、该找谁对话——在大多数公司里从来没成立过。既然没成立，指南就退一步，把“自管理”写成一个需要达成的状态，而不是默认前提。可惜很多培训还在照着 2017 年以前的版本讲。
故事点已经被翻译坏了
Ron Jeffries 是 story point 最早的提出者之一。2019 年他写了篇《Story Points Revisited》，大意是自己现在不再用故事点，而且觉得它在不少场景里弊大于利。原因不复杂：故事点从设计上就是相对值，是拿“这个比那个大两倍”做比较。可一旦它进了 Excel、进了燃尽图、进了季度汇报，有人把 34 点除以 10 天，算出“1 点等于 0.29 天”，相对估算就死了。剩下的只是一个更麻烦的甘特图，还附带一套心理负担——3 点的卡不能改成 5 点，改了显得效率下降。
我见过一个团队，评估一个需求到底是 5 点还是 8 点，能吵四十分钟。同一时间够他们把接口写完一半了。
算一笔很土的账
双周迭代到底给了团队多少净写代码时间？
10 个工作日打底。Sprint Planning 半天，Review 加 Retro 半天，再留一天缓冲，光会议就 1.8 天。每天站会 15 分钟，10 天加起来 2.5 小时，约 0.3 天，就算在上面那笔里。剩 8 天上下。如果维护、答疑、处理线上告警占掉三成，只剩 5.6 天做新功能。再扣代码评审、等 CI 排队、联调、环境问题——真正能静下来写业务逻辑的时间，往往只有 3 天出头。
10 天的迭代，净产出 3 天。这不是团队不努力。这是批量太大、切换太频繁。
有意思的是，还是这批人，切到看板以后，把“两周必须交付一个增量”改成“控制在做卡片不超过 4 张”，前置时间反而从平均 17 天掉到 9 天。原因挺朴素：维护需求和功能需求混在同一条流水线上，功能卡被反复打断，每断一次就丢一次上下文，而重建上下文的成本远比大多数人估得高。
真正的瓶颈，一般不在工程师手上
我见过太多公司，左边团队在跑双周迭代，右边十几个流程按另一个节奏走：年度预算编制、采购下单、安全评审、变更窗口、财务关账。你让工程师三天做完一个功能，只要变更审批委员会一周只开一次会，交付周期就锁死在 7 天以上。你让团队一周发一次版，只要采购流程三个月走完，换一个数据库就得等一个季度。
DORA 的四项指标——部署频率、变更前置时间、变更失败率、恢复服务时间——之所以比 velocity 有用，是因为其中两项盯的是组织的手速，不是团队的手速。可惜很多公司只把前两项拿去考核开发组，后面两项压根没人看。这几年的 DORA 报告里，能同时把四项都做好的团队一直是少数，而那个比例并没有因为大家更会写敏捷故事就变高。
那到底能做什么
第一条，把变更审批从“开会评审”改成“自动门禁”。 单元测试覆盖率、静态扫描结果、灰度比例、回滚脚本能不能跑通——这些东西用流水线卡就行，不用人卡。这条落下去前置时间通常能砍一半，因为等待排会的时间往往才是大头。
第二条，别用同一个节奏管“发现”和“交付”。 一个还没想清楚的需求，硬塞进双周迭代，只会把整条线拖慢。给它两周做探针，做技术验证、做用户访谈，不承诺产出。想清楚了再进交付队列。
第三条，把 velocity 从汇报里拿掉。 它一旦变成 KPI，团队三个月内就会学会怎么把它做大。换成前置时间和部署频率这两个数，它们撒谎的空间小得多。顺带一句，2012 年 Kniberg 和 Ivarsson 写的那个 Spotify 模型，本来就是一份快照，Spotify 自己后来说过它不是可以照抄的模板，别再拿它当组织改造蓝图了。
第四条，让 PO 或 EM 去撬组织时钟。 预算能不能按季度滚动？采购能不能给小额度开绿色通道？合规评审能不能前置到设计阶段？这些听着不像敏捷教练的活，但它们对交付周期的影响，通常比把站会从 15 分钟压到 10 分钟大得多。
后来
那个零售团队最后把月度发版改成了每周一次，前置时间从 90 天掉到 11 天。但他们年底做预算还是按年批的，明年要上的那个新模块，钱到三月才下来。
所以到现在我心里还有个没解决的问题：如果组织不愿意动自己那只钟，工程侧再怎么细抠，天花板是不是就锁死在那儿了。我没答案。