说实话，我们团队从2019年开始搞Scrum，当时公司刚拿到A轮，20个人，开发占12个。我作为技术负责人，被一个从大厂出来的产品经理忽悠，说Scrum能让我们“敏捷”起来。于是我们请了个外部敏捷教练，花了3万块培训了两天，买了Jira，定了2周一个Sprint。刚开始大家还挺新鲜，每天站着开会，每人说昨天干了啥今天干啥。但没过两个月，问题就来了。产品经理经常在Sprint中间插需求，说“这个很急，客户等着要”。结果我们Sprint目标经常完不成，Jira上的故事点估算越来越不准，团队开始互相甩锅。
我算过一笔账：一个Sprint 10个工作日，每天8小时，总共80小时。我们花在会议上的时间：Sprint计划会4小时，每日站会15分钟但经常拖到30分钟，算下来10天就是5小时，评审会2小时，回顾会2小时。加起来13小时，占16%。但实际上，因为站会拖堂、计划会经常超时，还有各种临时同步，我估计超过25%。更扯的是，Sprint中间插入的需求平均占每个Sprint总任务的40%。也就是说，我们计划了100个点，结果有40个点是计划外的。那还计划个啥？我们试过把Sprint缩短到1周，结果计划会变成每周4小时，团队直接炸了，说“我们是来写代码的，不是来开会的”。后来我们又试过取消每日站会，改成每周一次，但信息同步又跟不上。折腾了三年，换了4个Scrum Master，其中一个还是全职的，结果他每天就是整理Jira、催进度、组织会议，没写一行代码。团队效率没提升，反而因为会议太多，晚上加班越来越多。
2022年6月，我们一个关键项目延期了2个月，客户直接解约，损失了大概80万。老板拍桌子说“别再搞什么Scrum了”。于是我们开始转向看板。具体做法：取消Sprint，改成连续流。我们设了WIP限制，一开始每人最多3个进行中任务，结果发现还是太多，因为大家习惯性多任务。后来降到2个，再后来对于关键开发降到1.5个（就是有的任务可以两个人一起做，但总数控制）。每日站会改成每周一、三、五的15分钟，而且必须站着开，谁坐下就罚10块钱买奶茶。我们还搞了个物理看板，贴便利贴，Jira只用来记录。每周五下午花30分钟清理看板，把卡住的活儿讨论一下。效果挺明显的：交付周期从平均14天降到了6天，缺陷率下降了30%左右。2023年第一季度，我们交付了12个功能，而2022年同期只有7个。但看板也不是没问题，没有固定节奏，团队容易松散，有时候一周都没更新看板。所以后来我们混合了一下：日常用看板，但保留每月一次的计划会和回顾会，各2小时。
现在回过头看，Scrum不是不好，而是它假设你的需求相对稳定，团队自组织能力成熟。但大部分创业公司，尤其是做To C产品的，需求天天变，老板一句话就得改。这种环境下，Scrum的那些仪式——计划会、评审会、回顾会——反而成了负担。我个人的独立观点：Scrum Master这个角色，在20人以下的团队里，如果不是全职且真的懂技术，基本就是浪费。我们那个全职Scrum Master，月薪2万5，干了一年，没产生任何实际价值。后来取消，由Tech Lead兼任，反而更高效。还有，别信那些敏捷大师说的“Scrum适合所有团队”，他们没在你团队里干过。如果你团队Sprint目标达成率低于60%，赶紧换，别硬撑。我们当时就是硬撑了三年，浪费了太多时间。当然，如果你的团队是做企业软件，需求稳定，版本发布有固定节奏，Scrum可能合适。但如果你是做互联网产品，我劝你先试3个月看板，实在不行再考虑Scrum。反正我们是不回去了。
