软件开发成本与价值：开发、部署与运行模型

企业应该在开发者工具上投入多少时间和资金？改进开发平台究竟能够创造多大的商业价值？企业该如何量化应用程序 CPU 利用率优化所带来的业务影响？开发阶段与集成阶段又应该分别运行哪些测试？

这些问题都指向同一个核心主题：企业应该如何理解和衡量软件开发成本、软件价值以及研发流程中的资源投入。

尽管商业软件早已无处不在，业界、开源社区和学术界也积累了丰富经验，但要回答这些看似基础的软件开发问题，依然十分困难。

企业要实现长期可持续发展，就必须在软件开发成本、软件创造的价值以及相关风险之间取得平衡。软件价值的创造取决于产品成功、工程师生产力、硬件资源利用效率、创新能力和风险规避能力。这些因素有的相对可预测，有的则具有较大不确定性；有些成本可以直接用金额衡量，例如人员薪酬和硬件支出，另一些投入的价值却很难在短期内精确估算。

本文提出了一套用于理解软件开发成本与商业价值的整体模型。该模型将软件开发置于业务目标之下进行分析，深入拆解软件价值的形成过程，并提供一套可以在产品团队、职能团队和管理层之间通用的语言。

在此基础上，本文进一步提出了一种商业软件开发工作流模型，将软件开发带来的影响划分为四种类型，并探讨软件基础设施、平台工程和系统架构如何间接影响开发工作流与商业成果。

软件开发如何服务于业务目标

当企业投资于软件开发流程，而不是直接投资某个具体的软件产品或功能时，其根本目标是利用现有资源，最大限度地创造商业价值。换言之，企业希望在成本可持续的前提下，使软件达到可以接受的质量水平，并持续产生价值。

软件的价值来自使用。软件开发则是一个持续发生的过程，需要在人力、硬件、战略能力和时间等关键资源之间不断作出权衡。

尽管不同组织的软件开发工作流存在差异，但商业软件价值的交付通常包含三个相互关联的流程：开发、部署和运行，如图 1 所示。

这三个流程彼此依赖。任何一个流程发生变化，都可能影响整个软件系统。与此同时，每个流程又有各自不同的目标，而这些目标决定了企业应该如何开展成本收益分析，以及如何在关键资源之间进行权衡。

为什么需要从整体上理解这三个流程？

因为过度简化的软件开发模型，往往会忽视不同流程具有不同目标和约束这一事实。为了最大限度地提高收益、减少浪费，企业必须观察资源在开发、部署和运行三个流程中的使用情况，而不能只优化其中一个环节。

例如，孤立地削减硬件容量，可能导致发布延迟或软件质量下降。减少测试次数虽然能够降低短期计算成本，却可能让更多缺陷进入生产环境，最终造成更大的业务损失。

只有分别评估每个流程中的权衡，并从开发、部署和运行三个视角综合衡量成本与收益，决策者才能作出更有效的选择。

理解软件开发成本与价值的基本洞察

本节首先提出一些看似并不明显、但通常不会引起太大争议的观点，为后续分析奠定基础。

软件只有在被使用时才具有产品价值

软件只有在被发布、部署并实际使用时，才能创造商业价值。

与制造业类似，积压的在制品很容易成为价值陷阱。如果团队完成了一个新功能，或者修复了一个缺陷，却迟迟没有将其部署到生产环境，那么此前投入的时间和资金就无法真正转化为价值。

由此可以推导出一个重要结论：如果软件交付流程中的某个环节延迟过高，价值的实现就会被推迟，甚至被完全阻断。

过长的流程延迟还会增加战略风险。生产环境中的软件迟早会出现严重问题。问题发生时，能够快速响应和恢复的组织，显然比响应缓慢的组织更具优势。

软件价值是如何创造的

软件开发、部署和运行三个流程，对关键资源的权衡方式并不相同，如图 2 所示。

软件开发是一种创造性活动

