咨询公司的工作是抓住一轮高潮尽其所能的赚钱，然后去抓住另一轮。他可能不为客户利益服务很多，但是他能消耗客户利益。在一些循环的开头你会发现咨询师比较看重工程和技术的严格论证，但是在结束你会发现在对市场和销售扩展的普通关注之外，他们更关注咨询的反馈，税收和利益。

这些起伏可以在Gartner公司为多项技术做的曲线图中看到。你觉得它可能永远持续？没有什么可以永远持续，但是基于固体工程的事情能持续更久。你才他们把敏捷软件发展放在哪里？垃圾桶。事实上是有个宣言， 我希望它感受良好。

谁说的？

谁说敏捷已经死了的？敏捷的建立者和它的实施者这么说的，不是我。不要认为这是我造成的。（我宣称我没有做任何事情造成了它的死亡，我只是报告一些许多开发者的宣言。它死亡与否和我以及这篇帖子没有关系。至于我说的“死亡”应该怎么理解，看下文）

• Dave Thomas曾经是最早的13个提倡敏捷软解开发的开发者之一。他说它死了。懒得看文字？那看看视频吧

• Richard Bishop写了一封愤怒的开发者反馈，同意这个观点

• William Edmonson说敏捷已死

• Kent Beck，13人之一，对敏捷是否成功几乎无话可说。“我对敏捷没有什么可以和你说的金句。”

• 13人中的Andrew Hunt说敏捷已死

• Scott Ambler现在推进Disciplined Agile 发行版因为原始版本没有把它从企业级系统中剥离出来

• Hayim Makabee说它是因为过分简单化而死的，并且提供了一个荒诞的例子

• Andrew Binstock说敏捷在Dr.Dobbs中崩溃了

• Mike Hadlow解释了为什么敏捷失败了

• Stuart Eccles说“你越尝试敏捷你就会越不敏捷，反之亦然”

• Darren 说敏捷本不应该成为一个管理流程

• Nathan Dintenfass说使用的语言崩坏了

• Garreth Dottin 说它是毁灭性的

• Kristopher Wilson斥责了站立会议

• Erik Dietrich 提供巨大的讽刺来说明为什么敏捷很蠢

• 软件开发时报(Software Development Times)的主编说这个术语已经几乎死亡了

• DogitalRoot说它太错综复杂了，所以就死了

• 这些家伙有们一个网站来说明敏捷死亡的好处

• 这里有一个推特简讯

• 我大概省略了一百多个理由。实在对不起大家，太多了
   

不可避免
 

尽管很少被注意到，但是敏捷的颓势早已显现。我认为这种消亡是不可避免的。的确，我曾参与一些，之后便却步于这些无意义的媒体宣传事件。为什么?

• 敏捷有一个甜点区和一个范围的不适用区，但是每个人都选择忽视这点。

• 我早知道市场对敏捷的造势，而敏捷的内涵却是次要的。

• 一个神圣的方法论，奇怪的术语，一些神圣的工具和一堆诡异的行为。

• 我看见每个人都在修改它，使其符合更重要的企业管制。显然我们在开发思想上有了局部的优化，这些曾是企业生态中最重要的一部分。

• 我曾参与的一个敏捷开发工作，在初步工作中对用户的关注就像迷一样。终端用户并不知道他们的组织功能已经过期且冗余的。当时也没有理由使其自动化，所以数百万美元就被浪费了。

• 我们的确需要一些可重复的，成熟的流程。但只要你把敏捷加入到流程中，试着创造完全不同的方案，得到的却是一个妥协的垃圾流程。

• 敏捷对战略目标支持不够好。拓展敏捷标准使之达到战略标准的努力总是功亏一篑。也没有相应的校准机制.

• 敏捷仍存在着固有的信托责任问题。在你创造一个软件前，你不知道它能干什么，你也不能估计运行时的影响范围。因此，一开始你就不能计算出投资回报率(ROI)。对于不确定的回报，你将给出一个空头支票。.

