2018 年敏捷软件开发现状：伪敏捷、技术卓越与产品团队

敏捷软件开发已经成为主流，但主流化并不意味着问题消失。相反，许多所谓的“敏捷实践”正在偏离敏捷真正的价值观和原则。本文围绕 2018 年敏捷软件开发的现状展开，重点讨论伪敏捷、技术卓越以及围绕产品而非项目组织团队这三大挑战。

从表面上看，敏捷软件开发的处境似乎一片大好：它已经成为主流。但现实并不完全乐观，因为许多所谓的“敏捷”实践，其实只是披着敏捷外衣的伪敏捷，缺少敏捷真正的价值观和原则。

今天，我们尤其需要关注三项挑战：第一，对抗“敏捷产业复合体”，以及它习惯于把流程和方法强加给团队的做法；第二，重新强调技术卓越在软件开发中的重要性；第三，围绕产品而不是项目来组织团队。

尽管问题不少，但我仍然对敏捷社区抱有信心。因为敏捷社区最大的优势，正是它持续学习和适应变化的能力。我们这些《敏捷宣言》的最初作者，当年并没有预见到今天会出现的所有问题；但这个社区有能力面对这些新问题，并不断调整自己。

敏捷软件开发已经成为主流，但问题依然存在

在座有多少人以前在海外某敏捷大会上听过我的演讲？你们居然又来了？哇，我真是佩服。如果你以前在这类敏捷大会，或者其他任何会议上听过我的演讲，你大概知道，我几乎每次都会用类似“21 世纪的软件设计”这样的题目。因为这个题目足够宽泛，我可以借它谈很多事情。

我本来也打算这次继续用这个题目，但后来决定讲得更具体一点：谈谈我们现在所处的位置，也就是 2018 年的敏捷社区。

我还决定，这次不做那种精心准备、配有大量幻灯片、精巧图表和华丽转场的演讲。今天就只是我站在这里，随性地聊一聊。我以前也这么做过，不过已经有一段时间了，所以我们看看效果如何。

当我们审视敏捷的现状时，从表面看，很多方面似乎都发展得不错。比如，看看今天到场的人数。这里人山人海，挤满了这么大的会场。事实上，我们甚至挤得有点不太舒服，因为外面实在太拥挤了。

你走到哪里，都能看到敏捷的身影。有人曾给我发来一张海外某商业评论杂志的封面，上面赫然写着“敏捷”二字。我的意思是，敏捷已经无处不在。

这和十几年前，甚至更早以前，我们在某个滑雪度假地讨论“我们到底该怎么称呼自己”时的情形，已经截然不同。听起来，这似乎意味着成功。

但如果你和许多老派敏捷实践者聊一聊，尤其是那些在 20 世纪 90 年代末、在“敏捷”这个名称出现之前就已经开始实践的人，你会发现他们其实有很多不安、失望和不满。

这并不奇怪。事实上，据我所知，这种情绪一直存在。而这其实也是一件好事，因为不满往往意味着人们仍然想要改进。但它确实会让我们产生一个疑问：为什么我们仍然在苦苦挣扎？

从抵触敏捷到伪敏捷：新的挑战出现了

我们现在面临的挑战是什么？

十年前，挑战在于人们是否愿意认真对待敏捷。我记得当时去拜访海外某咨询公司在澳大利亚的一家大客户。按照惯例，他们希望我请某位知名专家来做一次演讲。客户那边有人说：“你想讲什么都可以，但别提敏捷。”

在 21 世纪初到中期，这多少令人担忧，因为那时我一直在大力倡导敏捷。但当时人们就是这么想的：敏捷似乎是一件不太好的事，最好不要提起。

如今，敏捷开发无处不在，也非常流行。但其中发生了一个重要变化。我的一位同事总结得很好。他说：“以前我们谈敏捷时，客户一开始往往会有所抵触，而这种抵触反而会促成一些重要对话。现在，他们会说：‘哦，我们已经在做敏捷了。’但当你真正深入了解之后，会发现实际情况和我们预期的相去甚远。”

作为长期实践敏捷的一群人，我们自认为非常理解敏捷的理念。可当我们走进一家公司，对方说“是的，我们已经在做敏捷了，没问题”时，我们常常发现，他们所做的事情和我们理解的敏捷截然不同。

所以，我们现在面临的挑战，已经不是如何让敏捷成为人们愿意采用的方法，而是如何应对我所谓的“伪敏捷”：它有敏捷之名，却没有相应的实践和价值观。

