2018 年敏捷软件状态

这是我在 2018 年墨尔本澳大利亚敏捷大会上演讲的文字稿。我即兴发表了演讲，只用提纲来引导我。我对文字稿进行了编辑，使文本读起来更连贯，同时遵循了演讲的思路。您可以在 InfoQ 上找到演讲视频。

有多少人以前在澳大利亚敏捷大会上听过我的演讲？ 你又来了？ 哇，我印象深刻。如果你以前在澳大利亚敏捷大会或任何会议上听过我的演讲，你就知道我每次演讲几乎都称之为“21 世纪的软件设计”，或类似的标题：因为它是一个模糊的标题，我可以谈论任何我喜欢的东西。我本来打算在这里再做一次，但我决定我要做一些具体的事情：谈谈我们所处的位置：2018 年的敏捷社区。我决定我不做那种特别精心策划的演讲，里面有很多幻灯片、精美的图表和漂亮的过渡——只是我一个人在闲聊。我以前做过，但已经有一段时间了，所以我们拭目以待。

当我们审视敏捷的状态时：在很多方面，从某种表面上看，情况看起来非常好。我的意思是，例如看看人群的规模。我们人很多，我们在这个大型会议场所里——实际上并没有很好地融入，因为那里非常拥挤。你去所有的地方，你会看到敏捷无处不在。有人给我发了一份印有“敏捷”字样的《哈佛商业评论》封面。我的意思是，它无处不在。这与 10 年前我们在这里，或者更早的时候我们在雪鸟的那个滑雪场谈论我们到底应该称自己为什么的时候相比，是一个巨大的转变。这听起来像是成功，但你与许多老牌敏捷人士交谈，那些在 90 年代后期被称为“敏捷”之前就在做这件事的人，实际上空气中充满了不安、失望和不快乐。

这实际上并不罕见，因为据我所知，它几乎一直都是这样的[1]。这实际上是一件好事，因为这种不满是想要改进的标志。但它确实导致了这种感觉：“为什么我们在挣扎”?

我们目前面临的挑战是什么？ 10 年前，挑战是让人们认真对待敏捷。我记得我去过 Thoughtworks 在澳大利亚的一家大客户那里。他们想让我给他们做通常的“Martin Fowler 来给我们做个演讲”之类的例行公事。客户中有人说：“是的，我们想让你谈谈你喜欢的话题，但不要说任何关于敏捷的东西。”在 2000 年代中期，当我谈论了很多关于敏捷的内容时，这有点令人震惊，但当时的感觉就是这样。感觉这东西有点糟糕，你不想谈论它。

现在敏捷无处不在，它很受欢迎，但发生了一个重要的转变。我的一个同事很好地总结了这一点，他说：“在过去，当我们谈论做敏捷的时候，从一开始就总是遭到客户的抵制，这会引发一些重要的对话。现在，他们说，‘哦，是的，我们已经在做敏捷了’，但你进去后突然发现，我们期望做的事情与实际情况有很大差异。作为 Thoughtworks，我们喜欢认为我们深谙敏捷的概念，但我们去一家公司，他们说，“是的，我们正在做敏捷，没问题，”我们发现这是一个与我们期望截然不同的世界。

我们目前面临的挑战不是让敏捷成为人们想做的事情，而是应对我所说的伪敏捷：只有名字的敏捷，但没有实践和价值观。Ron Jeffries 经常将其称为“黑暗敏捷”，或者更具体地说是“黑暗 Scrum”。这实际上比仅仅假装做敏捷更糟糕，它是积极地使用“敏捷”这个名字来反对我们在 90 年代后期和雪鸟谈论做这类工作时的基本原则。

所以这就是我们目前的战斗。这不是要让敏捷变得足够受人尊敬，以至于像这样的人群来参加这样的会议，而是要意识到很多人正在做的事情并称之为敏捷，其实不然。我们必须认识到这一点并与之作斗争，因为有些人说过，“哦，我们将进入‘后敏捷时代’，我们必须想出一个新词，”——但这无助于解决根本问题。重要的是价值观和原则，我们必须解决并继续推进这些价值观和原则，我们不妨使用相同的标签，但我们必须让人们知道它真正的含义。[2]

