20 年起义，敏捷已死，敏捷万岁

开发者，你们真的享受到敏捷开发的好处了吗？

敏捷宣言（Agile Manifesto，敏捷软件开发）诞生至今刚好 20 年，有两个事实似乎不言自明。

1. 作为一个标签，敏捷是胜利者；没有人希望被称为“非敏捷”。

2. 但敏捷在实践上和创始人的革命性思想相去甚远。

我们是怎么走到这一步的？大家都说自己敏捷，但是很少有人真的敏捷。

宣言从何而来

2001 年 2 月，由 17 名软件专家组成的小组在数天的的讨论和辩论后，共同撰写了《敏捷软件开发宣言》（Agile Software Development Manifesto）。

首先要强调的是，这些人是实践者，并非项目经理、首席技术官或工程副总裁。他们是开发者、程序员、科学家和工程师。他们仍然在一线编写代码，并与他们的利益相关者合作，共同解决问题。这非常重要。

笔者注：我并不了解每一个签署人的个人历史，但是在我认识的人当中，他们要么还在编写代码，要么写代码写了很长时间。

还有一点是，《敏捷宣言》并不是凭空产生的。很多人已经有了他们自己创造的方法论，并且正在宣传。也许我的记忆有些偏离，但是我想所有这些方法在“敏捷”之前就已经存在了。极限编程（Extreme Programming，XP）、Scrum、DSDM、自适应软件开发、Crystal、特征驱动开发（Feature-Driven Development，FDD）、实用主义编程。Schwaber 和 Sutherland 曾在 1995 年公开讨论过 Scrum；我印象中 Beck 和 Jeffries 在 1996 年就开始谈论极限编程了。

这个小组中的每个人都有编写软件的丰富经验，他们都在寻求一种方法来代替重量级的文档驱动开发过程。宣言的核心有四项价值陈述：

我们身体力行同时帮助他人来探索开发软件的更佳方式，进而认可下列价值：

• 个体和互动高于过程和工具。（Individuals and interactions over processes and tools.）

• 可工作的软件高于详尽的文档。（Working software over comprehensive documentation.）

• 客户合作高于合同谈判。（Customer collaboration over contract negotiation.）

• 响应变化高于遵循计划。（Responding to change over following a plan.）

曙光乍现

站在 2021 年往回看，我们可以轻易地认为现代软件开发的许多实践是理所当然的，但是在 2001 年，这些想法都非常激进。

你说你要在收集所有需求并评估每一个特征之前就开始开发软件？你绝对是疯了。

实际上，敏捷从一开始就公开且激进地反对项目管理。举例来说，Ken Schwaber 就曾直言不讳地表示，他的目标是解雇所有的项目经理——不只是让这些人离开他的项目，而是要将这个职业从行业中铲除。

敏捷性与 PMI

我们发现，在复杂的创造性工作中，项目经理角色会起反作用。作为项目计划的代表，项目经理的思维会将项目中其他人的创造力和智慧限制在计划范围内，而不是调动每个人的智慧去最好地解决这些问题。

——Ken Schwaber，宣言签署人和 Scrum 共同创始人

Scrum Master 在这个问题上没有什么权威，也没有投票权。他们是仆人型的领导者，帮助保护和疏通团队，但不能管理团队。极限编程也是如此。假如我没记错的话，极限编程最初有跟踪者和教练，它们的气氛很像，都是大家互相鼓励和支持。

Alistair Cockburn（敏捷宣言签署人，水晶方法论 Crystal methodology 和六边形架构 Hexagonal architecture 创始人）最近对这一问题提出了非凡而深刻的见解，包括这一观点（转述）：

Scrum 在充满敌意的领域中达成了一桩伟大的交易：

1. 管理层每年有 12 次机会，在每次 sprint 结束后，以他们希望的方式改变方向。

2. 团队有一整个月的安静时间，没有任何干扰或者方向的改变，可以进行大量的思考和工作。

3. 在没有管理层干预的情况下，团队必须宣布他们在本月能做什么，不能做什么。没有哪位高管能得到比这更好的交易。没有哪个开发团队能得到更好的交易。

作为一名认证的 Scrum Master，我在敏捷团队里工作超过 15 年，我阅读过该领域的许多流行书籍。在这方面，我从来没有见过任何人能够如此清楚、简明扼要地阐述这一观点（再次引用 Cockburn）：

Scrum 的发明是为了在恶劣的环境下工作。它是一个强硬的管理者与开发者之间的契约，需要时间思考和探索。

反击战

从某种意义上说，敏捷是一场源自基层的劳工运动，从基层工作者开始，然后被推到管理层。为什么会成功呢？

部分原因是因为开发者的数量以及他们对公司的价值不断增加，从而获得了影响力。我认为最大的因素是，传统的瀑布开发方法并不可行。由于软件变得越来越复杂，业务变更的速度更快，用户的复杂性更高，预先计划每件事情都变得不可能。采用迭代式开发更合乎逻辑，尽管对习惯于计划所有事务的管理者来说有些可怕。

在 2000 年代中期的会议上，你能看到管理层并不买账，但是他们已经没有更好的主意了。

接着，令他们吃惊的是，敏捷开始慢慢奏效了。团队需要奋斗一段时间，然后慢慢成长，找出哪种模式更适合自己，并获得发展的动力。经过几次 sprint 之后，你会发现在优先考虑工作软件、协作、花时间检查、适应以及其他所有方面的真正力量。

