软件工程指南
10.7

查看英文版

10.7 敏捷

概述与动机

敏捷 是一种以迭代、增量的方式交付软件（以及价值），并与未来的使用者紧密协作的思维方式。它于 2001 年被写入《敏捷软件开发宣言》（Manifesto for Agile Software Development），最好将其理解为一套价值观与原则，而不是一套流程：优先重视个体与互动、可工作的软件、客户协作，以及响应变化，而不是此前那种偏重计划、偏重合同、偏重文档的默认做法。Scrum、Kanban 和 极限编程（XP）等框架，都是这种思维方式的具体实现。它们是有用的起点，但本身并不等同于这种思维方式。本章与第 1.4 章（广泛概览各种工作方法的”工作方式”一章）相辅相成，专门深入探讨敏捷本身。

推动敏捷发展的力量，与驱动发现和交付流水线（第 11.1–11.2 章）的力量是同一种：软件的需求是被发现出来的，而不是一开始就能完全知晓，世界变化的速度也快于一份长期计划所能吸收的速度。一次性交付、事先规划好一切的做法，一再造就了延期、超预算的系统，而最糟糕的是，这些系统方向还是错的，因为所有的学习成果都要等到最后才会出现，而那时再采取行动的代价已经最为高昂。敏捷的核心赌注很简单：用短周期构建真实可用的软件，并获取真实的反馈，胜过用长周期进行推测。做得好的话，它会持续地降低风险，而不是把风险推迟到以后再面对。

对于大型团队、企业和政府而言，敏捷既是强有力的工具，也常常被曲解和滥用。企业在数百个团队中推行敏捷，却常常把它简化成一种仪式（“我们现在开始开站会了”），却并不改变决策的方式，也不改变价值的衡量方式。政府则有意识地拥抱了敏捷，因为以用户为中心的迭代交付，已被证明能够切实降低大型公共项目的风险：美国数字服务局（U.S. Digital Service）及其《数字服务手册》（Digital Services Playbook）、英国的政府数字服务局（Government Digital Service）及其服务标准（Service Standard），以及各类敏捷采购改革，都在一定程度上是为了应对广受关注的 瀑布式 开发失败案例而出现的。这份收获是真实的，但”名义上的敏捷”这种失败模式同样真实存在。

核心原则

  • 重视《宣言》中的四大价值观（人员、可工作的软件、协作和响应能力），而不是重视流程产物。
  • 以小批量增量的方式频繁交付可工作的软件；可工作的软件是衡量进度的首要标准。
  • 欢迎变化，即便是在项目后期出现的变化；适应能力是一种优点，而不是一种失败。
  • 围绕有动力、被赋能、自组织的团队来构建工作方式。
  • 与用户和利益相关者持续协作。
  • 按照固定的节奏进行反思与改进。
  • 保持人性化的工作节奏，并追求技术卓越：没有工艺水准支撑的速度终将崩溃。

建议

以价值观和原则为根基，而不是以仪式为根基

关于敏捷，最重要的一条建议就是：以为什么为先导。一个团队即便每天开站会、召开冲刺评审会和回顾会议，但如果仍然在固定日期前承诺固定范围、隐瞒坏消息、从不修改计划，那么这个团队就不是敏捷的，而只是”开着会的瀑布式开发”。把十二条原则当作检验真正敏捷性的清单：你是否经常交付可工作的软件？你能否在下一次迭代中欢迎一项变化？团队是否自主决定如何开展工作？客户是否真正参与其中？如果这些仪式没能带来这些成果，就应该去修正成果本身，而不是修正仪式。

把框架当作起点，而不是当作信条

选择一个适合手头工作的框架，并对其加以调整：

  • Scrum： 限定时间的冲刺、按优先级排序的待办事项列表，以及明确定义的角色（产品负责人、Scrum Master、开发人员）。适合有明确产品负责人的功能交付场景；在工作高度受中断驱动的场景下表现较弱。
  • Kanban： 以明确的在制品（WIP）限制和拉动系统实现持续流动。适合支持、运维等工作到达时间难以预测的场景（并直接建立在流理论和排队理论的基础之上，参见第 11.2 章和第 11.3 章）。限制在制品数量能够缩短前置时间（利特尔法则）。
  • 极限编程（XP）： 一系列工程实践，包括 测试驱动开发、结对编程、持续集成、重构，以及小批量发布。它是让任何框架都能够可持续运转的技术支柱。
  • Scrumban 及其他混合做法：许多成熟团队最终都会趋向于这类务实的组合方案。