软件企业面临的一项核心难题，是我们无法直接衡量软件开发生产力，也很难直接证明知识共享的价值。

我们应该用什么单位来衡量软件开发生产力？

早在迪杰斯特拉提出相关问题时，软件行业就已经认识到，代码行数并不是衡量生产力的有效指标。提交次数、变更提案数量或代码变更数量，最多只能反映活动量，却无法说明这些活动是否真正创造了成果。

人们希望衡量“功能数量”或“功能交付速度”，但除非观察规模足够大的汇总数据，否则这类指标依然很难使用。什么才算一个功能？不同功能之间是否具有可比性？更重要的是，我们如何确定团队实现的是正确的功能？

问题的根源在于，几乎每一次软件变更都是独一无二的。很少有两个功能相似到能够被直接比较。

软件开发依赖人的创造力、判断力和专业技能，包括系统设计、问题探索、方案打磨，以及对现有系统的深入理解。整个软件行业建立在知识和创造力之上。

在软件工作流的开发阶段，人类的创造力和创新能力至关重要。从形成变更意图，到完成软件设计与实现，每一个环节本质上都包含人的创造性判断，并体现人的意图。

正如软件工程领域的学者玛丽·肖多年来反复强调的那样：

编写软件更接近设计产品，而不是生产产品。

业务层面的汇总数据可以提供有价值的洞察，但个人层面的统计数据通常不足以代表一名工程师的真实生产力。

SPACE 框架提醒我们，汇总指标和代理指标可以帮助组织提出问题、发现趋势，并识别软件系统中可能的改进杠杆。但是，这些代理指标必须与更广泛的指标体系结合使用，最好同时观察彼此之间存在制衡关系的指标。

本文并不试图定义一套完整的软件开发生产力指标。即便如此，现有指标通常也很难以一种可预测的方式，把开发成本与业务收入直接联系起来。

如果把软件开发理解为设计、创造和意图表达，企业就更容易确定生产力投资的方向。

以汽车设计为例，企业会投资于设计标准、通用零部件、建模工具，以及机械、电气和液压系统的详细设计。只有在创造性设计完成之后，新原型才会进入工厂生产。

软件开发同样如此。

首先，团队通过协作确定应该构建什么；然后，决定如何构建；最后，完成软件实现，并将其交付到生产环境。

与汽车设计一样，软件开发也必须为原型设计、实验和迭代留出足够空间。在这一阶段，可复用组件、更高级的开发工具，以及对系统更完整的设计和理解，都至关重要。

软件部署是一种工厂流程

与开发不同，一旦变更被提交，软件部署过程原则上就不应依赖常规人工操作。

部署过程需要评估测试结果和生产环境信号，以判断当前版本、候选版本或配置是否满足发布要求，并能够创造价值。这类任务非常适合由机器完成，因为机器在持续处理大量信号、执行重复步骤和判断预设条件方面，通常比人类更可靠。

当然，负责建设企业级部署能力、处理复杂故障和解决异常问题的可靠性工程师依然不可或缺。

但如果软件部署的常规步骤仍然需要大量人工参与，通常说明组织至少存在以下一个问题：

• 自动化能力不足；
• 缺少作出自动化判断所需的信号；
• 自动化和信号体系同时存在缺陷。

需要持续人工干预的部署流程，很容易演变为烦琐、重复且缺乏人性化的工作。

人工监督和必要的专业判断不可能被完全消除，但企业仍然可以通过减少人在构建配置、集成测试、发布和生产可靠性流程中的实际投入，创造显著价值。

DORA 体系中的一些指标，例如“从代码提交到生产部署的时间”，实际上也隐含了这一观点：从提交到部署的过程具有足够的标准化程度，可以在不同团队之间进行衡量和比较，因为原则上，每一次发布和部署操作都可以实现自动化。

软件运行是应对意外情况的过程

开发和部署可以通过设计流程、标准与自动化机制进行控制。相比之下，软件进入生产环境后的运行过程，必须持续应对不可预期的情况。

