20 岁的敏捷：失败的反叛

敏捷宣言今年 20 周年，有两个事实似乎是不言而喻的：敏捷在实践中与创始人的革命性思想相去甚远。我们是如何走到这一步的？每个人都说他们在做敏捷，但几乎没有人是敏捷的。 2001 年 2 月，一个由 17 位专家软件从业者组成的小组在犹他州瓦萨奇山脉雪鸟滑雪胜地的小屋会面。经过几天的讨论和辩论，他们共同撰写了“敏捷软件开发宣言”。 * 我不知道每个签名者的个人历史，但在我认识的那些人中，他们要么仍在积极编写代码，要么有一段很长的近期历史。首先要强调的是，这些都是从业者。他们不是项目经理、CTO 或 VP Engs。他们是开发人员、程序员、科学家和工程师。他们仍在编写代码*并与利益相关者合作解决问题。这个很重要。另一点是敏捷宣言不是凭空产生的。这些人中的许多人已经有了他们创造和/或正在传教的方法。我的时间可能有点偏离，但我认为所有这些方法论都预先存在“资本敏捷”：极限编程、Scrum、DSDM、自适应软件开发、Crystal、功能驱动开发、实用编程。我知道 Schwaber 和 Sutherland 在 1995 年公开谈论过 Scrum，而贝克和杰弗里斯在 1996 年开始谈论极限编程 (XP)，我想。

这个小组中的每个人都有丰富的软件编写经验，他们都在寻找替代文档驱动的、重量级软件开发流程的方法。宣言的核心是四个价值陈述：我们正在通过做和帮助他人来发现更好的软件开发方法。通过这项工作，我们开始重视： 个人和交互胜过流程和工具 工作软件胜过综合文档 客户协作胜过合同谈判 响应变化胜过遵循计划 也就是说，虽然右边的项目有价值，但我们重视左边的项目更多。从我们 2021 年的观点来看，很容易将如此多的现代软件开发实践视为理所当然，但在 2001 年，这些想法非常激进。在收集所有需求并估算每项功能之前，您打算开始构建软件是什么意思？这太疯狂了！被遗忘的重要部分是，敏捷一开始就公开、激进地反对管理。例如，肯·施瓦伯 (Ken Schwaber) 直言不讳地表达了他要解雇所有项目经理的目标——不仅仅是让人们离开他的项目，还要从我们的行业中根除这个职业。

我们发现项目经理的角色在复杂的创造性工作中会适得其反。以项目计划为代表的项目经理的思维将项目中其他人的创造力和智慧限制在计划的创造力和智慧上，而不是调动每个人的智慧来最好地解决问题。 Scrum Masters 几乎没有权威，没有投票权。他们是仆人式领导者，帮助保护和疏通团队，但不管理团队。 XP 是类似的。如果我没记错的话，XP 最初有跟踪器和教练，它们具有类似的促进、支持氛围。 Alistair Cockburn，Crystal 方法论和六边形架构的宣言签署人和创造者，最近有一个奇妙的、有见地的线索，包括这个想法（解释）：管理层每年有 12 次以他们想要的任何方式改变方向，在每个冲刺之后.团队获得了整整一个月的安静时间，没有中断或方向的变化来进行繁重的思考和工作。团队必须宣布他们在本月可以做什么和不能做什么，而管理层不会干预他们的竞标。我是一名经过认证的 Scrum Master，在敏捷团队工作了 15 年以上，并且我阅读了该领域的许多流行书籍。我从未见过有人如此明确和简洁地描述这个想法（再次解释科伯恩）：

发明 Scrum 是为了在恶劣的环境中发挥作用。这是需要时间思考和探索的强硬经理和开发人员之间的契约。在某些方面，敏捷是一场草根劳工运动。它当然从实地的从业者开始，然后被推到管理层。这是如何成功的？部分原因是开发人员的数量和业务价值不断增长，影响力越来越大。但在我看来，最大的因素是传统的瀑布方法根本行不通。随着软件变得越来越复杂，业务步伐加快，用户的复杂程度不断提高，试图预先计划一切变得不可能。拥抱迭代开发是合乎逻辑的，如果对于习惯于计划一切的经理来说有点可怕。我记得 2000 年代中期的会议，你可以看出管理层并没有真正购买它，但他们没有想法。到底是什么，让我们试试工程师们一直在谈论的这个疯狂的想法。我们现在没有赶上最后期限。它会变得更糟多少？然后令他们惊讶的是，它开始工作，有点，断断续续地开始。团队会挣扎一段时间，然后慢慢地站起来，发现哪些模式对单个团队有效，从而获得动力。经过几次冲刺后，您会开始看到优先考虑工作软件、协作、花时间检查和适应以及所有其他方面的真正力量。在大约 5 年的时间里，敏捷从一种你听说过但可能并不习惯于每个人都做过的方法。 2005 年，我换了工作，我记得我对敏捷有一点了解，而 TDD 是一个真正的差异化因素。到 2010 年，人们认为现代软件团队正在做一些敏捷的工作。至少，我在咨询界的泡沫是这样的；大企业总是动作缓慢。