框架只是脚手架。保留有用的部分，舍弃无用的部分，永远不要让”框架就是这么说的”凌驾于”原则给出的理由”之上。

坚持追求技术卓越

没有工程纪律的敏捷，会迅速退化为快速生产不可维护的代码，也就是所谓的”黑暗 Scrum”（）团队一路冲刺，最终却把自己冲进了缺陷和 技术债务 的泥潭。XP 实践并不是可有可无的附加项。持续集成（第 8.1 章）、自动化测试（第 2.4 章）、重构、主干开发（第 2.6 章）和整洁设计（第 2.2 章），正是让团队能够以低成本持续修改软件的关键所在，而这恰恰是敏捷性的全部前提。出于同样的原因，可持续的节奏也十分重要：精疲力竭的团队无法维持质量，也无法维持响应能力。

谨慎扩展规模，优先考虑去规模化

诸如 SAFe（规模化敏捷框架）、LeSS、Nexus 和 Scrum@Scale 之类的规模化框架，能够协调众多团队朝着共同目标努力。它们确实能有所帮助，但也带着一个警示（与第 1.4 章的观点相呼应）：厚重的规模化框架，往往会不知不觉地重新引入敏捷本该消除的那种命令与控制式的、偏重计划的开销。在采用大型框架之前，先尝试去规模化。围绕拥有明确所有权、跨团队依赖极少的独立流对齐团队（第 1.2 章）来组织工作，这样一开始就不需要那么多协调机制。在确实需要协调的地方，添加能够奏效的最轻量结构，并将其与成果（OKR，即目标与关键结果，第 11.1 章）挂钩，而不是与产出挂钩。

让敏捷性在企业和政府中真正落地

适应性交付与体制性约束是可以共存的，但这需要有意识的设计：

  • 混合治理： 在预测型资金拨付/合规外壳（第 10.6 章）之内，建立一个适应性交付内核，让迭代能够满足监督要求，而不是与之相抗衡。
  • 敏捷采购： 采用模块化、基于成果的合同和更短的增量周期，而不是一份范围固定的超大合同；这正是公共部门敏捷实践最常成功或失败的关键所在。
  • 边做边合规： 通过自动化和适应度函数（持续验证架构与质量属性的自动化检查；第 8.5 章、第 1.6 章），将审计、无障碍性（第 5.3 章）和安全性（第 4.1 章）直接内建到每个增量中，而不是留到后期作为一道关卡。
  • 真实的用户接触： 这是最困难也是最重要的一点。团队需要与公民或客户建立真正的接触，而采购和安全规则往往会阻碍这一点。

持续改进，并且要动真格

回顾会议是敏捷的改进引擎，如果它没有带来任何改变，那就毫无价值。举行回顾会议时，应产出少量具体的、有明确负责人的行动项，并在下一次回顾会议之前真正把它们完成。度量成果（这项改变是否推动了某个关键结果？参见第 11.1 章）和流动情况（前置时间是否在缩短？参见第 11.2 章和第 11.3 章）。不要度量速度：它是一种容量信号，一旦你把它当作生产力目标来使用，它就会变成一种谎言。

权衡取舍：优点与缺点

决策优点缺点
敏捷（适应型）反馈快；能吸收变化；尽早、持续地产生价值事先固定范围/成本较为困难；要求客户深度参与并具备纪律性
瀑布式（预测型）范围可预测；对合同和审计友好反馈滞后；一次性交付风险高；难以适应不确定的需求
Scrum有节奏、有角色分工、有聚焦点；广为人知仪式开销较大；难以应对中断驱动型工作
Kanban强调流动、设有在制品限制、灵活；非常适合运维场景结构性较弱；需要纪律来维持限制
重型规模化（SAFe）能协调众多团队；大型组织比较熟悉可能重新引入命令与控制；仪式繁重
去规模化/团队自主协调开销更低；团队速度更快需要低耦合以及强大的平台/明确的所有权

