# 为何谷歌之类大厂程序员认为敏捷开发是瞎扯淡？

By [Tashia](https://paragraph.com/@tashia) · 2021-12-21

---

敏捷开发不是扯淡，但适用范围比较有限，而且很容易被用坏

我在Amazon和Microsoft的多个不同的部门工作过，其中只有一个部门对agile的用法我认为是比较成功的，而且是有效率的。国内我暂时没有发言权，但我想应该不会比这个更好

那个组用的是类似kanban的模式，大致有如下特点：

不设置整个项目的deadline，不设scrum周期

没有固定的backlog grooming，sprint planning和retro会议（由组里大佬在线下完成，当然一般会和这个module/feature的负责人讨论），每个人自己有一个backlog

每个任务没有estimate，每个人如果做完当前任务，第二天自动去领自己backlog里的下一个任务来做（对，如果当天提前做完，可以直接划水），否则就继续做当前没做完的任务

每天standup只解决一件事，有没有被block，有的话如何unblock（因为你现在做到哪个任务在scrum board都一眼可见）

最后我们整个项目比预计提前了一个月完成，效果非常好，上线3个月，零sev-2

这种模式唯一的缺点就是，需要有一个非常牛逼，软硬实力俱佳的大佬带着整个项目团队，所以极难推广。即便Amazon和Microsoft这种大厂，这种人至少也是千里挑一，可能一个VP下面顶多有一两个，对于普通程序员来说，参与进这种大佬带的项目的机会本就不多，所以很多人对于agile的理解也就仅限于自己组里那个既繁琐又残疾，为了agile而agile的诡异模式

至少我经历过的其他的部门，无一例外都陷入了下列几种情况之一（或者不止）：

一切从demo出发，demo频率过高

随意修改sprint定好的计划

无视任务复杂度，强行压缩时间

retro提出的问题不去解决，导致同样问题重复出现

重feature轻operation，tech debt从不处理或极少处理

scrum相关会议太多且时间太长

我个人认为，一个团队的scrum想要运转良好，需要两个条件，缺一不可——

一是scrum master具备充分的知识和经验，知道怎么根据组里的人员构成，项目特点等因素选择合适的scrum模式

二是老板自己需要理解并认同agile的内涵，而不是简单地认为agile = rush或者agile = infinite flexibility

然而实际操作中，大部分团队二者都不具备，所以你懂的

---

*Originally published on [Tashia](https://paragraph.com/@tashia/jttKtQteL71YmM0LeJGv)*