如果这是问题的概括层面，我们如何关注特定的事情？我想关注我认为值得强调的三个主要问题领域。我认为最值得我们关注的那些。

其中第一个是我所说的敏捷工业体系。公平地说，我也是其中一员，对吧？我站在这里谈论敏捷，事实上，我们都在某种程度上是其中的一员，我们中的许多人都是某种敏捷咨询公司的一员，标题中可能带有敏捷字样。但正在推动的事情很多，其推动方式正如我所说，确实违背了我们的许多戒律。

特别是，早期敏捷倡导者给我留下深刻印象的一件事是，他们意识到，当人们选择自己想要的工作方式时，他们的工作效率最高。

当我们谈论敏捷宣言并列出四个价值声明时，对于大多数价值声明，我们并不太在意它们的顺序。但我们确实对第一个有自己的看法：即“个人和互动高于流程和工具”。对我来说，这体现了敏捷思维的一个非常重要的部分。如果你想在软件开发中取得成功，你需要找到优秀的人才。你需要找到能够在人际层面上良好合作的优秀人才，这样他们才能有效地协作。他们使用什么工具或应该遵循什么流程的选择是次要的。我认为，从本质上来说，这是一群流程狂热者的聚会，这是一个非常重要的声明。我的意思是，我们都在某种程度上是流程人员，但我们承认我们正在谈论的事情实际上是次要的。重要的是团队选择自己的道路。

更进一步，团队不仅应该选择他们遵循的流程，而且应该积极鼓励他们随着时间的推移不断发展和改变它。关于任何类型的敏捷流程或敏捷方法，有一点是，它本身就非常容易改变。它每周、每月都在变化。我过去常常向人们强调的一句话是“如果你做极限编程的方式和你一年前做的一样，那么你就不再做极限编程了”。因为如果你不掌控并根据你的情况改变事情，那么你就错过了它的关键部分。我们可以建立各种仪式和事物来实现这一点，回顾显然是许多人认为非常核心的一种技术。事实上，我认为 Ron Jeffries 开玩笑说，Allistair Cockburn 的敏捷方法是“和平和谐地走到一起，每周交付软件，并且每次都进行回顾以找出如何改进”。回顾确实是实践中非常核心的部分。

现在，你是否真的有一个正式的回顾实际上并不重要。你的回顾板上是否有四个或五个标签，或者你究竟如何进行回顾，这些都无关紧要。重要的是思考我们在做什么以及我们如何才能做得更好，而进行这项工作的团队才是核心。

这是对整个弗雷德里克·泰勒式独立流程人员的反应。这里有多少人知道弗雷德里克·泰勒和他的方法的故事？[几个人举手] 有多少人听说过弗雷德里克·泰勒这个名字？又多了一些。你们应该有更多人举手。就他对人们日常生活的影响而言，他可能是 20 世纪历史上最重要的人物之一。他来自 19 世纪后期，在美国，他非常有兴趣试图让人们在当时正在发展的工业工作场所提高效率。他对普通工人的看法是，他们懒惰、贪婪、愚蠢。因此，你不希望他们来决定如何制造特定的机器，而是由其他人，一个更聪明、更有学识的人来找出最好的方法。甚至细化到：我是先做这个再做那个，还是先做那个再做这个。这是一种非常脚本化的动作和运动的感觉。整个时间和运动行业由此诞生。这种观念的核心是，从事这项工作的人不应该决定如何去做。应该由一个独立的计划小组来做这件事，这在 20 世纪早期严重影响了制造业和工厂的工作。

它也影响了软件行业——人们说，“我们需要软件流程专家来找出如何做事，然后程序员只需填补空缺”。但有趣的是，就在软件人员谈论我们如何需要遵循这种非常泰勒主义的观念作为软件开发的未来时（我在 80 年代和 90 年代就听到人们这样说过），制造业正在远离它。在许多制造场所，人们的整个观念是，从事这项工作的人需要在这方面有更多的话语权，因为他们实际上看到了正在发生的事情。

