软件项目评估工作量（简化软件交付的四个工程指标）

长期以来，衡量软件工程团队的绩效一直被视为一项复杂而艰巨的任务。随着软件变得更加复杂和分散，尤其如此。

为了交付更好的软件，工程团队需要持续改进的可见性、数据和决策。软件工程团队用来管理流程和发布软件的应用程序可以访问比以往更多的数据。团队可以使用这些数据来衡量他们的绩效——如果他们知道哪些数据最准确地反映了团队绩效。

Google的DevOps 研究和评估(DORA) 团队设计了一个为期六年的计划，以了解高绩效软件工程团队与低绩效软件工程团队的区别。他们调查了多个行业的数千个团队，以衡量和了解 DevOps 实践和能力。这是同类中运行时间最长的学术严谨调查，提供了对推动技术交付以及最终组织成果的高性能的可见性。

DORA 团队有两个他们想要验证的假设：

1. 软件工程团队的绩效可以用一种有意义的方式来衡量。
2. 高绩效的软件工程团队（基于他们发现的衡量标准）可以预测更广泛的组织绩效。简单来说，高绩效团队为组织带来高价值。

DORA 发现，高绩效组织更关注工程成果而不是产出，而团队则更关注个人。从研究中，他们确定了表明软件工程团队绩效的四个关键指标：

1. 部署频率
2. 平均变更提前期
3. 平均恢复时间
4. 更改失败率

这些指标提供了一种数据驱动的方法来分析和改进基于实际研究的性能。DORA 使用这些指标来识别精英、高、中、低绩效团队。他们的研究发现，精英团队实现或超过其组织绩效目标的可能性是低绩效团队的两倍。

让我们更深入地研究这四个指标，以了解关注它们如何帮助团队更快、更有效地交付软件。

在高层次上，DORA 工程指标衡量软件工程团队的速度以及他们构建和发布的软件的稳定性。如果团队可以不断改进这些指标，他们就可以更快地向客户发布更高质量的软件。

对于以下四个 DORA 工程指标中的每一个，我们将介绍指标是什么、如何计算、为什么重要、如何改进以及精英团队的目标价值。

部署频率是软件工程团队将代码部署到生产环境的频率。这个重要的指标可以代表团队为客户提供新价值的频率。

持续交付和交付代码，因为快速、小型、频繁的部署是 DevOps 的关键组成部分。部署频率揭示了团队的工作和发布流程的效率。例如，如果部署频率变慢，则可能表明新工作流程存在问题。测量部署频率可以揭示变更对团队结构、人员或流程的更广泛影响。与其他指标一起测量部署频率可确保部署的更改为客户增加真正的价值。

部署频率通常以每天的部署报告。您可以通过从团队的持续集成/持续交付工具中提取数据来自动执行此测量。

软件工程团队可以采用一些实践来提高他们的部署频率：

• 减少每批工作的大小，以便团队可以更频繁地交付较小的工作。另一个优势：风险较小的部署可以在出现问题时轻松跟踪或回滚。
• 与持续集成/持续交付工具集成，以提高发布过程的效率。
• 在将新更改部署到生产环境之前，使用自动化测试来提高对代码质量的信心，并减少对缓慢手动测试的需求。

精英团队每天多次部署生产变更，以持续为客户增加价值。

变更提前期（也称为周期时间）是从代码提交到代码成功运行所花费的时间。它允许您跟踪软件工程团队的步伐。更快的团队优化了流程，可以更快地将新功能推向市场。这种提高的效率为增加组织收入、提高客户续订率和创建快乐高效的团队提供了机会。另一方面，交付速度较慢意味着流程中存在浪费或效率低下，从而导致客户延误。

衡量变更提前期还有助于团队识别其工作流程中的瓶颈，以便他们可以优化和改进。

平均变更提前期是通过跟踪每个代码提交到生产中交付的代码之间的时间并计算平均值来计算的。

软件工程团队可以采取哪些措施来改善他们的平均变更提前期？

