敏捷宣言并未改变任何事情

当《敏捷宣言》于 2001 年首次出现时，整个行业刚刚从互联网泡沫的灾难性破灭中走出来。大量的资本涌入科技市场，每家公司都在“采用”互联网，但当不可避免的经济衰退到来时，许多软件工程师失去了工作。

由于 1998 年和 1999 年的低利率，90 年代末现金充裕，催生了一种新型的初创公司：互联网初创公司。许多企业家（通常没有能力真正执行自己的想法）被这个全新且蓬勃发展的市场可能性所蒙蔽，成功地将自己的企业推销给风险投资公司。虽然有一些非常成功的独角兽从这个泡沫中走了出来（比如谷歌的互联网搜索引擎、易趣的在线拍卖网站和亚马逊的互联网书店），但许多其他独角兽都失败了，不可避免地倒闭了，并重创了市场。

撇开糟糕的技术市场不谈，2001 年的软件世界是一个非常混乱、竞争激烈且“重流程”的地方。许多工程师都受制于可怕的瀑布式（Waterfall）软件开发方法：这是一种使用难以更改的严格需求来创建软件的系统。而且固定的软件产品交付期限几乎没有为任何迭代或集成测试留下空间。

在其他工程领域，瀑布式的效果不错：如果你正在建造一座桥梁，我当然希望你在开始建造之前就有一份要求、测量、材料和结构计算的清单。

但在软件领域，情况变化的很快，集成经常被中断，客户需求会毫无征兆地发生改变，因此通常需要一种更短、更简单的开发方法。你可能花了几个月的时间用瀑布式开发了一些软件，然后发现另一个部门的另一个团队提供的一些关键 API 集成与你所构建的软件完全不兼容（需要更长的瀑布周期）。或者，如果不是完全取消的话，你的项目可能会被业务降低优先级，（如果我们几个月前就能收到用户的反馈，这样我们就知道该做什么了……）。

上世纪 90 年代末和本世纪初，试图“采用互联网”的公司发现自己陷入到了冗长的工程流程和开发周期的泥潭中。这至少在一定程度上导致了互联网泡沫的经济崩溃：大量经济部门停滞不前，未能履行其对互联网业务价值和稳定性的夸大评估。我想知道，如果企业在早期技术革命期间采用更简单的敏捷方法，世界将会是什么样子：失败的企业会不会更少？如果是今天，我们的技术水平还会进一步提高吗？

值得庆幸的是，敏捷提出了一种不同的方法。

让我们想象一下，假设你团队的任务是构建并交付一辆软件汽车。在瀑布式开发中，你可能首先要建造车架，然后建造车轮，最后建造发动机，依此类推。很多事情都可能出错：如果最终产品不能满足客户的需求怎么办？如果你与道路软件套件的集成在交付时发生中断怎么办？或者你发现发动机部件实际上从未按预期工作，最终导致整个产品被损坏。汽车的计划和要求通常是由“业务部门”负责的，并在开发之初就交给了开发团队，但他们几乎没有进行更改的灵活性，也没有能力从真正的用户那里获取早期反馈。

相反，使用敏捷来构建这辆软件汽车，你将始终不断地交付可工作且经过测试的软件，并与了解客户需求的人员密切合作。你可以先交付一个滑板类型的东西。这建造起来足够简单；它有四个轮子，开门即用。然后，你可以把框架做得更大。你可以为小型推车式车辆添加一个发动机。为一辆汽车增加足够的座位。配置方向盘。添加收音机。最终，该项目将会完成，并且在此过程中，开发团队能够从真实用户那里获得反馈，并不断与现有系统集成，边开发边测试（团队在早期就能发现与道路系统的集成失败！）。

敏捷软件开发提出的原则对 2023 年的工程师来说似乎是显而易见的，但在当时，这些想法有趣、微妙且强大：始终交付可工作的软件，测试代码，持续集成，进行面对面的对话，优先考虑与团队中人的关系，快速适应不断变化的需求，与业务人员密切合作，让团队自组织以获得最佳结果。

就像任何好的“宣言”一样，所有这些都被包含在一个简单而优雅的文档中：《敏捷宣言》。这并不是来自业内权威人士的；它是由从事实际工作的软件工程师编写并签署的。它的诞生听起来就像是小说中的情节：2001 年的冬天，17 名软件开发人员聚集在犹他州的雪鸟城（Snowbird），滑雪、吃饭、喝酒，并讨论软件行业（但不幸的是，他们并没有进行什么史诗般的探索）。像 Kent Beck（后来建立了极限编程）、Andrew Hunt 和 David Thomas（《程序员修炼之道——The Pragmatic Programmer 的合著者）以及 Jeff Sutherland（scrum 项目管理方法的先驱）这样的人。他们都出席了。输出了一个单一、简单的文档，概述了一个理想、精益且高效的软件组织工程过程。

