无论您负责管理一个团队还是整个组织，您都需要密切关注事情的进展情况。良好的开发学习文化会教导您的团队以更聪明的方式工作，而不是更努力地工作，而优秀的工程领导者会寻求客观数据来确保他们正在创造这样的文化。

因此，要审查从等待时间到效率的所有方面，软件开发 KPI 可以帮助您利用客观数据来建立高效、健康且协作的团队。虽然有很多 KPI 需要跟踪，但有些 KPI 比其他 KPI 更有价值。为了完善您的个人指标列表，我们将分解前 13 个软件开发 KPI 和一些您应该避免的 KPI。 

目录：

• 1. 周期时间

• 2. 代码覆盖率

• 3. 代码重做

• 4.变更失败率（CFR）

• 5. 缺陷检测率（DDR）

• 6. Bug 率

• 7.平均恢复时间（MTTR）

• 8. 速度

• 9. 累计流量

• 10.部署频率

• 11. 排队时间

• 12.范围完成率

• 13. 增加范围

• 应避免的常见软件 KPI

• 为什么要在软件开发期间跟踪 KPI？

• 有关软件开发 KPI 的常见问题解答

• 使用 Pluralsight Flow 跟踪您的关键软件开发指标

周期时间是衡量团队完成特定任务所需时间的指标。尽管周期时间很简单，但它可以清晰地反映出开发效率，因为它可以衡量交付速度。它还可以通过概述完成给定流程所需的时间来帮助规划。通过了解每项任务通常需要多长时间，您可以轻松发现潜在的瓶颈并减少开发人员的辛劳。 

高循环时间可能意味着：

• 不理想的流程会减慢开发人员的速度

• 您的团队可能没有合适的工具来快速完成任务

• 员工人数不足

• 技术债务过多 

• 繁琐的审核流程

代码覆盖率衡量经过测试流程正确审查的源代码的百分比。此指标对于使用以下内容的团队至关重要：

• 持续交付管道

• 测试驱动开发 

通常情况下，您无法指望 100% 的代码覆盖率。不过，代码覆盖率越高，您在测试期间越能可靠地发现错误，并节省人工审核的时间。您还可以在代码审核清单上注明覆盖率，以便更好地确定其优先级。 

代码重写可以衡量代码随时间的变化程度。重写几行代码不是问题。事实上，这意味着您的代码可以获得改进所需的时间。另一方面，频繁重写会导致开发人员工作量过大，从而浪费大量工作，最终无法实质性地改善最终产品。 

变更失败率是指导致生产或发布后失败的部署和变更的百分比。要计算 CFR，请将导致失败的变更数除以总部署数。

变更失败率衡量源代码的质量。

• 较低的 CFR表明代码质量较高且错误很少。 

• 高 CFR意味着您的代码需要更多测试和调试。 

底线：高 CFR 会减慢您的开发速度，并将低质量的产品呈现在客户面前。Flow 等平台可以通过突出显示导致更改失败的开发流程部分来改善 CFR。这样，您的团队就可以了解某些更改的影响并降低未来部署的风险。

缺陷检测率将发布前发现的产品缺陷与发布后发现的缺陷数量进行比较。您也可以将 DDR 表示为发布前或发布后发现的缺陷百分比。高 DDR 通常表示测试流程无效。 

错误率会跟踪您在测试期间发现错误的频率。高错误率可能意味着： 

• 您的开发人员匆忙完成编码过程。如果他们在提交代码之前没有检查代码，您将遇到更多问题。 

• 您的开发人员需要获得必要的经验。他们可能对自己的角色或某种软件还不熟悉。 

高错误率本身并不是问题。虽然它可以指向开发问题，但也意味着您的测试有效地捕获了错误。有了这个指标，您可以结合好坏来诊断更深层次的问题。 

MTTR 计算系统发生故障后团队恢复服务所需的平均时间。此指标从产品发生故障时开始跟踪时间，到您恢复服务时结束。根据您所在的领域，此首字母缩略词末尾的“R”可以代表：

• 维修

• 恢复

• 解决

对于 SaaS 公司来说，这一指标至关重要。因为面对现实，事情不可避免地会出问题。这就是为什么最以客户为中心的团队都有事件响应计划和程序来帮助他们快速恢复在线。话虽如此，低 MTTR 本身并不是目标。在恢复服务之前，请确保找到问题的根源，以防止问题再次发生。 

我们建议将此指标与变更失败率配对使用。变更失败率会告诉您是否过于频繁地发生故障，而此指标可帮助您了解恢复在线状态需要多长时间。Flow 会跟踪这两个指标，以帮助您了解问题的来源并自信地实施修复。 

