敏捷开发将走向消亡，我们该如何应对

作者 | Ulises Ramirez-Roche

译者 | 弯月 责编 | 王晓曼

出品 | CSDN（ID：CSDNnews）

如果使用得当，敏捷方法论能够兑现其承诺：更快、更可靠地交付软件，并且在业务团队和工程团队之间建立信任。然而，我们很难正确地应用敏捷方法论，尤其是在规模比较大的时候。如果使用不恰当，敏捷方法论就是万丈深渊。

拯救敏捷的尝试都会以失败告终，因为这场战争在很久以前就已经输掉了。事实上，在2021年敏捷就已经一败涂地了。甚至是敏捷的创始人都表明放弃敏捷方法论了。

瀑布式开发可能已经消失了，而敏捷已经完全沦为了一群不懂软件开发的商人的“玩物”，这就是为什么现代软件开发成为了一个反乌托邦，如今回忆起 1984 年会觉得温馨又怀念。

我从事软件开发已有十余年，而敏捷的成功运用，我只见过两次，而且我本人就是这两个项目的技术负责人。不幸的是，我参与的所有其他敏捷项目都惨遭失败，看看我的简历，你就会发现其中都是苏格兰谬误（No true Scotsman，讽刺一些人的观点“失败的项目都不是真正的敏捷项目”）。

万物都必须学会适应，否则就会走向灭亡。那么，如何才能杀死一条巨龙呢？你可以等待英雄来拯救我们，也可以等待这条龙慢慢变老，然后自然死亡。在我们的世界里，《星球大战》的结局是：卢克·天行者被杀，达斯·维德死在床上，帝国即将崩溃。

在我们的世界里，新冠疫情加速了敏捷的发展，在家办公成为了常态，所有软件开发如今都是在分布式环境中完成的。

为什么 Scrum 会消亡？

关于这个问题的讨论早就有了结论，但问题是为什么是现在？

“能够替代Scrum” 将成为软件开发中最大的卖点。Scrum 作为主流敏捷框架将消亡，因为它起不到任何作用，而且也不具备可扩展性。随着各家公司由于项目反复失败而感受到压力，再加上由于技术债务导致代码库愈发混乱，他们会逐步转向专为大规模分布式软件开发而设计的敏捷框架。

但是，正如美国作家厄普顿·辛克莱所说：

“当一个人要靠着对某件事情的不理解来拿薪水时，要让他理解这件事情是很困难的。”

—— 厄普顿·辛克莱

Scrum会消亡，但敏捷仍然会存在，因为这是主流，而 Scrum 只是一只替罪羊。但敏捷本身并不是为我们生活的这个时代而设计的。在我们这个时代，软件开发是分布式的，在家办公是常态，因此投资者无法忽视因失败而付出的高昂代价。

我们正处于软件行业历史发展的十字路口，因为混乱带来了机遇，我们有机会修复敏捷，并修复业务与工程之间的鸿沟。我们将要面临的是“诸神的黄昏”，这是一场伟大的自然选择之战，要么适应，要么死亡。然而，什么才是新的 Scrum 呢？这仍然是一个未解之谜。

为什么 Scrum 还没有消亡？

普朗克曾经说过：

“一个新的科学真理取得胜利并不是通过让它的反对者们信服并看到真理的光明，而是通过这些反对者们最终死去，熟悉它的新一代成长起来。”

这就是著名的普朗克科学定律。

尽管我们都知道“敏捷行不通”，“Scrum 不具备可扩展性”，“真正理解Scrum的人不会错误地实施 Scrum”，但这并不重要，因为这场战斗的意义并不在此，这是中层管理人员与开发人员之间的权力斗争。

敏捷宣言是技术人员对于非技术管理者（和许多技术管理者）不断实施微观管理的反抗，这些人对于技术一窍不通，直到今天依然如此。而 Scrum 则是非技术管理者的回击，他们希望重新获得对项目以及开发人员的控制权。

Scrum还没有消亡，因为公司的消亡非常缓慢，因为 Scrum 是一个糟糕的微观管理优先框架，它给人一种生产力的错觉，同时将责任转移到开发人员身上。Scrum 框架就是一个典型的流程重于人的例子。

