敏捷开发方法：别把"敏捷"玩成了形式主义

我见过太多喊着“做敏捷”的团队，最后把敏捷做成了一场大型行为艺术。 每天15分钟站会，两周一次迭代，墙上贴满了便利贴，看起来热热闹闹。 一问产出，还是天天加班，需求改来改去，最后做出来的东西用户根本不要。 这哪是敏捷，这是给老板表演敏捷。

敏捷开发方法诞生，本来就是来反不靠谱的流程的

在上个世纪90年代，软件行业主流还是瀑布开发。什么是瀑布？需求、设计、编码、测试、上线，一步一步走，走完一步才能走下一步，像瀑布往下流，回不了头。 我之前待过的外包公司，做一个国企的内部管理系统，光需求文档就写了三百多页，前后评审了三个月，做了整整一年才上线，结果上线的时候原来对接的项目负责人都离职半年了，人家新负责人说，需求早就变了，你们这做的东西根本没法用，全部推倒重来，那叫一个欲哭无泪。 这种事，瀑布开发里太常见了。 传统瀑布与敏捷开发流程对比图 一帮忍不了这种无效劳动的程序员，凑在一起搞出了敏捷宣言，说白了就是四个字：拥抱变化。 说实话，百分之九十喊着做敏捷的公司，根本没翻过那薄薄一页敏捷宣言。 他们只看到了“每日站会”“迭代”“sprint”这些名词，拿走套到自己原来的流程上，就说自己转型成功了。 敏捷的四个核心价值观：个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。 看到没，第一个就是，个体比流程重要。结果好多公司搞成了，流程比命重要，站会必须卡15分钟，少一分钟都不行，晚开一秒都算你违纪。这完全搞反了。

真正能用好的敏捷开发方法，核心抓三点就够

别整那些复杂的框架，什么SAFe，什么Scrum of Scrums，大部分中小团队根本用不上。抓好三个核心，敏捷就能帮你少走弯路。 第一点，小步快跑，永远不要想着一口吃成胖子。 现在不管是To C还是To B，用户需求哪有一成不变的？你憋着半年做一个大版本，出来之后市场早就变了，所有投入全打水漂。敏捷要求把大需求拆成一个个两到四周就能做完的小版本，先把能用的版本扔给用户，拿到反馈再改。 比如现在很多互联网公司做新功能，先做个只有核心逻辑的版本，给几千个种子用户用，好用再扩量，不好直接砍掉，试错成本极低。 第二点，让团队自己说了算，别什么都要领导拍板。 原来的开发模式，领导定需求，定工期，开发只管做，完不成就是开发能力不行。敏捷不一样，需求有优先级，但是一个迭代能做多少东西，是开发团队自己估算自己承诺的。 我之前认识一个电商团队，原来领导定每个迭代要做八个需求，开发天天加班到十点，还是完不成，bug一堆。后来改成让团队自己估，每次只接四个需求，做完做好，按时交付，bug少了一半，大家还不用天天加班，产出比原来还高。 第三点，持续改自己，没有完美的流程。 每个迭代结束，抽一个小时做回顾，这个迭代哪里出问题了？需求排多了？沟通不顺畅？还是哪里流程卡了？马上调整，下一个迭代就改。 没有放之四海而皆准的敏捷流程，适合你团队的，就是最好的。 敏捷开发双周迭代工作流程示意图

敏捷不是万能药，别什么项目都往上套

敏捷不是万能药，别什么项目都往上套 不过话说回来，我最烦那些把敏捷吹上天的人，好像不用敏捷就是落伍，就是落后。 不对。敏捷适合需求变化快，需要快速试错的项目，比如互联网新产品创业，比如To C的APP功能迭代，这些用敏捷太香了。 但是你要是做航天飞船的控制软件，做医院的核心诊疗系统，需求是不能随便变的，每一步都要精准可控，那还是老老实实用瀑布，稳比快重要。 现在还有个好玩的趋势，AI代码生成普及之后，敏捷反而越来越吃香了。原来改一个需求，前端后端加测试要折腾三天，现在AI帮你写大部分代码，一天就能改完出版本，更快试错，刚好契合敏捷的思路。 去年Stack Overflow的开发者调查，超过60%的活跃开发团队，已经在使用周期小于4周的敏捷迭代，这个比例比2019年翻了一倍还多。 看得出来，大家用脚投票，确实好用才会越来越多人用。 我见过最舒服的敏捷团队，是杭州一个十几人的小创业团队，做宠物用品的私域系统，他们没有复杂的认证，没有一堆流程文档，每天站会十分钟就说完，两周上线一次，看完数据马上调，团队平均下班时间是六点半，一年做出来的东西，比隔壁甲方几十人的团队做的还好用。 这才是敏捷本来该有的样子。 敏捷开发方法，本质是帮你减少浪费，把时间花在真正有用的事情上，不是帮老板装点门面，更不是用来卡员工KPI的工具。 别把经念歪了。