别被神话了的敏捷开发方法，到底能解决什么问题？

我前阵子跟一个创业公司技术leader喝酒，他喝到一半拍桌子骂，说全公司喊敏捷喊了大半年，结果交付周期反而比之前长了三分之一，开发天天开无效会，没人真的关心做出来的东西对不对用户胃口。

这种吐槽我听得太多了。好像现在不管是做互联网还是做软件，不说自己用敏捷开发，都不好意思出门见投资人。可真能用对的，十家里面挑不出一家。

很多人学的敏捷，都是被简化歪了的

最早2001年，17个软件工程领域的老人凑在一起，弄出了那个著名的敏捷宣言，一共四句话，核心就一个意思：别盯着流程和文档死磕，盯着解决实际问题，盯着变化调整。

到了现在，被一帮咨询公司和培训机构一讲，变成了什么？必须每日站会，必须两周一个迭代，必须贴看板，必须改绩效按迭代算。

我见过最离谱的一家公司，要求开发每天站会必须站着开，美其名曰“保持敏捷的节奏感”，一群人抱着电脑站在会议室开四十分钟，老开发腰都站出问题了，最后啥问题没解决。

还有的公司，为了符合“可工作的软件高于详尽文档”这句话，直接把所有文档都砍了，新人进来接手项目，连哪个接口是干啥的都不知道，问就是“看代码啊，敏捷就是不需要文档”。

这哪是敏捷，这是懒，是瞎搞。

说实话，绝大多数公司做的不是敏捷，只是做了敏捷的样子，内核还是原来那一套乱撞，出了问题反而怪敏捷方法没用。

敏捷开发方法真正解决的痛点，根本不是“快”

绝大多数人对敏捷的第一个误区就是：敏捷就是更快赶工，就是多交活。

不对。敏捷从一开始，就不是为了让你更快堆功能，它要解决的，是瀑布开发模式下，大项目长期试错的高成本问题。

敏捷出来之前，行业里主流都是瀑布：需求调研一个月，方案设计一个月，写代码三个月，测试一个月，半年之后上线，结果发现市场变了，用户要的东西根本不是当初定的那回事，半年功夫全白费，几百万投入打水漂。

这种事在现在的互联网行业，太常见了对吧？谁能保证半年前定的需求，半年之后还符合市场？

敏捷的核心其实就是六个字：小步试错，快速调整。把大项目拆成一个个能独立上线、独立验证的小模块，每做一块就扔给用户测，拿到反馈马上改，不对就及时调头，避免把所有资源砸进去之后才发现错了。

去年我帮一家做本地生活SaaS的团队梳理流程，他们之前就是瀑布玩法，三个月做一个大版本，上线之后发现老板拍脑袋加的那个多门店连锁功能，付费用户根本没人用，四个工程师两个月的工作量全废了。

后来他们改了真敏捷，不是改站会形式，是把所有大需求拆成了一周就能做完上线的小功能，每两周就找十个核心客户测，收集反馈，不满足的话下一个迭代就改。三个月下来，上线的八个小功能，七个都是用户愿意加钱升级的，浪费的人力直接降了七成，交付满意度翻了一倍还多。

不过话说回来，也不是所有项目都适合敏捷。你做航天火箭的飞控软件，需求十年前就定死了，每一步都要留痕可追溯，那当然还是瀑布更稳。你做给政府的定制项目，需求写进合同，改个东西要走三个月审批，那也没必要硬套敏捷，对吧？

落地敏捷开发方法，最容易踩的三个坑

我见过太多公司倒在这几个地方，说出来避避坑。

第一个坑，把敏捷做成管理层压榨员工的工具。很多老板张口就是“敏捷就是要响应变化，所以这个需求今天加进来，这个迭代就得做”，反正固定了两周迭代，不管团队能接多少，拼命往里面塞需求，最后变成开发天天996，迭代永远做不完，质量烂得一塌糊涂，团队半年就跑光了。

说实话，敏捷反而是保护团队的。固定时间固定人力，能做多少就是多少，要加新需求就得把同等工作量的旧需求挪出去，这个是底线，碰都不能碰。

第二个坑，没有配套的工程能力就硬上。你要小步交付，频繁上线，是不是得有自动化测试、持续集成、自动化部署？不然你改一行代码，测试手动测一遍要大半天，部署要一天，那两周迭代一半时间都在搞发布，能快起来才怪。很多小公司，连个自动化测试框架都没搭，开发改完代码全靠测试手动点，就喊着要做敏捷，最后只能是一地鸡毛。

第三个坑，只有开发敏捷，其他部门全是瀑布。开发两周一个迭代，产品需求一个月才出，设计排期排到半个月后，等需求到开发手里，迭代已经过去一半了，最后只能赶工，代码写得烂，bug一堆，交付出来根本不能用。敏捷是整个团队的事，产品、设计、运维都得跟上节奏，不是光开发改改开会方式就能成的。

最后说句实在话，现在市面上太多概念，都是包装出来割韭菜的，敏捷开发方法本身是个好东西，帮很多团队省了试错成本，提高了交付效率，但是别为了赶潮流追概念，硬往自己身上套。

你哪怕不天天开站会，不贴满墙的看板，只要能做到小步交付，及时拿到用户反馈调整，少做没用的无用功，那你就已经摸到敏捷的门道了。