生产力指标。关于软件中的性能测量，您需要了解什么？

尽管特定编程语言、工具和技术的实用技能和知识是作为软件开发人员找到一份全职工作的关键，但还有另一个有价值的指标，在​​许多方面可以被视为在这个职业中取得成功的先决条件：生产率。生产力衡量是所有专业软件开发人员都需要了解和考虑的事情，因为性能指标对于当今商业环境中的任何软件开发团队来说都非常重要。

为什么您作为开发人员的生产力很重要？

在敏捷开发、DevOps 和缩短软件发布周期的时代，当开发人员需要尽快发布产品的新版本时，公司会使用多种不同的生产力指标来评估单个程序员和整个团队的绩效。从开发人员的角度来看，性能测量可以服务于许多有价值的目的，帮助您跟踪编程技能的进步，这将使您实现持续的专业成长。高效的编码人员最终会收到令人瞠目结舌的薪水，并开始从事最令人兴奋的项目。但即使你不是一个高成就者，只是想从事软件开发方面的任何工作并在其中取得相当大的成功，您仍然需要至少对绩效指标以及如何使用它们来衡量工作投入的生产率有基本的了解。这就是我们今天要讨论的内容。

软件开发生产力测量指标

什么是软件开发生产力指标？

软件开发指标是编程工作的领域，可以应用定量测量来跟踪开发人员的性能、工作质量和生产力。每个生产力指标都基于从开发过程中获取数据并使用它来衡量生产力。由于与软件开发相关的几乎没有任何事情是简单直接的，您可以说衡量编程生产力在整个行业中也非常不一致和分散。或者，简单地说，不同的团队和公司可以使用完全不同的绩效指标，从多个角度来解决这个问题。因此，您无需费心学习软件开发团队可能使用的每一个指标。

有哪些类型的软件开发生产力指标？

自然地，有多种不同的生产力指标可以从不同的层面和角度衡量绩效。以下是此类生产力指标的最常见类型：

• 正式的以规模为中心的指标。

这些指标侧重于衡量程序员工作成果的大小，例如代码行数 (LOC)、代码指令长度、代码复杂度等。在当今的软件开发行业中，这些指标越来越被认为已经过时。

• 以时间和功能为中心的生产力指标。

瀑布式软件开发中使用了一系列传统的生产力指标，例如活跃天数、特定时间段内发布的功能范围、代码改动率、分配的任务数量等。

• 敏捷开发过程指标。

敏捷开发过程指标，如冲刺燃尽报告、速度、提前期、周期时间等，可能是当今软件开发团队最常用的指标。我们将在本文后面更详细地讨论敏捷指标。

• 运营分析指标。

这组指标侧重于衡量软件在其当前生产环境中的性能。平均故障间隔时间 (MTBF)、平均恢复时间 (MTTR) 和应用程序崩溃率是此处最常用的指标。

• 测试指标。

软件测试有自己的一套指标来衡量系统测试的质量，例如自动化测试的百分比、代码覆盖率等。

• 客户满意度指标。

最后，任何软件的最终指标都是最终客户体验，并且还有一整套指标，例如客户努力得分 (CES)、客户满意度得分 (CSAT)、净推荐得分 (NPS)和别的。

敏捷软件开发指标

如您所见，很容易迷失在软件生产力指标的所有复杂性中。然而，普通软件开发人员唯一应该熟悉的是敏捷指标，当今软件开发团队通常将其用作衡量软件开发生命周期不同部分的团队生产力的标准。让我们列出主要和最常用的敏捷指标。

1. 冲刺燃尽。

Sprint Burndown 报告是敏捷 Scrum 开发团队的关键指标之一。在敏捷中，开发过程是通过有时间限制的冲刺来组织的，Sprint Burndown 被用作在冲刺期间跟踪任务完成情况的一种方式。小时或故事点用作度量单位。目标是实现一致的进展，并根据最初的预测交付工作。Sprint Burndown 帮助团队衡量工作节奏并在需要时进行调整。

2. 团队速度。

速度是另一个关键指标，它也是以小时或故事点数作为衡量单位。它衡量团队在冲刺期间完成的平均工作量，并用于整个项目的估算和规划。跟踪速度对于确保团队提供一致的性能非常重要。

3.故事点。

在单个开发团队成员的级别上，故事点是一个有价值的指标，因为程序员在每次发布期间交付的故事的大小是该编码员生产力的指标。

4.周期控制图。

测量从任务或另一个积压项目的工作开始到完成的总时间。允许跟踪和控制周期时间，提供更可预测的结果。

5. 吞吐量和交付价值。

项目经理分析分配给开发人员的任务并为他们分配价值。然后使用该指标衡量团队的吞吐量，换句话说，衡量完成的增值工作量。

6. 代码流失。

代码流失是另一个值得一提的指标，因为它既可用于衡量整个团队的生产力，也可用于跟踪单个程序员的绩效。代码流失衡量开发人员删除或更改之前添加的代码行的频率，以及之前编写的代码最终被更改或丢弃的百分比。

专家意见

最后，补充一些观点，引用经验丰富的软件开发行业专业人士对此事的一些看法。“我确实希望您不要将您的指标与某种标准或什至与另一家公司的另一个团队的绩效进行“比较”。在我工作过的每个地方，他们对故事点、速度、每小时估算、任务等的定义都有独特的差异，这真的使得几乎不可能将一家公司的一个团队的绩效直接与另一家公司的另一个团队的绩效进行比较公司，”前技术产品经理兼敏捷教练 Cliff Gilley指出. “在指导团队绩效方面，我对指标有点怀疑。一旦你只关注一个或两个变量，就很容易陷入（有意或无意）衡量指标的游戏并自欺欺人地认为你正在改进 - 当你所做的只是改进指标时。例如，基于速度的指标可以通过团队转移到更小的故事来“改进”（每个故事的工作更少——所以完成的故事更多——所以速度上升）。如果这些故事是有用的用户故事，可以提供较小的商业价值增量，那可能是一件好事。如果故事变得更小，更“技术性”的任务本身并不能带来真正的价值，那可能是一件坏事，”另一位行业专家 Adrian Howard说. “在基于拉动的系统中工作时，我重视吞吐量和周期时间。第一个给了我关于我们团队能力的一般信息，随着时间的推移可以成为一个非常强大的预测指标。第二个有助于作为我们管道效率的一般衡量标准。如果周期时间很长，是时候开始查看管道了，因为有一个限制条件，我们可能会努力缓解/利用。但指标只是工具。不要迷失在其中，当然也不要开始针对特定指标进行计划。想想你作为一个团队在做什么，以及你自然如何工作，然后围绕人构建系统。这些指标应该可以帮助您了解您的系统如何支持每个人的工作。或者不是，”视频游戏开发制作人戴夫·塞拉 (Dave Cerra)总结道。