敏捷辩护

现状

战争结束了，我们赢了。敏捷方法论，无论人们如何理解它，都被证明是运行软件开发项目最有效的方式。团队成员愉快地编码、测试和部署产品。管理层采纳了敏捷方法论并认可了其价值。满意的客户渴望尝试新功能。其他行业正排队加入这场革命。瀑布模型举起了白旗。

或者说，我们有些人是这么认为的。事实是，从来没有战争。这里没有好人坏人，没有输赢之分。我们只是成千上万在IT行业工作的专业人士，探索交付优质产品的最佳方式。而且没有所谓的敏捷方法论。有一种敏捷方法，有许多方法以这样或那样的方式采纳它。不，它还没有结束，也永远不会结束。事实上，整个敏捷哲学都涉及持续改进。说到这里，其他行业并不羡慕我们珍贵的敏捷性。在效率和生产力方面，我们远远落后于其他行业，只是站在巨人肩膀上的学徒。

敏捷并没有我们想象的那么普及。那些有幸在以开发者为中心的现代环境中工作的人^[1]，可能会被原谅没有注意到世界其他地方的落后。许多组织正在努力解决信任、技能或人员配备问题。对于一些组织来说，采用主流敏捷没有任何意义。有些看不到商业价值。另一些则只是名义上的敏捷，只是为了跟上当前趋势。或者他们让他们的开发团队随心所欲地做敏捷的事情，只要甘特图是最新的，并且严格遵循变更管理流程。请在下班前记录你的工作时间。所以，这就是我最近以相当残酷的方式体验到的一个丑陋事实：大多数组织都在努力采用敏捷。

敏捷到底意味着什么？敏捷工业综合体^[2]中有许多组织会很乐意向你解释。当然，费用不菲。参加他们提供的众多课程之一，你将学习如何应用严谨的技术，从而提高效率。你还将了解为什么其他技术不是“真正的敏捷”。或者你可以聘请顾问带你进行“敏捷之旅”。他们的存在表明了当今敏捷存在的许多问题。本文将尝试回答敏捷的含义、它解决的问题以及它如何帮助应对软件开发挑战。但让我们从习惯开始的地方开始：从头说起。

不那么谦逊的开端

我们的行业^[3]于1954年随着第一个COBOL编译器的创建而出现。毫不奇怪，编译器的创建者遭到了抗议：“但是格蕾丝，那样人人都能编写程序了！”^[4]。在接下来的几十年里，确实有大量人开始编写程序。世界也因此改变了。我们生活的方方面面都能看到软件的身影，从驾驶汽车到教学，从吸烟到刷牙。世界各地有许多车库充当新想法的孵化器。这种创新和成功产品的丰富性使这个行业如此有吸引力。

但最初的IT项目并非如此。计算机庞大而昂贵，资源稀缺。只有政府和预算庞大的组织才能承担IT项目。这与人类数千年来构思的其他行业形成了鲜明对比。通常是缓慢而小规模地开始，随着时间的推移，适当的实践就会出现。建筑、汽车、医疗、教育以及几乎所有行业都是以这种方式起步的。IT最初由大型项目主导的事实，长期以来塑造了我们创建软件的方式。

大多数软件开发项目都遵循相同的路径。一些聪明人构思出想法，然后将其传递给其他人进行进一步分析。技术专家准备了宏伟的设计。代码按照计划编写，然后移交进行验证。最后，快乐的用户接受系统使用培训。与此同时，项目经理监控整个执行过程，并确保一切按计划进行。

下图代表了管理软件开发生命周期（SDLC）的著名方法，称为经典瀑布模型。

情节更加复杂

让我们记住这张图，同时我们阐述一些与软件创建过程相关的概念。大多数问题都是采用瀑布模型的反响，并且以非特定顺序呈现。

你不能失败。大多数IT项目都会失败^[5]。有些项目未能按时完成。有些项目超出预算。有些项目规模缩减。有些项目在错误的时间向错误的人交付了错误的产品。许多项目遇到了所有这些问题，或者完全被取消。大多数都失败了。想象一下70%的桥梁随着时间的推移而倒塌，或者70%的手术导致患者健康并发症。我们有责任扭转这一趋势，重建行业的声誉。从长远来看，我们都将受益。

是产品，笨蛋。到目前为止，我特意强调了“IT项目”这个词。项目有其开始和结束。它们有自己的节奏和预算。它们有项目经理，确保每个人都遵守计划。但无论是开发者还是客户，都不是专注于项目。我们创造和使用产品，它们的性质更加持久。预算很重要，但更重要的是客户满意度。有一个计划是好的，但意料之外的才是关键。而且产品越早交付给客户越好。^[40]

