被神化也被污名化的敏捷开发方法，到底适合谁用？
我上个月跟一个创业公司的技术负责人吃饭，他拍着桌子吐槽，说全公司搞敏捷搞了大半年，最后变成了天天站会打卡，进度反而比以前慢了30%。
另一个在大厂做ToB产品的朋友，情况完全相反。原来他们半年发一次版，改需求改到团队集体离职，上了敏捷之后，两个月就把核心功能跑通，客户满意度翻了一倍。
同一个方法，怎么会差这么多？
传统瀑布开发与敏捷开发流程对比图
说实话，我见过最多的坑，就是把敏捷搞成了形式主义。很多公司学了个皮毛，要求每天开15分钟站会，两周一个迭代，要写故事点，要开评审会回顾会，一套流程走下来，没人记得为什么要这么做。
敏捷宣言的核心从来不是流程，是四个价值：个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。
你看，核心是响应变化，不是走流程。10个人的团队站会开20分钟，每个人汇报完，本来写代码的思路都断了，这叫哪门子敏捷？这就是给领导看的打卡活动。
互联网团队Scrum敏捷开发站会现场图
说白了，不同的敏捷变体对应不同的场景，没有最好的，只有最合适的。
比如说，你是三五个人的小创业团队，做的产品需求变化快，那用轻量版Scrum就够了：两周一个迭代，每天站会控制在5分钟以内，说完就散，别搞那么多仪式。
如果你是持续接需求的业务团队、运维团队，需求排期不稳定，那看板方法就够了，核心就是限制在制品数量，同一个时间只做3个以内的需求，做完一个再下一个，避免所有人都手忙脚乱，哪个都做不完。很多团队把看板做成了墙上的便利贴展示板，该同时开十个需求还是开十个，那根本没摸到看板的门槛。
至于SAFe，那是给千人以上的大型复杂产品团队用的，十几个人几十个人的团队凑什么热闹？
哦对了，现在还有什么敏捷营销、敏捷HR，什么领域都要蹭一把敏捷的热度，我只能说，大部分都是换个皮搞KPI，本质就是折腾人。
怎么判断你的团队是不是在搞假敏捷？
三个很简单的判断标准，一对照就清楚。
第一，是不是把流程仪式放在比产出更高的位置？
要是你的团队每天必须准点开站会，不管手头有没有紧急事，不管有没有东西要说，不开就算违规，迭代结束必须写满多少页文档，改进项必须列够十条，转头就没人跟进，那不用怀疑，百分百假敏捷。敏捷的目的是做出好用的产品，不是走流程给别人看。
第二，是不是还是靠领导拍板压进度，根本没给团队自主权？
敏捷讲究自组织团队，就是谁干活谁拍板，一个迭代能做多少需求，团队自己说了算。很多公司搞敏捷，还是产品经理或者老板硬塞需求，一个迭代塞进去两倍的工作量，完不成就加班，这就是换了个名字的压榨，跟敏捷半毛钱关系都没有。
第三，是不是从来不调整方向，做完一整个版本才上线？
敏捷的核心是快速反馈，你做出来最小可用版本，就要尽快丢给用户用，拿了反馈马上改，要是你拆分了迭代，还是要攒完所有功能再上线，那拆分迭代有什么用？还不如用瀑布省事儿。
我之前接触过一个做素质教育的创业团队，最早老板要求憋一年做完整APP上线，做了八个月，发现赛道变了，原来的定位完全没人买账，几百万打了水漂。后来他们改了敏捷，两周一个迭代，每轮迭代完就放给几百个种子用户测试，一个月就把核心的上课功能跑通，三个月调整了三次定位，最后做出来的产品正好踩中了风口，第二年就拿到了下一轮融资。
不过话说回来，敏捷真不是万能的。你要是做心脏起搏器的控制软件，做火箭的飞行控制系统，需求不能错半分，那你老老实实搞瀑布，搞严格的流程验证，别瞎碰敏捷，那是拿生命开玩笑。
现在行业里就喜欢把简单的概念搞复杂，好割韭菜，敏捷就是重灾区。很多敏捷教练过来，先给你讲一堆听不懂的术语，收几百万服务费，最后给你整一堆复杂流程，把好好的团队搞僵。
说白了，敏捷开发方法的核心，就是小步快跑，快速试错，别憋大招，错了赶紧改，就这么简单。
你要是能做到这一点，哪怕你不开站会，不做看板，你也是真敏捷。要是做不到，你把所有流程都走一遍，也是假的。
对吧？
敏捷开发不是“赶进度神器”，是“应对不确定性的工具”
很多人对敏捷的第一印象，就是“快”，老板们最喜欢说，我们要敏捷，快点把产品做出来上线。 这完全是误解。 早几十年，软件开发主流用的是瀑布开发，所有需求提前敲定，一步一步走：需求分析→方案设计→代码开发→测试上线，走完一步才能走下一步。这套方法对需求稳定、不能出错的项目非常好用，比如航天飞行控制软件、医疗植入设备的系统，到现在都在用。 但放到现在的互联网行业，大部分项目从一开始就没人知道最终需求是什么。你做一个新的社交APP，做出来才发现用户不喜欢这个功能，要改，要是按瀑布来，等你做完全部再上线，风口早就没了，钱也烧完了。 敏捷开发就是为了应对这种情况出现的。传统瀑布开发与敏捷开发流程对比图
说实话，我见过最多的坑，就是把敏捷搞成了形式主义。很多公司学了个皮毛，要求每天开15分钟站会，两周一个迭代，要写故事点，要开评审会回顾会，一套流程走下来，没人记得为什么要这么做。
敏捷宣言的核心从来不是流程，是四个价值：个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。
你看，核心是响应变化，不是走流程。10个人的团队站会开20分钟，每个人汇报完，本来写代码的思路都断了，这叫哪门子敏捷？这就是给领导看的打卡活动。
现在流行的敏捷变体，真的适合你的团队吗？
现在圈子里的敏捷花样多了去了：Scrum、看板方法、极限编程、SAFe规模化敏捷，还有人把敏捷和DevOps、OKR绑在一起卖，一套咨询下来几十万。 很多团队不管自身情况，上来就套最流行的框架。我见过一个12个人的创业团队，老板听了咨询课，非要搞SAFe规模化敏捷，全公司按流程走，一半的时间花在开各种会上，最后核心产品拖了三个月才出来。互联网团队Scrum敏捷开发站会现场图
说白了，不同的敏捷变体对应不同的场景，没有最好的，只有最合适的。
比如说，你是三五个人的小创业团队，做的产品需求变化快，那用轻量版Scrum就够了：两周一个迭代，每天站会控制在5分钟以内，说完就散，别搞那么多仪式。
如果你是持续接需求的业务团队、运维团队，需求排期不稳定，那看板方法就够了，核心就是限制在制品数量，同一个时间只做3个以内的需求，做完一个再下一个，避免所有人都手忙脚乱，哪个都做不完。很多团队把看板做成了墙上的便利贴展示板，该同时开十个需求还是开十个，那根本没摸到看板的门槛。
至于SAFe，那是给千人以上的大型复杂产品团队用的，十几个人几十个人的团队凑什么热闹？
哦对了，现在还有什么敏捷营销、敏捷HR，什么领域都要蹭一把敏捷的热度，我只能说，大部分都是换个皮搞KPI，本质就是折腾人。
怎么判断你的团队是不是在搞假敏捷？
怎么判断你的团队是不是在搞假敏捷？
三个很简单的判断标准，一对照就清楚。
第一，是不是把流程仪式放在比产出更高的位置？
要是你的团队每天必须准点开站会，不管手头有没有紧急事，不管有没有东西要说，不开就算违规，迭代结束必须写满多少页文档，改进项必须列够十条，转头就没人跟进，那不用怀疑，百分百假敏捷。敏捷的目的是做出好用的产品，不是走流程给别人看。
第二，是不是还是靠领导拍板压进度，根本没给团队自主权？
敏捷讲究自组织团队，就是谁干活谁拍板，一个迭代能做多少需求，团队自己说了算。很多公司搞敏捷，还是产品经理或者老板硬塞需求，一个迭代塞进去两倍的工作量，完不成就加班，这就是换了个名字的压榨，跟敏捷半毛钱关系都没有。
第三，是不是从来不调整方向，做完一整个版本才上线？
敏捷的核心是快速反馈，你做出来最小可用版本，就要尽快丢给用户用，拿了反馈马上改，要是你拆分了迭代，还是要攒完所有功能再上线，那拆分迭代有什么用？还不如用瀑布省事儿。
我之前接触过一个做素质教育的创业团队，最早老板要求憋一年做完整APP上线，做了八个月，发现赛道变了，原来的定位完全没人买账，几百万打了水漂。后来他们改了敏捷，两周一个迭代，每轮迭代完就放给几百个种子用户测试，一个月就把核心的上课功能跑通，三个月调整了三次定位，最后做出来的产品正好踩中了风口，第二年就拿到了下一轮融资。
不过话说回来，敏捷真不是万能的。你要是做心脏起搏器的控制软件，做火箭的飞行控制系统，需求不能错半分，那你老老实实搞瀑布，搞严格的流程验证，别瞎碰敏捷，那是拿生命开玩笑。
现在行业里就喜欢把简单的概念搞复杂，好割韭菜，敏捷就是重灾区。很多敏捷教练过来，先给你讲一堆听不懂的术语，收几百万服务费，最后给你整一堆复杂流程，把好好的团队搞僵。
说白了，敏捷开发方法的核心，就是小步快跑，快速试错，别憋大招，错了赶紧改，就这么简单。
你要是能做到这一点，哪怕你不开站会，不做看板，你也是真敏捷。要是做不到，你把所有流程都走一遍，也是假的。
对吧？