Ron Jeffries 经常把这种现象称为“黑暗敏捷”，或者更具体地说，称为“黑暗 Scrum”。这其实比单纯假装敏捷更糟糕，因为它打着“敏捷”的旗号，却违背了我们在 20 世纪 90 年代末，以及后来讨论这类工作方式时所坚持的基本原则。

这就是我们当前面临的挑战。关键已经不在于如何让敏捷方法获得足够认可，吸引像今天这样的人群来参加这样的会议。关键在于，我们必须意识到，许多人正在做的、并称之为“敏捷”的事情，其实并不是真正的敏捷。我们必须认识到这一点，并与之抗争。

有人会说：“哦，我们要进入‘后敏捷’时代了，我们得想一个新词。”但这并不能解决根本问题。真正重要的是价值观和原则。我们必须正视这些价值观和原则，并不断推进它们。我们或许仍然可以沿用原来的标签，但必须让人们明白，这个标签真正代表的是什么。

如果这是问题的宏观层面，那么我们该如何聚焦到更具体的细节呢？我想重点谈三个主要问题领域。我认为，它们是最值得我们关注的。

挑战一：警惕“敏捷产业复合体”

首先，我想谈谈所谓的“敏捷产业复合体”。

公平地说，我也是其中一员，对吧？我现在就站在台上谈论敏捷。事实上，我们在某种程度上都是其中的一部分。我们当中的许多人供职于某些敏捷咨询公司，有些公司的名称里甚至就带着“敏捷”二字。

但是，正如我刚才所说，很多被推广的做法，实际上违背了敏捷的许多原则。

尤其让我印象深刻的是，早期敏捷倡导者意识到：只有当人们能够自主选择工作方式时，他们才能发挥出最佳水平。

当我们讨论《敏捷宣言》并写下其中四项价值主张时，我们其实并没有特别在意它们的顺序。但对于第一项，我们确实有自己的看法，那就是：“个体和互动高于流程和工具。”

在我看来，这句话清晰地揭示了敏捷思维的核心。

如果你想在软件开发领域取得成功，你需要找到优秀的人。你需要找到那些能够以人为本、高效协作的优秀人才。至于他们使用什么工具、遵循什么流程，则是次要的。

尤其值得注意的是，这番话出自一群非常重视流程的人之口。我的意思是，我们这些人或多或少都关心流程，但我们同时承认，我们所讨论的流程并不是最重要的。真正重要的是，团队能够自主选择自己的发展路径。

不仅如此，团队不应该只是选择自己要遵循的流程，还应该被积极鼓励去不断改进和调整流程。任何敏捷流程或敏捷方法都有一个内在特征：它本身就应该是灵活变化的。它每周、每月都在改变。

我以前经常对人说：“如果你还在用一年前的方式做极限编程，那你就不是在做极限编程。”因为如果你没有主动掌控局面，没有根据实际情况做出调整，你就错过了其中的关键。

我们可以建立各种仪式和机制来确保这一点，而回顾会议显然是许多人认为至关重要的一种实践。我记得 Ron Jeffries 曾开玩笑说，Alistair Cockburn 的敏捷方法可以概括为：“大家和睦相处，每周交付软件，然后每次都做回顾，找出改进方法。”

回顾确实是整个实践中非常重要的一部分。

不过，是否举行正式的回顾会议，其实并不是最重要的。回顾看板上列出四五个待办事项，也不是最重要的。回顾会议采取什么具体形式，同样不是最重要的。

真正重要的是，团队要思考自己正在做什么，以及如何做得更好。而真正承担这种思考和改进责任的，应该是正在执行工作的团队。这才是核心所在。

这种思想，是对 Frederick Taylor 及其“独立流程设计”理念的一种反动。在座有多少人了解 Frederick Taylor 的故事和他的方法？有多少人听说过 Frederick Taylor 这个名字？应该有更多人举手。就他对人们日常生活的影响而言，他或许是 20 世纪历史上最重要的人物之一。

Taylor 生活在 19 世纪末的美国，致力于提高当时正在兴起的工业化工作场所的效率。他认为普通工人懒惰、贪婪而愚笨。因此，他不希望工人自己决定如何制造某台机器，而是认为应该由其他更聪明、更有学识的人来找出最佳制造方法。

甚至细到：我是应该先做这个再做那个，还是先做那个再做这个。于是，一种非常程式化的操作方式诞生了，整个时间与动作研究行业也由此兴起。

