敏捷已死：一场程序员们历经20年的失败反叛

Posted 2023-04-04 彼岸教育Beacon

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了敏捷已死：一场程序员们历经20年的失败反叛相关的知识，希望对你有一定的参考价值。

敏捷宣言20周年之际，有两个事实似乎不言自明。

1. 敏捷，作为一个标签，赢了；没有人想被称为非敏捷。

2. 但是，敏捷在实践中远远低于其创始人的革命性思想。

我们是如何走到这一步的？每个人都说他们在做敏捷，但几乎没有人是真正敏捷的。

注：敏捷宣言（Agile Manifesto），也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。

点击下方链接自测是否符合美国百年理工强校计算机硕士入学申请资格，同时还可以免费观看IT大咖们的热情分享，包括人工智能家具的应用、计算机视觉的就业和学习等热门话题，欢迎大家观看

美国百年理工强校计算机硕士

1、宣言从何而来？

2001年2月，一个由17位专家软件从业者组成的小组在犹他州瓦萨奇山脉滑雪胜地的小屋会面。经过几天的讨论和辩论，他们共同撰写了“敏捷软件开发宣言”。

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

另一点是，敏捷宣言不是凭空产生的。

这些人中的许多人已经有了他们创造或正在宣传的方法论。我的时间可能有点偏离，但我认为所有这些方法论都预先存在“资本敏捷”：极限编程、Scrum、DSDM、自适应软件开发、Crystal、功能驱动开发、实用编程。我知道 Schwaber 和 Sutherland 在 1995 年公开谈论过 Scrum，而贝克和杰弗里斯在 1996 年开始谈论极限编程 (XP)，我想。

这个小组中的每个人都有丰富的软件编写经验，他们都在寻找替代文档驱动的、重量级软件开发流程的方法。

宣言的核心是四项价值陈述：

官网信息中文译文

2、窥见曙光

从我们 2021 年的角度来看，很容易将如此多的现代软件开发实践视为理所当然，但在 2001年，这些想法非常激进

被遗忘的重要部分是，敏捷一开始就公开、激进地反对管理。

例如，肯·施瓦伯 (Ken Schwaber) 直言不讳地表达了他要解雇所有项目经理的目标——不仅仅是让这些离开他的项目，而是要从计算机相关行业中彻底根除项目经理这个职业。

敏捷性和 PMI

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

Ken Schwaber，宣言签署人和 Scrum 共同创建者

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

极限编程是类似的。如果我没记错的话，极限编程最初有跟踪器和教练，它们具有类似的促进、支持氛围。

Alistair Cockburn 是水晶方法论和六边形建筑的宣言签署人和创造者，最近对此提出了一个奇妙的、有见地的想法：

Scrum 在充满敌意的领域达成了一笔为大的交易：

管理层每年有12次机会，在每次sprint结束后，以他们想要的任何方式改变方向。

团队获得了每月的安静时间，没有中断或方向的变化，专注于进行繁重的思考和工作。

每月管理层干预的情况下，团队必须宣布他们在本月可以做什么和不能做什么。

没有哪位高管得到过比这更好的交易。
没有开发团队得到过比这更好的交易。

我是一名经过认证的 Scrum Master，在敏捷团队工作了15年以上，阅读过该领域的许多流行书籍。我从未见过有人如此明确和简洁地描述这个想法（再次引用一句Cockburn的话）：

发明 Scrum 是为了在恶劣的环境中发挥作用。这是需要时间思考和探索的、强硬管理者和开发人员之间的契约。

3、反击战

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

部分原因是开发人员的数量和业务价值不断增长，影响力越来越大。但在我看来，最大的因素是传统的瀑布方法根本行不通。

随着软件变得越来越复杂，业务步伐加快，用户的复杂程度不断提高，试图预先计划一切变得不可能。拥抱迭代开发是合乎逻辑的，如果对于习惯于计划一切的经理来说有点可怕。

我记得2000年代中期的会议，你可以看出管理层并没有真正买账，但他们没有更好的想法。

——那就让我们试试工程师们一直在谈论的这个疯狂的想法吧。

然后令他们惊讶的是，它开始奏效了。

起初，团队会挣扎一段时间，然后慢慢成长，发现哪些模式对单个团队有效，从而获得动力。经过几次冲刺后，你会开始看到优先考虑工作软件、协作、花时间检查和适应以及所有其他方面的真正力量。

