2019 年我在一家做跨境电商 SaaS 的公司，团队 9 个人：2 前端、3 后端、1 测试、1 产品、1 设计，我算半个 TL 半个 PM。Sprint 两周一次，Jira 管需求，计划扑克估点，每天上午 10 点站会，Retro 用的是「Keep / Problem / Try」三栏。该有的都有。现在回头看，我们属于那种「敏捷姿势很标准、交付速度很一般」的团队。
真正让我开始怀疑流程的是一次 Retro。8 个人在会议室待了 50 分钟，产出三条 action item：一是「会议室空调太冷」，二是「希望大家站会别迟到」，三是「下个 Sprint 争取把 XX 需求做完」。第三条严格说不叫行动项，叫许愿。散会后我翻了前三个月的 Retro 记录，6 次，去掉重复内容，实际落地的改动 2 条，其中一条是把站会从 10:00 挪到 10:15。
我算了一笔仪式的账，占了 15%
5 个开发 + 1 测试，两周一个 Sprint，我按人时拍了一遍：Planning 2 小时 × 5 人 = 10 人时；每日站会 15 分钟 × 10 天 × 5 人 = 12.5 人时；Refinement 每周 1 小时 × 2 次 × 5 人 = 10 人时；Review 1 小时含外部 3 人 = 6 人时；Retro 1.5 小时 × 5 人 = 7.5 人时。加起来 46 人时。团队两周的有效产能我按每人每天 6 小时算（扣除邮件、答疑、Code Review），是 300 人时。也就是说，光开会就吃掉 15.3%。
这不是说仪式没价值。问题在于这 15% 里有多少在真正改变决策。我们的 Daily 早就变成了轮流汇报，每个人对着 Jira 板念票号；Review 变成了产品经理一个人讲 PPT，其他人低头改 bug。占着 15% 的成本，干着 3% 的活。
Sprint 时间盒，其实是给管理层的一份期权
这是我当时最反直觉的一个想法。表面上 Sprint 保护的是团队，让你两周内不被插需求。但实际上，它把「承诺」这件事切成了很碎的块——每两周你就得重新承诺一次。对管理层来说，这是一种几乎零成本的期权：方向不对，下个 Sprint 换个方向就行，因为「敏捷本来就是拥抱变化」；方向对了，那是决策英明。风险去哪了？全在工程师这一侧。你要每一周都面对「我说了要做完但没做完」的心理压力。
我们团队当时的实际数据：连续 9 个 Sprint，承诺完成率的平均值是 71%，最好的一次 92%，最差 54%。而每次没完成的原因列表里，超过一半写着「需求变更」或「上游接口延迟」。换句话说，我们每两周承诺一次的事情，有一半根本不在自己的控制范围内。那你承诺的是什么呢。
故事点是虚假精度，而且很贵
再聊估算。斐波那契数列 1、2、3、5、8、13、21，看起来科学，其实它制造的是一种「我们量化了不确定性」的错觉。我记得很清楚，有一次评审一个导出功能，两个后端为了它是 5 还是 8 掰了 20 分钟。20 分钟 × 5 个参会人 = 100 分钟 ≈ 1.67 人时，而这个需求本身的实现工作量大概是 8 到 10 人时。也就是说，光争论它的估价，就花掉了需求成本的 17% 到 20%。
更离谱的是速度图。我们的 Velocity 在 32 到 45 点之间摆动，管理层每次看这张图都要问为什么掉下来了。但点的定义团队自己都换过三次——把「1 点 = 半天」改成「1 点 = 理想人天」，又改回去。同一件事的估价能差一倍，那这条曲线的可比性和股票 K 线差不多。
我们改了什么，具体到参数
后来我们把 Sprint 整个拆掉，换成看板，具体改动有这些：1）看板列改为「待做 / 开发中 / 待测试 / 测试中 / 待上线」，WIP 上限：开发中限 4（等于开发人数 - 1），测试中限 3；2）不再估点，改用「这个需求是 S / M / L」粗分，S < 1 天，M 1-3 天，L > 3 天必须拆；3）每天站会保留，但砍到 10 分钟，只回答「有没有被卡住」，不汇报进度；4）每两周一次的 Review 改成每周五下午自愿参加的产品演示，谁做完谁上来演示 5 分钟；5）Retro 从两周一次改成一个月一次，但每次必须产出一条可验证的改动。
跑了一个季度后，我们的需求平均周期时间（从进入「开发中」到上线）从 11.4 天降到 6.8 天。上线需求数量从平均 6.2 个/月变成 9 个/月左右。这两个数字口径不完全一样，别当严谨统计看，但方向的差异是真实的。更重要的是，没人再为「这个 Sprint 有没有完成承诺」焦虑了，因为不存在承诺这个东西，只有一条不断流动的队列。
什么情况下你不该学我们
我想说的不是「看板比 Scrum 好」。我们当时的处境有三个特征，你可以对照一下：一是需求插单率超过 30%（每周新进来的 P0/P1 占到当周总需求的比例）；二是单个需求的平均粒度小于 3 人天，Sprint 这个盒子相对于需求来说太长了；三是对外部依赖（别的团队、第三方 API）的占比超过 40%。这三条里中两条，Sprint 的时间盒大概率就是自欺欺人。
反过来，如果你做的是 to B 交付或者有合同节点的项目，需要给甲方一个可汇报的节拍，那 Sprint 依然有用。只是我现在的看法比较不政治正确：那种场景下，Sprint 的价值主要是对外的，是给汇报和结算用的，跟工程效率关系不大。硬说它是为了「让团队专注」，有点给自己加戏。
写到这我得承认，我对 Scrum 的态度从当年的虔诚变成了现在的怀疑。但我不觉得是 Scrum 错了，是我们把一个为 7 人左右资深团队设计的东西，硬套在了需求高度不稳定、外部依赖一堆的小团队上，然后花了 15% 的工时去维护这个套子的形状。值不值，你自己算算你团队的账。