我们每天上午十点准时开站会，十五个人围在投影仪前面，轮流对着Jira看板报数。
“昨天把登录模块修了，今天准备改支付接口。”
说这话的时候，没人真的在看代码。后排同事在刷手机，前端妹子的目光穿过天花板，产品经理假装在记录，但我瞥见他的本子上画了个猫。
等所有人报完数，Scrum Master（其实是我们部门经理兼职）拍两下手：“好，就这事，散吧。”
然后大家像逃一样滚回工位。这种站会持续了半年，我们跟彼此的代码互相不认识，但每天都能精准地知道对方昨天干了哪张卡片的活。
有没有人认真听？没有。为什么还要开？因为这是“流程”。
我去翻了敏捷宣言，第一句话是“个体和互动高于流程和工具”。可Scrum给我们的是一整套流程和工具——角色、事件、工件、时间盒。每天站会、Sprint规划会、Sprint评审会、Sprint回顾会，一个都不许少。但个体和互动呢？被塞进了Jira的字段里。
有一次我试着在站会上提了个技术风险，说“支付接口的第三方回调可能有坑”，结果所有人都沉默了。产品经理说：“先放到Sprint backlog里，回头细化。”然后下一个同事接着报“昨天干了什么”。那个风险后来真的在线上炸了，我们花了两个通宵才修好。
Scrum大师们可能会说，那是我们回顾会没开好，没有暴露问题。可回顾会上谁又敢说真话呢？上一回真的有人说了“站会浪费时间”，第二天他的Sprint评分就被打了个折（我们给每个Story估分，但没人承认估分就是为了KPI）。
我们团队名义上有三个角色：Product Owner、Scrum Master、开发团队。实际上产品负责人是个远程的英国老头，一年就来过两次。Scrum Master是行政经理，连什么是优先级都不知道，只会在站会最后喊一句“加油”。开发团队就是十五个工具人。这种组织结构跟敏捷宣言里的“自组织团队”差得不是一点半点。
我私下跟一个老程序员聊过，他说：“敏捷在2001年提出的时候，目的是干掉繁重的文档和流程。可Scrum把这套实践变成了新的繁重流程——不过是换了个名字，站会代替了早会，Sprint代替了立项，评审代替了验收。本质还是一样的控制。”
他说的可能有点极端，但我觉得他讲透了一件事：企业引入Scrum，从来不是为了“响应变化”，而是为了“证明自己在响应变化”。你去看公司官网，写着“我们采用敏捷开发”，客户看着放心，投资人听着开心。至于站会上报的那串数字，只要不被推翻，谁在乎呢。
我们每两周搞一次Sprint评审，把做好的功能演示给老板看。老板其实根本不关心用户，他只看我们“有没有按时交付”。所以演示前，我们会专门做一版“演示专用包”，把出错按钮藏起来，把加载时间改短，把测试数据调成漂亮的样子。这跟敏捷宣言里的“客户合作高于合同谈判”正好相反——我们是在跟客户演戏。
后来我实在憋不住，在一次回顾会说了句：“我们能不能不搞站会，改成每天下午下班前发个邮件？”沉默了几秒钟，项目经理当场反驳：“那不行，领导要看我们在开站会。”
你看，Scrum到这里已经变成了一个景观——一个用来证明“我们在敏捷”的景观。它不是工具，是装饰品。
我不否认Scrum在某些团队里有用。但前提是，团队里真的有人觉得“问题可以浮出水面”，並且有勇气去处理它。而我们这个团队，大家早就学会了闭嘴。因为多说话意味着多做事，多做事意味着下个Sprint被塞进更多故事点。
所以现在的站会，我永远报“昨天解决了一个bug，今天看看有没有新的bug”。听起来很忙，实际上我大部分时间在摸鱼。这是我个人的被动反抗——用虚伪对付虚伪。
我知道这种态度很糟糕。但当一个流程从根上就不尊重人，那我要么离开，要么陪它演下去。我还没想好。
如果让我提一个建议，我会说：砍掉每日站会，把每天下午四点到五点的这段时间留出来，谁有问题就去谁的工位聊，没问题就自己做自己的。或者，如果你非要保留站会，那请让每个真正需要帮助的人有机会说出来，而不是让所有人轮流背诵Jira卡片的编号。
但大概率没人听。所以明天的站会，我还会站在人群里，盯着自己鞋尖上的泥点，安静地等这十五分钟过去。