这一理念的核心在于：实际执行工作的人不应该决定如何完成工作；工作方式应该由一个独立的规划团队来设计。这一理念在 20 世纪初对制造业和工厂工作产生了深远影响。

它同样影响了软件行业。人们会说：“我们需要软件流程专家来制定方案，然后程序员只需要各司其职。”

有趣的是，当软件行业还在讨论是否应该遵循这种泰勒主义，把它视为软件开发的未来方向时——我在 20 世纪 80 年代和 90 年代就听到过这种说法——制造业却已经在逐渐摒弃它。制造业越来越认识到，一线员工需要拥有更大的发言权，因为他们亲眼看到了整个流程的实际运行情况。

敏捷运动兴起，正是为了推动这种理念：参与工作的团队应该决定如何完成工作。归根结底，我们谈论的是软件开发人员。他们收入不错，受过良好教育，我们也希望他们有充分的内在动力。因此，他们理应弄清楚，在自己的具体情境中，什么才是真正必要的。

“具体情境”之所以重要，是因为不同类型的软件差异很大。我职业生涯的大部分时间都在做企业应用开发：数据库支撑、图形界面或 Web 前端之类的工作。我认识的大多数人也从事这类工作。

但这和设计电话交换机或嵌入式软件截然不同。即使在我相对熟悉的领域内，不同团队也会面临不同情况：我们需要协调不同的遗留环境，团队成员之间的互动方式也各不相同。

差异如此之多，我们怎么可能说存在一种适用于所有人的方法呢？我们做不到。

然而，我却经常看到“敏捷产业复合体”把各种方法强加给团队。在我看来，这简直荒唐至极。我本来想说“悲剧”，但我觉得“荒唐”更贴切。归根结底，软件开发并不存在万能模式。即使是敏捷的拥护者，也不会说敏捷适用于所有情况。

关键在于，团队最终要自己决定如何完成工作。这是敏捷的基本原则。

这也意味着，如果某个团队不想采用敏捷方式，那么敏捷也许就不适合他们当前的情况。于是，在某种奇妙的逻辑世界里，不采用敏捷，反而可能是他们能做出的最“敏捷”的选择。

所以，第一个问题是：敏捷产业复合体，以及它强加给团队的所谓“最佳工作方式”。这是我们必须抗争的对象。

挑战二：重新强调技术卓越

第二个问题是，人们往往忽视了技术卓越对我们工作的重要性。

我参加过很多敏捷会议，其中很少讨论真正的软件编写技术。顺便问一句，在座有多少人是软件开发人员？零星几位，但显然是少数。

海外某敏捷组织的主会议也曾长期存在同样的问题。后来他们意识到，参会者大多来自项目管理领域，而真正从事技术工作的开发人员却寥寥无几。这其实很可惜。

更糟糕的是，一些软件开发人员会说：“我们需要为自己创造一个全新的世界。比如软件工匠运动，在那里我们可以摆脱所有业务专家、项目经理和业务分析师，只讨论我们的技术问题。”

但这非常糟糕。因为敏捷的精髓，恰恰在于跨越这些不同领域进行整合。即使是级别最低、资历最浅的程序员，在敲 JavaScript 代码时，也应该与那些思考业务问题和业务战略的人保持联系。

我会在第三点中进一步阐述这一点。但这意味着，我们必须重视技术能力，思考如何培养它们、如何让它们成长、如何让它们真正发挥作用。

过去几年，我主要在写作，尤其是在撰写一本关于重构的新版本。在座有多少人听说过重构？很好。那有多少人能够准确地向别人解释它？少了很多。

重构是敏捷思维中的核心技术之一，因为它与我们构建软件的方式高度契合，使软件能够更容易地发生变化。

当我向人们概括敏捷时，通常会说它包含两个主要方面。一方面，是我前面谈到的团队至上，以及团队有权自主选择工作方式。另一方面，则是我们快速变化的能力，也就是轻松应对变化的能力。

我一直很喜欢 Mary Poppendieck 的那句话：“在开发后期仍能处理需求变更，是一种竞争优势。”

但要做到这一点，你需要设计出能够承受变化的软件。重构正是其中的关键，因为重构是一种有纪律的变更方式。

现在，如果有人在社交媒体上发类似这样的话：“我正在重构我们的软件，所以接下来两周它都会出问题。”那真是糟透了。那根本不是重构。