运行阶段的关键并不是简单重复既定流程，而是观察系统的真实行为、识别异常、响应变化，并在不确定条件下保持系统可用。

为什么软件越早部署，价值越高

大多数商业软件项目的目标都很相似，也值得反复强调：

在达到既定质量水平的前提下，在单位时间内交付尽可能多的软件价值。

仅这一点，就足以解释为什么软件行业如此重视持续部署。

假设有两个团队，每个季度都能完成相同数量、具有相同总价值的软件变更。

其中一个团队每季度发布一次，另一个团队每天发布一次。虽然两个团队最终交付的工作成果价值相同，但每天发布的团队能够更早地让这些变更开始创造价值。

由于软件价值会随使用时间不断累积，仅仅提高发布频率，就可能使已部署价值在一个周期内的累计总量提升接近 50%。

当然，实际情况要复杂得多。

首先，部分变更会在生产环境中失败，尤其是带有实验性质的产品变更。一个变更可能需要经历多轮发布和验证，才能真正创造价值，产品市场适配和用户体验方面的变化尤其如此。这种迭代需求，也是提高发布频率的重要原因。

其次，发布本身也会产生额外成本。部署流程中的每一步都需要计算资源。缺乏高效、低成本的自动化能力，会拖慢发布节奏。任何经历过手机系统更新和重启的人都知道，发布过程最终也可能给用户带来负担。

但总体而言，这些成本通常仍然小于更早、更频繁地交付有价值变更所产生的收益。

软件系统中的功能与质量属性

软件产品由功能和质量属性共同构成。

质量属性是指系统的非功能性要求或整体性质量要求，例如可靠性、性能、安全性、可维护性和可扩展性。

功能通常具有局部性。我们往往可以指出系统中实现某项功能的具体代码，例如登录功能。

质量属性则通常分散在整个系统中，很难通过某个单独模块加以识别。它们涉及系统中的交互、依赖关系、运行行为和整体属性。

不同质量属性之间，以及质量属性与成本之间，经常存在冲突。本文不试图提供完整的质量属性分类体系，而是重点讨论其中几项与软件成本和价值相关的洞察。

固定成本不等于业务价值损失

软件开发成本和缺陷造成的价值损失，都会影响企业最终收益，但二者有着本质区别。

缺陷可能导致收入下降、客户满意度降低和品牌声誉受损。用户在生产环境中遇到的缺陷可能非常严重。尽管任何软件系统都不可能达到绝对完美，但企业仍然应该努力使系统足够接近完美，让绝大多数用户感知不到明显问题。

一旦生产环境中的软件质量下降，损失就会真实发生，而且通常难以预测。

相比之下，在一个季度等相对较短的周期内，人员和计算资源成本通常相对固定。企业可以大致预测工程师薪酬，以及交付和运行产品所需的云资源或其他基础设施成本。

此外还有一些次级成本，例如检测和修复开发过程中自然产生的缺陷。缺陷检测和修复会占用原本可以用于开发新功能的资源，但它们也是达到质量目标所必需的投入。

同样，尚未进行的性能优化和被浪费的计算资源，虽然会降低基础设施的有效容量，但在特定周期内，运行整个代码库所需支付的总成本通常仍然相对固定。

换言之，在开发过程中发现缺陷虽然令人遗憾，却属于软件开发的正常现象。只要它没有显著推迟重要变更的上线，就不一定会直接影响企业最终收益。

相比之下，发布后才被发现的缺陷会产生真实风险，并且在许多情况下会直接冲击商业结果。此时的“成本”不只是修复、回滚或重新发布的费用，还包括用户信任下降、企业声誉受损，以及市场对软件可靠性的负面认知。

因此，快速、自动化地发布软件所创造的价值，必须与发布过多缺陷所带来的风险进行权衡。

生产环境中的缺陷，必须与开发阶段内部发现并修复的缺陷区分开来。

