敏捷开发方法：为什么很多团队用了还是一地鸡毛？
前阵子跟一个创业公司的技术负责人吃饭，他吐槽了三个小时，说公司花大价钱请了敏捷顾问，搞了大半年敏捷，现在团队效率反而更低了。
每天早会站会，午会评审，晚会回顾，一周一半时间在开敏捷会，真正写代码的时间不到一半。上线的需求还经常错，客户骂完老板骂，最后老板说你们敏捷搞得不对，要继续优化流程。
这种事儿，我听过太多了。
敏捷开发四核心价值原文截图
核心四句话，第一句就是个体和互动高于流程和工具。
说白了，敏捷从根上就是反僵化的，就是为了打破死板的流程，让团队能快速跟着需求变。
现在倒好，好多团队把敏捷搞成了新的八股。流程卡的比原来瀑布还死，每天强制站会，不到点不能散会，燃尽图必须画的漂漂亮亮，backlog要整理的整整齐齐，就是没人关心需求对不对，用户要不要。
我之前见过一个十个人的小团队，硬生生按百人团队的标准SAFe框架走，每个迭代都要做十份文档，开五个评审会。两个月下来，一个核心功能都没上线。这不搞笑吗！这哪儿是敏捷，这是换了个皮的形式主义。
互联网小团队敏捷开发白板站会现场
就这么干，人家上线一年，迭代了快一百五十次，核心功能更了十几版，bug率比隔壁按标准Scrum走的团队低了三成。用户口碑好得离谱，不到两年就做到了百万付费。
什么是敏捷的核心？刨掉那些花里胡哨的名词，其实就两件事。
第一件，快速试错，小步调整。别把大半年的需求一锤子定死，做一点，测一点，对了继续，错了立刻改，把风险摊到每个星期，而不是等到上线才爆雷。
第二件，拆掉信息墙，让听得见炮声的人决策。产品、开发、运营别各干各的，天天信息不通，需求是老板拍的，开发是接活的，最后错了全怪开发不行。有问题当场说，要改当场调，别层层审批走流程。
去年看过国内顶尖软件学院的一份行业调研，国内超过六成的互联网团队宣称自己在用敏捷开发方法，真正摸到核心的，不到两成。大部分都是学了个形式，丢了本质。
老板要管控，所以把敏捷变成了天天汇报进度的工具，原来一个月汇报一次，现在天天说，美其名曰透明化。需求还是老板拍板，半年不变，流程比原来还多，效率怎么可能高？
不过话说回来，这也不是敏捷的错，是人用错了方法，对吧？
AI时代，敏捷开发又玩出了新花样
这两年大模型火了之后，敏捷的玩法又变了，效率直接上了一个台阶。
原来拆需求，产品经理要对着大需求捋个两三天，分好优先级，估好工作量，才能放进迭代。现在呢？GPT把需求输进去，几分钟就能帮你拆成粒度合适的小任务，还能根据历史数据给出工作量预估，准度比很多新手产品还高。
原来测试环节，一个迭代要抽两三天做人工回归，现在AI自动化测试能覆盖八成以上的基础用例，开发写完代码，提交之后自动测，有问题当场改，改完就能准备上线，迭代周期直接从两周缩到一周，甚至更短。
我前阵子跟字节的一个资深开发聊天，他们现在做新的小功能，从需求提出到正式上线，快的话一天就能走完。放在五年前，走标准敏捷至少要两周，走瀑布要一个多月，这差距不是一点半点。
那大团队呢？现在很多上千人的业务团队，都在搞模块化拆分的敏捷网状架构，把大团队拆成十几个十几人的小敏捷单元，每个单元管一块独立的业务，自己定迭代节奏，总部只管方向和最终结果，不管你开不开会，流程怎么走。
腾讯、阿里的很多新业务线，现在都是这么干的，原来一个大版本要三个月才能更，现在一个月就能更两次，应对市场变化的速度快了不止一倍。
别觉得敏捷开发方法只适合互联网做软件，现在传统行业早就用开了。新能源汽车做新车开发，原来全套流程走下来要四五年，现在把动力、座舱、智驾拆成不同的模块，每个模块按敏捷迭代，两年就能出下一代，不然根本跟不上电池和智驾技术的更新速度。
很多人入门敏捷，第一反应就是买本厚书，背熟Scrum、Kanban、XP的所有规则，结果到了团队还是寸步难行。
为啥？敏捷从来不是一套必须严格遵守的标准流程，它是一种解决问题的思路。你十个人的团队，没必要硬套百人大团的SAFe框架。你做甲方定制项目，需求签死了不变，安安稳稳走瀑布也没人说你不对。
适合自己团队节奏，能快速做出对的东西，就是好的敏捷。
就这么简单。
别神化敏捷，它本来就是被逼出来的
上世纪90年代，软件圈主流还是瀑布模型。 需求分析→设计→编码→测试→上线，一步接一步，走完全程少则半年多则一两年。那时候互联网还没普及，软件卖拷贝，需求提前一年定好也没问题。 后来互联网起来了，用户口味变的比翻书还快，你花一年做出来的东西，上线那天就过时了。改需求？瀑布模型牵一发动全身，改一个地方整个流程重来，成本高到吓人。 一堆受不了的程序员凑在一块儿开了个会，整出了那篇著名的敏捷宣言。敏捷开发四核心价值原文截图
核心四句话，第一句就是个体和互动高于流程和工具。
说白了，敏捷从根上就是反僵化的，就是为了打破死板的流程，让团队能快速跟着需求变。
现在倒好，好多团队把敏捷搞成了新的八股。流程卡的比原来瀑布还死，每天强制站会，不到点不能散会，燃尽图必须画的漂漂亮亮，backlog要整理的整整齐齐，就是没人关心需求对不对，用户要不要。
我之前见过一个十个人的小团队，硬生生按百人团队的标准SAFe框架走，每个迭代都要做十份文档，开五个评审会。两个月下来，一个核心功能都没上线。这不搞笑吗！这哪儿是敏捷，这是换了个皮的形式主义。
真正好用的敏捷，从来没有标准姿势
说实话，我见过活的用得好的敏捷，全都是“野路子”，没有一个完全按书本上来的。 前两年接触过一个做小众效率工具的团队，八个人，挤在一个商住两用房里干活。没有固定的两周迭代，没有成套的敏捷工具，就是一块大白板，写着要做的需求，谁有空谁拿，做完擦了。大需求拆成两三天就能做完的小块，每天中午吃完饭大家凑一块儿聊十分钟，说说哪里不对，要调方向。互联网小团队敏捷开发白板站会现场
就这么干，人家上线一年，迭代了快一百五十次，核心功能更了十几版，bug率比隔壁按标准Scrum走的团队低了三成。用户口碑好得离谱，不到两年就做到了百万付费。
什么是敏捷的核心？刨掉那些花里胡哨的名词，其实就两件事。
第一件，快速试错，小步调整。别把大半年的需求一锤子定死，做一点，测一点，对了继续，错了立刻改，把风险摊到每个星期，而不是等到上线才爆雷。
第二件，拆掉信息墙，让听得见炮声的人决策。产品、开发、运营别各干各的，天天信息不通，需求是老板拍的，开发是接活的，最后错了全怪开发不行。有问题当场说，要改当场调，别层层审批走流程。
去年看过国内顶尖软件学院的一份行业调研，国内超过六成的互联网团队宣称自己在用敏捷开发方法，真正摸到核心的，不到两成。大部分都是学了个形式，丢了本质。
老板要管控，所以把敏捷变成了天天汇报进度的工具，原来一个月汇报一次，现在天天说，美其名曰透明化。需求还是老板拍板，半年不变，流程比原来还多，效率怎么可能高？
不过话说回来，这也不是敏捷的错，是人用错了方法，对吧？
AI时代，敏捷开发又玩出了新花样
AI时代，敏捷开发又玩出了新花样
这两年大模型火了之后，敏捷的玩法又变了，效率直接上了一个台阶。
原来拆需求，产品经理要对着大需求捋个两三天，分好优先级，估好工作量，才能放进迭代。现在呢？GPT把需求输进去，几分钟就能帮你拆成粒度合适的小任务，还能根据历史数据给出工作量预估，准度比很多新手产品还高。
原来测试环节，一个迭代要抽两三天做人工回归，现在AI自动化测试能覆盖八成以上的基础用例，开发写完代码，提交之后自动测，有问题当场改，改完就能准备上线，迭代周期直接从两周缩到一周，甚至更短。
我前阵子跟字节的一个资深开发聊天，他们现在做新的小功能，从需求提出到正式上线，快的话一天就能走完。放在五年前，走标准敏捷至少要两周，走瀑布要一个多月，这差距不是一点半点。
那大团队呢？现在很多上千人的业务团队，都在搞模块化拆分的敏捷网状架构，把大团队拆成十几个十几人的小敏捷单元，每个单元管一块独立的业务，自己定迭代节奏，总部只管方向和最终结果，不管你开不开会，流程怎么走。
腾讯、阿里的很多新业务线，现在都是这么干的，原来一个大版本要三个月才能更，现在一个月就能更两次，应对市场变化的速度快了不止一倍。
别觉得敏捷开发方法只适合互联网做软件，现在传统行业早就用开了。新能源汽车做新车开发，原来全套流程走下来要四五年，现在把动力、座舱、智驾拆成不同的模块，每个模块按敏捷迭代，两年就能出下一代，不然根本跟不上电池和智驾技术的更新速度。
很多人入门敏捷，第一反应就是买本厚书，背熟Scrum、Kanban、XP的所有规则，结果到了团队还是寸步难行。
为啥？敏捷从来不是一套必须严格遵守的标准流程，它是一种解决问题的思路。你十个人的团队，没必要硬套百人大团的SAFe框架。你做甲方定制项目，需求签死了不变，安安稳稳走瀑布也没人说你不对。
适合自己团队节奏，能快速做出对的东西，就是好的敏捷。
就这么简单。