Matthew(Ford) Kern和Miko最近都发表了与“敏捷已死”主题相关的文章。Matthew将这个话题与敏捷咨询的饱和度以及市场炒作周期的速度相关联，而Miko看到了比敏捷运动中的方法还要更快的需求，并将这个话题与之进行联系，提出用DevOps来替换敏捷。

Matthew的第一篇文章简单地题为“敏捷已死”，他故意采取一个有争议的（和尖刻的）立场，他说，

“敏捷软件开发已经死了。如果你还在实践它或还在用那种管理方式，你本身就是一种障碍。敏捷运动浪潮已经结束了，如果你还想购买证书来掩人耳目，那就是在浪费钱了。”

他接着解释了“死亡”是针对营销和管理时尚的炒作周期而言，并认为

原本冠名为敏捷的意义已经丢失，该技术的价值也已经被稀释，那些追求技术卓越的人们已经放弃了努力。如果不是那些“忠实信徒”的努力，它可能早已成为历史。

他指出，消亡是不可避免的，并给出了一系列原因来解释，其中包括：

• 敏捷有一个最佳点，以及一系列不适应的范围，但每个人似乎都想忽略这些。
• 我知道这是营销噱头，而事实真相却变成了次要的。
• 这里有一个宗教神话，奇怪的术语，专门的宗教工具和其他古怪的祭祀行为。（例如，为了让你同意他们的观点，许多敏捷从业者会欺负你，恐吓你。他们还会攻击你，破坏你的信誉。4月28日的时候我就收到来自一个年轻助手的威胁。）
• 我看到每个人都在抨击它去适应更重要的企业治理。显然，我们在采用局部优化的发展思路，认为它们是生态系统中最重要的的组成部分。然而，在绝大多数的企业中，它们只是次要的支持功能，而不是核心业务。它们应适应更重要的业务功能。

他继续分析了一些他认为可以被保留下来的元素，包括迭代、团队、一些社会实践和许多技术实践。
在文中，他总结了他自己关于什么会替代敏捷的一些想法，即DevOps潮流。

所以下一波是DevOps潮流。它是“继承者”。如果你购买一个中等或大型规模的软件开发服务，那么今年就会有人向你推销DevOps。 （他们推销的时候会说，它比纯粹的敏捷更好，你值得拥有。）这里还有另一个机会来解决这个问题：

• 除了关注上次针对企业的考量，我们可以看的更远一点。
• 我们可以结合企业治理.
• 我们可以试着识别企业软件（里面有大量定制化代码）存在的真正原因，并专注于代码的相关性。
• 如果这些分析师们中的任何一个能够领会整个生命周期，并认识到每个方法都有它适应的时刻，那么双模IT可以解决部分问题。
• 我们可能就失去了全栈开发人员的神话。

现在市场上也有很多从实践经验和改进活动中而来的不同敏捷修订版本，也许一些人会努力为其中的一项做真正的市场营销。

Miko认为持续交付是敏捷的下一个继承者。

“持续交付（CD）”的模式似乎顺理成章的成为了敏捷的继承者。持续交付提供了一个涵盖性的术语，但并没有定义任何的方法论，也没有要求一系列的宣言。所有你需要知道的都包含在标题里-你只需要尽可能的，持续的去交付软件。这会使得团队可以根据需要去选择合适的敏捷原则和方法，从而达到指定的目标。这也解决了敏捷一直以来被抱怨的一个问题，即敏捷是一场有大师们参与的宗教运动，而这些高薪的敏捷大师们只会为开发团队开出一个适应于所有问题的解决方案，而这个方案又是难以适应开发的真实工作，很难落地。

他认为，我们现处在需要正视DevOps的时代。

Matthew在他的第二篇文章中提供了更深入一些的分析，他提供了一些统计数据和通过查看当下的就业机会和薪水来探索DevOps和敏捷的市场位置。

他总结到：

就业数据和薪水的数据显示敏捷在IT服务行业可能已经处于或接近市场饱和。 DevOps的市场渗透率预计将在2016年迅速增加，而敏捷服务的下降很可能是由于DevOps相关服务的崛起而导致的。假设下一个潮流是DevOps，那么当下的市场需要的是一个占主导地位的方法论和工具使用经验，而不是意识形态。

在过去几年里，敏捷作为一种方法的死亡和它的替代品一直是InfoQ访谈和文章的主题。2014年Dave Thomas鼓励读者接纳敏捷度而非敏捷，2015年他发表了题为“敏捷已死”的演讲。在2012年Alex Bell指出“敏捷热”对组织会有致命的风险。

查看英文原文：Agile is dead again