减少故障次数不是衡量局部改进的最佳指标

故障总次数可以作为软件系统整体可靠性的参考指标，但如果想通过这一指标判断某个特定工具或流程变更是否有效，通常很难得到具有统计意义的结论。

这可能导致组织错误地认为：

• 某项工具或流程改进没有效果；
• 软件质量并不重要；
• 现有指标无法反映真实影响。

更可靠的证据来自团队级结果与组织绩效之间的关系。相关研究表明，DORA 指标表现更好的团队，往往也能取得更好的组织绩效。

这意味着，组织应通过中间机制理解工具、流程和基础设施对最终结果的影响，而不是试图直接证明某项工具减少了多少次生产故障。

大多数反事实情景无法准确衡量

要把实际结果与“如果没有采取某项措施会发生什么”进行比较，首先需要定义明确的基线，并能够识别由缺陷或干预措施直接造成的偏差。

如果缺少一条随时间变化的结果曲线，无法显示某个事件前后明显的上升或下降，就很难将实际结果与反事实情景进行可靠比较。

目前，软件行业还没有单一、公认的工程生产力指标，也不存在能够代表工程生产力的统一指数。

这意味着，通常只有规模足够大的汇总代理指标，才可能反映生产力变化；也只有影响足够大范围人群的事件，才可能被稳定测量。

直接衡量一种新工具或新流程对某位工程师或某个小团队生产力的影响，通常并不可行。

缺陷成本与测试保真度之间的矛盾

在真实生产环境中验证软件，是判断软件是否真正具有价值、是否适合用户的最高保真方式，但它同时伴随着造成重大损失的风险。

一旦缺陷进入生产环境，修复代价可能非常高。因此，相比直接在生产环境中进行高保真、高风险测试，软件团队通常应该尽早执行成本更低、保真度相对较低的测试。

缺陷发现得越早，修复成本通常越低。

从测试角度看，软件工作流前一个阶段的测试，可以看作后一个阶段测试的近似代理：

• 单元测试可以作为集成测试的代理；
• 集成测试可以作为发布验证的代理；
• 发布验证可以作为金丝雀测试的代理；
• 金丝雀测试则更加接近真实生产环境。

越接近生产环境，产品质量信号的保真度通常越高，但发现缺陷后造成的产能损失也越大。

试想，如果直到发布前才发现一个缺陷，团队不仅需要定位根因，还可能需要进行大规模返工、重新协调相关人员、生成新的候选版本，并重新执行此前已经完成的验证步骤。

如何衡量软件开发的商业影响

本文提出四种软件开发影响，其中三种可以进行一定程度的量化。

结合前文“固定成本不等于价值损失”的观点，软件组织可以重点观察三种可衡量的影响：

1. 产品成功；
2. 硬件资源效率；
3. 工程能力。

此外，还需要考虑第四种难以量化但非常重要的影响：战略能力。

产品成功

产品是否成功，是商业软件开发中最关键的影响指标。

成功的定义会因企业和产品而异，但通常包括以下因素：

• 收入；
• 市场覆盖范围；
• 用户采纳率；
• 用户信任度；
• 客户满意度。

当产品价值提高，同时缺陷率和故障率下降时，产品成功的可能性通常也会提高。

硬件资源效率

生产环境中的硬件和云资源是否得到了高效利用，是一个与软件运行高度相关、也相对容易衡量的指标。

代码优化和编译器优化都可能显著影响硬件资源效率。效率提升通常体现在两个相似但不同的方向。

第一，面向客户的资源消耗，即交付客户所使用功能需要多少计算能力。

第二，内部工程流程的资源消耗，即生成一个新变更、构建软件或评估候选版本需要消耗多少计算资源。

对于面向客户的资源消耗，效率提升可能只是纯粹的成本优化，不会改变产品价值；也可能是产品需求和用户规模增长的结果。在后一种情况下，资源使用量增加反而可能代表产品获得成功。

