聊点真东西：敏捷开发方法到底是不是互联网人的安慰剂？

上周跟一个创业公司的技术负责人喝夜啤酒，他拍着桌子骂，说他们公司花大价钱请人做敏捷转型，转了大半年，越转越乱。 天天站会开得跟打卡早朝一样，每个人轮流念台词，遇到真问题都说会后聊，半小时开完啥也没解决。 说白了，学了一肚子流程，没捞着半点好处。

很多人学的敏捷，根本不是真敏捷

现在市面上对敏捷开发方法的误解，真的太深了。 不少管理层眼里，敏捷就是「不用写文档」「不用做规划」「想改就改」，甚至把天天加班改需求叫拥抱变化。 还有些咨询公司，把敏捷包装成包治百病的神药，不管你做什么行业什么项目，上来就先给你套一堆框架、角色、仪式感，收钱走人，剩下一堆烂摊子留给团队自己扛。 你去翻2001年17位技术大佬起草的敏捷宣言，核心就四句话，没有半句提到复杂流程：个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。 说白了，所有的流程都是为交付价值服务的，不是为了走流程而走流程。 很多人搞反了顺序。 错误敏捷开发站会打卡现场照 我见过更扯的，团队一共三个人，做一个小项目，非要照搬十个人规模的敏捷流程，每天站会、每周回顾、每个迭代搞评审，光开例会就要占掉三分之一的工作时间。产出还没原来多，效率反而降了一半。 说实话，这不是敏捷，这是形式主义。

哪些场景，敏捷开发方法才真的能打

方法没有好坏，只有适合不适合。 我敢说，现在百分之九十的互联网ToC产品团队，之所以用敏捷能出成果，核心是踩对了场景。 你做一个面向C端的社交APP，新功能上线之前，你根本没法确定用户会不会买账。你要是用传统瀑布开发，憋半年做一个完美版本出来，推出去发现用户根本不喜欢，那半年时间成本全打了水漂。 敏捷就不一样，先做一个最小可用版本，扔到小范围用户里测，两周一个迭代，根据反馈快速调整，试错成本极低，试对了再放大投入。这太香了。 就连现在最火的AI大模型应用开发，几乎所有团队都在用敏捷开发方法。为什么？大模型技术迭代太快了，今天出一个新的微调框架，明天用户需求变了，你不可能提前三个月把所有需求定死，只能快速试错快速调整。 互联网产品敏捷迭代需求排期看板 不过话说回来，敏捷不是万能药。 你给航天卫星做嵌入式软件，需求错一个参数都要出大事，你能上来就敏捷迭代试错吗？那不是开玩笑吗？ 你给甲方做定制化项目，合同都把需求签死了，交付时间卡死了，你天天跟甲方说我们要敏捷要改需求，甲方不把你尾款扣了才怪。 对吧？适合瀑布的场景，硬套敏捷，纯属自讨苦吃。

落地敏捷避不开的三个坑，踩过都懂

落地敏捷避不开的三个坑，踩过都懂 就算找对了场景，落地的时候也很容易踩坑。我见过太多团队折在这三个地方。 第一个坑，把敏捷变成了无底线加班的挡箭牌。 很多老板觉得，既然拥抱变化，那我想改需求就改需求，今天提的需求明天就要上线，美其名曰我们是敏捷开发，实际上就是把团队当驴使唤。 敏捷从来不是无底线接纳变化，每个迭代的排期都是固定的，加需求就得挤掉其他低优先级需求，这是基本原则，破了这个原则，整个节奏全乱。 第二个坑，彻底废掉架构设计，把代码堆成屎山。 很多人说敏捷就是不需要提前设计，边做边改就完了。结果做了一年，代码耦合得跟乱麻一样，改个小功能牵一发动全身，最后只能整个项目推倒重来。 实际上敏捷反对的是过度提前设计，不是反对设计。正确的做法是先做好核心架构的设计，然后每个迭代做增量设计，跟着需求演化慢慢调整，既不浪费时间做没用的预判，也不会把代码搞成烂摊子。 第三个坑，只改流程不改授权，换汤不换药。 敏捷要求的是自组织团队，团队对自己的交付负责，能自己拍板大部分事。结果很多公司，流程换成敏捷了，决策权还是牢牢抓在高层手里，遇到个事层层审批，一周批不下来，迭代直接卡死。 这种敏捷，除了给团队多添了几个会，啥用没有。 说白了，敏捷从诞生第一天起，核心就是以人为本，把决策权交给听得见炮火的人，把交付价值放在第一位。 现在太多人把它搞成了流程崇拜，全是花架子，没有内核。说白了，能帮你把活干好的方法，就是好方法，别整那些没用的名头。