敏捷开发方法：别把“迭代”做成了“反复横跳”
我前阵子跟一个创业公司的技术负责人喝酒，他拍着桌子骂，说他们公司搞了一年敏捷，现在每个 Sprint 都在赶需求，上线bug堆得比需求文档还厚。
真假敏捷开发流程对比图
说白了，大多数人根本没读懂当年17位程序员写下的敏捷宣言。只记住了“响应变化”，忘了排在它前面的工作的软件才是核心。什么叫工作的软件？就是每个迭代结束，你拿到的必须是一个能用、能给用户用的完整功能，不是一堆写了一半的代码，更不是改了八版的PPT需求。我见过最扯的操作，某公司要求开发每天写站会日报，三个问题必须填得整整齐齐，本来15分钟能说完的事，光写文档就要半小时。把流程放在比人还高的位置，这跟敏捷的初衷完全背道而驰。敏捷第一句价值观就是“个体和互动高于流程和工具”啊。真的搞笑。
敏捷开发用户价值迭代拆分示意图
这里有个90%的新手都会搞错的点，拆迭代不是按技术模块拆，是按用户价值拆。我举个例子，你要做一个全新的同城二手交易APP，怎么拆？很多人会说，第一个迭代做用户登录注册，第二个做商品发布，第三个做聊天，第四个做支付。错得离谱。第一个迭代做完，你只有个登录注册，根本验证不了有没有用户愿意在你这卖东西啊。正确的拆法是什么？第一个迭代做最核心的用户价值：用户能发二手商品，能看商品，能联系卖家，就够了。UI丑一点没关系，没有支付就走线下，甚至只开放给一个城市的几百个用户测，先跑通整个流程，看看有没有人用，再往下加功能。这才是敏捷的正确打开方式。之前看过2024年最新的全球工程效能调研数据，用对敏捷方法的团队，项目失败率比传统瀑布开发低了46%，核心原因就是试错成本低，不会把所有筹码压在一个不知道对错的需求上。不过话说回来，现在很多公司把敏捷做成了压榨开发的工具，什么每个迭代加满满当当的需求，完不成就是开发效率低，这根本就是歪经。敏捷是帮你少做无用功，不是给你加更多活。
敏捷不是银弹，这些坑一定要避开
我见过太多团队，为了赶风口硬上敏捷，根本不管自己适合不适合。首先说清楚，敏捷真不是所有项目都能用。如果你做的是航天嵌入式软件，或者银行核心系统的改造，需求明确，验收标准清晰，出一点错就是天大的问题，那瀑布开发反而比敏捷更靠谱，没必要硬蹭敏捷的热度。其次几个常见的坑，说出来给大家提个醒。第一个坑，产品经理无限制加需求，不做优先级排序。很多人觉得敏捷就是随时可以改需求，Sprint进行到一半，塞进来好几个新需求，开发做不完就怪团队不行。Sprint的核心规则是什么？一旦迭代开始，范围就不能乱改，有新需求放到下个迭代排期，这个底线绝对不能破。破了一次，以后就永远是赶工。第二个坑，没有配套的工程实践，光套流程。你两周一个迭代，每次发版都要手动测一周，那速度怎么提得上来？敏捷要求测试左移、持续集成，开发写完代码就写单元测试，每次提交自动跑测试用例，自动化搞定回归测试，才能支撑快速迭代。没有这些基础，光改开会流程，就是换汤不换药。第三个坑，站会变成向上汇报会。本来站会就是团队内部同步信息，解决阻塞，10到15分钟结束，结果老板非要来旁听，每个人都对着老板汇报工作，15分钟的会开成一小时，完全变味。真要汇报，会后单独找老板说不行吗？浪费整个团队的时间，算什么事。对吧？我见过做得最好的敏捷团队，是一个二十人的创业团队，他们根本不死守Scrum那一堆规则，每个迭代结束会花半小时开回顾会，这周流程哪里不对，哪里卡了，立刻改，舒服就好，能把事做成就行。别把流程当圣旨。
说白了，搞来搞去，敏捷就是个干活的方法而已。不是什么大厂身份象征，也不是能治百病的神药。你要做的，就是搞懂它的核心，适配自己的团队，别把迭代做成反复横跳，就够了。
很多公司的敏捷，其实是“伪敏捷”
刚搞敏捷那几年，我也踩过一模一样的坑。老板听说隔壁厂用敏捷半年就上线了爆款项目，回来就逼着全公司改流程，把原来的需求评审砍掉一半，要求两周必须发一个版本，美其名曰“快速试错”。结果呢？需求想改就改，开发天天救火，上线的功能连逻辑都跑不通，最后老板说“敏捷都是骗人的”，转头又改回了原来的乱搞模式。真假敏捷开发流程对比图
说白了，大多数人根本没读懂当年17位程序员写下的敏捷宣言。只记住了“响应变化”，忘了排在它前面的工作的软件才是核心。什么叫工作的软件？就是每个迭代结束，你拿到的必须是一个能用、能给用户用的完整功能，不是一堆写了一半的代码，更不是改了八版的PPT需求。我见过最扯的操作，某公司要求开发每天写站会日报，三个问题必须填得整整齐齐，本来15分钟能说完的事，光写文档就要半小时。把流程放在比人还高的位置，这跟敏捷的初衷完全背道而驰。敏捷第一句价值观就是“个体和互动高于流程和工具”啊。真的搞笑。
敏捷开发方法真正的核心，是“试错成本可控”
说实话，敏捷诞生本来就是为了补瀑布开发的坑。几十年前做软件，大多是给政府、企业做定制项目，需求一年半载都不会变，瀑布式分需求、设计、开发、测试、上线，一步一步走完全没问题。放到现在呢？你做个面向C端的产品，今天用户喜欢这个，明天风向变了又喜欢那个，你花半年把所有需求定死做出来，上线直接扑街，几百万打水漂，找谁哭去？敏捷的本质，就是把大项目拆成一个个小的可交付单元，每一块做完都能拿到市场验证，对的接着干，错了立刻停，把试错成本压到最低。敏捷开发用户价值迭代拆分示意图
这里有个90%的新手都会搞错的点，拆迭代不是按技术模块拆，是按用户价值拆。我举个例子，你要做一个全新的同城二手交易APP，怎么拆？很多人会说，第一个迭代做用户登录注册，第二个做商品发布，第三个做聊天，第四个做支付。错得离谱。第一个迭代做完，你只有个登录注册，根本验证不了有没有用户愿意在你这卖东西啊。正确的拆法是什么？第一个迭代做最核心的用户价值：用户能发二手商品，能看商品，能联系卖家，就够了。UI丑一点没关系，没有支付就走线下，甚至只开放给一个城市的几百个用户测，先跑通整个流程，看看有没有人用，再往下加功能。这才是敏捷的正确打开方式。之前看过2024年最新的全球工程效能调研数据，用对敏捷方法的团队，项目失败率比传统瀑布开发低了46%，核心原因就是试错成本低，不会把所有筹码压在一个不知道对错的需求上。不过话说回来，现在很多公司把敏捷做成了压榨开发的工具，什么每个迭代加满满当当的需求，完不成就是开发效率低，这根本就是歪经。敏捷是帮你少做无用功，不是给你加更多活。
敏捷不是银弹，这些坑一定要避开
敏捷不是银弹，这些坑一定要避开
我见过太多团队，为了赶风口硬上敏捷，根本不管自己适合不适合。首先说清楚，敏捷真不是所有项目都能用。如果你做的是航天嵌入式软件，或者银行核心系统的改造，需求明确，验收标准清晰，出一点错就是天大的问题，那瀑布开发反而比敏捷更靠谱，没必要硬蹭敏捷的热度。其次几个常见的坑，说出来给大家提个醒。第一个坑，产品经理无限制加需求，不做优先级排序。很多人觉得敏捷就是随时可以改需求，Sprint进行到一半，塞进来好几个新需求，开发做不完就怪团队不行。Sprint的核心规则是什么？一旦迭代开始，范围就不能乱改，有新需求放到下个迭代排期，这个底线绝对不能破。破了一次，以后就永远是赶工。第二个坑，没有配套的工程实践，光套流程。你两周一个迭代，每次发版都要手动测一周，那速度怎么提得上来？敏捷要求测试左移、持续集成，开发写完代码就写单元测试，每次提交自动跑测试用例，自动化搞定回归测试，才能支撑快速迭代。没有这些基础，光改开会流程，就是换汤不换药。第三个坑，站会变成向上汇报会。本来站会就是团队内部同步信息，解决阻塞，10到15分钟结束，结果老板非要来旁听，每个人都对着老板汇报工作，15分钟的会开成一小时，完全变味。真要汇报，会后单独找老板说不行吗？浪费整个团队的时间，算什么事。对吧？我见过做得最好的敏捷团队，是一个二十人的创业团队，他们根本不死守Scrum那一堆规则，每个迭代结束会花半小时开回顾会，这周流程哪里不对，哪里卡了，立刻改，舒服就好，能把事做成就行。别把流程当圣旨。
说白了，搞来搞去，敏捷就是个干活的方法而已。不是什么大厂身份象征，也不是能治百病的神药。你要做的，就是搞懂它的核心，适配自己的团队，别把迭代做成反复横跳，就够了。