对于工程流程中的资源消耗，则需要在工程师时间与潜在硬件或云资源节省之间进行权衡。

有些效率问题值得投入工程师时间解决，因为长期节省的成本足以覆盖投入；另一些问题则不值得优化，因为节省的资源价值低于工程师为此付出的时间成本。

工程能力

企业是否有效利用了人力资源？

虽然工程能力通常难以直接衡量，但以下两项洞察可以降低组织进行精确测量的必要性。

首先，正如前文所述，部署是一种工厂流程。理论上，几乎所有部署流程中的常规人工干预都属于可以减少的额外开销。

DORA 相关研究通常将这种现象归入“部署痛点”。如果企业能够在保持产品成功和质量水平稳定的同时，减少工程师在测试、部署和发布流程中的参与，那么这种人力投入的减少本身就具有显著价值。

减少部署流程中的人工操作是一项明确收益，而且其投资回报率通常高于单纯增加工程师人数。

其次，衡量“某种后果因为一项措施而没有发生”几乎是不可能的。

组织至少可以通过两种方式衡量干预措施对工程能力的影响。

第一种方式是衡量措施产生的增量收益。但这种方式通常需要与反事实情景进行比较，因此很难做到。

第二种方式是估算当前流程消耗了多少工程能力，并寻找降低总体成本的方法。

第一种方式提出的问题是：

我们采取这项措施后，节省了多少资源？

第二种方式提出的问题则是：

当前流程浪费了多少资源？采用方案 X 能否提高这一流程的效率？

当组织试图衡量“在某个阶段提前阻止一个缺陷”的价值时，实际上是在构造一个反事实情景：

• 如果该缺陷进入生产环境，是否会造成真正的业务损失，而不只是工程产能损失？
• 如果当前阶段没有发现缺陷，后续哪些阶段可能发现它？
• 在剩余工作流中，每个阶段发现缺陷的概率是多少？
• 检测和修复该缺陷所需的预期工程成本是多少？

逐个缺陷回答这些问题极其复杂。这也进一步说明，对工作流和工具改进的影响进行精确量化和分类有多么困难。

我们建议采用基于共识的估算方法，评估缺陷检测与解决成本，即 DDR 成本。

DDR 成本通常与两个因素相关：

• 接触到该缺陷的工程师人数；
• 从缺陷被引入到被发现和修复所经历的时间。

接触人数越多，缺陷存在时间越长，DDR 成本通常越高。

因此，能够在工作流早期发现某类缺陷的工具或流程，通常比在后期发现缺陷更有价值。

例如，在集成开发环境中自动格式化代码，并自动修复制表符、空格或行尾空白等格式问题，可以在缺陷产生的最早阶段解决问题。此时，通常只有提交变更的工程师会接触到这个问题。

如果缺少这种干预，格式问题可能在几分钟后通过代码检查被发现，也可能直到数小时甚至数天后的集成阶段才被发现。

借助 IDE 内置的自动格式化功能，未被检测的问题只会存在几秒或几分钟。将某类问题的检测和修复周期从数小时缩短到几分钟，通常具有明确价值。

但只有当问题发生频率足够高，能够抵消开发和维护自动化机制的成本时，这项投入才是合理的。

反过来，如果在工作流后期处理某类问题的成本与问题本身的价值不成比例，例如因为无关紧要的空格问题而阻塞整个版本发布，那么更合理的选择可能是降低规则严格程度，甚至忽略该问题。

结合这一粗略的 DDR 估算，并考虑到部署过程中的人工参与应该尽可能少，组织可以通过以下两种方式提高工程能力：

• 在保持 DDR 水平稳定的前提下，减少部署和集成过程中的人力投入；
• 降低单个缺陷或某类缺陷的总体检测与解决成本。

战略能力

战略能力是第四种重要影响，但它往往无法被直接量化。

战略能力是指组织能够执行过去无法完成，或者过去成本高到不具备现实可行性的任务。

