Scrum的黄昏：当流程成为终极障碍

Scrum是个好东西，直到它成为你每天的负担。2019年我加入某家金融科技公司，团队11个人，每个Sprint两周时间。那时我以为自己在实践敏捷开发，后来回头审视才发现：我们做的只是“每日站立、Sprint评审、回顾”这三个仪式的外壳。真正的产出交付速度，反而比我来之前慢了不少。这件事让我开始思考一个不太讨喜的问题：当Scrum变成流程本身时，它是不是已经背叛了敏捷的初衷？

很多团队正在经历一种奇特的自我消耗。每日站会变成了背诵进度报告，Sprint计划会开了两个半小时只是为了让产品经理觉得大家有一致理解，Sprint回顾变成了吐槽大会但没有人被授权动手改流程。我在那家金融科技公司待了两个月，发现团队的燃尽图几乎永远是平的，Sprint一开始画了一堆故事点，到中期纹丝不动，最后两天疯狂补任务到板子上——因为第二天就是评审会，没人想空着手出现在领导面前。后来我看了Henrik Kniberg的相关分享，再对比自家公司，突然意识到：Scrum原本只是敏捷工具箱里的一个框架，但不知从何时起，它被尊为不可更替的“正确姿势”。很多团队把Scrum的规则当成铁律，把大师们的话当成圣旨，却忽略了Scrum只是通往敏捷的一个手段，不是目的本身。

Scrum原教旨主义者会引述Scrum Guide：框架是轻量级的，容易掌握但难以精通。这是句漂亮话，但实践中，多数团队连“轻量”都做不到。每周要开至少4种会议，每个会议都要有明确产出，再加Grooming、Backlog清理、Sprint切换的准备。一个十人团队，一周花在Scrum仪式上的时间，保守估计也在六到八小时之间。如果团队还处在协作磨合期，这个数字只高不低。对比之下，我在2016年做过一个咨询项目，那家公司的研发团队只有七个人，没有用Scrum，也没有用看板，而是每天早上喝咖啡的十五分钟里口头同步进度。他们的产品更新频率却常年保持在一天一次到两次。没有任何仪式感的流程加持，他们靠着极低的沟通成本和极强的个人责任感，做到了很多Scrum团队做不到的持续交付。这件事让我对“工具决定产出”的说法产生了更深的怀疑。

更重要的是，Scrum对团队规模、产品形态、组织文化都有隐形要求。三四人的小团队去搞标准Scrum，经常是杀鸡用牛刀；上百人的产品线强行套两三个Scrum团队，跨团队协调的成本会让Sprint的意义荡然无存。在那种情形下，Scrum的仪式感成了团队之间互相推卸责任的挡箭牌——因为“Sprint里没排进这个需求”变成了一个万能的理由。我的观点可能会让某些人不满：Scrum在大多数团队的真正价值，可能只是提供了一个让管理者安心的“可视化交付承诺”。它的节奏感、透明性和仪式感，更多是在安抚组织上层，而不是在真正解决问题。真正解决问题的是具体的人、具体的技术、具体的代码习惯、具体的用户体验循环。而这些，没有一个Scrum会议可以替你完成。

我没有否定Scrum的意思。它确实是很多团队走向敏捷的有效起点。但起点不等于终点。那些把Scrum做成宗教的组织，最终都会发现：流程的产出堆积起来，比代码的死代码还要难清理。如果你正在一个Scrum团队里感到窒息，你或许不应该更努力地拥抱Scrum，而应该开始思考，你们的团队到底需要的是什么样的协作方式。这问题和Scrum无关，但它比任何Scrum的细节都更重要。