Scrum只适合纸上谈兵，如果应用得当就会奏效，然而我们根本无法在实践中实施 Scrum。但是，“真正的 ScrumMaster不会……”的论点纯属胡说八道，我们心知肚明。

Scrum将如何消亡

在新冠疫情爆发之前，在 Web 2.0 的推动下，科技行业发展迅猛，遍地黄金，因此即便是构建软件花费巨额成本，也没人在乎。

人类都喜欢安于现状，因此敏捷也得到了社区的支持。但敏捷本身是它那个时代的产物，而如今软件开发步入了分布式的新时代。而软件开发的费用如此巨大，总有一天资金会出现短缺，相应的也会有公司陷入绝境。

Scrum将会消亡，因为 Scrum 的设计有一个前提：各个团队之间需要面对面地互动。大部分交流都是非正式的，而且必须以密切的合作为基础。然而，分布式开发需要正式的沟通，文档成为了信息流的重要组成部分。于是，结对编程之类的实践失去了价值，也无法保持高质量，而且集成代码的难度增大，团队之间的协调也越来越困难。我们无法进行正确地评估，因为没有准确的信息作为基础。最终，由于冲突和误解太多，导致整个项目举步维艰。

从本质上讲，敏捷和 Scrum 的设计前提是：所有人都在办公室工作。眼下在家办公已成为常态的情况下，Scrum理论本身就有问题，又何谈实践呢？

如今，每个采用了敏捷开发的人都进入了黑暗阶段。而这一次，仍然有人抱有希望，以“真正的 Scrum Master 不会……”为借口。但是这一次，屠龙英雄不会来。

事实上，公司越大，遭受的打击就越大，越剧烈。生产力会一落千丈，业务团队和工程团队会争锋相对。每一个 Sprint 都会变成一次死亡行军。这个过程不断重复，开发软件的成本越累越高，直到最后资金耗尽。

一些公司为了缓解压力，会放弃 Scrum 并尝试新框架，但大多数公司都将死在黑暗 Scrum 阶段。Scrum 将成为过去，因为在分布式环境中开发软件的挑战将打破 Scrum 日复一日努力编织的梦幻，Scrum 所有的认证（包括Scrum Master）都会消亡。

只有适应时代的人才能生存下来，但绝大多数都会被其他公司所吞噬。

如何挺过这场灾难

为了挺过即将到来的诸神黄昏，各个公司必须将开发流程中的 Scrum 替换掉。当然，他们不能在敏捷上犯错误，因为在分布式环境中开发软件的风险要高得多。这个新世界是一片没有奇迹的土地。再也不能靠运气了，因为现在所有问题的根源不仅是技术债务，还有沟通。

当初巴比伦人的傲慢招致上帝的不满，于是上帝让他们说不同的语言，并将他们分散到世界各地，从而扰乱了他们的交流。这是一种真正的设计模式，你可以了解一下。

因此，各个公司必须正确地使用敏捷，弥合业务团队和工程团队之间的鸿沟，否则就做好被时代遗忘的准备。

你必须改善沟通，并偿还技术债务。首先，弄清楚自己是否身处黑暗的 Scrum 之中，并制定一个摆脱计划。接下来，理解敏捷的核心概念，并做一些尝试。最后，建立自己的框架。

如果你没有权力在组织中实现这些变化，则不要攻击想象中的敌人。首先，这个问题牵扯的范围很广；其次，有些人仍然沉浸在 Scrum 的幻想中，他们会不惜一切代价保持现状，而你会成为他们的攻击目标。你会被解雇。你要学会低调，或者另找一份工作。记得面试的时候，一定要问一问他们对 Scrum 的看法，以及他们如何应对向分布式开发的转变。如果有人意识到这个问题的严重性，则你可以考虑加入他们公司。

我们面临的是一个充满巨大变化和实验的时代，也是一个充满动荡和冲突的时代。我们将被迫抛弃旧方式，并寻找新方式，因为我们生活在一个没有办公室的世界。但我希望这个时代会更加美好。我希望找到取代 Scrum 的新方式，并将开发人员的快乐放在首位。

原文链接：

• https://www.ulisesrmzroche.dev/archives/2021/08/agile-armageddon/