这种影响很难像产品成功、硬件资源效率或工程能力一样，用直接数值表示。

为决策者提供高质量信息，本身也具有战略价值，即使这些信息并不经常被使用。例如，一组每季度才会使用一次的遥测数据，依然可能在关键决策中产生巨大影响。

人工智能对信息进行聚合、整理和总结的能力，就是一种战略能力，因为它可以辅助人类作出决策。

自 20 世纪 90 年代搜索引擎出现以来，生产力提升不再只来自获取原始信息，而是越来越依赖获得经过筛选、聚合和总结、可以直接使用的信息。

另一个战略能力的例子是函数调用火焰图。它能够帮助工程师判断系统性能消耗发生在哪里，以及应该如何进行优化。

战略能力还可能来自长期或实验性投资。这类投资可能从根本上改变企业的运行方式，例如将一个全新的技术领域确定为战略重点。

这类转变通常需要较长的准备周期，并伴随着高度不确定性。

在实验性领域工作的团队，需要一种以原则为导向的投资方法，也需要高层管理者给予支持，包括采用更审慎的绩效评估和晋升机制。

但战略能力不应被视为解释所有基础设施投资价值的万能理由。它只是理解基础设施投资组合整体影响的一部分，而且需要保持克制。

开发、部署与运行之间的权衡

开发、部署和运行中的任何一项改进，都可能影响另外两个流程。

表 1：一个软件流程中的改进可能影响其他流程

这意味着，组织不能只观察局部指标。某项改进可能降低一个环节的成本，却增加另一个环节的延迟、风险或工程负担。

真正有效的优化，必须从软件价值交付的整体流程出发。

基础设施与平台工程如何创造价值

基础设施和平台工程团队能够提供工程能力和战略影响力，并间接影响产品成功。

确定应该构建哪些产品功能，主要是产品开发团队的责任。基础设施团队则可以加速工程工作、提高交付效率，并为软件质量提供保障。

负责提供共享软件能力和基础设施的团队，可以从以下三个方面创造影响。

提升工程能力

• 能否缩短编辑—构建—测试循环？
• 能否降低缺陷产生率？
• 能否提高开发者满意度？
• 能否减少部署过程中的返工和重复劳动？

提高硬件资源效率

• 能否在不损害其他质量属性的前提下，减少硬件资源消耗？
• 能否分析资源效率提升与其他目标之间的权衡？

构建战略能力

• 能否提供新的基础设施能力？
• 能否改善遥测和可观测性？
• 能否构建新的平台能力，使过去不可行的工作成为可能？

基础设施领域的不同专业方向，也会产生不同类型的影响。

有效的技术教育可以提高工程能力，因此技术教育项目也应该围绕工程能力进行衡量。

教育投入可以减少缺陷、降低返工，并缩短编辑—构建—测试周期。在条件允许的情况下，这些指标应成为评估技术教育项目价值的重要依据。

开发者工具可以通过多种方式创造价值：

• 通过提高开发效率，增强工程能力；
• 通过减少计算资源消耗，提高硬件资源效率；
• 通过遥测、新平台和新能力，增强战略能力。

在实践中，企业也可以借助 PingCode 这类覆盖研发全生命周期的管理平台，将团队目标、客户反馈、需求评审、开发任务、测试缺陷、版本发布和 Wiki 知识沉淀连接起来，并集成代码托管、持续集成等研发工具。这样不仅能够减少跨系统流转带来的信息断层，也有助于形成更完整的研发数据，为分析交付效率、流程延迟和研发效能提供基础。

代码库效率的提升，则通常会直接改善硬件资源利用率。

企业最高层级的业务报告，通常关注产品组合的整体结果，例如收入、成本和其他经营指标。

基础设施团队和中央开发平台团队，则可以关注硬件或云资源利用率，以及 DORA 或类似的工程交付指标。

DORA 指标可以帮助组织回答一个关键问题：