在大约5年的历程，敏捷已经从一个未曾实践的方法变成了人人都在做的事情。2005 年，我换了工作，我记得我对敏捷有一点了解，而 TDD 是一个真正的差异化因素。到2010年，人们认为现代软件团队正在进行某种形式的敏捷开发。

🎉🎉我们做到了！我们赢了！恭喜大家！🎉🎉

这就是故事的结局。

——如果你希望如此，那么到此结束吧，接下里发生的事，你可以选择不再看下去了。

4、现实·反转

获胜很容易，年轻人。治理更难。

诚如百老汇音乐剧《汉密尔顿》中乔治·华盛顿所言

不幸的是，像许多革命一样，接下来的故事并没有像创始人所设想的那样展开。

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

事实证明，与不切实际的计划和大量文档相比，可运行的软件更难生产；

事实证明，与客户合作需要信任和脆弱性，在商业环境中并不总是存在；

事实证明，高管们想要掌控一切，但仍然需要为他们的业务制定长期计划，这往往比对变化做出反应更重要；

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

这并不意味着这四个值是错误的。这只是意味着整个事情需要一些努力才能做得正确，需要一些勇气来接受软件有时本质上是无序混乱的。

你必须理解并相信，如果你不断学习、适应、改进和提升，你最终会到达一个更好的地方，一个比瀑布方法更诚实、更现实、更高效的地方。

敏捷运动并不是反对方法论，事实上我们很多人都想恢复方法论这个词的可信度。我们想要恢复平衡。

我们接受建模，但不是为了在尘土飞扬的公司存储库中归档一些图表；我们接受文档，但不接受数百页从未维护和很少使用的大部头；我们指定计划，但认识到在动荡的环境中计划的局限性。

那些将 XP 或 SCRUM 或任何其他敏捷方法论的支持者称为“黑客”的人是对方法论和术语“黑客”的原始定义一无所知的人。

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

这些都是重点。我们仍然需要在敏捷中进行计划和记录并保持严谨。这关乎平衡。
但是，如果你的组织正在为敏捷转型而苦苦挣扎，陷入混乱，当有人以认证、流程和工具的形式为你提供救生艇时，你就会一跃而上。

高管们对流程和工具的了解远远超过他们对自组织团队的了解。

5、敏捷已死

这是我的三幕结构有点崩溃的地方，因为不幸的是，我没有看到勇敢的叛逆者重新回到这个结构上，至少不是在敏捷标签下。

工具供应商、流程顾问和专家做出了永远无法兑现的承诺，已经超出了它的范围。这就是我们最终采用 SAFe 和 Scaled Scrum 以及所有其他企业敏捷风格的方式。这些框架不是出于恶意而创建的，它们甚至可能在正确的上下文中具有一定的价值。但我不会称它们为敏捷。

试图扩展一种专注于个人和互动的方法论将不可避免地导致问题——并侵蚀该方法论的原始价值。

此为Ron Jeffries 作为宣言签署人和极限编程的共同创始人在 2018 年发表的著名文章结语。

开发人员应该放弃敏捷

当“敏捷”理念应用不当时，往往会导致对开发人员的更多干扰、更少的工作时间、更高的压力以及“更快”的要求。这对开发人员不利，最终对企业也不利，因为“敏捷”做得不好，往往会导致更多的缺陷和更慢的进展。通常，优秀的开发人员会离开这样的组织，导致企业效率低于安装“敏捷”之前。

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

敏捷已死（敏捷万岁）

“敏捷”这个词已经被颠覆到了实际上毫无意义的地步，敏捷社区所传递的似乎主要是顾问和供应商兜售服务和产品的舞台……

一旦宣言流行起来，敏捷这个词就变成了吸引任何有支持点数、账单时间或产品销售点的人的磁铁。它变成了一个营销术语。

所以我认为是时候让“敏捷”这个词退休了。

6、一些反思

对我来说，真正令人难过的部分是看到年轻的开发人员诋毁敏捷，并将其视为管理层画饼并推动开发团队疯狂工作的一种手段。

他们所知道的唯一敏捷是强加于他们的控制机制，而不是他们欣然接受的自我赋权工具。但我希望围绕历史和原始愿景展开一些讨论可以帮助我们记住事情应该如何发展。

好消息是，敏捷宣言的原则在今天与20年前一样明智且有意义。甚至连那些所谓的反叛者也不得不承认这一点。

Jeffries 在上面提到的文章中说，“然而，敏捷软件开发宣言的价值观和原则仍然提供了我所知道的构建软件的最佳方式，并且根据我长期而多样的经验，无论大型组织使用什么方法，我都将遵循原这些原则。”

