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/