如果你是一个IT工作者，你该知道，敏捷方法正在走向死亡。如果你还在践行敏捷方法，只不过是在苟延残喘。如果你还在用它来管理开发团队，你的团队会因此停滞不前。敏捷的浪潮已经结束了。如果你还执迷不悟地花钱去购买敏捷方法认证，纯粹是浪费金钱。不久以后，招聘者们会把你的简历丢到角落里吃灰。我已经不止一次表达过我的观点，而这一天就要来临了。
那些受人追捧的事物总有一个存活的周期，若是跟管理相关的就更是如此。在现代社会，这些潮流就像波浪曲线一样，发生的频率越来越高。曲线的末端意味着热度的消退，销售的萎靡，利润的萎缩，用一个词来概括，那就是"死亡"。收入锐减，没有更大的利润空间，这是市场达到饱和状态的结果。先达到一个最高点，然后开始走下坡路。那些参与到市场中的人们，薪资收入也跟着下滑。这跟极客精神是背道而驰的。它更像是"脑死亡",意味着整个事情已经没有更多的技术价值。
IT工作者们抓住一个又一个潮流，在每一个潮流中尽其所能地赚钱，一个潮流结束就换另一个。他们不见得能很好地服务客户，却从客户那里得到很多。刚开始的时候，你会发现他们在工程技术上做得很规范严瑾，但到了后面他们开始把关注点放在跟市场销售有关的各种收入上。
这些潮流可以从叠加的甘特技术热度周期图上看出来。你觉得这些潮流会一直持续下去吗？天下无不散之筵席。不过那些具备坚实工程基础的东西会走得长远一些。你们认为敏捷方法最终会何去何从？它最终会被扔到垃圾堆里。希望这个说法不会让人感到不快。
事物总是循环往复的，所以它最终会在市场上失去生命力，被另一个新的事物所取代。
众说纷纭
都有谁认为敏捷已死？其实说这些话的人恰恰不是我，而是敏捷方法的创立者和践行者们。所以不要认为这个观点是我先提出来的。
- Richard Bishop写了一篇名为《愤怒的开发者》的博文。
- Dave Thomas就是敏捷方法13个发起人之一。他说敏捷已死。
- William Edmonson说敏捷已死。
- Kent Beck，也是发起人之一，对于如何评价敏捷的成败，他不置一词。"对于这个问题，我也无可奉告"。Andrew Hunt，发起人之一，他也说敏捷已死。
- Scott Ambler现在正在推行他的《规范的敏捷交付》，因为最初的版本没有为了企业级系统把敏捷方法剥离出去。Hayim Makabee说敏捷死于过度简化，而且让人产生了迷思。
- Andrew Binstock在Dr.Dobbs网站说敏捷已奔溃。
- Mike Hadlow解释了为什么敏捷是失败的。
- Stuart Eccles说"你越是花时间在敏捷上，越是会变得不敏捷。反之亦然"。
- Darren说敏捷不应该成为一种开发管理流程工具。
- Nathan Dintenfass说敏捷语言已经破碎不堪。
- Garreth Dottin说敏捷具有破坏性。
- Kristopher Wilson对敏捷站会颇有微词。
- Erik Dietrich举了很多例子来挖苦敏捷。
- 软件开发时报的编辑说敏捷已死。
- DogitalRoot说敏捷太过迂回，跟死了没什么两样。
- 还有一群人专门建立了一个网站来诟病敏捷。
- Twitter上还有一个专门的Feed。
- 这里略去几百个。。。
大势已去
其实敏捷的离奇死亡早有征兆，当时的主要负责人就想弃用"敏捷"这个名字，只是很少人知道。在我看来它的死亡是不可避免的。敏捷被市场追捧成灵丹妙药，包治百病。确实，一开始我也参与进去了，但后来发生的一些事情让我退了回来。为什么呢？
- 人们尝到敏捷的甜头，却忽略了它在实用性方面存在的一系列不足。
- 市场把敏捷追捧得过了头，掩盖了某些真相。
- 人们把敏捷神化了，甚至还出现了一些稀奇古怪的带有仪式感的膜拜行为。
- 人们把敏捷看成管控企业的有力手段。很显然，我们太过聚焦局部的优化，高估了它在整个生态系统中的作用。在很多企业里，它只起到支持作用，并不涉及核心业务。当然，它本该向核心业务靠拢。
- 我曾经参与过一个敏捷项目，用户希望通过敏捷来彻头彻尾地改变现状。但他们不明白，他们的企业是如此的臃肿和老旧，通过敏捷实现自动化根本不是一个有效的办法。他们因此浪费了数百万美元。
- 我们需要可重复的流程和成熟度模型，但当我们把敏捷变成流程，会因为要去平衡各方面的差异而做出糟糕的设计。
- 敏捷对如何实现策略性目标支持得不好，如果硬要往这方面靠，很快会以失败告终。在这一点上真的没有更好的办法。
- 敏捷有它与生俱来的信托责任问题。在你把软件开发出来之前你都不知道它是用来做什么的，而且也没办法评估需要投入多少精力。一开始你无法评估它的投资回报率，看起来就像在为一个无法预期的回报写一张空头**。
- 敏捷在复杂的大系统中表现得很糟糕。
- 敏捷在企业环境里也表现不佳。
- 敏捷严重依赖用户的测评，特别是那些脱离底层的测评和安全测试。低效的测试带来的问题比在开发中出现的更严重。
- “填坑”设计是一种糟糕的架构习惯，也就是所谓的“大泥球”模式。
还有很多失败的敏捷案例是我们所不知道的。2012年敏捷项目的成功率为67%，这个数字不算太好，况且这还只是一个粗略的统计结果。要知道，这里面很多都是复杂的大型项目，预算巨大。
通过敏捷构建出来的软件系统质量低下。整个软件行业并没有把焦点放在质量上。从公布的安全隐患列表中可以看出几个主要软件公司在软件缺陷方面的大概情况。敏捷开发中的缺陷数量一直在增长，这个我们可以从“技术债务风险”中看出来。尽管我们一直呼吁要提高敏捷开发的质量，但许多网站的性能仍然很糟糕，可能是因为很多非功能性需求没有受到重视。而这也大大增加了软件开发的成本。
敏捷似乎跟“FITARA”法则存在冲突，所以那些跟政府有合作关系的人就要小心了。比如我，好事将尽。
除了上面提到的那些，还有其他人对敏捷也是持怀疑态度的。
David Longstreet写了一篇文章表达他在疑虑之余对敏捷的深层次思考。敏捷成为最流行的软件开发管理方法，诚然超出了我的预期。人们一意孤行，践行敏捷方法，尝试解决上面提到的一些问题。然而，虽然市场渗透率很高，实际效果却很有限，实质问题没有得到解决，最初的支持者相继离开，连敏捷这个名字都黯然失色，最终的结果跟最初的目标更是相去甚远。
有人认为敏捷彻底征服了世界。但存在这么多悬而未决的缺陷，我们没理由相信敏捷会一直存在下去。为了持续盈利，市场资本会被用于支持新的产品和解决旧产品中存在的问题。敏捷在不久的将来会变成过时的技术。这是市场运行的规律。周瑜打黄盖，一个愿打，一个愿挨。
去其糟粕
当然，我敢肯定敏捷还是有一些可取之处的。大概在1994年，我参与了一个大型项目。我们的团队不大，每天有站会，每周有进度跟踪。我很享受当时的状态。在2005年，我还参与了一个非常典型的敏捷开发项目，跟一个天才的团队一起，干练而高效地工作。在这两个项目中，架构师在一开始就能很好地掌控项目，而且有办法对投资回报率进行评估。所以小团队迭代开发的方式可以被保留下来，虽然它在敏捷出现之前就已存在。当然，肯定还有更多的东西可以被保留下来，只要细心去挖掘。
用户故事也是可以被保留下来的，可以用它来收集真实的用户需求。糟糕的需求收集和测试催生了敏捷开发的质量问题。当然，我指的不是那些可以通过自动化执行的底层测试。
Count Agile这个名字也可以得以保留，不管以什么形式。最近有人说我还有机会通过古老的Fortran编程赚到六位数的酬劳。不过敏捷这个品牌无论如何是要消失的，就像Dave Thomas说的那样。
不管怎么说，敏捷宣言应该被有说服力的新的研究成果和严肃的管理方式所取代。敏捷宣言避重就轻，规避了管理流程和工程规范。它们中的一些本该被烧毁，然后埋起来，接着搬一块大石头压在上面。最后在石头上为后来者刻上以下警句“简单粗暴化的管理意识形态不会一直生意兴隆，特别是当有一帮不懂管理的人在后面捣鼓"。
接踵而至
下一个潮流DevOps接踵而至，它其实是敏捷的继任者。如果你购买了中大型软件开发服务，那么今年一整年都会有人坐在你的办公室卖DevOps服务给你。（他们会告诉你DevOps比敏捷更好，而你没得选择）。不过你还是有机会去做一些挽回的。
- 我们可以更多地从企业角度去考虑问题
- 我们可以把公司管控集成进来
- 我们要找出企业软件存在的意义，搞清楚为什么要做定制化，并把焦点放在具有相关性的代码上
- 有的公司就可以做到这点，只要它们的分析师能够洞察整个软件开发生命周期，并注意到每一种方法怎样在特定领域发挥作用
- 我们要打破所谓的“全栈开发者”神话
市场上有许多敏捷的变种，是人们在实践过程中总结和改进得来的。也许有人会把其中的一些继续发扬光大。
些许建议
有些人希望我能在市场方面给出一些建议，不过我还是想说一些更接地气的话。如果你正在使用AINO，那么你已经行驶在正确的轨道上了。做好准备，在DevOps中加入监管和控制。考虑放宽死板的强制性约束，让PM们有更多自由发挥的余地。接受敏捷不适用于大型复杂项目的事实。如果你被迫使用敏捷，那么就接受它，然后想方设法地让它进入正轨，别管那些吹毛求疵的人怎么说。
如果你问我接下来该何去何从，我倒真的有些话说。在生产力方面，Lean和Six Sigma更注重质量的提升，而敏捷和DevOps注重数量的增长。我们的软件质量很差，但需求却在不断增加。缺陷的数量真的是高得离谱。在以实用至上为宗旨的企业领域，软件质量也很差，而且越来越难以维护。如果我有足够的资格，我会偏爱那些采用了ISC和OWASP实践的方法论。前者在SDLC中被推荐使用，后者跟CSSLP一样包含很多认证。我希望有朝一日，在一堆糟糕的软件毁掉人类文明之前，我们有机会回头。
前行之路
敏捷浪潮真的结束了。我不认为敏捷中存在的那些根本性的问题会在DevOps中得到解决。企业客户必须想方设法寻找组合型的方法，就像敏捷那样。我们当前的软件技术文化并不关心如何改进软件，而是聚焦在策略和效率上。
如果你认为你确实想解决这些问题，那就让我们来仔细说道说道。这时候你的脑子里可能出现了系统工程，CMMI模型，企业管控，安全测试，运营评估，然后想着怎么把这些东西跟DevOps结合在一起。可能你是在一个以产品为主导的软件公司工作，而不是在企业系统里。过度简化的做法在软件公司里也许行得通，但在企业里就不是那么一回事。大企业都已经转向AINO。
当你提及“敏捷软件开发”，所有人都知道你指的是什么。一个实际效果远不如承诺那么好的方法论，一个没有被恰当地实践的方法论，一个比瀑布模型和螺旋模型好不了多少的方法论，一个在某些方面稍好，某些方面却差得多的方法论。不会再有什么奇迹出现了。敏捷方法的几位创始人和许多有影响力的实践者都认为敏捷已死。只有那些还在靠敏捷这个品牌赚钱的利益相关者仍然希望它活下去。
总结陈词
我再重新总结一下我的观点：
- 因为市场的大肆宣传，敏捷成为一个标杆品牌。刚开始它被接受的程度很高，然后开始崩溃。被市场接受的时间长短，取决于它实际产生的效果。不过被狂热追捧的日子总会过去的。从市场角度来说，它死了。
- 敏捷潮流的结束，让那些重度实践者们感到幻象破灭，因为之前承诺的美好愿景都没有实现。尽管敏捷有很多变种，但那些替代方案都没能达成最初的目标。它被那些重度实践者们抛弃了，核心的技术价值已经不存在。从极客角度来说，它也死了。
- 那些还在靠敏捷这个品牌赚钱的人，其实是在挂羊头卖狗肉。通过市场销售手段包装仍然有利可图，毕竟品牌效应的完全消失还需要一段时间。
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