我同意。

现在谈论敏捷并不时髦或酷。敏捷是无聊的。每个人都做敏捷，对吧？现在是反思过去 20 年并问自己几个问题的最佳时机：

什么做对了？

什么地方出了错？

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

一些 Simple Thread 的员工正在经历这场革命，他们计划在未来几个月内反思最初12条敏捷原则中的每一条，将它们的原始含义置于语境中，并考虑它们在当前软件开发环境中的价值。

我的希望是，通过研究基本原则，我们可以从过去中学习，就如Dave Thomas所言：我们可以保持我们的灵活性，即使我们选择放弃“敏捷”。

敏捷20周年：一场失败的起义

编者按：2001年，敏捷宣言诞生。随后，敏捷开发成了互联网家喻户晓的热门话题，人人喊敏捷，家家企业用敏捷。然而，恰逢敏捷宣言提出20年之际，敏捷已死的新闻、讨论屡见不鲜，这背后又有哪些引人深思的地方呢？

作者 | Al Tenhundfeld

译者 | 弯月

出品 | CSDN（ID：CSDNnews）

今年距离敏捷宣言发布已经20年了，而我们可以从这20年的发展中，总结出以下两个不争的事实：

敏捷，作为一个标签，赢了。人人都想套上敏捷这个标签。
敏捷，实践的结果与创始人革命性的思想相去甚远。

我们是如何走到这一步的？每个人都说他们采用了敏捷，但几乎没有人是敏捷的。

敏捷宣言的来历

2001年2月，17 位专业的软件从业者聚集在美国犹他州瓦萨奇山区雪鸟滑雪胜地的洛奇酒店。经过几天的讨论和争辩，他们共同撰写了“敏捷软件开发宣言”。

首先需要说明，这些人都是软件开发从业者。他们不是项目经理、CTO或工程总监。他们是开发人员、程序员、科学家和工程师。他们都会编写代码，并与利益相关者合作解决问题。这一点很重要。

还有一点，敏捷宣言不是凭空产生的。在这些人之中，许多人都已经创建了自己的方法论，比如极限编程、Scrum、DSDM、自适应软件开发、水晶方法、功能驱动开发、实用编程等等。

这个小组中的每个人都拥有丰富的软件编写经验，他们都在寻找一种方法，以替代当时由文档驱动的重量级软件开发流程。敏捷宣言的核心是四项价值陈述：

我们一直在实践中探寻更好的软件开发方法，

身体力行的同时也帮助他人。由此我们建立了如下价值观：

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

新希望

今时今日看来，这些现代软件开发实践是理所当然的事情，但在2001年，这些想法非常激进。

还没有收集所有需求，并估算每项功能，你就打算开始构建软件？这太疯狂了！

还有最重要的一点却被人们忘记了：公开积极地反对管理。例如，Ken Schwaber直言不讳地表达了他的目标是所有项目都可以摆脱项目经理，不仅仅是让这些人离开他的项目，他希望我们整个行业消灭这个职业。

敏捷与PMI

“我们发现，在复杂的创造性工作中，项目经理的角色会阻碍生产力的提高。项目经理的思维代表了项目计划，只会将项目中其他人的创造力和智慧约束在计划之内，而不是调动每个人的聪明智慧来更好地解决问题。”—— Ken Schwaber，敏捷宣言签署人、Scrum 联合创始人

ScrumMaster几乎没有任何权力，也没有投票权。他们是团队的公仆，负责保护团队，并为团队解决难题，但不会管理团队。极限编程也很类似，最初极限编程有负责跟踪的人和教练，这些团队也有类似的促进和支持力量。

AlistairCockburn是敏捷宣言签署人，也是水晶方法论以及六边形架构的创始人，最近他提出了一个奇妙且非常有见地的看法：

Scrum在一片充满对立的领域达成了一项完美的协议：

管理层每年有12次机会，在每个sprint结束后调整团队前进的方向。
团队有一个月的时间静静地思考和工作，不会被人打断，也不需要调整方向。
团队必须宣布本月他们可以完成哪些工作，而哪些完成不了，而管理层不会干涉他们的计划。

无论是对于高管，还是对于开发团队，这都是堪称完美的协议。

我是一名经过认证的Scrum Master，在敏捷团队工作15年，而且我阅读了大量该领域的流行书籍。而下面是对Scrum最为简洁清晰的描述：

