《敏捷宣言》诞生 20 年，敏捷成功了吗？

Posted 2021-09-03 小魔

对于广大程序员而言，“敏捷开发”并不是个陌生的词汇。这是一种从 1990 年代开始逐渐引起广泛关注的新型软件开发方法，是一种应对快速变化的需求的软件开发能力。相对于“非敏捷”，敏捷开发更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

2001 年，17 位软件行业领军人物共同发表了《敏捷宣言》，宣告了敏捷开发运动的正式开始。今年，距离《敏捷宣言》的发布已经过了 20 年，那么敏捷开发成功了吗？资深软件工程师、现 Simple Thread 联合创始人 Al Tenhundfeld 发表了自己的看法。

全文编译如下：

《敏捷宣言》诞生 20 年，有两个事实似乎不言而喻：

1. “敏捷”作为一个标签赢了，没有人想被称为“非敏捷”；
2. 然而在实践中，敏捷与其提出者的革命性理念相去甚远。

我们是怎么走到这一步的？—— 每个人都在做敏捷，然而几乎没有人是真正敏捷的。

《敏捷宣言》诞生史

2001 年 2 月，17 名软件行业专家在犹他州瓦萨奇山雪鸟滑雪场的小屋会面。经过几天的讨论和辩论，他们合作撰写了《敏捷软件开发宣言》（《敏捷宣言》）。

首先要强调的是，这些专家都是从业者。他们不是项目经理、CTO 或工程 VP，而是开发者、程序员、科学家和工程师，他们仍在写代码，并与利益相关者合作解决问题。这一点非常重要。

另一点是《敏捷宣言》并非凭空产生，这些专家中的许多人已经有了自己创建的方法论，并开始传播。他们都具备编写软件的丰富经验，并且都在寻求文档驱动的重量级软件开发流程的替代方案。

该宣言宣布了四种核心价值：

我们正在通过自己开发和帮助他人开发软件，来发现软件开发的更好方法。由此我们建立了如下价值观：

  个体和交互 高于 流程和工具
  可工作软件 高于 详尽的文档
  客户合作  高于 合同谈判
  响应变化  高于 遵循计划
  
也就是说，右栏中的项目固然有价值，但我们更重视左栏中的项目。

敏捷开发带来的新希望

站在 2021 年回望，我们很容易认为这些现代软件开发实践准则是理所当然的，但在 2001 年，这些想法非常激进。

什么叫“在收集所有需求和评估每一项功能之前就开始构建软件”？这太疯狂了！

被遗忘的重要一点是，敏捷在一开始就是公开、激进地反管理。例如，Ken Schwaber 直言，他的目标是除掉所有项目经理，从软件行业中根除这个职业。

“我们发现，在复杂的创造性工作中，项目经理的角色适得其反。项目经理的思维体现为项目计划，将项目中每个人的创造力和智力限制在计划中，而不是调动每个人的智力来最好地解决问题。”

Ken Schwaber，《敏捷宣言》签署人、Scrum 联合创始人

Scrum Masters 几乎没有权威，在问题上没有投票权。他们是仆人式的领导者，帮助保护和疏导团队，但不管理团队。

反击

在某些方面，敏捷是一场草根劳工运动。它从基层的从业者开始，被推到管理层。那么它是如何成功的呢？

部分原因在于开发者的数量及其对业务的价值不断增长，并获得了影响力。但在我看来，最大的因素是传统的瀑布方法根本不起作用。随着软件变得越来越复杂，业务节奏加快，用户越来越复杂，试图预先计划一切变得不再可能。拥抱迭代开发是合乎逻辑的，尽管这对于习惯于计划一切的管理者来说有点可怕。

我记得在 2000 年代中期的会议上，你可以看出管理层并不是真的买账，但他们也没有办法。

管他呢，要不就试试工程师一直在谈论的这个疯狂想法。反正还没到最后期限，再糟还能有多糟？

但令他们惊讶的是，敏捷开发开始奏效。团队会反复研究一段时间，然后慢慢站稳脚跟，发现哪些模式对团队有效，并获得动力。经过几次冲刺，你会看到优先考虑可工作软件、协作、花时间检查和适应等的真正力量。

在大约 5 年的时间里，“敏捷”从一种你听说过但可能不习惯于使用的方法发展成为每个人都在做的事情。2005 年我换工作的时候，对敏捷和 TDD 有一点了解，而这将我与其他人区分开来。到了 2010 年，人们普遍认为现代软件团队在做敏捷开发。

那么，敏捷开发赢了吗？事情并没有那么简单。

像许多革命一样，敏捷的历史并没有按照创始人的设想展开。