这里的核心张力在于适应能力与可预测性之间的取舍，一个常见的误解是认为敏捷意味着”没有计划”。事实并非如此。它意味着持续地进行规划，并致力于成果和节奏的确定，同时让范围保持灵活。另一个反复出现的陷阱，是把敏捷仅仅当作流程（仪式），或者仅仅当作工程实践（XP）。两者缺一不可。

与团队讨论的问题

  1. 在你所在的企业或政府场景中，你们的合同是模块化的、基于成果的，还是交付被锁定在一份范围固定的超大合同之中？ 敏捷采购正是公共部门敏捷实践最常成功或失败的关键所在，因为一份固定价格、固定范围的合同，无论交付团队把自己的会议叫做什么，都会迫使整个交付过程走向瀑布式。采用更短增量周期的模块化、基于成果的合同，能让范围在固定资金之内灵活地聚焦于有价值的核心内容，这正是现代公共部门成功案例背后的模式，也是对过往一次性交付失败案例的解药。拿出证据来说明：审视你们目前的合同，问一问供应商的报酬究竟是基于已证实可用的软件，还是基于多年前就已签署确定的固定范围。这个答案应当比你们内部团队采用哪种框架，更大程度地决定你们下一次采购该如何设计。当你们的合同要求一次遥远的、要么全部完成要么全部作废的上线时，交付过程就不可能做到真正的适应性调整。

  2. 审计、无障碍性和安全性，是通过自动化被内建到每个增量之中，还是作为后期关卡被临时附加上去的？ “边做边合规”正是能让适应性交付与体制性约束共存的关键：通过自动化和适应度函数把各项检查内建到每个增量之中，而不是把它们留到发布前的最后一刻集中突击。后期的合规关卡，会重新引入敏捷本该消除的一次性交付风险，因为那些代价高昂的问题会在最难修复的最后阶段才浮现出来。拿出证据来说明：检查你们上一个增量中，无障碍性、安全性和审计证据是在流水线中被自动验证的，还是被推迟到发布前的人工评审阶段。这个答案应当推动你们把这些属性纳入持续的自动化检查之中，让监督要求通过构建这一行为本身就得到满足，而不是依靠一个独立的阶段来满足。这也正是让一个受监管项目在两次审计之间同样诚实、而不仅仅是在审计前几周才诚实的关键所在。

  3. 你怎么知道你的团队是不是正在把自己冲进技术债务之中？在上线压力之下，又是什么在保护可持续的节奏？ 没有工程纪律的敏捷，会退化为”黑暗 Scrum”（）团队快速冲刺，最终冲进缺陷和不可维护代码的泥潭，而精疲力竭的团队无法维持质量，也无法维持响应能力。XP 实践（持续集成、自动化测试、重构、主干开发）正是让团队能够以低成本持续修改软件的关键所在，而这恰恰是敏捷性的全部前提，因此当截止日期临近时，它们不是可以牺牲掉的可选项。拿出证据来说明：追踪前置时间是在缩短还是在增长，缺陷率是否在攀升，团队是否在悄悄地延长工作时间来赶完每一个冲刺。这个答案应当让技术卓越和人性化的节奏变得不容商量，因为靠牺牲工艺水准换来的速度，会在几次迭代之内就崩溃。要度量流动情况和成果，而绝不要把速度当作目标，因为一旦你把一个容量信号变成生产力目标，它就会变成谎言。

  4. 在你诉诸重型规模化框架之前，你是否尝试过减少那些从一开始就催生协调需求的跨团队依赖？ 这一点对大型组织而言尤其重要，因为当许多团队必须协同交付时，人们的本能反应就是购买一个像 SAFe、LeSS 或 Scrum@Scale 这样的框架，而厚重的规模化机制往往会不知不觉地夹带回敏捷本该消除的那种命令与控制式的、偏重计划的开销。与此相对的现实考量也确实存在：某些协调确实是必要的，而去规模化为独立的流对齐团队，需要低耦合、明确的所有权，以及一个足够成熟、能让团队自助服务的平台，而这些你们可能尚不具备。把证据带到讨论中来：梳理出那些真正迫使各团队相互等待的依赖关系，并问一问，如果对团队边界和服务所有权进行一次有意识的重新设计，其中有多少依赖能够真正消失。在企业和政府项目中，一个由几十个团队组成的组织架构图十分常见，这时诚实的问题是：你们究竟是在增加协调结构，来弥补本可以简化的架构和团队设计，还是从根本上减少了对协调的需求？

  5. 你的团队是否与他们所服务的公民或客户建立了真实的、反复的接触，还是反馈总是经过代理人过滤之后才传递过来？ 客户协作是《宣言》四大价值观之一，缺乏真实用户接触的迭代，会在不知不觉中把力气用错地方，而这正是敏捷本该防止的最昂贵的失败。这里存在的张力在于：大规模地安排直接接触十分困难，而大型和公共组织必须遵守的那些采购、隐私和安全规则，恰恰常常成为直接接触的阻碍，于是最容易走的路，就是用某种代理来替代：一位业务分析师、一个利益相关者委员会，或者上个季度的调研报告。拿出证据来说明：数一数你们最近几个增量之中，有多少是通过真实用户实际使用软件来验证的，又有多少只是建立在某人对用户需求的主观看法之上。对于政府服务而言，还要追问你们的可用性测试是否触及了受影响最大的人群，包括辅助技术的使用者和数字信心较低的人群，因为一项只对自信的多数人有效的公共服务，即便每一场仪式都按计划举行，也依然没有履行其问责义务。

  6. 你的团队是围绕成果和节奏获得资金和治理支持的，还是围绕一个在仪式背后悄悄逼出瀑布式行为的固定范围？ 这正是真正的敏捷性与虚假的敏捷之间的分野，而这一点是在团队之上、由资金如何拨付以及成功如何汇报所决定的，而不是由是否举行站会所决定的。与之相抗衡的拉力在于：财务、组合管理和监督职能，其设计初衷就是要提前数年批准一份对应固定预算的固定范围，而要求它们为一个范围灵活的成果提供资金，在它们看来就像是失去控制，因此会遭到抵制。拿出证据来说明：追溯一项当前计划的资金是如何拨付的，它汇报的又是什么内容，检查团队究竟是依据交付的成果和流动情况被衡量，还是依据故事点数和对一份早已签署确定的范围的遵守程度被衡量。在企业和政府环境中，把这一点与资金拨付和合规外壳（第 10.6 章）直接联系起来：如果资金被绑定在一次遥远的、要么全部完成要么全部作废的上线上，那么无论团队多么忠实地履行各种仪式，都不可能做到真正的适应性调整，而这个问题的解决办法属于治理模型，而不属于交付团队。

