衡量开发者的效率对公司是非常重要的。然而，软件工程团队可能会碰到一些普遍存在的问题。接下来我们将探讨如何有效地测量开发者的效率并优化团队的表现。
目前，你们公司可能是基于工程团队的输出成果来评估他们，而不是他们实际的工作流程。而公司的高层领导更关心的是新的功能、客户的满意度，以及如何在不增加成本的前提下获取更多的利益，而不是代码提交、团队的活跃度或故事点等细节。那么问题是，如何将开发者的效率量化和解释，让公司领导真正重视它，尽管它可能是一个主观的概念？再者，你如何准确地测量开发者的效率，以确保工程团队的目标与公司的业务目标一致？
本文将帮助你找到最佳方法来衡量公司的开发者生产力。一旦做到这一点，就可以指导你的团队领导进行流程优化和提高工作效率。
什么是开发者生产力？
简单来说，开发者的工作效率是指一个团队（而非个体，这一点后面会有更深入的解释）有效地发布对业务有价值的高质量代码的能力。
开发者的工作效率不仅要有定性的评估，还要有定量的数据来支持。基于原始的DevOps研究和评估（DORA）报告和其四个主要的指标，研究团队进一步提出了SPACE框架，这是一个更为全面的方法来评估开发者的效率。
坦诚的说，你可能并没有正确地应用DORA的指标。为了真正评估开发者的效率，你需要考虑更多的因素，而不是仅仅依赖几个关键的绩效指标(KPI)。
需要注意的是，开发者的满意度和他们的工作效率不是不能共存的两个因素。所以，你的团队应该考虑其他的评估标准，而不是仅仅局限于上述的框架。
因此，我们现在希望帮助你明确应该如何衡量团队的工作效率。
衡量结果，而非产出
很多软件公司通过统计开发者写的代码行数来衡量他们的工作效率。他们认为源代码的量和项目的规模直接代表了软件的复杂度。
但这种做法并不理想。简洁总比繁杂好，开发者秉持这一原则。仅仅鼓励开发者写更多的代码并不代表代码会更有效，或者问题能更快被解决。
因此，不应该过分关注产量。更应该专注于实际的效果，尤其是更频繁地发布新功能或准确地按照预定的日期交付。这种方式可以帮助软件工程团队更准确地衡量开发者的工作效率。同时，你还可以推广加速开发过程的有效方法。
衡量团队，而非个人
一些公司在衡量开发者生产力时，会对每个团队成员进行评估。他们采用一系列的指标，如代码审查所花费的时间、代码提交的次数、提交的平均大小，以及代码审查的次数和频率，来评估每个成员的工作表现。
然而，这种方法并不是最有效的，因为软件开发是团队的工作，而不仅仅是个人的工作。一个团队应该关注于他们共同达到的目标和共同取得的成果，而不是每个个体的成就。
因此，与其单独追踪每个开发者的表现，更应该关注整个团队的表现。我们应该观察团队是否达成了既定的目标，鼓励团队之间的合作，并帮助整个团队一同进步，而不仅仅是其中的个别成员。
如何衡量开发者的生产力？
软件公司有很多方法来衡量开发者的工作效率。例如，他们可以使用指标来评估由于软件过于臃肿所引发的效率问题。另外，有些公司则依据客户的满意度和产品的发布频率来衡量表现。但我们想让这个过程更为简洁，因此我们列出了一些具体的、你应该考虑的工作效率指标。
1、周期时间
周期时间是指从团队首次提交代码到代码上线生产环境所需要的时间。如果团队所需的周期时间较长，说明可能存在某种阻碍，使得团队的进度受到了限制。如果这个时间持续增长，它可能导致团队成员感到疲劳，或者可能无法按时完成既定目标。因此，如果让我选择一个用来衡量的关键指标，我会选择周期时间。 在我们进行的一个工程度量基准研究中，我们发现，表现最优秀的开发团队从开始到完成的周期时间通常少于48小时。一般来说，短的周期时间意味着更小的PR（拉取请求）尺寸、有效的代码审查过程和高频率的代码部署。总的来说，周期时间短的团队能更加稳定地、以更高的质量，交付更多的功能。
2、部署频率
部署频率表示团队发布或部署代码的次数。频繁地部署代码的团队通常意味着他们有一个稳健的交付流程，并且生产环境每天都会得到几次小的更新。然而，如果团队部署的频率较低，可能意味着他们发布的是大规模、可能存在稳定性问题的版本。
3、PR大小
这里要指出的是，衡量代码的行数并不是一个有效的生产力指标。再次强调，简洁胜于冗长。所以不应该鼓励开发团队写比实际需要的更多的代码。这同样适用于拉取请求（PR）：较大的PR意味着团队在开发和审查上需要花费更多的时间。相比之下，较小的PR可以更快、更稳定地被接受、审查和部署。
4、重新工作率
简单来说，重新工作率衡量的是在21天内修改的代码的数量。如果你的团队经常在部署后不久对代码进行修改，那么这可能是代码经常发生变化或代码质量较低的标志。一个团队需要反复修改同一部分代码的次数越少，越好。
5、投资概况
总的来说，投资概况可以告诉你你的团队具体都在做什么。他们是在花费大部分时间开发用户故事，还是在修复错误，又或者是在进行其他任务？如果没有这种概览，你只会对团队的工作有一个模糊的了解，这并不会对你有任何实质性的帮助。监测这个指标可以帮助你确定“工程团队是否真的在投资正确类型的工作？”这个问题。
6、计划准确性
如果制定的计划是不准确的，那么制定计划还有什么意义呢？计划准确性是用来比较你预计的工作量与团队在一个冲刺周期内实际完成的工作内容。如果你的团队没能达到每次冲刺的目标，可能是因为他们在技术债务或者其他未计划的工作上投入了太多的时间，这些都可能会降低团队的士气。
开发者生产力的障碍
技术的复杂性和不必要的工作经常是困扰开发团队的问题。原因是什么呢？因为他们不得不在多个平台上处理任务和使用各种生产力工具。此外，过多的功能需求或变动（也被称为”范围蔓延”）或者不断错过预定的截止日期都是不好的迹象。开发者的疲劳是一个真实的问题，可能会带来很多不良的影响。那我们应该如何避免这种疲劳呢？
范围蔓延
这是一个真实存在且可能造成严重问题的现象。如果你的团队没能达到冲刺计划会议中制定的目标，很可能就是受到范围蔓延的影响。当团队在冲刺过程中不断地加入额外的任务，这会很容易导致他们感到疲劳，从而影响到整体的生产力。你应该与团队沟通，找出可能的解决方案来降低范围蔓延的风险，并确保开发者感到满意。
开发者体验
当我们提到保持开发者的满意度时，你的团队成员真的感到快乐吗？如果他们不快乐，这很容易导致他们感到疲劳，或者导致公司有更高的员工流失率。
提高开发者的生产力
为了提高开发者的生产力，你的工程管理团队需要能够正确地衡量它。你需要考虑多个指标，为你的组织选择最合适的指标。而且，优化开发者的工作流程是直接与提高他们的生产力相关的关键因素。