在采用共享基础设施的不同团队中，这些基础设施如何影响整体工程绩效和交付能力，而不仅仅是影响某个具体产品？

基础设施和开发平台团队在设定 KPI 时，可以进一步思考：

客户团队采用我们的服务之后，其工程交付指标会发生怎样的变化？

总体而言，我们建议组织减少部署所需的人力投入，并提高发布频率。

在此基础上，还需要采取一些更细致但同样重要的措施：

• 在工作流的正确阶段衡量正确指标；
• 在适当环节部署有效的缺陷检测机制；
• 在流程延迟、资源成本和人工投入之间取得平衡。

一套衡量软件开发效率的模型

结合前述洞察和缺陷成本估算方法，我们可以构建一种潜在的软件开发模型。

该模型侧重软件开发的业务属性，并允许组织基于实际测量结果和非反事实估算，分析流程效率和优化方案。

要对该流程进行随机模拟，至少需要以下数据。

缺陷产生率

特定团队中的工程师平均技能水平如何？工程师在开发过程中产生缺陷的概率是多少？

随着实践、经验和学习不断积累，缺陷产生率通常会下降。技术教育可能是一种更有针对性、更有效的干预方式，但其直接成本也可能更高。

流程延迟

团队或项目工作流中的每个阶段，会给软件交付增加多少实际延迟？

如前文所述，部署是一种工厂流程，因此降低部署阶段的延迟尤其重要。

硬件容量成本

团队或项目工作流的每个阶段，需要运行多少测试和计算任务？这些任务会消耗多少机器容量？

工程能力成本

项目工作流的每个阶段，有多少工程师参与？分别投入了多少时间？

在部署阶段，开发者的常规参与通常属于不必要成本。

即便在开发阶段，在不损害创造性判断和软件质量的前提下，减少不必要的人工操作同样具有价值。

缺陷检测率

项目工作流的每个阶段，能够过滤掉多少比例的缺陷？

缺陷漏检率

工作流的每个阶段，有多大概率漏过包含缺陷的变更？

缺陷漏检会把问题推迟到后续阶段，延长缺陷存在时间，并增加发现问题所需的资源。

缺陷越晚被发现，接触问题的工程师人数通常越多；如果缺陷进入最终版本，影响范围还可能扩大到用户和客户。

缺陷误报率

项目工作流的每个阶段，有多大概率把实际并不存在生产问题的变更识别为故障？

过高的误报率会浪费工程能力，并降低团队对测试和监控信号的信任。

这些组成部分反复强调“每个项目工作流的每个阶段”，体现了工作流一致性对组织的重要价值。

不同团队共享的工具和基础设施越多，组织就越容易实现规模经济，并开展全局优化。

当然，如果某个项目的需求与其他项目存在明显差异，标准工作流可能无法完全满足需求，此时需要在局部进行调整。

缺陷检测率、漏检率和误报率，也呼应了前文“缺陷成本与测试保真度之间的矛盾”。

规模更小、成本更低、运行速度更快的测试和缺陷检测机制固然重要，但它们并不总能准确代表生产环境中的质量和适用性信号。

随着变更逐渐接近生产环境，缺陷检测信号的保真度通常会提高，但资源成本和修复成本也会随之上升。

把所有测试都前移到开发阶段并不可行。这样会显著增加硬件成本、工程成本和单次变更的等待时间。

把所有测试都推迟到发布验证阶段也不可行。到了工作流后期，一个缺陷可能已经影响大量工程师，其检测和修复成本会变得非常高。

因此，组织的目标应该是设计一组层层递进的工作流阶段，对缺陷进行过滤。

这套流程需要在尽量减少开发者延迟的同时达到可接受的质量水平，并尽可能降低缺陷检测与解决成本的总和。

DORA 指标为什么能够衡量软件交付效率

标准 DORA 指标背后的逻辑，有助于理解这一模型。

降低变更失败率

合理过滤缺陷，应当能够降低生产环境中的故障和错误发生率。