重构意味着小步修改，并且每一步都确保一切仍然正常运行。它不会改变软件的可观察行为；这正是重构的定义。而我应该最清楚这一点，因为这个定义正是我提出的。重构包含许多细小的改动，这些改动都不会改变软件的外部可见行为，但会改变它的内部结构。

通常，你之所以重构，是因为你想添加某个新功能，而当前的内部结构并不适合这个新功能。因此，你需要先改变结构，让新功能能够轻松融入。在这个过程中，你持续进行重构，同时不能破坏任何现有代码。最后，你再实现新功能。

Kent Beck 对此有一句很好的总结：“当你想做出改变时，先让改变变得容易。注意，这可能很难。然后再做那个容易的改变。”这是使用重构的一个非常关键的方法。

但重构的意义远不止于此，因为重构是一个持续的过程。当你查看一段代码时，你会问自己：“这段代码到底在做什么？我不太明白它的作用。让我想一想，深入看看。啊，现在我明白它在做什么了。”然后，在你继续之前，正如 Ward Cunningham 所说：“你要把脑海中的理解转化到代码里。”你可以通过重构代码、重命名代码来做到这一点。命名在这一切中非常重要。这样，下次你或其他人再遇到同一段代码时，就不必重新费力理解它了。

为什么这很重要？

因为如果你想做修改，想快速添加功能，就必须迅速理解程序中的关键部分：它们的作用是什么，你该如何与它们协作。只有这样，你才能快速完成修改。

这也与模块化密切相关。如果我拥有一个模块化良好的软件系统，就不必理解整个程序，而只需理解其中的一部分即可。技术卓越的意义，就在于能够构建这种适应性强的软件。

随后，一个自我强化的原则就开始发挥作用。一旦你意识到，我可以快速修改软件来添加新功能，我就不会一开始就试图把将来可能需要的所有功能都塞进去。因为我没有必要这样做。以后需要时，我还可以再改。

这就是 YAGNI 原则，即“You Aren’t Gonna Need It”——“你不会需要它”。不要在真正需要之前就向软件中添加功能，因为那会让软件臃肿、难以理解。

但如果没有良好的重构技术，这种策略完全行不通。而重构依赖于测试，重构也依赖于持续集成。持续集成进一步支撑了持续交付，也支撑了我们能够非常频繁地发布软件这一理念。在一些组织中，我们确实可以非常频繁地发布软件。

现在有一种观点认为，只有准备好承受大量错误，才能实现快速发布；如果想要软件可靠，就必须采用更慢、更谨慎的方式。

这种观点是错误的。越来越多证据表明，它大错特错。

我今年最喜欢的一本书——我认为它最终会成为年度最佳书籍——是 Nicole Forsgren、Jez Humble 和 Gene Kim 合著的《加速》。说这话时我其实有点难过，因为我自己的书今年也要出版了，但我希望它能排第二。在《加速》中，作者通过对大量组织的调研，展示了不同实践如何影响结果。他们论证的一点是：每天多次发布和低缺陷率是相辅相成的。因为如果你无法降低缺陷率，就不可能做到每天多次发布。而这需要我们前面讨论的那些实践：自动化测试、重构、YAGNI——所有这些都彼此支撑。极限编程最重要的特征之一，就是它的各项实践会相互强化。

挑战三：围绕产品而不是项目组织团队

我想强调的第三点是：我们必须摒弃“软件项目”这个概念。

我们应该转向以产品为导向的视角。不要再把软件工作看作一个个启动、运行一段时间、然后结束的项目；而应该关注更长期存在的产品，并围绕这些产品组建产品团队。换句话说，我们要明确组织所拥有的业务能力，然后围绕这些能力组建团队。这些业务能力是长期存在的，因此必然要求我们把技术人员和业务人员整合到同一个团队中。

在具体落地时，团队需要的不只是任务列表，而是一套能够贯穿目标制定、客户反馈、需求管理、开发、测试、发布和知识沉淀的研发管理体系。以 PingCode 为例，这类智能化研发管理工具能够帮助企业把研发流程中的数据打通，让研发管理更加自动化、数据化和智能化，从而支撑团队围绕产品持续改进，而不是只围绕单个项目推进。