行业视角

初创企业。 践行价值观，跳过关于框架的争论。每周向真实用户交付一个可工作的切片，与创始人和早期客户保持足够紧密的接触，让反馈每天都能传递过来，并且一旦有证据表明当前的赌注方向错了，就立刻欢迎方向上的转变。你们最稀缺的资源是工程注意力，因此即便在上线压力之下，也要保护技术卓越（持续集成、自动化测试、主干开发），因为正是这种纪律，才能让你在下周依然能够以低成本转型。

小型企业。 由于没有敏捷教练、预算也很紧张，应该把敏捷当作一系列习惯，而不是一个需要专门配备人手的转型项目：一个较短的每周周期、一块设有在制品限制的可见看板，以及每周一项你们真正能完成的具体改进。多依靠 Kanban，因为它所需的仪式很少，也适合中断驱动型工作，并采用你们已经购买的工具中自带的实践方式，而不是搭建一套厚重的流程。评判成效的标准，应当是你们是否更频繁地向客户交付有用的软件，而不是你们模仿 Scrum 的相似程度。

企业。 这里的问题在于：如何在不重新引入命令与控制的前提下协调众多团队。在采用重型规模化框架之前，优先考虑去规模化，也就是通过流对齐的团队设计和坚实的平台来减少跨团队依赖。围绕成果（OKR）和节奏来拨付资金、开展治理，而不是围绕固定的年度范围和故事点数；让 XP 风格的工程实践在各团队中都不容商量；并以组合的方式管理交付，配合流指标和成果度量，从而让各个团队依据证据而非仪式来改进。

政府。 采购规则、透明度和公共问责制，塑造着每一个选择。构建采用更短增量周期的模块化、基于成果的合同，而不是一份范围固定的超大合同，因为敏捷采购正是公共部门敏捷实践最常成功或失败的关键所在。通过自动化把审计、无障碍性和安全性内建到每一个增量之中，让监督要求通过构建这一行为本身就得到满足；向监督机构公开进展和公共价值的证据；并在每一次迭代中，都要争取与公民（包括辅助技术使用者）建立真正的接触，因为这恰恰是最常在博弈中被牺牲掉的约束条件。