敏捷运动是推动这一点的一部分，试图说服人们，“参与这项工作的团队应该决定如何完成它，”因为让我们面对现实吧，我们在这里谈论的是软件开发人员。这些人收入丰厚、受过良好教育，而且希望是积极向上的人，因此他们应该弄清楚在他们的特定情况下需要什么。

“具体情况”之所以重要，是因为不同类型的软件是不同的。我一生中的大部分时间都在企业应用程序领域度过：数据库支持、GUI/Web 前端类型的世界。这是我认识的大多数人所做的事情，但这与设计电话交换机或设计嵌入式软件有很大不同。即使在我相对熟悉的领域内，不同的团队也有不同类型的情况，我们有不同的遗留环境需要协调，而且团队中个人之间的动态也不同。有这么多差异，我们怎么能说有一种方法对每个人都有效呢？我们不能。然而，我听到的却是敏捷工业体系将方法强加于人，对我来说，这绝对是荒谬的。

我本来想说“悲剧”，但我认为“荒谬”是更好的词，因为最终软件开发中没有万能的方法。即使是敏捷倡导者也不会说*敏捷*一定是处处适用的最佳方法。关键是，执行工作的团队决定如何去做。这是一条基本的敏捷原则。这甚至意味着，如果团队不想以敏捷的方式工作，那么敏捷可能不适合这种情况，而*（不使用敏捷）*是他们在某种奇怪扭曲的逻辑世界中能够做事的最敏捷的方式。

所以这是第一个问题：敏捷工业体系以及这种强加一种最佳做事方式的做法。这是我们必须反对的。

第二个问题是缺乏对技术卓越对我们所做工作的重要性的认识。我参加的很多敏捷会议往往不太谈论编写软件的实际技术。顺便问一下，这里有多少人是软件开发人员？（少数人举手）零星几个，但绝对是少数。同样的问题在敏捷联盟的主要会议上也存在了相当长一段时间，但他们意识到，他们吸引了很多参与项目管理方面的人，而真正做技术工作的人却很少。这实际上是相当可悲的。这导致了一些软件开发人员说出了更可悲的话：“哦，我们需要为自己创造一个全新的世界。软件匠艺运动，在那里我们可以离开，远离所有这些业务专家、项目经理和业务分析师，只谈论我们的技术内容。”但这是一件可怕的事情，因为敏捷的全部意义在于将这些不同的领域结合起来。最底层、最初级的程序员敲击 JavaScript 代码，应该与那些正在思考他们所服务的团队的业务问题和业务战略的人联系起来。

在我的第三点中，我将对此进行更详细的阐述，但这意味着我们必须关注这些技术技能，我们必须思考如何培养这些技能，如何让它们成长，如何让它们变得重要。在过去的几年里，我的主要写作练习是编写一本关于重构的新版本。这里有多少人听说过重构？（很多人举手）很好。有多少人可以准确地向别人描述它？（举手的人少了）少了很多。这是一种非常核心的敏捷思维技术，因为它符合我们以易于更改的方式构建软件的整体方式。当我向人们总结敏捷时，我通常会说它有两个主要部分。一个是团队的首要地位，以及团队对做事方式的选择，我已经谈过了，另一个是我们快速改变、轻松应对变化的能力。

我一直很喜欢 Mary Poppendieck 的一句话：“需求的后期变更是一种竞争优势。”但要做到这一点，您需要以能够对这种变化做出反应的方式设计的软件。重构是其中的核心，因为重构是一种进行更改的规范化方法。当有人在推特上发布类似这样的内容时，这是一件可怕的事情：“我目前正在重构我们的软件，所以在接下来的两周内它将无法使用。”*嗡嗡声*——这不是重构。重构是小的更改，每次更改都会保持所有内容正常工作。它不会改变软件的可观察行为，这就是它的定义。我应该知道，因为我是定义它的人。