这就是故事的结局。你可以继续关闭浏览器选项卡。🥳 不幸的是，像许多革命一样，敏捷的历史并没有像创始人所设想的那样展开。事实证明，优先考虑个人和互动是一个很难推销的概念。销售流程和工具要容易得多。事实证明，与不切实际的计划和大量文档相比，可运行的软件更难生产。事实证明，与客户合作需要信任和脆弱性，在商业环境中并不总是存在。事实证明，高管们想要掌控一切，但仍然需要为他们的业务制定长期计划，这往往比对变化做出反应更重要。这并不意味着这四个值是错误的。这只是意味着整个事情需要一些努力才能正确，需要一些勇气来接受软件有时本质上是混乱和混乱的。你必须理解并相信，如果你不断学习、适应、改进和运输，你最终会到达一个更好的地方，一个比瀑布更诚实、更现实、更高效的地方。

敏捷运动并不反对方法论，事实上我们很多人都想恢复方法论这个词的可信度。我们想要恢复平衡。我们接受建模，但不是为了在尘土飞扬的公司存储库中归档一些图表。我们接受文档，但不接受数百页从未维护和很少使用的大部头。我们计划，但认识到在动荡的环境中计划的局限性。那些将 XP 或 SCRUM 或任何其他敏捷方法论的支持者称为“黑客”的人是对方法论和术语“黑客”的原始定义一无所知的人。这些都是重点。我们仍然需要在敏捷中进行计划和记录并保持严谨。这是关于平衡。但是，如果您的组织正在为敏捷转型而苦苦挣扎，陷入混乱，当有人以认证、流程和工具的形式为您提供救生艇时，您就会飞跃。高管们对流程和工具的了解远远超过他们对自组织团队的了解。这是我的三幕结构有点崩溃的地方，因为不幸的是，我没有看到勇敢的叛逆者重新回到这个结构上，至少不是在敏捷标签下。工具供应商、流程顾问和专家做出了永远无法兑现的承诺，已经超出了它的范围。这就是我们最终采用 SAFe 和 Scaled Scrum 以及所有其他企业敏捷风格的方式。这些框架并非出于恶意而创建，它们甚至可能在正确的上下文中具有一定的价值。但我不会称它们为敏捷。试图扩展一种专注于个人和互动的方法论将不可避免地导致问题——并侵蚀该方法论的原始价值。这就是我们最终获得宣言签署者和 XP 共同创作者 Ron Jeffries 的 2018 年著名作品的方式。当“敏捷”理念应用不当时，往往会导致对开发人员的更多干扰、更少的工作时间、更高的压力以及“更快”的要求。这对开发人员不利，最终对企业也不利，因为“敏捷”做得不好，往往会导致更多的缺陷和更慢的进展。通常，优秀的开发人员会离开这样的组织，导致企业效率低于安装“敏捷”之前。这就是我们最终获得宣言签署者和实用编程共同创作者戴夫·托马斯 (Dave Thomas) 2014 年著名作品的方式。

“敏捷”这个词已经被颠覆到了实际上毫无意义的地步，敏捷社区所传递的似乎主要是顾问和供应商兜售服务和产品的舞台……一旦宣言流行起来，敏捷这个词就变成了吸引任何有支持点数、账单时间或产品销售点的人的磁铁。它变成了一个营销术语。对我来说，真正令人难过的部分是看到年轻的开发人员诋毁敏捷，并将其视为管理层提取不切实际的承诺并推动开发团队疯狂工作的一种手段。我得到它。他们所知道的唯一敏捷是强加于他们的控制机制，而不是他们欣然接受的自我赋权工具。但我希望围绕历史和原始愿景展开一些讨论可以帮助我们记住事情应该如何发展。所有这一切的好消息是，敏捷宣言的原则在今天与 20 年前一样明智和相关。甚至像杰弗里斯和托马斯这样的假想叛教者仍然这么认为。 Jeffries 在上面提到的文章中说，“然而，敏捷软件开发宣言的价值观和原则仍然提供了我所知道的构建软件的最佳方式，并且根据我长期而多样的经验，我会遵循这些价值观和无论大型组织使用什么方法，都遵循原则。”现在谈论敏捷并不时髦或酷。敏捷是无聊的。每个人都做敏捷，对吧？现在是反思过去 20 年并问自己几个问题的最佳时机：我们 Simple Thread 中的一些经历过革命的人计划在未来几个月内反思最初的 12 条敏捷原则中的每一条，将它们的原始原则置于语境中意义，并考虑它们在当前软件开发环境中的价值。我希望通过研究创始原则，我们可以从过去吸取教训，用 Dave Thomas 的话来说，即使我们选择放弃“敏捷”，我们也能保持敏捷。