案例

初创企业。 一家五人规模的初创公司跳过了关于仪式的争论，直接践行敏捷的各项价值观。它每周向真实用户交付一个可工作的切片，与创始人和早期客户保持足够紧密的接触，让反馈每天都能传递过来，并且在有证据表明当前赌注方向错误时，愿意在下一周就欢迎方向上的转变。团队拒绝用技术卓越去换取速度，因此即便在上线压力之下，持续集成、自动化测试和主干开发也不容商量；每周五的回顾会议都会产出一项具体的改变，团队会在下一次回顾会议之前真正完成它。团队从不把速度当作目标来追踪，而是转而度量已交付的工作是否推动了激活率，以及前置时间是否在缩短。

企业。 一家电信公司涉及 60 个团队的转型，起初只是”照搬 Scrum”，却看不到任何改善。各团队依然被分配固定的年度范围，并按速度进行汇报。一次重新调整把重心转回到原则本身：季度 OKR 取代了功能指令，团队被重新组织以减少跨团队依赖（去规模化），XP 实践（持续集成、TDD、主干开发）变得不容商量。前置时间缩短了，缺陷减少了，而更重要的是，业务方开始度量成果而不是故事点数，把敏捷交付与发现流水线（第 11.1 章）连接了起来。

政府。 一个数字服务团队在一个混合治理外壳之内，采用敏捷方式重建了一个面向公民的福利申请应用：以两周为一个增量，交付经过用户测试的可工作软件；无障碍性和安全性被内建到每一个增量之中；模块化采购取代了单一的固定价格合同。每次迭代都会与公民（包括辅助技术使用者）开展真实的可用性测试，从而发现了那些在旧的瀑布式流程下本会被直接上线的问题。该项目提前交付了一项可用的服务，并向监督机构展示了可衡量的公共价值。这正是现代公共部门成功案例背后的模式，也是对过往一次性交付失败案例的解药。

商业论证：动机、投资回报率与总拥有成本

敏捷的回报来自于风险的降低和价值实现速度的提升。通过尽早并频繁地交付可工作的软件，团队能够持续地把不确定性转化为证据，在”做错了方向”和”根本行不通”这两类失败代价还很低廉的时候就将其捕捉到，而不是等到遥远且代价高昂的正式上线时才发现。支撑现代交付实践的研究成果（第 11.2 章中介绍的 DORA，即 DevOps 研究与评估 的相关发现）表明，敏捷所倡导的各项实践（小批量、频繁发布、快速反馈、技术卓越）与更好的交付能力、更高的稳定性以及更好的组织绩效都存在相关性。更早的增量也能更早开始产生价值回报，相较于要等到最后才产生任何回报的一次性发布，这能改善投资回报的时机和总体规模。

在总拥有成本方面，只要工程纪律是真实存在的，敏捷就能降低系统整个生命周期内的变更成本。它最主要的风险是虚假的敏捷：只有仪式、没有原则和工艺，这会增加会议开销，却带不来任何好处，甚至可能比一个诚实的瀑布式流程还要糟糕。因此，这个商业论证是有条件的。当你把敏捷当作”思维方式加工程实践”来采用时，投资回报率很高；而当你把它当作仪式来采用时，投资回报率大致为零（甚至为负）。向领导层论证时，应当把敏捷定位为持续的风险降低和成果度量，而不是”跑得更快”，并坚持要求这项投入必须包含技术实践，而不仅仅是新增会议。

反模式与陷阱

  • 虚假/货物崇拜式敏捷： 表面上举行各种仪式，但决策方式、资金拨付方式和思维方式仍然停留在瀑布式。
  • 把速度当作生产力： 把一个容量估算指标变成目标，从而使其失真（古德哈特定律）。
  • 黑暗 Scrum： 在没有技术卓越支撑的情况下一路冲刺，最终产出不可维护、充满缺陷的代码。
  • 没有改变的回顾会议： 一种不产出任何已完成行动的反思活动。
  • 范围、日期和成本三者都固定： 却把这称为敏捷，而质量则在悄悄承受着由此带来的压力。
  • 客户缺席： 没有真实的用户反馈，导致迭代优化的方向出现偏差。
  • 框架崇拜： “SAFe/Scrum 就是这么规定的”凌驾于原则和团队自身判断之上。
  • 先扩展规模，后考虑去规模化： 添加厚重的协调框架，而不是先去减少依赖关系。

