研究表明，相较于传统办公室环境，远程工作团队的效率更高。这引出了一个问题：远程软件工程师的效率提升到了什么程度？

想要了解远程工作如何影响团队表现的管理人员可能会设定一些关键绩效指标。但是，并不是所有的KPI都适用：像代码行数、工作时间和修复的错误这类数据可能会误导对生产力的判断。这些不成熟的指标衡量的是错误的方面，很容易被操作，而且它们无法提供任何有助于个人或团队提升表现的真实或可操作的洞见。

选择正确的指标来衡量是关键，这样才能确保软件开发项目按计划顺利进行，同时不破坏团队的士气。通过提供合适的工具来赋能开发人员高效工作，这就是将KPI融入业务运作的理由。

在软件开发中，采用KPI旨在确保与业务目标和目的保持一致。但是，调查表明，有90%的组织仍然靠直觉来设立有效的工作流程，尤其是在执行策略、衡量和规划成功方面，他们遇到了挑战。

为了避免依赖直觉而导致的效率和执行问题，企业应该设置清晰的目标和高级策略来衡量软件开发过程的生产力和效率的关键绩效指标（KPI），并确保这些KPI与他们目标的质量相匹配。

在制定这些KPI时，技术管理者需要问自己一些问题：

为了确保KPI与软件开发项目正确对齐，可以采用SMART技巧，意味着KPI应该是：

通过引入更好的规划机制并在组织的不同层面纳入KPI，组织将能够：

软件开发的关键绩效指标（KPI）有五种主要类型：

关键的理念是，指标是用来指导而非直接衡量的工具。通过设定具体的指标，可以预测和改善团队的表现。

要让开发团队保持正确的发展方向，就需要利用这些关键的绩效指标。

这一KPI有助于描绘出开发过程的趋势图，并评估把一个想法转换成成品需要多少时间。通过创建交付时间分布图来估计从概念到完成的整个过程需要多长时间。

这种交付时间分布图对于改善工作流程十分有用。明白在何时何地设定目标可以帮助稳定工作流程并提高预测性，为组织带来新的机会。

效果图截取自：PingCode

指的是一个缺陷、功能或任务从开始到结束所需的时间。这可以更详细地反映出团队的工作速度和效率。根据问题的类型，比如是缺陷修复还是新功能开发，可以有不同的周期时间分类。

使用项目管理工具，比如JIRA，可以追踪周期时间，即从任务开始到完成的整个过程。周期时间可以揭示工作流程中的任何瓶颈、障碍或问题，并帮助设定合理的期望值，确保其他团队的问题能被开发团队有效解决。

计算周期时间的方法是用结束日期减去开始日期。这个公式有助于比较不同任务的周期时间，让软件开发团队更清楚地理解在各个任务上的时间投入。

效果图截取自：PingCode

累积流动图是一种显示所有正在进行、待处理和已完成任务的视觉工具。通过不同的颜色，它展示了任务在项目的不同阶段的分布情况，比如“已确认”、“项目已批准”、“任务正在进行中”、“工作即将完成”、“调整中”、“项目准备就绪”和“任务已完成”等。

这种图表涵盖了工作流的三个关键方面：工作的吞吐量（即完成的工作量）、任务完成所需的周期时间以及正在进行的工作量。累积流动图能帮助跟踪开发团队的工作产出，确保他们对其持续的表现负责。

效果图截取自：PingCode

流动效率是衡量等待工作完成所需时间的指标。它通过比较剩余时间和正在进行的工作量来揭示效率低下的地方，指出哪些地方的工作没有按计划进行。改进流动效率意味着减少等待时间，从而改善项目管理和工作分配。要计算流动效率，只需将投入开发的时间除以整个周期的时间。

冲刺燃尽图是敏捷Scrum方法中的一个关键指标，它展示了项目中剩余的工作量以及时间进度。通过在图表的y轴上标记尚未完成的工作量，在x轴上标记时间，可以观察团队的工作进度是否符合计划，以及项目的规划是否准确。

它还可以帮助你更有效地计划你的冲刺，将工作分配成细小的部分，以避免你的团队过度劳累。

这段内容讲述了如何通过将工作划分为更小的部分来更有效地规划冲刺，以此避免团队成员过度工作。

效果图截取自：PingCode

速度这一指标反映了软件开发者在一定时间内完成了多少具备交付价值的工作。根据一个开发者博客的补充，交付价值通常指的是那些已经完成并且准备好发布或测试的功能的数量。