角色专业化的谬误。上面所示的工作流程自然地导致了流水线式的工作组织。在每个工位上，参与者（工人）添加他们的部分，然后将半成品交给下一个。任务明确，项目经理和计划充当传送带。于是，业务分析师收集需求，架构师设计，开发人员编码，测试人员验证，支持人员进行维护。这种工作组织存在一些严重的影响。首先，由于情境归因^[7]、从众性质和权威力量，人们倾向于无意识地陷入被分配的角色^[6]。这是以个人发展、美德^[8]和对专业领域之外的贡献为代价的。其次，它导致团队碎片化。团队分裂成派系^[35]，通常分散在不同地点，这只会加剧分裂。第三，这种工作组织削弱了对最终产品的责任感，因为每个参与者只能对自己的部分负责。最后，它在上下游引发了“推卸责任”的游戏。

隔离的危险。分裂团队中的派系在功能上和组织上都日益疏远。此外，每个派系的视野都局限于其操作所需的输入和输出。这导致了柏拉图的洞穴效应^[36]。派系基于有限的信息获取和受损的能力，形成自己的信念和实践体系。为了控制日益分裂的团队，公司往往不恰当地使用侵入式沟通、会议过载和强制团队建设活动等方法。这只会导致更强的隔离感。

“如果在冻结状态下，水上行走和根据规范开发软件都很容易。”^[9] 软件是根据瀑布模型SDLC第一阶段收集的具体需求构建的。在此过程中，需求不可避免地会发生变化。规范变更的原因有很多，从新功能到技术难题，从基础设施要求到缺陷。项目不同阶段发生的变更会带来不同的成本。下图展示了变更常见的成本影响。

由于变化的性质，无法知道它何时会发生、是否会发生，也无法知道变化的范围。此外，经典的瀑布SDLC不假设对需求进行任何重新评估或对缺陷做出反应。人们已经投入了大量精力使瀑布模型更具适应性。一般的假设是增加一种机制，将问题反馈给上游的决策者。这在下图中得到了最好的展示^[34]

这很难做到，无论团队多么注重流程。即使是对瀑布模型最被动的修正，也无法减轻变更本质上与模型自然流程相悖的事实。但事实是，在软件开发生命周期中，需求变更会发生，而且会经常发生。由于每次变更实际上都会导致更适合的软件，我们需要修正对变更的看法：从问题变为竞争优势。任何围绕变更的严格流程都会限制这种改进的窗口。

“但我们一直都是这么做的。”^[10] 大多数管理层会试图识别、跟踪和控制规范的变动。但软件开发团队也必须应对不断变化的环境。这包括但不限于以下方面的变化：

• 团队动态：离职、入职、技能提升、技能下降、个人情况、职业发展、项目疲劳
• 工作环境：办公室设置、炎热的夏天、一月低潮、安全问题、恐怖主义影响
• 公司：声誉、文化、重组、财务状况、领导力
• 行业：流程、设计、架构、实践和实用工具的变化，其影响超越非功能性需求；行业焦点的转变可能导致其他领域人才流失^[11]，技术突破的难以捉摸性，劳动力国际化和移民便利性，失业率，技术工作者的包容/排他性^[12]

其中一些环境变化可能难以识别。软件开发团队必须快速响应这些变化，最大限度地减少其负面影响，或者最好将其转化为优势。在这样做的同时，团队必须在保持自身完整性和适应变化环境之间取得平衡。^[13]

响应机构。这个机构负责适应环境变化。它可能位于团队内部。这意味着该机构离问题更近，但可能缺乏视角、技能或所需的权限来应用适当的响应。它也可能位于团队外部。但它与团队的距离以及对内部动态缺乏了解可能会导致效率低下^[14]，忽略问题或对错误的疾病应用错误的药物。此外，外部机构的专制性质可能会在团队内部引起不满。将该机构同时置于团队内部和外部可能会导致职责重叠和冲突。缺乏该机构会导致随着时间的推移环境发展，生产力降低。

自适应系统。^[15] 任何封闭系统的熵都会随着时间的推移而增加，这已由热力学第二定律^[16][17]证明。熵的增加会导致工作产出降低。这就是为什么在像软件开发团队这样的复杂自适应系统^[18]中保持秩序如此重要。正如控制论所规定的那样，反馈机制在维持秩序中起着关键作用。团队所处的环境不断变化，因此需要适应团队的流程和实践。经典的瀑布模型将系统校准的负担放在外部机构（高层管理、指导委员会等）身上。这些适应变化的尝试往往不足（太少，太迟）或未得到团队的认同。