敏捷花了 5 年左右的时间，从一种你听说过但可能从未使用过的的方法变成了每个人都在做的事情。在 2005 年，我换了工作，我还记得我当时只是对敏捷略有了解，而 TDD 才是真正的不同。2010 年，人们认为现代的软件团队都在进行某种形式的敏捷开发。

我们做到了！我们赢了！恭喜各位！

我非常希望故事到此结束。你可以关闭浏览器的标签页了。

赢很轻松，年轻人，治国才更艰辛。（Winning was easy, young man. Governing’s harder.）

——百老汇音乐剧《汉密尔顿》（Hamilton）中乔治·华盛顿的歌词

遗憾的是，像许多革命一样，敏捷并不像创始人预想的那样发展。

• 事实证明，优先考虑个体和互动是一个很难推广的概念。销售过程和工具要容易得多。

• 事实证明，比起不切实际的计划和堆积如山的文件，工作中的软件更难生产。

• 事实证明，与客户合作需要信任和脆弱性，而这在业务环境中并不总是如此。

• 事实证明，对于那些想要控制局面、同时又需要为自己的业务制定长期计划的高管来说，应对变化往往显得不够重要。

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

但这并不意味着这四种价值观都错了。这只意味着整个事情需要更多努力才能做好，也需要一些勇气去接受软件有时候本来就混乱无序的。你必须了解并相信，如果你一直在学习、适应、改进和提升，你最终将达到一个更好的境界，这比使用瀑布方法更诚实、更现实、更富有成效。

敏捷运动并不反对方法论，事实上，我们很多人都想要恢复方法论这一术语的可信度。我们想要恢复一种平衡。我们支持建模，但不是为了将一些图表存档到尘封的公司仓库中。我们支持文档，而不是几百页从来没有维护、很少使用的“大部头”。我们制定计划，但也承认在不稳定环境下计划的局限性。有些人把极限编程、SCRUM 或者任何其他敏捷方法的拥护者当做黑客来对待，他们根本不知道这些方法和“黑客”的最初定义。

——《历史：敏捷宣言》（History: The Agile Manifesto），Jim Highsmith

这些都很重要。对于敏捷，我们仍然需要计划和文档，并且具有严谨性。这涉及平衡。但是，如果你的组织在敏捷转型中挣扎，陷入混乱之中，那么当有人以认证、过程和工具的形式为你提供“救生艇”时，你就可以一跃而上。管理层对于过程和工具的理解要比对自组织团队更了解。

起义失败

不幸的是，我没有看到勇敢的反叛者在这一幕中卷土重来，至少在敏捷这个大方向下是如此。

工具供应商、过程顾问和专家们所作的承诺永远不能实现，这种情况已经泛滥成灾。因此，这就是我们最终采用 SAFe 和 Scaled Scrum 以及所有其他企业敏捷风格的原因。这些框架并非出于恶意而创建，它们甚至在正确的情况下具有一定的价值。但是我不认为它们是敏捷。尝试拓展一种注重个体和互动的方法论，会不可避免地带来问题，并侵蚀其方法论的原始价值。

我们正是这样结束了 Ron Jeffries 作为宣言签署人和极限编程的共同创始人在 2018 年发表的著名文章。

开发者应该放弃敏捷

如果不恰当地运用“敏捷”的理念，它们往往会导致开发人员更容易被干扰，缩短工作时间，增加压力，并且要求“更快地开展工作”。这样做不利于开发者，并最终影响到企业，因为不能很好地应用敏捷，通常会导致更多的缺陷和进展缓慢。优秀的开发者经常会离开这样的组织，导致企业的效率比安装“敏捷”之前要低。

我们正是这样结束了 Dave Thomas 作为宣言签署人和实用主义编程的共同创始人在 2014 年发表的著名文章。

敏捷已死（敏捷万岁）

“敏捷” 这个词已经被颠覆了，实际上已经毫无意义，而所谓的敏捷社区似乎主要是顾问和供应商兜售服务和产品的舞台……一旦《宣言》流行起来，“敏捷”一词就会吸引任何有观点支持、有时间收费、有产品销售的人。这已成为一个行销术语。

因此，我认为是时候让“敏捷”这个词退休了。

反思

看着年轻的开发者们诋毁敏捷，把它看成是管理层压榨不现实的承诺、迫使开发团队疯狂工作的一种方法，我感觉非常悲哀。好吧。他们唯一知道的敏捷是强加给他们的控制机制，而非一种他们乐于接受的自我授权工具。但是我希望，一些围绕着历史和最初设想的讨论能够帮助我想起来这件事本应如何演变。

《敏捷宣言》的原则在今天和 20 年前一样明智且有意义，甚至像 Jeffries 和 Thomas 这样的所谓反叛者也仍然这样认为。

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

我深以为然。

如今讨论敏捷既不时髦也不酷。敏捷很无聊。每个人都在做敏捷，对吧？现在是反思过去 20 年的最佳时机，问自己一些问题：

• 哪些地方做对了？

• 哪些地方出错了？

• 下次我们想做些什么不同的事情？

一些 Simple Thread 的员工正在经历这场革命，他们计划在未来几个月里重新思考最初的 12 条敏捷原则中的每一条，对其原始含义进行背景分析，并考虑它们在当前软件开发环境中的价值。

我希望我们能通过研究创始原则，从过去的经验中学到一些东西。用 Dave Thomas 的话说，即使我们选择放弃“敏捷”，我们也能保持敏捷。

原文链接：

https://www.simplethread.com/agile-at-20-the-failed-rebellion/