敏捷开发最终将成为其他软件开发系统的基石，如 Scrum、DevOps、极限（Extreme）编程和平台工程。这些后续的开发系统在很大程度上强调了敏捷中的不同原则；如持续交付、持续集成自动化套件、各个贡献者之间的关系，以及轻松地为个人贡献者和开发团队部署和交付优化的开发环境。但贯穿所有这些方法的方法论是敏捷。敏捷仍然是支柱。敏捷赋予了这些方法生命。

尽管敏捷看起来是关于过程和如何完成工作的，但《敏捷宣言》首先也是最重要的是对一个正在分崩离析、从内到外自相残杀并耗尽人才的行业的回应。

《敏捷宣言》的核心是：

一套基于相互信任和尊重的价值观，促进以人为本、协作为基础的组织模式，并建立我们希望为其工作的组织社区类型。

接受敏捷工程流程也意味着接受了围绕并包含敏捷的文化理想。经常测试、发布工作代码、持续集成等工程流程仅服务于支持自组织团队蓬勃发展的工程组织类型，在这里，人们热爱他们所做的工作，并且信任其工程师同事。

如今，大多数软件组织都会说他们已经采用了敏捷（或者至少采用了某种敏捷的派生形式）。然而，我认为该行业在采用敏捷的真正核心方面并没有达到目标。

我们发现自己的处境与 2001 年的网络泡沫破灭非常相似；利率不断上升，大批软件人才以最糟糕的方式被解雇，优先事项从协作和心理安全的工程组织转移到更高效地交付产品上。

似乎整个行业都在抵制敏捷的理念。

我最担心的是，《敏捷宣言》并未改变任何事情，因为越来越多的部门都变成了我不想为之工作的地方。

我首先要承认：敏捷需要时间、精力和奉献精神。但这并不总是那么容易。回顾、规划会议、用户研究（等等）都需要时间和工程资源。 时间并没有花在编码或直接处理产品上。但是，如果说过去 20 多年的科技繁荣市场向我们展示了什么，那就是敏捷在行业中被广泛采用了，这就是敏捷的作用。快乐的工程师热爱他们的工作，提供了令人惊叹的解决方案，从长远来看，他们打造更具可持续性的组织，这些组织可以持续交付客户喜爱的稳定和创新的产品。

如果到目前为止，你还在读这篇文章，会发现自己在说“嗯，网络泡沫有点像今天的科技市场”，那是因为它确实如此。从经济、文化和工程流等程角度来看。当经济不景气时，工程组织似乎都会变得更糟。

埃隆·马斯克（Elon Musk） 收购推特（Twitter） 就是一个主要且引人注目的例子：大多数工程师都被解雇了，出现了多次长时间的停机，有传言称内部基础设施系统严重受损，以及出现了一种新的“极端硬核”文化，所有这些都是为了寻找盈利能力和交付软件需求的运动。

但埃隆·马斯克不应该受到指责。推特的问题早在收购之前就已经存在了：

在 2019 年加入推特不久，Dantley Davis 将他的员工聚集在公司旧金山总部的一个会议室里……他要求员工们在会议室里四处走动，相互赞扬和批评。他说，严厉的批评将有助于推特的改进。倒刺很快就飞了起来。据在场的三名人士说，在两个小时的会议中，有几名与会者都哭了。

这听起来肯定不像是“我们希望在其中工作的组织社区类型”。

这一点意义重大，因为科技市场是一只自食其力、总是自相残杀的野兽：无论大公司做什么，尤其是像谷歌、Meta 和亚马逊这样公司，科技市场的其他公司都会紧随其后。工程文化、薪酬、面试等方面的这些趋势总会渗透到行业的其他领域。所以，在你不自知的情况下，埃隆·马斯克对推特的收购可能就已经影响到了你。

2023 年的裁员和缩编可能还没有结束。许多经济学家认为，我们正走向衰退（如果还没有衰退的话），这可能会加速许多公司的文化和工程组织变革。就像 2001 年互联网泡沫破灭时一样，今天的软件和科技行业必须要面对经济的冲击。

但我对未来的希望是，工程组织和领导层认识到这一正在重复的历史，改变方向，并继续专注于为他们工作的精益和敏捷流程。否则，我们可能会看到更多像推特这样的公司，它们的商业模式失败了，基础设施崩溃了，稳定性令人遗憾，也许最糟糕的是，它们是一个没有人愿意加入的工程组织。

原文链接：https://onengineering.substack.com/p/how-the-agile-manifesto-changed-nothing