通过规范进行沟通。团队越是分裂，各派系之间的沟通就越受阻。这通常反映在最终产品中^[39]。直接沟通被对各派系之间传递的文档的过度依赖所取代。各派系往往采取按章行事的态度，即严格按照规范中的每一项指令执行，即使参与者清楚潜在的负面影响。这种行为的例子是开发人员精确地实现规范，即使他们知道它与其他系统部分或以前的工作不兼容。这种自伤行为是由两个因素造成的：证明观点的冲动（渴望被倾听）和为未来的推卸责任创造安全网。这种行为降低了参与者的主动性，并削弱了所有权感。通过规范进行沟通的另一个后果是“传话筒游戏”^[37]效应：离源头越远，指定需求的环节越多，含义就越扭曲。显然，这种效应是非常不可取的。

地图不是领土。^[19] 一张完美精确的地图将成为地形本身，因此变得毫无用处。在不那么极端的情况下，想象一张英国地图，每英里大小。在这种比例下，所有微小的细节都已丢失，但这张地图对于导航来说仍然不是很方便。另一方面，这样的地图细节足够，以至于地形中发生的任何有机变化都不会反映在地图上。因此，它在印刷的那一刻就过时了。必须在地图的准确性、实用性和可维护性之间找到平衡。此外，只有一个真理来源：地形。当地图和地形不同时，请遵循地形。这导致我们得出结论，即使是最好的模型也只是现实的简化表示^[20]，或者换句话说，“所有模型都是错误的，但有些是有用的。”^[21] 不幸的是，对于许多人来说，“地图似乎比土地更真实。”^[22]

规范作为路线图。技术规范提供了一个模型，开发人员使用该模型来实现所需的功能。讽刺的是，达到某个阈值后，规范包含的细节越多，其用处就越小。现在有一种日益增长的趋势，用诸如按契约设计（Design by Contract）、行为驱动开发（Behaviour-driven Development）、消费者驱动契约（Consumer-driven Contracts）等方法来取代传统的正式规范。尽管这些方法用于解决不同的问题，但它们有一个共同点：它们更注重“为什么”而不是“如何”。规范变成了一个具有不可侵犯的会合点的路线图。实际里程可能会有所不同，但只要关键点被访问，目标就达到了。这意味着实现过程是在团队不同派系之间“协商”进行的。大多数项目经理可能会对此感到不安，但这仅仅是对“真理只能在一个地方找到：代码”^[23]这一事实的重述。在采用这种方法之前，需要考虑两个方面。首先，它要求团队具有高度的所有权感。其次，存在开发人员被赋予权力，有效地成为源代码“黑魔法”解释者的风险。

时间成本。在最简单的模型中，为了交付一个产品，我们需要雇佣一定数量的分析师、架构师、开发人员、测试人员、基础设施工程师和支持人员。在瀑布式分阶段方法中，任何给定时间只有一个小组可以得到充分利用。与此同时，其他小组处于闲置状态，或者更糟的是，利用额外的时间过度完成手头的任务，对同事产生负面影响。虽然将小组分配给其他项目以应对低利用率时期很诱人，但这会增加到产品的距离（DTR）。距离加上任务切换成本会降低整体生产力。从以上来看，很明显，一个能够让所有小组始终保持充分工作状态的模型，将提供更高的投入时间回报率（ROTI）。

架构的恶性循环。在瀑布模型中，架构师承担了提供初始技术设计的重任。这是一项吃力不讨好的任务，因为在这个阶段几乎没有足够的信息来提供全面的设计，所以架构师注定要失败。这导致了实际实现与最初计划之间的差异。与此同时，架构师根据帕金森定律提供更多的设计。随着技术设计的增长，它与开发人员实际所做工作的距离也越来越远。这实际上导致架构师提供更多的设计来“掌控局面”，从而形成了一个恶性循环。以至于架构派系为了满足不断扩张的架构派系的需求而扩张。^[24] 这种机制可以在分裂团队的其他派系中观察到。在架构的情况下，它之所以特别引人注目，是因为自我保护本能的复合效应。由于教育的提升和工具的改进，整个软件开发团队承担起提供设计的责任变得越来越普遍。实际上，我们不再需要架构师来进行架构设计，就像我们不需要打字员来打字一样。这种不可避免的灭绝感只会加强恶性循环，因为架构师为了证明架构的价值而创建了更多的设计。当然，这里描述的情况适用于技术架构，而不是跨领域的企业架构。

