前几天看到Infoq转载的文章“DevOps 已死，平台工程才是未来”，心生感慨。因为这不禁让人想起2014或2015年左右，敏捷宣言的提出者之一“Dave Thomas”在一次大会上发表的主题为“敏捷已死”的演讲，两者有非常相似的内涵。

“敏捷开发”和“DevOps”在诞生之后都对软件开发领域产生了巨大的影响，借用“Al Tenhundfeld”的说法，没有人想被称为非“敏捷”(或非“DevOps”)，这是作为一种“标签”的胜利。但是，“敏捷”或“DevOps”在真正的实践过程中往往偏离了一开始的初衷，甚至走向了反面。每个人都说他们在做敏捷，但几乎没有人是真正敏捷的，DevOps同理。

敏捷已死？

让我们先来重温一下“敏捷软件开发宣言”的内容：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：  

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

然后，按照宣言内容提到的价值观来观察一下现实：

推销“流程与工具”比“个人和互动”容易的多

生产不切实际的的计划和大量文档比生产可“工作的软件”容易的多

“合同谈判”带来的安全感比“客户合作”需要建立的信任更容易得到

管理层对“遵循计划”的需求往往高于对变化作出反应

而现实是如此残酷，因此当缺乏经验的团队实施敏捷的过程往往会陷入混乱。当各种“认证”、流程和工具自称能引导实现敏捷时，团队就会很自然的走向了敏捷的“反模式”。

当“敏捷”已经成为供应商兜售服务喝产品的标签时，当“敏捷”已经被颠覆到了毫无意义的地步时，是的，敏捷已死。

关于这个主题还可以看看Al Tenhundfeld的文章或者看看InfoQ的中文翻译版，本文不再赘述。

DevOps已死？

“DevOps”的提出要晚于“敏捷”，大约是在2009年为了突出重视软件开发人员和运维人员的沟通合作而被创造出来的组合词(即Development和Operations)。最初“DevOps”是一种理念，通过打破开发人员和运维人员之间的壁垒，来更快的交付和改进产品。

理想情况下，“DevOps”的落地会形成一个同时包含开发、运维人员的全功能团队并承担产品的上线运行、变更管理和维护等工作和职责。没错，这听起来就像是一个“敏捷”的自组织团队，共同努力为客户交付价值。因此要正确执行 DevOps，所有参与者都必须接受敏捷思维。

而现实是，在管理层正确的理解和支持的情况下，团队自底向上实施真正的DevOp近乎不可能。

某些组织会建立独立的DevOps团队来负责应用的部署和运维。这种情况下，即使使用了相关的工具，这种所谓的“DevOps”团队也只不过是对运维团队的另一种称呼。

另外一些组织则是简单的将在开发团队中增加所谓的“DevOps工程师”这类角色并负责相关职责，这不但增加了对“DevOps工程师”们的技能要求(需要同时了解开发和运维知识)，并且形成了新的“约束点”。

而与“敏捷”相似的，“DevOps”逐渐标签化，逐渐丧失了原有的语义而变成了流程、工具厂商推销产品的标签。开发与运维人员之间的壁垒不仅没有被打破，反而由于更高的交付压力而更加凸显。

追本溯源

“敏捷”和“DevOps”等运动或文化兴起的背后原因在于“软件危机”。“软件危机”所描述的核心问题就是：

如何开发软件，以满足对软件日益增长的需求
如何维护数量不断膨胀的已有软件

在上世纪60年代至90年代，通过在软件领域引入工程学而形成的“软件工程学”、结构化编程技术、面向对象的程序设计等等都是为了解决“软件危机”问题。而进入新世纪后，随着互联网等技术的发展，市场对软件的需求产生了爆发式的增长。由此催生出了“敏捷开发”、“DevOps”等新的方式来尝试解决“软件危机”。

可以预见的是，在上述问题没有解决之前，软件领域仍然会不断的催生出各种新的解决方案。例如，“低代码”工具希望在特定领域实现“公民开发者”(即非技术人员)可以直接参与解决方案的开发。又或者前文提到的“平台工程”、“NoOps”等等。

但我们仍应看到，软件开发的核心是开发者。“敏捷”与“DevOps”的内核体现的是对人的关注而非流程、工具之类。即使在2022年，“敏捷”与“DevOps”的原则也并没有过时。

保持心态

软件开发本身是工程学领域中一个比较年轻的分支。虽然发展速度很快并且融入了诸多交叉学科理论，但是仍然不能脱离工程学的基本原则，即“应用科学和技术的原理，来解决问题”。无论是“敏捷”还是“DevOps”，一切理论皆需要在实践中验证与修正。

最后，作为“工程师”，我们应该更深入的了解问题的本质，才能更好的理解新兴的潮流并保持一个平稳的心态。永远记得，“没有银弹”！