重构是许多小的更改，这些更改都不会改变软件的可观察部分，但所有更改都会改变其内部结构。通常（您重构）是因为您想制作一些新功能，而当前的内部结构不太适合该新功能。因此，您更改结构以使新功能易于适应，始终进行重构而不破坏任何内容，然后您可以将其放入。Kent Beck 对此进行了总结。“当您想要进行更改时，首先，使更改变得容易。（警告：这可能很难。）然后进行简单的更改”。这是一种使用重构的关键方法，但它不止于此，因为重构是一件持续的事情。您正在查看一些代码，并试图说：“这是什么？我不太明白这是什么。让我考虑一下。让我们深入研究一下。啊，现在我明白这段代码是做什么的了。”然后，在您继续之前，用 Ward Cunningham 的话说：“您将理解从您的脑海中取出，并将其放入代码中”：通过重构它，通过重命名它。命名是所有这一切中非常重要的一部分。这样，下次您或其他人查看同一段代码时，就不必再进行这种谜题练习了。

对于每个所需的更改，使更改变得容易（警告：这可能很难），然后进行简单的更改。

-- Kent Beck

为什么这很重要？因为如果您想进行更改，想快速添加内容，您必须快速了解程序的哪些部分重要，它们做什么，以及我如何工作才能快速进行更改。这也深入到了模块化。如果我有一个模块化良好的软件，我不必理解整个软件，而只需理解其中的一部分。技术卓越在于能够构建这种自适应软件。

然后是一个自我强化的原则。一旦您意识到我可以快速更改软件以添加新内容，我就不会试图让软件在一开始就完成我想要它做的所有事情。因为我不需要。因为以后我可以改变。这就是 YAGNI 原则——“您将不需要它”。在您需要之前，不要向软件添加功能，因为如果您这样做，它会使软件膨胀并使其难以理解。但是，如果没有良好的重构技术，这种策略是完全没有希望的。然后重构依赖于测试，重构也依赖于持续集成，与持续集成一起，您拥有持续交付的实践和我们将能够非常非常频繁地发布软件的概念。在一些组织中，我们实际上确实非常非常频繁地发布软件。

现在，有一种说法认为，只有在您准备好忍受大量错误的情况下，才能快速发布软件。如果您希望软件可靠，则需要以更加缓慢、谨慎的方式做事。错误的。我们看到越来越多的证据表明，这是非常非常错误的。到目前为止，我最喜欢的年度书籍，我认为它将是今年最好的书籍，是 Nicole Forsgren、Jez Humble 和 Gene Kim 合著的《加速》。 （我这样说是非常悲伤的，因为我的书今年就要出版了，但我希望是第二名）在这本书中，他们通过对大量组织的调查，展示了不同的实践如何影响事物。他们证明的一件事是，每天多次发布和低缺陷率是相辅相成的。因为除非您弄清楚如何降低缺陷率，否则您无法每天发布多次。这需要我们谈论的各种实践：自动化测试、重构、YAGNI——所有这些东西都汇集在一起。极限编程最重要的一点是，极限编程的各个实践相互 reinforcing。

我想强调的第三件事是摆脱软件项目概念的重要性。相反，我们希望转向以产品为导向的世界观，在这个世界观中，您启动、运行一段时间然后停止的项目不再存在；您改为说：“让我们专注于更持久的事情，并围绕它组织一个产品团队。”另一种思考方式是：您的组织有哪些业务能力，然后围绕这些能力组织团队。这些业务能力将是持久的，并且必然意味着将技术人员和业务方面的人员组合到同一个团队中。

目前流行的一种说法是亚马逊两个披萨团队——人们一直在谈论这个：“将自己组织成两个披萨团队。”也许还有一个关于美式披萨如何如何大的小笑话，所以它们可能比你想象的要大。但当他们给出这种描述时，他们常常会漏掉一些我在听到亚马逊人谈论这件事时很清楚的东西；那就是每个团队都需要联系——一直到客户。每个团队都专注于客户体验的某个方面，专注于 Kathy Sierra 所说的让客户在他们所做的事情上做得出色的某个方面。这改变了我们对小型团队职责的看法，因为如果小型团队专注于客户体验的某个部分，专注于让客户更好地完成他们所做的事情，那么这将告诉我们如何在小型团队之间划定界限。现在，做到这一点并不总是那么容易，但我认为这应该是驱动因素。

