敏捷开发已熄火？苦敏捷久矣的程序员，难识敏捷真面目

        天下程序员苦敏捷久矣！

        敏捷开发，以前非常火，尤其是2010年后，走哪都能听到“敏捷开发”。爆火之后，不少程序员开始喷敏捷开发。

        被喷多了，慢慢便熄火了，实际上，程序员的唾沫，威力并不大，吐槽996那么久，也没见有啥成效。

        历经几年的发展，“敏捷开发”似乎成了上个年代的名词。如今，敏捷开发并没有退出历史舞台，依然存在，只是不提了。

        敏捷开发，熄火的真正原因，不是被喷灭的，其“功劳”或归功于一些新理念。个人认为，熄灭敏捷开发这把火的，或许是“架构和微服务”。

        什么是敏捷开发？

        我回忆了下以前的“敏捷开发”：没日没夜的加班加点，反反复复的开会，压缩的开发周期，紧凑的工作任务，很随意的版本测试，以及草率的版本更新。

        这些，应该并不是“敏捷开发”吧？接着，网上找了好些资料，确认了下我的理解：一千个人眼中有一千个哈姆雷特。

        敏捷开发，不应该是“科学的软件开发”方法论吗？

        严谨和无歧义，那是正统科学方法，该有的特点。到底是哪里出了问题？带着疑问，回顾了下其他软件开发方法。

        从原型模型、增量模型、到瀑布模型、再到螺旋模型，他们都有一个特点——流程化非常清晰。此前的软件开发方法，不仅，能精确的表达，甚至，可以清清楚楚的画出工作模型。

        但是，这些传统的模型，存在缺陷，一种更好的模型呼之欲出，也就是“敏捷开发”。

         敏捷开发：天下武功，唯快不破，无招胜有招，见招拆招！

        敏捷开发，便是在这样的理念下诞生了。武术，集大成者，便是无招胜有招，见招拆招，集百家之长，融会贯通，随机应变，且得快。

        显然，这理念是先进的，且无敌（毕竟，这种理想的方法论，本就是万能的）。心法有了，外功招式，要怎么搞？没有外功，只有心法，没法落地实施，也展现不出威力。

        既然，能有万能的心法，那也能有万能的功夫招式。

        第一招：化繁为简，拆解复杂需求

        第二招：见招拆招，拥抱变化    

        第三招：版本迭代，持续化发展

        第四招：海纳百川，多模型多方法并存

        第五招：高要求，多个快和好

        理想是好的，现实是残酷的。

        希望的是：简单、快速、只选对的，高质量高效的产出。

        实际是：大量无用功，埋了很多雷，不断返工，管理一片混乱，员工怨声载道。

        敏捷开发火爆，当年的大环境是关键，2010年前后，正赶上“互联网红利”的巅峰年代。快速开发互联网应用，快速抢占市场，需要好的软件开发方法，尤其是出现了一波又一波失败的案例。

        当时，敏捷开发，把软件公司搞得乌烟瘴气的，程序员痛苦不堪，由“追捧”迅速变成“骂声一片”，程序员谈“敏”色变。

        软件开发万能方法论，真的存在吗？

        不是敏捷开发有问题，而是对敏捷开发的理解错了。不过，“敏捷开发”也并不无辜，这不明摆着是“万能方法论”吗。

        敏捷开发，也是有功劳的，经敏捷开发这么一折腾，软件企业更加的重视软件开发管理，从而，注意力都转移到了“架构师”一职。

        可能，把“敏捷开发”说成“万能方法论”，有点不合适。但是，软件行业一直在寻找“万能方法论”。

        如今，软件架构师，承担了降低开发风险的重任。在架构师的指导下，使用微服务，结合现在的技术，除了让系统整体更复杂，其他方面都挺符合“敏捷开发”的主旨。

        有些企业，依然在进化着“微服务+敏捷开发”，有的团体挺好的，也有的团体问题很多。本质不在于方法本身，合适便是最好的，永远不会有绝对的“万能方法论”。