泰勒主义的缺陷。软件创建过程本质上是不可预测的，我们永远不知道最终会得到什么。这使得瀑布模型偏爱的大型前期计划变得毫无用处。即使是中期规划也充满了高度不确定性。因此，科学管理^[25]方法不适用，编码不是可重复的任务，也没有切实的绩效衡量标准（例如每分钟代码行数）；软件开发团队的每一天都是不同的。事实上，一项任务越具创造性，泰勒主义的应用就越少。^[26]

自组织。^[28] 自组织系统会从其环境中消耗能量和秩序以改善其秩序^[27]。这种秩序必须旨在提高生产力。这意味着以各种方式（认可、工作满意度、培训和个人发展、职位、羞耻、披萨、威胁等）鼓励开发团队将精力集中在构建产品上。没有这些激励，系统秩序很容易被优化以服务于非生产性目的，例如增加个人自我、复仇、幸灾乐祸。自组织团队被证明是一种非常有效的管理形式。^[29]

我们正在探索更好的方法^[30]

敏捷运动的倡导者认为，上面强调的问题不仅仅与瀑布模型相关。它们是内置在模型中的，是其不可分割的一部分。因此，必须采用更好的工作方式。基于众多以往IT项目的经验、使用了数十年的实践^[31]以及在其他行业成功采用的方法^[32][33]，形成了敏捷软件开发方法。

敏捷运动通过认识到软件开发不仅仅是按照既定设计编写代码的行为，来解决传统模型的问题。它是技术、心理学、社会学、经济学、科学和管理的复杂结合。

敏捷软件开发方法建立在以下关键概念之上：

• 跨职能、多技能、自组织、领域特定团队
• 持续改进
• 频繁交付
• 适应性而非预测性模型
• 以人为本而非以流程为本

我们可以看到，使用这些简单的概念可以解决，或至少显著改善，上面强调的问题。敏捷团队紧密合作，实现共同目标，从而避免了解体带来的陷阱。规范成为整个团队努力的成果，避免了模型准确性不足的问题。需求变化是一个非常受欢迎的改进产品的机会。自组织是提高生产力并应对不断变化的环境的重要方面。此外，外部响应机构的影响更有可能产生积极反应，通常会减少负面二阶效应。^[38] 团队工作围绕频繁发布进行组织，自然地消除了任何低效率。所有团队成员的产能在大多数时候都得到充分利用，从而缩短了他们与产品的距离，并提高了整体投入时间回报率（ROTI）。

以下迭代模型是敏捷方法的典型表示

敏捷方法绝不是可以解决所有问题的魔杖。这些问题包括缺乏长期项目可见性、职业发展有限以及对团队协作的依赖。有些软件系统或组织显然不会从采用敏捷中受益。许多基于敏捷构建的方法论质量各异。这可能会让新人望而却步。事实上，敏捷方法的问题需要另写一篇文章。

尽管如此，敏捷方法仍然是现代软件开发生命周期管理中最强大的概念。它已被证明是高效的，并能提供更好的结果。它如此吸引人的原因是敏捷的本质在于不断改进和演进。没有什么比宣言中这些朴素而精彩的词语更能总结它了

“我们通过实践和帮助他人实践，正在探索更好的软件开发方法。通过这项工作，我们珍视：

个体和互动胜过流程和工具
工作的软件胜过详尽的文档
客户协作胜过合同谈判
响应变化胜过遵循计划

也就是说，尽管右边的项目有价值，但我们更珍视左边的项目。”

---

备注

[1] 郑重声明，我不认为以开发者为中心的技术官僚主义是一件好事。就像生活中的一切一样，需要平衡，如果我们忘记了我们工作的服务导向性质，历史的巨大钟摆最终会摆回来，我们可能不喜欢接下来会发生什么。

[2] Martin Fowler (2018) 2018年敏捷软件现状，可查阅：https://martinfowler.com.cn/articles/agile-aus-2018.html

[3] 我所指的“行业”是大众化、专业化的软件开发。显然，计算机编程、硬件开发和相关科学学科在此之前就已经存在。

[4] 这是一句常被引用的无出处名言

[5] Standish Group (1995-2018) CHAOS报告

[6] 基于轶事证据和个人经验，我拒绝斯坦福监狱实验的结论（Haney, Banks, Zimbardo (1973) 模拟监狱中的囚犯和看守研究）。该主题在具有更高科学严谨性的BBC监狱研究中得到了进一步探索（Haslam, Reicher (2006) 重新思考暴政心理学）。两项研究都受到WEIRD人群偏见的影响（Henrich, Heine, Norenzayan (2010) 世界上最怪异的人群）

[7] Fritz Heider (1958) 人际关系心理学