现在，海外某大型科技公司的“双披萨团队”概念很流行。人们经常谈论它：“把团队拆分成双披萨规模的小组。”也许还会开个玩笑，说美式披萨真的很大，所以团队规模可能比你想象的还要大。但这种描述往往忽略了一个重点。每当我听这家公司的人谈论这个概念时，都会注意到这一点：每个团队都需要一直连接到客户。每个团队都专注于客户体验的某个方面，也就是 Kathy Sierra 所说的“让用户变得更出色”的某个方面。

这会改变我们对团队职责的理解。因为如果一个团队专注于客户体验的某个环节，或者专注于某种让客户做得更好的方式，那么这就告诉我们应该如何划分团队。当然，做到这一点并不总是容易，但我认为它应该成为核心理念。

然而，我们经常看到敏捷原则被践踏。我曾去过一家号称敏捷的公司。我和一个开发团队聊天，他们大约有六名程序员，但只有四位用户：零售规划部门的高级规划师。六位开发人员，四位用户，可他们之间从未交流过，而且还被禁止交流。取而代之的是一位 Scrum 产品负责人来管理他们之间的沟通。事实上，在一年之内，他们换了四位产品负责人。

我的意思是，这究竟是怎样一个所谓的敏捷噩梦？他们怎么敢用“敏捷”这个词来描述它？

当年我们讨论敏捷软件开发该叫什么名字时，Kent Beck 曾建议使用“对话式”这个词，因为软件开发人员、业务人员，以及所有致力于改善客户体验的人之间，都应该保持持续沟通。

如果我是那个团队中的开发人员，我会希望自己认识所有用户，能叫出他们的名字。我会和他们交流，观察他们工作，了解他们如何思考怎样让客户更满意，也了解整个流程是如何运作的。所以，我们必须认真思考这一点。这是我提出的第三个挑战。

敏捷软件开发需要面对的三项核心挑战

因此，我认为我们应该面对的三项挑战是：

第一，摒弃敏捷产业复合体以及那些强加给团队的做法，让团队自己探索最适合他们的工作方式。

第二，提升技术卓越的重要性。永远不要忘记，当我们编写软件时，技术层面至关重要。

第三，围绕产品来组织团队。

为什么我仍然看好敏捷的未来

到这里为止，我讲的内容可能显得有些消极，因为我一直在谈敏捷目前存在的问题。接下来，我还有两分四十五秒，用来解释为什么我并没有对现状感到太沮丧。

这或许源于我最喜欢《敏捷宣言》的一点。这个故事并不是发生在我们撰写宣言的时候，而是发生在大约六个月后，在海外某技术大会上。当时，《敏捷宣言》的大部分作者，以及其他一些对此感兴趣的人，都聚集在那里。那时，《敏捷宣言》已经以我们从未想象过的速度传播开来。突然之间，大家意识到，这里蕴藏着巨大的机会，可以做很多有趣的事情。许多人开始说：“我们需要在这里建立一个真正的组织。”

其中一个问题是：“最初撰写宣言的 17 位作者，是否应该在后续工作中拥有某种特殊地位？”我为我们这 17 位作者所做的一件事感到自豪：我们回答说“不”。

我们撰写了宣言。我们完成了一项出色的工作。我们也会参与未来的发展，但我们在未来并不拥有任何特殊角色。这个领域需要继续发展壮大。我们说过：“会有新人加入，并做出伟大的贡献。”事实也确实如此。这一点之所以重要，其中一个原因在于，它揭示了宣言作者群体的一个重大问题。尤其当我们站在 2018 年的视角回看这份宣言时，这个问题更加明显。17 个人：17 位白人中年男性。这里显然缺乏多样性。

但正因为我们选择放手，敏捷世界才得以吸纳来自各种背景的参与者。Mary Poppendieck 是早期敏捷社区的重要领导者之一。我曾经共事过的一位负责人，也曾长期担任海外某敏捷组织的主席。我参加敏捷大会时发现，女性参会者比其他类型的软件大会要多得多。这是一件好事。

当然，这并不是我们最初设定的目标。我们当时甚至没有想到这一点。但关键在于：正因为我们放手，最终才形成了一个能够自我发展、能够应对我们甚至未曾想象过的挑战，并努力解决这些挑战的社区。而这种作为一个社区不断学习、成长和改变的精神，正是我们最大的优势。

不久前，我和一位刚接触敏捷开发的人聊过。他说，他在这里感受到的热情和开放程度，是许多其他群体所不具备的。这让我非常非常高兴。因为只要我们能够保持这种灵活性，只要我们能够不断调整，那么无论面临怎样的挑战，我相信我们都会拥有美好的未来。