• 对于庞大，复杂的系统，它从来没有运行的很好（是的，无数的人参与了反对敏捷宣言，我也这么干了）。

• 敏捷通过测试和评估，对用户过分依赖，特别是高层次的测试，评估和安全测试。测试不够充分是比开发范围更大的问题。

• 我过去知道紧急设计是垃圾架构。  

• 失败的敏捷项目多得我都数不清。

• 软件质量在过去的十年中明显下降了。MS Word 2003版比2010版好。在大多数的软件厂商的安全缺陷列表中，显示了高层次的产开缺陷。甚至网站也运行欠佳。尽管敏捷宣称高质量，这样的事还是发生了，原因可能是非功能性的需求和衍生需求没有被发掘。

• 新的联邦信息技术采办改革法案（FITARA) 似乎有些冲突，所以在政府合同中一掷千金会有很大风险。对我来说,早就结束了。（ Fat Lady was singing表示事情落下帷幕）

其他人也开始怀疑敏捷了。这篇文章表达了一系列深思过后的疑虑。然而，敏捷已经成为l了最流行的软件项目管理的模式，肯定超出了我的预期。人们通常能解决上述的一些问题，却忽略了宣言， 只管使用敏捷(AINO)。敏捷的市场普及率很高，但是真正的适用性却是有限的，在问题还没有得到解决前，原来的支持者就已经离开了，敏捷这个名字已经被滥用了，敏捷的目的也被大幅度修改了。为了保证销售的持续性，市场资金将转移到支持新的产品名称，并强调老产品的问题。敏捷将过时。这是市场对这种方法和服务的运作方式。

还能留下点什么

我确信还是可以留下点东西的。1994年，我在一个小团队中，参与到了一个大型项目中，我们随时候命项目中的问题，还有每周的例检。这种工作方式很好。2005年，我和一个天才团队也用敏捷的开始工作过，不过没有用敏捷的宣言和各种名词。这2个案例中，我们在正在工作前都知道事情会怎么发展下去，也就可以确定投资回报率。当然，还有更多的好东西，如果能剔除那种邪教般的行事方法，这些都可以保留下来。

举个例子来说，如果你是以用户为主导来决定真正的需求，那是好的。在敏捷下糟糕的需求和糟糕的测试会导致软件质量问题。这里我不是说很低级别的可以自动化的测试，而是其他那些。

Count Agile的名字也许会永远存在，有些成为不死的亡灵，有些却消亡很快。我最近听说可以用FORTRAN来实现，哇哦，强调一次，6位数字的Fortran。

无论如何，敏捷宣言应该被卓越的研究成果和严肃管理方式所代替。这个“宣言”精确的回避了所有喜欢偷懒的工程师和管理方式。他们中的有一些可能也需要被烧毁，埋葬，然后用一块巨大的石头压在上面，上面应该刻上类似这样的对未来的警示：“天真的过于简单的管理理念不会永远受欢迎，特别是当它是由非管理人员提出的时候。躲开！”

下一步是什么

所以DevOps的浪潮来了。还有机会可以修复这个。

• 我们可以比上次更关注企业事项。

• 我们可以整合公司控制。

• 我们应该认识到商业软件存在的真正理由，它包含了大部分的自定义代码，并且关注在代码的关联上。

• BiModalIT可以修复其中的一些，只要任何分析师可以理解整个生命周期，每个方法在生命周期里都只能适用一小段时间。

• 我们应该放弃“全栈工程师”的神话。

建议

同时，如果你现在使用AINO(就像我政府里的同事那样)，那么你是在使用最高级的产品，这是在做对的事情。准备适应DevOps是完全一样的事，调节管理和控制。思考一下，放宽强制的执行规则，让PM可以根据手头的情况做定制。也许敏捷不是执行大型复杂的项目开发的最佳方法。读这里