速度是通过故事点数或功能票证来衡量的，它能够帮助进行以下几方面的工作：

要计算软件开发团队的工作速度，了解他们的平均速度至关重要。比如，如果一个团队在第一轮冲刺中完成了80个故事点，在第二轮和第三轮分别完成了90个和130个故事点。

效果图截取自：PingCode

这三次冲刺的平均故事点数是100，这个数字可以用来估算团队完成项目所需的平均时间。例如，在实际的软件开发中，如果一个项目需要完成500个故事点，那么团队可能需要进行五轮冲刺来完成所有开发工作。一般来说，更高的速度表示团队的生产力和表现更好。

如果你发现团队的速度指标每周波动很大，这可能意味着有些问题阻碍了开发者的绩效。如果速度与平均值相比有明显偏差，这可能是一个警示，表明流程中可能出现了问题。那么，问题在哪里，应该怎么解决呢？

以下是一些建议，帮助你测量和理解速度：

软件故障是难以避免的，软件开发中两个重要的指标是平均故障间隔时间（MTBF）和平均修复时间（MTTR），它们衡量的是软件在发生故障后恢复的能力。

MTBF是指两次故障之间的平均时间，通过将软件的总正常运行时间除以故障发生的次数来计算。而MTTR是指修复软件故障所需的平均时间，同样是通过将总修复时间除以故障次数来计算。这两个指标可以帮助评价软件开发团队的整体效率和表现。

在软件发布前，确保产品稳定性极为重要。代码变动指标通过追踪一定时间内添加、编辑或删除的代码行数来帮助公司监控开发生命周期和软件工程师的工作质量，特别是识别哪些开发阶段最不稳定。

通过分析代码变化来发现问题，比如哪些修改引发了大量变动，可以避免发布不稳定的代码。

在软件开发的整个生命周期中，代码的质量扮演着至关重要的角色。代码覆盖率是一个评估软件测试质量的重要工具，它帮助软件工程团队评价测试驱动开发的实践效果、分析整体的代码质量，以及在测试执行期间实际运行了多少代码行。如果没有这个关键绩效指标（KPI），就几乎无法有效地进行生命周期管理和数字产品的测试。

代码覆盖率的计算可以检测哪些代码行被测试执行过，从而帮助识别错误和需要调试的地方。计算公式是：CCP = (A/B)*100，这里的A是在测试中执行的代码行数，B是系统中总的代码行数。

开放请求（或称为未处理的拉取请求）是衡量团队协作效率的一个指标。拉取请求是开发人员请求团队其他成员审查代码更改或提供反馈的一种方式。

如果这些请求没有得到及时的处理，就会保持“开放”状态，这可能会阻碍项目的其他部分或某个冲刺的进展。定期检查未处理的拉取请求可以帮助发现功能交付过程中的瓶颈，从而为代码审查过程分配更多的时间或资源。

吞吐量是衡量团队总体工作成果的指标，包括了所有准备好测试和发布的功能、任务、缺陷或其他小事项的总数。这个指标通常在一定的时间段内测量，比如一周或一个月，并且会持续跟踪，让你能够看到团队的工作是否保持一致。

测量吞吐量的目的是检查工作成果是否符合你的目标。如果你的目标是解决软件中的缺陷，那么你应该能看到一个健康的解决缺陷票据的比例。如果你的焦点是增加新功能，那么完成的新功能票据应该会多于琐事和缺陷票据。通过参考这些票据来精确测量吞吐量，可以帮助软件开发者更高效地工作。

随着远程工作成为新常态，选择能够真正帮助软件工程团队改善和达成开发目标的正确关键绩效指标（KPI）变得至关重要。同时，确保这些KPI与项目相关且易于理解、可执行、可测量、可见，并且及时，也同样重要。

设立KPI并努力达成它们会给软件开发团队带来额外的压力。过度管理开发人员可能会创造出一个不利于团队成长的环境。以下是一些建议，可以帮助避免这种情况：

软件开发的KPI对于整个编程过程至关重要，因为它们帮助管理层评估和排序目标及团队目标。这些指标分为四个主要类别：开发团队的生产力、软件性能、缺陷管理、以及可用性和用户体验。这些类别根据其关注的特定领域分类，每一类都提供了项目整体状况的重要视角。对所有相关方来说，了解各种KPI、它们的应用以及计算方法是非常关键的。