Scrum的创立是为了在充满对立的环境中发挥作用。这是强硬的经理和需要时间思考与探索的开发人员之间的契约。

管理层反击战

从某些方面来说，敏捷是一场底层劳动人民的起义。这场运动始于底层的从业者，然后向上推至管理层。敏捷是如何取得成功的呢？

部分原因是开发人员的数量和业务价值不断增长，影响力越来越大。但在我看来，最大的原因是传统的瀑布方法根本行不通。随着软件变得越来越复杂，业务步伐加快，用户的复杂程度不断提高，我们不可能提前计划好一切。尽管迭代开发尽管是合乎逻辑的，但习惯于计划好一切的管理者依然对此心存畏惧。

我记得在2005年前后的会议上，可以看出管理层并不认可敏捷，但他们也没有更好的主意。

“我们何不试一试工程师们一直在谈论的这个疯狂的想法呢？反正我们无法在最后截止期限前完成工作。情况还能更糟吗？”

然而，令他们感到惊讶的是，敏捷居然真的有成效。虽然刚开始的时候，团队会有点不适应，但经过一段时间后，就会站稳脚跟，并逐步发现哪些模式对团队有效，慢慢地一切都会好转。经过几个sprint后，你就会感受到敏捷的真正力量：划分工作的优先级、协作、检查和调整，以及其他方面等等。

大约经过了5年的时间，敏捷从一种有所耳闻、但不太熟悉的方法论，变成了人人都在实施的实践。2005年，我换了一份工作，我记得当时我对敏捷的了解非常肤浅，而在当时测试驱动开发才是主流。时至2010年，几乎所有现代软件团队都采用了敏捷。

在当时看来，敏捷成功了！大获全胜！恭喜大家！

然而，“打天下易，守天下难”。不幸的是，敏捷未能实现创始人的梦想。

事实证明，优先考虑个人以及互动是一个很难贯彻的概念。普及流程和工具要容易得多。
事实证明，生产能够正常工作的软件的难度远大于不切实际的计划和大量的文档。
事实证明，与客户合作需要信任和坦诚，这在业务环境中并不一定存在。
事实证明，高管们想要掌控一切，我们需要根据他们的业务制定长期计划，这往往根据变化做出反应更重要。
事实证明，敏捷实施不当往往会让人觉得很混乱。

这并不意味着敏捷的四项价值是错误的。这只是意味着为了正确地实施敏捷，我们需要付出巨大的努力，此外还需要一些勇气来接受软件中固有的混乱本质。你必须理解并相信，只要不断地学习，适应、改进和发布产品，最终肯定能够取得更好的成果，实现比瀑布式更现实、更高效的开发。

“敏捷运动并不是反对方法论，事实上我们很多人都希望重塑方法论的可信度。我们希望恢复平衡。我们接受建模，但不是为了将各种图表存储到公司的仓库里。我们接受文档，但不接受从未得到维护且很少使用的长篇巨著。我们计划，但是我们也清楚在动荡的环境中计划的局限性。那些称极限编程、Scrum以及其他敏捷方法论的支持者为‘黑客’的人，对于敏捷方法论和‘黑客’的原始定义一无所知。”—— Jim Highsmith，《History: The Agile Manifesto》

上述内容说到了重点，敏捷开发仍然需要计划和文档，以及严谨的实施。这是一个度的把控问题。但是，如果组织正在为敏捷转型而苦苦挣扎，陷入了混乱，此时有人提供认证、流程和工具，你必然会将之视为救命的稻草，死死抓住。高管们对流程和工具的了解远远超过他们对自组织团队的了解。

起义失败

然而不幸的是，敏捷这场起义并没有取得成功。

工具供应商、流程顾问和专家做出了许多永远无法兑现的承诺。很多人采用了 SAFe、 Scaled Scrum以及所有其他企业敏捷风格的方法论。这些框架的诞生并非出于恶意，在正确的环境下，它们甚至还有一定的价值。但我不会称它们为敏捷。试图扩展一种专注于个人与互动的方法论将不可避免地引发各种问题，并最终侵蚀该方法论原有的价值。

开发人员应该放弃敏捷

如果“敏捷”理念运用不当，则往往会给开发人员带来更多干扰，导致他们实际的工作时间更少，承受的压力更大，而且还需要“更快”地完成工作。这对开发人员很不友好，而且最终对企业也不利，因为这样的“敏捷”效果非常差，往往会引发更多缺陷，导致项目进展更缓慢。出现这样的情况，优秀的开发人员会离职，企业的效率还不如不实施敏捷。