敏捷开发方法：不是银弹，却是当代技术人的破局工具
上周跟一个创业公司的技术负责人喝酒，他拍着桌子骂，说之前跟风学大厂搞敏捷，搞了半年，进度拖了，团队散了，项目直接黄了。
很多人提起敏捷，要么觉得是互联网大厂赶KPI的幌子，要么觉得是咨询公司卖课割韭菜的噱头。骂归骂，你去看看现在活得还不错的 tech 团队，十个里有八个都在沾敏捷。问题出在哪？大部分人从一开始就学歪了。
错误敏捷开发每日站会现场
个体和互动高于流程和工具，这是敏捷宣言的第一句话。好多人反过来了，流程工具大于天，人变成了给流程填数据的工具，这不扯吗？
当年那17个大牛写敏捷宣言，不是为了发明一套新的管理流程折腾人，是真的受不了传统瀑布开发的慢和蠢——你花三个月写需求文档，半年开发，三个月测试，做出来一看，市场变了，用户要的东西完全不一样，大几十万的投入直接打了水漂，谁受得了？
敏捷开发两周迭代流程示意图
很多人对敏捷有个最大的误解：觉得敏捷就是「快」，就是压缩工期赶进度。不对。敏捷的核心不是快，是降低试错成本。
原来你一次把所有赌注都压在一个方向上，错了就是满盘皆输。敏捷是每次压十分之一的赌注，走对了再加码，错了掉头的成本也不高。现在哪个行业变化不快？今天的热门需求，半年之后可能就没人要了，小步快跑总比all in输光了强，对吧？
不过话说回来，敏捷也不是所有项目都适合。你做航天卫星的飞控软件，做心脏起搏器的内置代码，需求从一开始就定死了，不能出一点错，那你老老实实按瀑布来，把每个环节都测到位，别瞎折腾敏捷，那是拿人命开玩笑。
落地敏捷别搞花架子，先做这几件事就行
好多咨询公司一讲敏捷，就让你上SAFe大规模敏捷，搞一堆认证，买几万块的管理工具，折腾半天，团队先累垮了。其实小团队落地敏捷，根本不需要那么复杂，先把三件事做好，就够用了。
第一，迭代别搞太长，最长两周。一次只选能实实在在做完的需求，别往迭代里塞一堆活，做不完欠着，越拖债越多，最后又回到瀑布的老路子。需求排优先级，最重要的先做，不重要的往后放，哪怕一个迭代只上线两个功能，也比做十个半成品强。
第二，所有会议别开太长。每日站会控制在10分钟以内，只说三件事：我卡在哪了，需要谁帮忙，没了就散。别变成工作汇报，领导要听会后单独找你说，别耽误所有人的时间。迭代会、回顾会都控制在两个小时以内，扯远了立刻拉回来，开会就是浪费开发时间，能不开就不开，能短开就不长开。
第三，每个迭代结束一定要给需求方看可运行的demo。别藏着，不好看也没关系，有问题早改比晚改强太多。我见过太多团队，一个迭代结束，代码还没集成，测都没测，就说做完了，下一个迭代又加新需求，最后攒到上线才出问题，一改就是半个月，那还是瀑布换了个皮，根本不是敏捷。
见过不少公司，办公室墙上贴满了敏捷看板，买了大几千一年的敏捷管理工具，每个人都考了敏捷认证，结果需求还是半年不变一次，开发还是最后一个月通宵赶工，这不叫敏捷，这叫给办公室做了个敏捷装修，中看不中用。
说白了，敏捷开发方法从来就不是什么包治百病的银弹，它就是一群被坑过的程序员总结出来的避坑指南。需求变的快，你就小步快跑试错；信息不对称，你就多跟需求方对齐；别搞一堆没用的流程折腾人，把人当人，把能交付的软件当回事，这就够了。
很多人学敏捷，从根上就错了
说实话，百分之八十喊着做敏捷的公司，连2001年的敏捷宣言都没认真读完。他们只抄来了Scrum的几个「仪式」：每日站会、迭代规划会、回顾会，往自己流程上一套，就对外说我们是敏捷团队了。 站会变成了给领导汇报工作的早会。要求所有人必须站着开，美其名曰提高效率，结果大家都怕说自己卡壳挨骂，每个人三句话「昨天做了XX，今天要做XX，没有问题」，十分钟走个过场，该卡的还是卡，该拖的还是拖。 哦对，还有燃尽图。为了好看的数据，开发把没做完的任务拆成半个，凑进度，最后燃尽图漂漂亮亮，上线时间一推再推。错误敏捷开发每日站会现场
个体和互动高于流程和工具，这是敏捷宣言的第一句话。好多人反过来了，流程工具大于天，人变成了给流程填数据的工具，这不扯吗？
当年那17个大牛写敏捷宣言，不是为了发明一套新的管理流程折腾人，是真的受不了传统瀑布开发的慢和蠢——你花三个月写需求文档，半年开发，三个月测试，做出来一看，市场变了，用户要的东西完全不一样，大几十万的投入直接打了水漂，谁受得了？
真敏捷到底能解决什么问题？
我自己踩过这个坑。刚工作那几年做一个企业服务项目，客户一开始说要做一个全模块的CRM，我们按瀑布开发，写了三百多页的需求文档，所有人签字确认，刚写完一半设计，客户公司换了CEO，新老板换了业务方向，原来的需求直接废了小一半，前期投入全打水漂，那叫一个心疼。 后来项目推倒重来，转了敏捷，两周一个小迭代，每两周就给客户看一次可运行的demo，有不满意的地方当场改，大方向不对立刻调，结果三个多月就拿出了能用的版本，客户反而挺满意，最后还成了我们的标杆案例。 去年看过斯坦福信息技术研究所的一份调研，抽了全球一千二百个不同规模的软件项目做统计，需求不确定性超过50%的项目里，采用成熟敏捷开发方法的团队，项目按期交付率比传统瀑布模型高41个百分点，最终盈利的概率更是比瀑布高出近一倍。敏捷开发两周迭代流程示意图
很多人对敏捷有个最大的误解：觉得敏捷就是「快」，就是压缩工期赶进度。不对。敏捷的核心不是快，是降低试错成本。
原来你一次把所有赌注都压在一个方向上，错了就是满盘皆输。敏捷是每次压十分之一的赌注，走对了再加码，错了掉头的成本也不高。现在哪个行业变化不快？今天的热门需求，半年之后可能就没人要了，小步快跑总比all in输光了强，对吧？
不过话说回来，敏捷也不是所有项目都适合。你做航天卫星的飞控软件，做心脏起搏器的内置代码，需求从一开始就定死了，不能出一点错，那你老老实实按瀑布来，把每个环节都测到位，别瞎折腾敏捷，那是拿人命开玩笑。
落地敏捷别搞花架子，先做这几件事就行
落地敏捷别搞花架子，先做这几件事就行
好多咨询公司一讲敏捷，就让你上SAFe大规模敏捷，搞一堆认证，买几万块的管理工具，折腾半天，团队先累垮了。其实小团队落地敏捷，根本不需要那么复杂，先把三件事做好，就够用了。
第一，迭代别搞太长，最长两周。一次只选能实实在在做完的需求，别往迭代里塞一堆活，做不完欠着，越拖债越多，最后又回到瀑布的老路子。需求排优先级，最重要的先做，不重要的往后放，哪怕一个迭代只上线两个功能，也比做十个半成品强。
第二，所有会议别开太长。每日站会控制在10分钟以内，只说三件事：我卡在哪了，需要谁帮忙，没了就散。别变成工作汇报，领导要听会后单独找你说，别耽误所有人的时间。迭代会、回顾会都控制在两个小时以内，扯远了立刻拉回来，开会就是浪费开发时间，能不开就不开，能短开就不长开。
第三，每个迭代结束一定要给需求方看可运行的demo。别藏着，不好看也没关系，有问题早改比晚改强太多。我见过太多团队，一个迭代结束，代码还没集成，测都没测，就说做完了，下一个迭代又加新需求，最后攒到上线才出问题，一改就是半个月，那还是瀑布换了个皮，根本不是敏捷。
见过不少公司，办公室墙上贴满了敏捷看板，买了大几千一年的敏捷管理工具，每个人都考了敏捷认证，结果需求还是半年不变一次，开发还是最后一个月通宵赶工，这不叫敏捷，这叫给办公室做了个敏捷装修，中看不中用。
说白了，敏捷开发方法从来就不是什么包治百病的银弹，它就是一群被坑过的程序员总结出来的避坑指南。需求变的快，你就小步快跑试错；信息不对称，你就多跟需求方对齐；别搞一堆没用的流程折腾人，把人当人，把能交付的软件当回事，这就够了。