成熟度模型

  • 第 1 级，启动级。 采用瀑布式或临时性的交付方式；一次性发布；工作是被动式的，且偏重计划，没有迭代反馈，团队也没有形成”为什么敏捷可能有帮助”的共识。
  • 第 2 级，发展级。 少数团队采用了敏捷仪式（站会、冲刺、回顾会议），但整个组织的实践并不一致：思维方式和工程纪律落后于各种仪式，速度被当作产出来看待，范围依然是事先固定好的。
  • 第 3 级，标准化级。 价值观与原则真正在整个组织范围内指导着工作，并被记录下来，成为对每个团队的共同期望：XP 风格的技术卓越（持续集成、自动化测试、重构、主干开发）成为标准实践，团队实现自组织，客户在每次迭代中都参与其中，回顾会议会产出具体的、已完成的改变。
  • 第 4 级，管理级。 交付会与基线进行对照度量和控制：团队追踪前置时间、部署频率、变更失败率和缺陷逃逸率（DORA 风格的流动性和稳定性指标），并配合与关键结果挂钩的成果度量，将每一项都与已知的基线进行比较。回顾会议产出的行动项会被追踪直至完成，加班和职业倦怠等可持续节奏信号会受到监测，速度绝不会被当作生产力目标来使用。是否推进的决策，依据的是这些证据，而不是主观意见。
  • 第 5 级，协同级。 适应性交付在整个组织范围内与业务规划和风险规划融为一体：成果（OKR）驱动着资金拨付和节奏，低依赖的团队设计（去规模化）将协调开销降到最低，混合治理在不拖慢交付速度的前提下满足监督要求。持续改进成为一种文化，而不再是一种仪式，组织会随着证据和风险状况的变化，常态化地重新界定范围、重新组建团队，并重新平衡其项目组合。

讨论议题

  1. 对照敏捷的十二条原则，给你的团队打分：你们在哪些方面只是仪式上敏捷，而实质上并非如此？
  2. 你的团队把速度当作一种预测手段，还是当作一个目标？这对团队行为造成了什么影响？
  3. 你们缺少哪些 XP 技术实践？这种缺失又是如何以缺陷或变更缓慢的形式表现出来的？
  4. 在采用规模化框架之前，你们能否转而先去减少跨团队依赖？
  5. 在你们的具体场景中，究竟是什么在每次迭代中阻碍了对真实用户的接触？你们又该如何消除这种阻碍？
  6. 上一次回顾会议真正产出的具体改变是什么？

关键要点

  • 敏捷是一种价值观和原则的思维方式，而不是一套仪式；框架只是起点，而不是目标本身。
  • 频繁地交付可工作的软件，欢迎变化，并赋能自组织团队。
  • 技术卓越（XP 实践）不容商量。 没有它，敏捷性就会变成快速的衰败。
  • 谨慎地扩展规模；优先考虑去规模化。 在添加协调框架之前，先减少依赖关系。
  • 在企业和政府场景中，将适应性交付与混合治理和敏捷采购结合起来，并努力争取真实的用户接触。
  • 其投资回报体现在持续的风险降低和更早实现的价值，但前提是敏捷是真实的，而不是仪式性的。参见第 1.4 章、第 11.1 章、第 11.2 章、第 10.6 章和第 11.3 章。

参考资料与延伸阅读

  • Kent Beck et al., Manifesto for Agile Software Development 及其十二条原则（agilemanifesto.org, 2001 年）。
  • Ken Schwaber and Jeff Sutherland, The Scrum Guide。
  • Kent Beck, Extreme Programming Explained: Embrace Change。
  • David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business。
  • Mike Cohn, User Stories Applied 及 Succeeding with Agile。
  • Jeff Patton, User Story Mapping。
  • Stephen Denning, The Age of Agile。
  • Matthew Skelton and Manuel Pais, Team Topologies（团队设计与去规模化）。
  • Nicole Forsgren, Jez Humble, Gene Kim, Accelerate（关于敏捷/DevOps 实践的实证研究）。
  • U.S. Digital Service, Digital Services Playbook；UK Government, Government Service Standard。