但同样，我们经常看到它被违反。我去了一家据说是敏捷的组织。我正在和一个开发团队聊天。大约有六名程序员。他们正在编写的软件只有四个用户，即零售计划中的高级计划员。六个开发人员，四个用户。他们从未说过话。他们不被允许这样做。相反，有一个 Scrum 产品负责人来管理他们之间的对话。嗯，实际上，一年中已经有四位产品负责人。我的意思是，这究竟是什么样的敏捷噩梦世界，他们竟敢用“敏捷”这个词来形容它？当[在雪鸟会议上]我们谈论敏捷软件开发的名称时，Kent Beck 建议使用“对话”，因为软件开发人员、业务人员以及任何参与改善客户体验的人都应该进行持续的对话。

如果我作为开发人员加入那个团队，我希望与所有用户都直呼其名。我希望能够交谈。我希望观察他们做什么，我想了解他们如何看待让客户更快乐，并看到整个流程。所以我们需要考虑一下。这是我的第三个挑战。

所以，我的三件事，我们应该将其视为挑战。

• 摆脱敏捷工业体系和将东西强加于团队的想法。让团队自己决定他们应该如何工作。
• 提高技术卓越的重要性，永远不要忘记，在编写软件时，技术方面至关重要，并且
• 围绕产品进行组织。.

所以，这一切听起来都有些负面，因为我已经谈到了当前敏捷状态的问题。我还有 2 分 45 秒的时间来解释为什么我对这种情况并不感到太沮丧。这可能来自于我对整个敏捷宣言最喜欢的一点。这并不是在我们撰写宣言时在雪鸟发生的，而是在大约六个月后，在佛罗里达州坦帕市举行的OOPSLA大会上，当时大多数撰写宣言的人都和其他一些感兴趣的人在一起。那时，敏捷宣言以我们从未想过的方式迅速传播开来。突然之间，很明显，这是一个做有趣事情的巨大机会，许多人说：“我们需要在这里建立一个真正的组织。”

其中一个问题是：“最初撰写宣言的 17 个人是否应该在这个持续的努力中占据特殊地位？” 我感到自豪的是，我们这 17 位作者说“不”。我们撰写了宣言。我们做了一件很好的工作，我们将成为未来发展的一部分，但我们在未来没有特殊的角色。这个角色必须向前发展。我们说“新人会进来做伟大的事情”，而这正是发生的事情。

这一点之所以重要，其中一个原因是，撰写宣言的人存在一个很大的问题，尤其是现在用 2018 年的眼光来看。17 个人：17 个白人中年男子。[3] 那里没有一丝多样性，但因为我们放手了，敏捷世界才能接纳来自各种背景的许多人参与进来。玛丽·波彭迪克是早期敏捷联盟工作的领导者之一。我的 Thoughtworks 老板丽贝卡·帕森斯曾长期担任敏捷联盟的主席。我去参加敏捷大会，我倾向于看到比其他类型的软件大会更多的女性。这是一件好事。当然，这不是我们一开始的工作。我们甚至都没有考虑过这一点。但关键是：因为我们放手了，我们最终拥有了一个可以自己发展事物的社区。这个社区可以应对我们甚至没有想到的挑战，并为之努力。正是这种作为社区不断学习、成长和变化的能力，才是我们最大的优势。

不久前，我与一位敏捷世界的新人交谈过，他说他们发现了一种在许多其他群体中并不存在的欢迎和开放程度。这让我非常非常高兴，因为只要我们能够保持这种灵活性，只要我们能够始终改变，那么无论我们面临什么挑战，我认为我们都有未来。谢谢。

---