然而，如果你问我我们应该何去何从，我确实有些想法。敏捷和Dev-Ops的目的是提高产能，而Lean和 Six-Sigma 等工业方法的目的是为了提高质量。但软件的质量在下降，而需求却在增长。软件错误的数量，包括漏洞的数量， 实在太多了 。 在企业软件中，符合“满足目标”质量度量标准的软件 越来越少， 提升软件可运维性的努力也越来越少。如果我能决定，我更愿看到人们采用SDLC推荐的实践方法论(ISC)2，和新兴的OWASP实践，采用更多类似 CSSLP的认证。我希望，在那些大量的蹩脚软件毁坏我们的文明前，我们能和他们说拜拜。

展望

俱往矣，敏捷大潮。在DevOps中，那些遗留的严肃的、基础性的问题，我真的怀疑是否有人会解决它们。企业用户也将创造出恰如敏捷方法论的混杂方法，我们的软件技术文化不会得到实质性的提升。当前我们宁愿在超越文化和效用的文化上得过且过。

如果你真的想修复它，我将会马上谈一谈。同时你应该寻求系统工程，CMMI企业管理，安全测试，操作评估的帮助，并开始思考它怎么才能质变成DevOps。或者你可以远离企业软件实现，去基于产品的软件开发公司工作。这种过于简单的垃圾可能在软件开发公司能行得通，但是在企业客户环境里不行。（Toby Wootton最近使用PM角度阐述得很清楚）大企业已经切换到了AINO（名义上的敏捷）。

同时当你说到“敏捷软件开发”，每个人都知道你只是在提一个方法，它没有办法按承诺交付产品，它不适当的在广泛的被使用，它并不比瀑布模型或螺旋模型更先进，它有一些优点但更多的是缺点。没有魔术尘埃了，敏捷软件开发组织的几个创建者和很多其他有影响力的开发者都已经宣布敏捷已经死亡。只有在敏捷这个牌子的有既得利益的顾问和管理者们希望它还活着。

总结

总结如下：

(1)在营销炒作的推动下，敏捷已经成功知名品牌。因此它也遵循所有这类炒作产物的规则。首先是享有盛誉，接着就崩盘。基于现实结果，可能会存在一段长时间的接受期，亦或者没有。然而狂热的日子以及巨大的炒作将永远结束。这是一种营销意义上的“死亡”。

(2)当这发生后，由于幻想都无法实现，那些创建并采用这种方法技术的深刻编程思想家们将醒悟。替换和更改也没有实现方案的目标。它已经被那些深刻思想家所抛弃。核心技术价值已经失去。在极客的观念上意味着“死亡”。

(3)那些仍然在出售高度修改功能的敏捷，保持了原始名字但是有一点点原始的幻想。这种务实的观点被销售以及营销所驱动，正如它的名字在剩下的生命周期内仍然会被利用。例如，客户采用那些为符合公司治理机制以及企业管控进行巨大修改的敏捷。在AINO上看我的帖子。

这最后是现有采纳的本质，但炒作波已经结束或正在结束。这是一篇关于炒作技术、方法、营销和最终被发起者所放弃的品牌的帖子。它是关于剩下的愤世嫉俗的本质。它是关于在根本问题没有被解决时，旧品牌被新品牌所取代。

(注意：强调一下，软件开发和企业级架构的日常任务基本没有关系。（企业架构经常保持一系列的组织标准。敏捷可以是其中之一。这里面有一些可能的关联）但是，就像你们有些人知道的，我很久以前是一个整合项目的PM，一个解决型架构，并且在几年里自己做了一些协议，写了一些驱动，编过一些汇编。因为我对这个话题感兴趣。我不认为这是我许多个企业架构内容之一。在宣称我认为开发是企业架构上并没有更多的言论，谢谢。）

（注意：对我那些仍然追寻神秘的可以抛弃键盘和屏幕只保留你的思想和代码的同行来说，这部分意味着一项公共服务。你发布真实但是市场机器无视它。我开了枪，我不期望所有仍然推动敏捷（来赚钱）的管理顾问发布绝望的攻击并宣布它有一个无限光明的前景。这不是我为什么选择这个话题，我并不预期它成为如此有煽动性的话题。真的。我只是随机的选择了它。不？）