• 将测试集成到开发过程中。
• 自动化测试而不是手动测试。
• 与持续集成/持续交付工具集成
• 简化代码审查流程以减少延迟。

精英团队的平均变更提前期低至一小时。

平均恢复时间衡量软件工程团队从故障中恢复的速度。故障是指任何中断预期生产服务质量的事情，从部署中引入的新错误到托管基础设施出现故障。平均恢复时间表明软件工程团队能够以多快的速度理解和解决生产中出现的问题。停机时间对客户来说从来都不是好事。较短的平均恢复时间让团队有信心，如果生产受到影响，它可以迅速恢复到功能状态。

平均恢复时间是通过跟踪报告生产错误或故障与修复该问题之间的平均时间来计算的。

以下是软件工程团队可以提高平均恢复时间的一些方法：

• 引入可快速报告生产故障的监控工具。
• 实施强大的待命和支持文档系统。
• 缩短部署时间，以便可以将已修复的问题快速发布到生产环境中。
• 使用功能标志，您可以通过单击按钮来打开/关闭生产中的功能。这可以将平均恢复时间减少到几秒钟。

精英团队的目标是平均恢复时间少于一小时。

变更失败率衡量软件工程团队发布导致失败的生产变更的频率。这些更改会导致错误或必须回滚，因为它们不符合客户的期望。该指标表明团队构建的软件的质量。修复错误和回滚代码是一项代价高昂的工作，因为它占用了可用于构建为客户增加价值的新功能的时间，因此高更改失败率表明低质量的软件会让客户感到沮丧。

更改失败率以百分比计算。它是每个部署次数的失败次数与生产的比率。

软件工程团队可以实施这些实践来提高他们的变更失败率：

• 引入自动代码审查工具来捕捉手动代码审查遗漏的问题。
• 为所有新代码添加自动化测试。
• 使用持续集成/持续交付工具运行所有自动化测试作为发布过程的一部分。
• 引入事件回顾，以便团队了解导致事件的原因并努力确保它不会再次发生。

精英团队的目标是让变更失败率在 0% 到 15% 之间。

当然，在评估软件工程团队的绩效时，这些并不是您可以考虑的唯一指标。您可以跟踪的许多其他指标可以提供对团队绩效的洞察。然而，DORA 发现这四个指标与更广泛的组织成功最相关。

四个 DORA 指标看起来很简单，但如果使用不当，就会产生问题。

每个使用 DORA 工程指标的团队都存在于自己的环境中，其产品/服务将与其他团队不同。这些指标应该用于帮助各个团队不断改进他们的交付。一种反模式是使用指标来对您的团队进行相互评分。这是不公平的，因为每个团队的背景和出发点都不同。

一起考虑所有四个指标，而不是只关注一个子集。这些指标旨在平衡速度和质量，因此对子集进行归零可能会导致性能下降。例如，如果您发布的许多更改都有错误，那么高部署频率可能会对质量产生负面影响。

这些指标不应该消耗你的团队，成为他们唯一关注的事情。改进指标永远不应该是你的主要目标。古德哈特定律说：“任何成为目标的措施都不再是好的措施。” 目标应该是不断、有效地为客户提供价值，使用指标来反映您的团队朝着该目标取得的进展

最后，确保 DORA 工程指标不会成为显示数字的虚荣指标，但没有提供关于采取什么行动的明显线索。如果一个团队部署 100 次，这意味着什么？一天、一周、一年有 100 次吗？自上次测量以来，这个数字是否有所改善？如何改进？其他指标是否受到影响？DORA 指标帮助团队评估和提高他们的绩效，但为了让团队采取有意义的行动，他们需要了解指标在上下文中做了（和不）表明什么。

软件工程团队一直在寻找改进流程和交付的方法。多年来，团队一直缺乏一种客观、有意义的方式来衡量他们的表现。DORA 团队希望通过关注指标来改变这种状况，这些指标不仅可以表明团队的表现，还可以揭示有关组织整体健康状况的重要线索。

您的团队在 DORA 的四个指标方面的表现如何？这对您的组织有什么影响？