• 事实证明，优先考虑个人和交互是一个很难推销的概念，宣传流程和工具要容易得多；
• 可工作软件比不切实际的计划和大量文档更难制作；
• 与客户合作需要信任和脆弱性，而这并不总是出现在业务环境中；
• 对变化的响应往往被管理者压倒，他们希望掌控局面，且认为自己仍有理由为业务制定长期计划。

事实证明，敏捷做得不好会让人感觉混乱。

但这并不意味着《敏捷宣言》提出的四种核心价值是错误的。这只能说明我们需要付出一些努力才能做好敏捷开发，需要一些勇气去接受软件本质上混乱的事实。你必须理解并相信，如果你不断学习、适应、改进和运输，你最终会到达一个更好的地方，一个比瀑布开发更坦诚、更现实、更有生产力的地方。

敏捷运动并非反方法论，事实上我们很多人都想恢复 “方法论” 这个词的可信度。我们想要恢复平衡。我们接受建模，但不是为了在尘土飞扬的公司存储库中归档一些图表。我们接受文档，但不接受数百页从未维护过且很少使用的大部头。我们制定计划，同时也了解计划在动荡环境中的局限性。那些将 XP 或 SCRUM 或任何其他敏捷方法的支持者称为 “黑客” 的人，对 “方法论” 和“黑客”的最初定义一无所知。

Jim Highsmith，《历史：敏捷宣言诞生记》

这些很重要。我们仍然需要计划和文档记录，并在敏捷开发中保持严谨，这关乎平衡。然而，如果你的组织在敏捷转型中挣扎，淹没在混乱中，当有人以认证、流程和工具的形式为你提供救生艇时，你会立刻飞跃。高管们对流程和工具的理解远远超过他们对自组织团队的理解。

失败的反叛

然而在这方面，我并未看到勇敢的反叛者回归，至少在敏捷标签下没有。

工具供应商、流程顾问和专家做出了永远无法兑现的承诺，这就是为何我们最终得到了 SAFe、Scaled Scrum 以及其他企业的敏捷方式。这些框架并非恶意创建，它们甚至可能在恰当的语境中具备一定价值，但我不会称之为敏捷。试图扩展一种专注于个人和交互的方法将不可避免地导致问题，并侵蚀该方法的原始价值。

2018 年，《敏捷宣言》签署人、XP 联合创始人 Ron Jeffries 发表文章《开发人员应该放弃敏捷》并表示：

“敏捷”思想如果应用不当，会导致对开发人员的干扰更大，完成工作的时间更少，压力更大，并被要求 “进行得更快”。这对开发人员是不利的，最终对企业也是不利的，因为“敏捷” 做得不好往往会导致更多的缺陷，以及更慢的进度。通常，优秀的开发人员会离开这样的组织，进而导致企业的效率不如实施 “敏捷” 之前。

2014 年，《敏捷宣言》签署人、Pragmatic Programming 提出者之一 Dave Thomas 发表了著名的文章《敏捷已死，敏捷性万岁》：

“敏捷”这个词已经到了被颠覆的地步，敏捷社区看起来像是顾问和商家兜售服务和产品的舞台…… 《宣言》流行起来后，“敏捷”这个词就成为了营销术语。

所以我认为是时候淘汰“敏捷”这个词了。

重新流行

对我来说，真正可悲的是看到年轻开发人员诋毁敏捷，并认为这是管理层获取不切实际的承诺并迫使开发团队疯狂工作的手段。他们了解到的敏捷是强加的控制机制，而不是他们乐于拥抱的自我授权工具。但我希望围绕敏捷开发的历史和最初愿景展开一些讨论，帮助我们记住事情原本的发展走向。

好消息是《敏捷宣言》所提出的原则不管在今天还是在 20 年前都一样明智，即使像 Jeffries 和 Thomas 这样的反叛者也仍然这样认为。

Jeffries 在上面提到的文章中说，“然而，《敏捷软件开发宣言》的价值观和原则仍然提供了我所知道的最好的构建软件的方法，基于我长期和各种各样的经验，无论大型组织使用什么方法，我都会遵循这些价值观和原则。”

我同意他的观点。

现在谈论敏捷既不时髦也不酷。敏捷很无聊，每个人都做敏捷…… 但现在是回顾过去 20 年的敏捷发展过程，并提问自己如下问题的最佳时机：

什么是对的？出了什么问题？下次我们想做哪些不一样的事情？

我希望，我们能够通过研究敏捷宣言提出的核心价值和原则，从过去中学习。用 Dave Thomas 的话来说就是，即使我们选择放弃“敏捷”，我们也可以保持敏捷性。

原文链接：https://www.simplethread.com/...