[8] 例如，在职责面前放弃个人价值观和信仰。参见 Darley, Batson (1973) 从耶路撒冷到耶利哥：帮助行为中情境和性格变量的研究 中的好撒玛利亚人实验。

[9] 作者：Edward V. Berard。我无法找到确切的来源和日期。

[10] Grace Hopper 在《巴尔的摩太阳报》(1975) 海军计算机奶奶一直在前进，另见：https://quoteinvestigator.com/2014/11/27/always-done/

[11] 几十年来，技能短缺一直是行业的一个严重问题。其不断扩大的性质只会加剧这一问题，例如，开发人员因职业发展、经济激励或“老无所依”的污名而转向DevOps；或新毕业生选择数据科学而非软件开发

[12] 历史上，技术工作者的偏见一直很明显，倾向于特定种族（白人/亚洲人）、性别（男性）、年龄（35岁以下）、性格特质（内向）。随着向更平衡局面转变的喜人变化，团队动态和需求也随之改变。

[13] Stafford Beer (1959) 控制论与管理

[14] 由于团队稳态，系统倾向于对外在因素具有弹性并保持其关键特征，Douglas Shepard Riggs (1970) 控制理论与生理反馈机制

[15] William Ross Ashby (1956) 控制论导论

[16] Rudolf Clausius (1867) 热力学的力学理论——及其在蒸汽机和物体物理性质方面的应用

[17] Constantin Carathéodory (1909) 热力学基础的考察，可查阅：http://neo-classical-physics.info/uploads/3/0/6/5/3065888/caratheodory_-_thermodynamics.pdf

[18] Ahmed E, Elgazzar AS, Hegazi AS (2005) 复杂自适应系统概述

[19] Alfred Korzybski (1931) 非亚里士多德系统及其在数学和物理学中严谨性的必要性，可查阅：http://esgs.free.fr/uk/art/sands-sup3.pdf

[20] 我使用了地图和地形的寓言作为模型。然后，我使用这个不完美的模型得出了一个普遍而严格的结论，即所有模型都是不完美的。你看到我在这里做了什么吗？在这种情况下，这是一个有趣的、有意的措施，但我们应该警惕那些“在科学上无用，在实际后果上有害”的肤浅类比（Spyros G. Tzafestas (2017) 系统、控制论、控制和自动化）

[21] Box, Draper (1987) 经验模型构建与响应曲面

[22] D.H. Lawrence (1936) 托马斯·哈代研究

[23] Robert C. Martin (2008) 整洁代码

[24] 显然，这是对奥斯卡·王尔德“官僚机构的扩张是为了满足不断扩张的官僚机构的需求”的转述。

[25] 也称为泰勒制（Frederick Winslow Taylor (1911) 科学管理原理）：“只有通过强制性的方法标准化，强制性的最佳工具和工作条件的采用，以及强制性的合作，才能确保这种更快的速度。而强制采用标准和强制这种合作的责任仅在于管理层。”

[26] Katia Caldari (2007) 阿尔弗雷德·马歇尔对科学管理的批判性分析

[27] Von Foerster (1960) 论自组织系统及其环境

[28] Ashby (1962) 自组织系统原理

[29] Tribus, Myron (2001) 托马斯·巴塔给现代经理人的启示

[30] Robert C. Martin 等人 (2001) 敏捷软件开发宣言，可查阅：http://agilemanifesto.org/

[31] Edmonds (1974) 非技术用户软件开发过程作为自适应系统

[32] Iacocca Institute (1991) 21世纪制造企业战略：行业主导观点

[33] Presley, Liles (1995) 敏捷航空航天制造

[34] Winston Royce (1970) 管理大型软件系统开发

[35] 派系：一个大团体内部的一个团体，特别是与主团体想法略有不同的团体 (剑桥词典)    

[36] 洞穴寓言：柏拉图（柏拉图 (公元前380年) 理想国）提出的一个深刻实验，关于在有限认知情况下的人类感知及其在塑造主体所获得概念中的作用

[37] 传话筒游戏（又名“电话”或“中国耳语”）是一种国际流行的儿童游戏。玩家排成一队，第一个人悄悄地将信息传给下一个人。信息一直传递到最后一个人，然后与原始信息进行比较，产生滑稽的效果。

[38] “改变复杂系统的某个方面总是会引入二阶效应，其中一些可能与改变的初衷相悖。”——乔什·考夫曼

[39] 康威定律 ( Melvin E. Conway (1968) 委员会如何发明？)：“设计系统的组织受限于产生复制其组织沟通结构的设计。”

[40] 根据帕累托原则，20%的产品涵盖了80%所需的功能。