缩短失败恢复时间

经过良好优化的工作流和充分自动化的发布流程，可以带来两项积极结果。

第一，建立更有效的监控体系。

后期工作流阶段之间的推进，例如从版本验证进入金丝雀发布，通常依赖可靠性工程师使用的指标、告警和监控机制。

改进早期缺陷检测能力，也有助于提升生产环境监控水平。需要回滚到先前版本的问题，必须依靠可靠监控才能被及时发现。

第二，提高修复版本的发布速度。

如果进入生产环境的是非灾难性缺陷，不需要完全回滚，那么团队可以快速生成、验证和部署修复版本，从而缩短服务恢复时间。

缩短从提交到部署的时间

DORA 特别关注从代码提交到生产部署所需的时间，是因为提交之后的流程具有较强可比性。

对于大多数团队而言，这一时间都应该尽可能缩短。

提高软件发布频率

当工作流经过优化，并具备充分的自动化和监控能力后，发布更多、更小的版本，可以减少在制品积压，并延长每项变更实际创造价值的时间。

这些标准 DORA 指标都位于代码提交之后。

它们之所以有效，是因为它们从技术层面反映了团队、项目或产品系统的交付能力：

• 团队能否发现足够多的缺陷？
• 能否稳定、可靠地完成部署？
• 能否达到既定的服务级别目标或服务级别协议？
• 系统出现问题后，能否快速恢复？

改进项目级技术系统，例如持续集成、发布系统、金丝雀发布和监控能力，可以改善这些系统级指标。

团队可以采用并持续优化这些系统，以提高整体交付表现。

衡量并减少一段时间内投入部署和运行流程的人工总量，同样十分重要。

如何优化提交前的软件开发流程

与提交后的部署流程不同，提交前阶段具有明显的人为、创造性和设计属性。

这一阶段的指标应该重点关注如何帮助每位工程师更有效地完成创造过程，而不是简单统计个人产出数量。

由于不同变更之间差异极大，工具使用指标和汇总数据通常只能应用于远大于单个团队的群体，而不适合直接评价个人。

提交前阶段的主要改进方向包括：

• 减少编辑—构建—测试循环次数；
• 提高 IDE 自动化和代码理解功能的使用率；
• 减少开发者在工作流中的摩擦；
• 改进开发工具功能；
• 完善文档；
• 加强培训；
• 优化设计流程；
• 改善 IDE 体验；
• 提升诊断能力；
• 降低提交前检查的误报率；
• 缩短提交前等待时间；
• 改进代码审查流程。

开发者也可以提供有价值的定性信息。

既然开发阶段涉及软件流程中人的创造、设计和判断，那么询问工程师是否能够高效完成工作，虽然不能作为绝对指标，却仍然是一项有价值的参考。

创造性流程中的问题和瓶颈，往往会表现为持续的挫败感，进而影响员工满意度和幸福感。

因此，DORA 相关研究也会将工作效率和工作体验纳入开发者幸福感与组织绩效的观察范围。

结论：从整体上衡量软件开发成本与价值

通过对商业软件开发流程进行整体分析，我们可以看到，不同因素之间存在大量相互制约关系。

某个工作流阶段或某项基础设施发生变化，可能同时影响开发、部署和运行中的其他环节。

本文区分了四种不同的软件影响形式：

• 产品成功；
• 硬件资源效率；
• 工程能力；
• 战略能力。

我们提醒组织，不要试图通过无法验证的反事实情景证明某项投资的价值，并提出了一种基于共识的缺陷检测与解决成本估算机制。

这一方法同时考虑了产品结果、战略变革需求，以及创造和运行有价值软件所需的人力与机器成本。

借助这一软件开发成本与价值模型，不同岗位和管理层级可以使用一套更加统一的语言理解商业软件开发流程。

当软件开发的成本、价值、风险和资源权衡能够被更清楚地表达时，组织也就更容易识别问题、评估研发投入，并持续改进软件交付体系。