本文《Agile as Trauma》指出敏捷的本质是反动的（reactionary：保守、落后、反动）。敏捷就像任何概念一样，必须适应和学习，将产品管理和领域驱动设计的方法与敏捷相结合是我们今天所处的位置，但这种组合还没有被命名。
原文点击标题：
敏捷宣言是程序员对不良管理的免疫反应。宣言文件是受伤后的痛苦的表情，以及它的知识分子后代继续背负着这个包袱。虽然敏捷时代带来了项目管理技术和开发工具的显著进步，但它仍然是一个战术性的、技术性的、最终是反动的运动。
敏捷诞生的上下文
为了开始愈合，把敏捷放在更广阔的上下文环境中是很重要的。许多与敏捷相关的实质性思想早于它大约20到30年。这不是指控它剽窃，相反，这是一个断言软件开发有其特殊性，即使在技术和技术进步的情况下，这些模式也是不变的，因此您最终一定会重述这些模式。模式包括但不一定限于：
- 增量开发：软件是在模块中创建的：就像书是由章节组成的，而章节是由部分，段落和句子，它们本身在代码中就像在文本中一样逐字排列。基本结构不能组合成更大的结构，除非它们本身在内部是一致的，因此软件的创建，就像任何语言制品一样，是自然递增的。
- 迭代开发：不要被混淆增量发展。软件非常冗长，非常精确咒语信息系统应该如何表现. 整个过程简化为获取信息关于信息系统并将其凝聚成正式语言—如果您继续为其提供资源，这个过程永远不会自然终止：您可以总是回去把你写的东西和一些随着时间的推移，重访是规则。
- 跨职能团队：由于软件开发简化为收集和集中信息，很明显，这些信息将来自不同的来源，负责收集和集中信息的人员将具有不同的专业知识。而且，编程本身就是一种准唯我论的活动。程序员要求,严格说来，不比小说家或画家合作。因为软件开发是自然递增的，人们可以并行地在系统的不同部分上工作。这自然而然地让程序员自己拥有各种各样的专业知识。
- 固定时间，可变范围：就像任何其他媒介中的内容开发一样，软件开发减少到消除熵。不像然而，其他媒体几乎没有其他的计数. 问题是你和/或你的团队每单位时间只消除固定数量的熵，一开始你不知道问题中有多少位需要消除。你这么说我们要工作了这很多，而这个过程的另一端产生的结果就是你得到的。在目前的理论中，有时在实践中，这就是冲刺它们应该起作用，而不适合的物质会积累到一些积压或者其他。
- 用户参与：既然软件的目的是为用户服务，那么用户构成了一个重要的信息源，包括他们与原型的交互，以及作为被称为最小可行产品.
敏捷错在哪里
20年来，敏捷为我们提供了站立会议、sprint、结对编程、用户故事、DevOps和持续集成。这都是战术上的东西。
70年代敏捷讨论中最明显缺失的一个观点是概念完整性.
如果没有概念上的完整性，团队中有多少人就有多少个心智模型。这种状况就要求“某人说了算”的战略决策，
任何敏捷的拥护者都可以告诉你瀑布是坏的，如果你不是在做敏捷，你一定是在做瀑布。
还有一种观点认为：产品必须尽快进入市场，以获得先行者的优势，或者也许以更温和的形式，必须立即在市场上进行测试，以确保它是人们想要的东西。这些说法都不假，但它们也不是全部的真相。
尤其是，并非所有的软件都是Web应用程序。事实上，相当一部分软件不是消费品，甚至不是完全的消费品产品。
古特哈特定律的诅咒
古特哈特定律是一个简单的心理模型：当一个度量成为目标时，它就不再是一个好目标。当开发了“多少功能”称为程序员的考核目标时，它就不是一个好的目标了。
“功能”是程序员输出的一个单位，大致相当于一个子程序。“功能”可以作为一种管理控制，因为它们体现在最终产品中，而且它们与程序员时间的关系是最接近线性的。
“功能”也适用于市场营销，由于没有人可以否认一个功能的存在，一个方便的策略就是计算它们。在我们最新的版本中，有超过100个新功能！"。同样地，任何时候，信息传递都是这样的：我们的产品让你......，他们在谈论功能。的确，如果没有可敬的功能作为依托，各地的营销部门都会漂泊不定。
但是，“功能”这个衡量目标并没有用，因为它们很容易被操纵。
一个脆弱的、敷衍了事的、快速完成的功能实现会比一个强大的、完整的功能实现获得更多的内部夸奖。如果提出的问题是：产品A有X功能吗？ 那么答案是肯定的。这也使得功能成为竞争产品的一个虚假的比较基础，为什么说虚假？因为你需要认真地检查它们，以确定它们好到何种程度上。
"功能工厂 "作为一个贬义词来指代那些沉迷于增加功能的公司，同时积累了不可估量的所谓技术债务。
这种情况是由管理层为了营销的方便而推动的，我对更忠实于敏捷原则的应用能否纠正这种情况持怀疑态度。事实上，我怀疑敏捷过程在本质上很容易受到这种妥协的影响。
还有一个与软件开发相关的客观可计算的现象，那就是行为。产品是否在Y条件下做了X，也是一个经验问题，其答案是 "是 "或 "否"。程序员应该熟悉这种模式；这正是测试套件的编写方式。
行为比功能更有优势，因为你可以用行为来描述任何功能，但你不能用功能来描述行为。这是因为功能在软件静止时是可见的，而行为只有在软件运行时才是可见的。此外，功能的存在只能向用户表明一个目标是否可能实现，行为将决定实现该目标的痛苦程度。
我在这里要讨论的行为的最后一个优点是，它模糊了修复错误和建立功能之间的界限，并将这两者凝聚成一个雕塑行为的统一过程。功能的数量可能不会很快增加，但产品的行为将在微妙和适合方面稳步增长。我还打赌，行为不容易被操纵，因为任何尝试都会显得非常明显和愚蠢。市场部可以自己挖掘语料库中的可识别功能；反正他们已经做得差不多了。
什么时候冲刺才是真正的马拉松？
像其他创造性的工作一样，软件开发的速度不会因为我们可以消除那些使它变慢的现象而加快。
编程工具的进步确实可以消除一些变慢的现象，开发人员可以把更多的时间花在应用逻辑上。理想情况下，你可以直接告诉计算机你想要什么，它就会制造出来，但如果你能做到这一点，那么就不需要程序员了。
即使在一个没有程序员的世界里，仍然需要弄清楚，你想告诉计算机为你做什么：你希望它的行为是什么。
除了你用什么框架编写它，或者你是否使用NoSQL，或者你如何布置源码树之外，仍然有很多决定要做。
如果你排除了那些涉及到让工件工作的决定，剩下的决定将涉及到它是否比其他方式更好地工作。这些决定中的大部分都是试验和错误的结果，而其中相当大的一部分都涉及到用户的反馈。
。。。