无论何时，只要是要评估或对比某些东西，就需要使用度量指标。它们是可量化的衡量标准，用于判断每个行业的进展。这其中包括软件开发，在该领域，开发负责人依靠软件度量指标来跟踪性能和生产。
在我们关于如何衡量和提高开发人员工作效率的博客文章中，我们讨论了代码度量指标在衡量和提高开发人员工作效率方面的作用。其中一个挑战就是在适当的时候为适当的工作选择适当的度量指标，本文将帮助您了解需要了解的内容。
管理者的工作是为公司创造价值，在软件领域，开发负责人负责构建和改进产品、管理时间和满足预算。这些职责都依赖于评估团队或项目的当前状态、衡量进度以及估计达到下一个里程碑所需时间和资源的能力。
开发负责人依赖软件度量指标来保证质量，并帮助加强团队成员之间的协作。有效的软件度量指标与主动管理相辅相成，帮助开发负责人满足发布日期并控制开支。软件度量指标有助于识别当前版本和预发行版本中的问题，可用于相应地跟踪问题并确定其优先级。重要的是，正确的软件度量指标为更准确的预测铺平了道路，并有助于考虑在开发生命周期期间所做决策的影响。
软件度量指标比较棘手，因为衡量软件质量不仅具有多方面性和主观性，而且重要的东西可能会因项目而异。一个团队或组织中的优先级和最重要的事情对于另一个团队或组织而言会有所不同，这意味着没有一种通用的软件度量指标。
软件度量指标五花八门，数量众多，因此选择正确的度量指标取决于您需要跟踪的确切内容。一个常见问题是，度量指标并不总是与项目目标相关联。例如，如果内存优化很重要，那么减少代码行(LOC) 可能是相关的。但是，如果目标是尽可能地减少错误，那么应该对测试指标（如报告的错误数量）施加更大的权重。
项目阶段也将决定哪些软件度量指标应给予更多考虑。项目早期，Git 提交的数量将产生有关模块添加速度的宝贵信息。以后，开发负责人将会对平均故障间隔时间 (MTBF) 或应用程序崩溃率 (ACR) 更感兴趣。
我们应该记住，一个有价值的度量指标不仅仅是一个数字。任何给定时间的单点指示在不显示趋势的情况下几乎没有用，它们需要呈现更大的画面。这是因为从一天到另一天，某一特定度量指标可能几乎没有变化。然而，随着时间的推移，这一趋势将逐渐凸显成功或失败。如果您的度量指标没有凸显出趋势，那么就需要重新考虑。
另一个重要点就是，度量指标必须建议和促进变化。使用不会带来显著变化的度量指标其实就是浪费时间，因为没有这个，开发人员会继续犯同样的错误。需要重申的是，度量指标不仅仅是一个数字，而是需要进一步推进您的目标。如果有一个度量指标没有导致代码库或进程发生变化，那么最好用更有意义的指标来代替它。
软件度量指标可以分为几个不同的类别，根据团队、环境和开发阶段的不同，每个类别对项目可能或多或少有用。不同的度量指标适用于不同的粒度级别，其中一个与单个开发人员相关，而其他指标则考虑团队绩效。当然，有些适用于两者，尽管个人和团队应该分开评估。
代码度量指标
代码度量指标是用于指示代码库细节的衡量标准。这些可能是以大小为导向的指标（例如，代码行总数或逻辑与注释的比率），或者是与内容相关的指标（例如，代码复杂性指标）。总之，代码度量指标只在一定程度上有帮助，特别是在单独使用时，因为它们没有充分考虑环境，因此不能说明全部情况。
以规模为导向的度量指标
以规模为导向的度量指标是一种代码度量指标，通常用于以千行代码 (KLOC) 来比较相同语言的项目。KLOC 度量指标不用于衡量项目规模。相反，它们是统计度量，指示每 1000 行代码的相对错误数、相对缺陷数和相对成本。无论项目规模如何，它都使用这个通用基线。由于编程语言之间的内在差异，以规模为导向的度量指标在比较使用不同语言开发的项目时并没有用处。
方法特定度量指标
编码方法因公司和项目而异。虽然有共同的目标，但是方法，或者更具体地说，过程各有不同。说到 KPI，不同的方法有不同的优先级。两种流行的方法是 Agile（敏捷方法）和 Waterfall（瀑布法）。
敏捷过程度量指标
这些度量指标专用于遵循敏捷过程方法的开发团队。它们用于衡量团队在发布可交付软件方面的效率。例如，Sprint Burndown 用于跟踪冲刺期间的工作完成情况，并显示剩余的工作量。速度是另一个敏捷法度量指标，用于描述团队在冲刺期间可以完成的工作量，以小时或故事点来衡量。
瀑布法度量指标
瀑布法比敏捷方法更为固定，通常在项目需要高度可靠性或要求明确的情况下使用。由于固定的时间线不包括频繁的反馈，因此度量指标有所不同。例如，在实施阶段发现的错误数量非常重要，因为有时需要返回设计阶段。如果这种情况发生的太频繁，可能表明实施前审查过于仓促。
工作效率度量指标
工作效率指标可以用来确定一个项目或一个团队已完成的工作量。这与工作完成的效率和速度高度相关，本质上突出了团队的优势和需要改进的地方。选择工作效率指标时，应确保选择不仅相关且代表项目实际目标的指标。
工作效率实际上是任何项目都应该最大化的指标。正如我们在博客文章 C++ 开发人员的工作效率工具中所讨论的那样，有各种各样的工具可以帮助提高个人和团队的工作效率。
安全度量指标
安全度量指标用于衡量软件对安全事件的敏感度或抵抗力。存在软件漏洞的成本可能非常高，而且会导致政府合规性方面的问题，因此这种类型的度量指标对于某些产品来说是必不可少的。安全度量指标的例子包括解决漏洞所需的平均时间和自动静态代码扫描识别的漏洞数量。需要记住的重要一点就是，与代码分析器检测到的漏洞数量相比，某些安全度量指标（例如与合规性相关的度量指标）与执行管理层的相关性更大。满足所有相关利益相关者的需求很重要。
运营度量指标
运营度量指标有助于评估软件在生产环境中的运行情况，包括产品的年度正常运行时间或正常运行时间与停机时间的比率。这些指标很重要，因为它涉及到质量保证、产品可靠性，以及是否有足够的资源用于维护和支持。但是，这些指标对于开发新产品的开发团队来说没有那么有用。
产品度量指标
产品度量指标可表明产品在市场上的表现如何。这些指标并不只是适用于软件领域，但至少可以应用。您可以利用这些指标跟踪诸如您的产品在多大程度上满足公司目标等情况。这些指标的例子包括用户采纳和客户保留。这些指标旨在回答管理层和规划者的问题，而不是开发人员的问题。
质量保证度量指标
质量保证是个笼统的术语，包括故障指标以及其他与维护相关的衡量指标。这其中包括诸如平均故障间隔时间以及修复故障通常需要多长时间等细节。这可以深入了解正常运行时间与停机时间，以及有多少停机时间可归因于维护。
测试度量指标
在任何版本转移到生产环境之前，开发人员和产品测试人员都会使用各种测试指标。这些指标有助于提供有关系统测试情况的信息，这与质量保证有关。但是，这些指标并不适用于管理层，这是它们与更一般的质量保证指标的不同之处。管理层使用质量保证指标判断发布的质量，而测试指标仅用于在预发布阶段为开发人员提供帮助。
现在，您已经有了一个大概的了解，接下来让我们看一下根据您的项目和流程可能会选择的一些特定软件度量指标。
交付周期
这反映了开发新功能或模块从定义到交付所需的时间。它倾向于显示开发组对利益相关者的请求的响应程度。即使团队不愿意提供大致的交付时间，我们也可以通过查看具有类似功能集的以前的产品来估计。
循环时间
该度量指标是指变更请求与其可交付或生产发布之间的时间。其中包括打开问题的时间、发现和审查问题的时间、批准工作的时间、完成更改所需的时间，以及部署时间。这是一个非常重要的度量指标，因为它表明了价值实现时间与效率的比率。
部署频率
部署频率指的是每天发布的数量。该度量指标可表示交付给客户的价值水平。考虑这一点很重要，因为开发管道可以在较短的周期内实现高效，但同时，部署频率低可能意味着交付的价值不足。
团队速度
通过团队速度，我们可以深入了解团队在敏捷法冲刺期间或发布迭代期间完成的工作量。虽然它对于衡量团队内部随着时间的推移而取得的进展很有用，但它不应该用于比较团队，因为每个团队可交付成果的性质和复杂性可能无法比较。
打开/关闭率
打开/关闭是在规定期限内识别和确认的生产问题。这一比率随时间的推移而增加，这表明团队在解决问题方面变得更加高效。
效率/工作效率
效率通常是指开发人员在生产中的代码量，以百分比而不是代码行数来衡量。高效率与更长时间地提供价值相关，而低效率则可能表明在难以实施的创新功能上出现了许多错误的开始。与效率相反的是代码改动，它表示非生产性编码的水平。
活跃天数
活跃天数与程序员的工作效率有关。一个活跃日代表单个开发人员在单个项目上工作的一个编码日。这可以仅跟踪编程，而不包括行政管理工作。事实上，会议等行政管理任务占用了编码时间，而这正是该度量指标所衡量的。从本质上说，跟踪活动天数重点关注中断成本。
影响
该度量指标是一种主观衡量标准，表示添加、删除或修改代码后项目的更改程度。其理念是，影响更大的变更更难实施，这意味着需要承担更大的任务，或者可能需要更大的认知努力。例如，与更改一组输出语句中的文本相比，添加一个新颖而复杂的功能将产生更大的影响，即使有更多行的修改代码。
代码改动
代码改动是一个基于 Git 的度量指标，可提供对个人和团队等的洞察。它表示开发人员在短时间内修改或删除了多少工作，通常表示为在指定时间内更改的代码行数。代码改动率高可能意味着开发人员不确定该做什么，实施时遇到问题，甚至他们没有其他工作要做。从管理层或团队的角度来看，这可能表明相关模块或功能未正确定义或过早添加。
平均故障间隔时间 (MTBF)
该质量保证度量指标表示平均无故障时间，定义系统的可靠性。故障是必然会发生的，但是最好很少且相隔甚远。理想情况下，当确实发生故障时，恢复所需的时间相对较短，但无论如何，在安排预防性维护时，该度量指标可以提供帮助。
平均恢复/修复时间 (MTTR)
即使是高度可靠的系统也会发生故障，而当它们发生故障时，客户希望将因此导致的任何停机时间降至最低。为此，平均故障恢复时间必须尽可能地短。当然，故障的严重程度会有所不同，做出必要更改的个人也会有所不同，所有这些都会给度量指标增加干扰。但是，随着时间的推移，在预测客户在操作恢复正常之前必须等待多长时间时，MTTR 将作为一个可靠的估计。
应用程序崩溃率 (ACR)
应用程序的崩溃率类似于 MTBF，但它是指使用频率与失败频率的比率。MTBF 则不一样，因为它是时间度量。
终点事件
终点事件涉及安全相关问题，表示在规定时间段内有多少设备受到恶意软件的影响。这可能是软件漏洞造成的。
每 KLOC 的错误数/每 KLOC 的缺陷数
每 KLOC 的成本
该指标描述每一千行代码的平均成本。它可用于描述项目的不同阶段。例如，开发期间每 KLOC 的成本将与发布后维护期间的每 KLOC 的成本不同。
每个功能点的工作量/每个功能点的缺陷数/每个功能点的成本
这些是以功能为导向的度量指标，取决于首先计算功能点 (FP) 的指标。功能点是一个表示软件应用程序中用户可用的业务功能的衡量标准，可根据需求进行定义。
作为一个基本的度量单位，功能点具有相关的衡量标准，其中包括每个功能点的工作量 (EFP)、每个功能点的缺陷数 (DFP) 以及每个功能点的成本 (CFP)。较低的 EFP 意味着较高的工作效率，而较低的 DFP 则代表较高的产品质量。CFP 表示成本效率，而 CFP 的降低意味着开发和维护变得更具成本效益。
缺陷排除效率
缺陷排除效率 (DRE) 用于表示与发布前开发和测试期间发现的缺陷数量相比，最终用户发现的缺陷数量。其计算方法是将交付前发现的错误数除以软件投入生产前后发现的错误总数。最终用户发现的错误越多，则用于表示效率的数字越小。满分是 1.0，这表明最终用户在生产中没有发现任何问题。
度量指标选择不当可能带来的后果不仅仅是浪费时间，尤其是在单独考虑时。了解您正在度量的内容很重要，以下示例说明了可能发生的一些潜在问题。
代码行 (LOC)
我们来考虑一下当代码行是唯一或主要度量指标时的情况。就其字面而言，人们可能会认为写更多行代码更好。但是，作为一个经验丰富的管理人员，您知道事情并不总是这样。实际上，当代码行作为驱动因素时，开发人员倾向于编写不那么优雅、更繁琐且效率可能更低的长代码。除非它与效率回报指标相结合，否则代码行更像是一种负担，而不是奖励。
代码覆盖率
另一个单独使用的有问题的度量指标是测试中的代码覆盖率。如果不使用诸如每次测试发现的缺陷数量等其它质量指标，而仅使用代码覆盖率，可能会产生误导性的结果。如果测试很幼稚，不能可靠地识别错误，就会发生这种情况。代码覆盖率可能会非常高，从而产生一个令人印象深刻的度量指标，但是如果不知道测试结果，会更难以对测试进行评估。
是否有与特定项目更加相关的衡量标准？
毫无疑问，不同的度量指标与特定项目更相关。例如，衡量影响就和处于初始阶段的项目无关。另一方面，与在更成熟的产品中处理功能请求相比，代码行等代码度量指标在早期开发期间更有价值。为您的项目选择适当的衡量标准意味着在适当的时间将度量指标与适当的目标相匹配，并确保度量指标相互补充，以增加统计数据的有效性，从而最终引导代码库、团队或流程发生积极变化。
软件度量指标是应用于软件开发周期的定量衡量标准，可用于评估项目的当前状态。随着时间的推移，趋势将会出现，而开发负责人可以展示进度，计算项目决策的影响，并对时间表做出可靠的估计。度量指标是无价的，对于任何项目的推进都至关重要。
同时，使用太多度量指标，或者使用那些对项目目标没有帮助的指标，反而会适得其反。没有哪个度量指标是一门精确的科学。请做出明智的选择！ 然后，跟踪和评估这些度量指标，以确保每一个都能发挥作用。如果一个度量指标没有带来变化，则必须对其进行修改或更换。
点击了解 Incredibuild 的分布式编译解决方案，并获取试用 License！