速度记录了您的团队在冲刺期间完成的工作量。大多数团队都了解速度与故事点的关系。通过对这些故事点进行分组并添加花费在这些点上的时间，您可以了解您的总体速度，从而可以设定切合实际的开发目标。 

虽然速度是一种常用的指标，但很难统一定义。一个团队可以在四个小时内解决问题，而另一个团队可能需要六个小时才能解决同一个问题。当团队负责项目的不同部分或提供不同的技术技能时，速度就更难定义。因此，如果您要比较速度，请将比较范围限制在团队或特定职位内。 

累计流程表示您的大部分任务及其所花费的时间在生产流程中的位置。累计流程通常将您的任务映射到流程图或表格上。在图表上，您可以按状态对任务进行分组，包括：

• 得到正式认可的

• 积压

• 已确认

• 进行中

您可以通过绘制任务花费时间最多的位置来找到瓶颈。这可以让团队成员承担责任，并有助于识别管道或流程中的问题。 

部署频率涵盖开发人员将代码部署到准备、测试或生产部门的频率。如果您的团队使用 Agile，那么快速、持续的开发就是首要任务。因此，通过提高部署频率，您可以提高 Agile 成熟度。高部署频率会增加产品更改次数，并有助于避免延迟。 

部署频率是一项综合指标。计算时，您会看到与其他 KPI 重叠，例如：

• 周期

• 平均恢复时间

• 变更失败率

通过将部署频率与此列表中的其他指标进行对比，您可以全面了解您的性能。也就是说，在跟踪此指标时，请考虑部署的规模。较小的更改可让您更频繁地进行部署，并在发生错误时深入了解代码库中受影响的区域。 

排队时间是指工单处于等待状态的平均时间。这些工单可能需要等待反馈、团队成员确认或质量保证。工单等待这些后续步骤的时间将计入排队时间。 

排队时间过长的原因可能是：

• 收到太多工单，而 QA 专家却太少

• 需要调整审核工单的要求

• 员工之间沟通不畅

• 缺乏出色的工具和支持来处理票务队列

排队时间越短，管道越优化。这个 KPI 越低越好。

范围完成率涵盖了冲刺中完成的票证百分比。百分比越低，完成的票证越少。密切关注完成百分比，以确保您的团队设定了可实现的目标。许多团队将其与冲刺燃尽图和发布燃尽图进行比较，但我们稍后会介绍这些内容。

范围完成率低可能意味着：

• 处理票务的工作人员太少

• 你为团队设定的目标不切实际

• 您的流程妨碍了更高的范围完成率

范围增加率记录了冲刺开始后增加的票证或故事点的百分比。范围增加率高意味着您的冲刺计划没有考虑到您面前的所有工作。此外，您在冲刺计划期间制定的计划可能会被抛诸脑后，以适应您的新工作。 

如果你想改善这个指标，你需要关注：

• 全面了解你在冲刺中收到的工单的要求

• 了解你最初确定冲刺范围时将要处理的系统或问题

• 消除你没有时间实现的功能

• 撰写维护预测，说明长期维持新增功能需要投入多少时间和劳动力

KPI 跟踪是一个不断发展的领域，新的指标不断涌现，以完善这一流程。因此，一些曾经流行的 KPI 已被边缘化。虽然跟踪这些指标不会有什么坏处，但您会在上面找到更好的指标。 

代码简洁性衡量代码的清晰度、简洁性和简洁性。从理论上讲，这个指标似乎很有价值——毕竟，干净的代码更容易执行、维护和修改。另一方面，与更明显的品质相比，简洁性更难衡量，而复杂的项目可能需要复杂的解决方案。 

代码稳定性跟踪对代码进行的风险更改的数量，这些更改可能会损害程序。稳定的代码可避免可能损害业务的重写。通常，您可以通过以下方式跟踪代码稳定性：

• 注意代码更改的频率

• 报告造成风险的个别变化

• 跟踪导致崩溃或停机的代码百分比

许多团队回避代码稳定性，因为它很难衡量。为了解决这个问题，您可以将所有代码更改归入代码变更。虽然该指标不跟踪风险，但它更加客观。 

冲刺燃尽图对冲刺期间完成的工作进行了狭义的衡量。与速度依赖平均值不同，冲刺燃尽图着眼于给定时间内完成的任务数量。速度可以预测团队的带宽，但冲刺燃尽图可以帮助团队在预测不准确时进行调整。

Sprint 燃尽图给出的里程数比增加的范围和范围完成率要少。这些指标更全面地描绘了以下内容：

• 你的团队在冲刺开始时的工作量