程序员的绩效到底是应该衡量项目，还是改 Bug 量？

你听说过有的团队使用各种衡量方法吗？比如 Bug 修正率，或者每周产生的代码行数？根据这种度量算出的业绩最差者就可以辞退了。接下来会怎样？团队就会只关注那些容易改的 Bug，以便做出漂亮的数据。最终，产品的质量只能越来越差，而不会变好，而且也会导致具有价值的开发者离职。难怪开发者们不信任生产力度量了。“我从来没有见过任何度量能真正起到作用的。”

这篇文章里我想剖析一下生产力度量的奥秘。我们会逐一讨论：

• 哪些度量必须小心使用——意味着它们可能涉及一些特殊的条件，以及特殊的使用方式；

• 哪些度量是真正有用的，不论你是团队贡献者、领导还是经理，都应该把这种度量引入团队。

让我们开始吧！

应当非常小心使用的度量

1) ticket 关闭率——用于衡量个人业绩

如果不使用故事点或类似的东西，那么这个度量可能是最具误导性的了。使用这个度量实际上等于假设所有 ticket 的工作量都是相同的，而这绝对是错误的。绝对不应该用这个度量来衡量个人开发者的业绩。一名开发者可以改正任何人都改不了的问题，改正一个从多个方面影响产品性能的问题，而这可能耗费他整个星期。而另一个开发者可能用同样的时间修改 20 个细节问题。哪个对团队和公司的影响更大？

即使你采用了故事点，那么上面的场景中，即使是最好的情况，那一个 Bug 可能有 5 个故事点，而另外 20 个 Bug 每个有 1 故事点。这还没有考虑到绝大多数团队都不会使用故事点来衡量 Bug，一般故事点只用来衡量功能。

但是，你可以使用这个度量来发现类似于开发者被某个任务缠住之类的问题。关键是，不要使用这个度量去衡量开发者的业绩，否则你的团队就会追求度量本身，而不会产生任何有意义的工作成果。这个度量仅能用来帮你理解，作为管理者的你怎样才能帮助团队前进。

2) 产生的代码行数(Lines of code，LoC)——用于衡量个人业绩

还是上面的例子，大型的 Bug 修改可能只需要改一行代码，另一个开发者可能导入了一个函数库，或者改动了每个文件中的每个头文件。这两个人怎么比较？显然没法比较。类似地，这个度量也绝不能用来衡量个人业绩。LoC 可以用同样的方式使用——用来理解你的团队是否遇到麻烦，或者是否为了项目的质量而引入了太多的函数库！

一些人会根据被修改的代码行数计算“影响度”度量，即这些改动的严重程度，以及影响到的文件数量。总的来说，这样做的目的是找出比 LoC 更好的度量标准。这个标准看上去不错，但我还是强烈建议，不要用它来衡量个人业绩。实际上，这个度量对于上面说到的只修改一行的 Bug 依然束手无策，许多实际工作中的例子也证明了这一点。

3) 代码扰动量(Code churn) vs. 代码吞吐量

代码扰动量有很多不同的定义。常见的度量方式是，对开发者近期工作的代码编辑量，占开发者自己的代码量的百分比。扰动率的突然增加可能意味着开发者在解决特定问题时遇到了困难。

一些人认为代码扰动量的生产效率不高，因此不如“代码吞吐量”，这是非常危险的看法。实际上，代码扰动量可能意味着开发者在优化某部分代码以获得更好的性能。也有可能产品团队无法做出决策，使得开发者只能原地踏步。因此规则是，要关注扰动量的任何巨大变化，以找出开发者可能遇到的潜在问题，从而帮助团队更快地前进。

有什么度量可以衡量个人业绩？

你肯定会问这个问题。答案是：没有！没错，你可以看看我说的这句话：

度量是主观的，能提供信息的。但不能根据度量评判任何个人的业绩。度量只能让你更好地理解项目的复杂性。

实际情况是，管理很困难，而且永远需要根据情况而定。你需要挖掘很多信息来理解问题的根源。有时候你会发现某个开发者的确业绩很差，但这个发现是因为你做出了努力来理解团队及团队的合作情况，才能发现是否有某个成员拖了大家的后腿。这是成为好的经理、促进团队提高生产力并维持团队的必经之路。

而且，如果你首先考虑了这一点，你就能正确地使用上面提到的三种度量。你还能使用更多的度量来帮你更好地理解团队的工作速度和质量。

应当使用的度量

我将这些度量分为两类：速度和质量。如果觉得我漏掉了什么，请告诉我，我很愿意加到这篇文章里。

速度相关的度量

这些度量是最具争议性的，因为许多人（包括我）都很讨厌敏捷开发的故事点。但还有一些其他度量，我希望你在试图用它们衡量“速度”时能三思而后行。

4) 提交频率

这个度量可以促使大家每天提交代码，这是个好的实践。还可以用来测量打断的代价。计划和会议等非编码的任务都会不可避免地拉低提交频率。通常，团队每周都至少要浪费一天时间来从事这些活动。监视提交频率能让你看到哪些会议会影响团队提交代码的能力。

经理应当尽可能保护团队的专注力，确保流程相关的活动不会造成负担。

5) 服务水平协议(SLA)

每个团队都有自己定义的SLA。但下面Airbnb使用的这个 SLA 我觉得很有意思。这个 SLA 定义为：在一定时间内团队修正并部署的 blocker bug 占的百分比（例如，blocker 的时间为 24 小时，critical bug 的修改时间为 5 天）。我喜欢这个度量的真正原因是，它能让你从用户的角度理解产品质量。

注意，我认为这个度量是速度类别的，因为它显示了团队的速度，而不是生产软件的质量。

6) 与拉取请求有关的速度

• 每周打开的拉取请求数量

• 每周合并的拉取请求数量

• 每周产品部署次数

• 合并所需平均时间（或在特定阈值下合并拉取请求的百分比）。这个度量有时等价于“提交到部署所需时间”（一段代码从提交到部署所需时间，期间这段代码可能要经历测试、QA、staging 等，取决于你的组织流程）。这个度量能显示出工作流中遇到的障碍。

这些度量能让你理解工程团队的持续输出。例如，如果向团队添加更多的人也无法让这些数字增加，那么可能因为流程本身有问题，或者需要先解决一些技术债务。但是，如果它增长得快，说明可能出现了质量问题。

不要忘记，只衡量团队速度而忽略工作成果的质量是非常具有误导性，而且是极其危险的。

与质量有关的度量

质量本身并不是目标。真正起作用的是能够安全地增加并修改功能时的信心。

7) 测试覆盖率

当然，不需要 100% 的覆盖率。但是，知道自己的位置并跟踪，可以看到是否在为了质量而牺牲了速度。

(8) 拉取请求质量

拉取请求能让你清晰地看到代码的整体复杂度。代码越复杂，下面这些度量增大的可能性就越高：

• 拉取请求导致构建失败或测试失败的次数百分比

• 拉取请求被合并和被拒绝的比例

• 每个拉取请求的评论数——这个度量不应该太低，但也不应该太高。

9) 项目中的 Bug 数

一般来说，在项目生命周期的中期，Bug 数量会上升。在最后期限之前几天或几周（不同大小的项目不一样），团队会专心减少 Bug 数量，直到 Bug 接近某个程度。这个接近程度最终能代表项目的产品的整体质量。所以，整体的 Bug 数量（要注意区分优先级）是个很好的项目指示器。

另一个度量是发现的 Bug 数量，或者使用 Bug 修正数量与发布的功能数量的比例。这两个度量通常按照每周或每月的频率统计。它们能够指示实现的质量水平。

10) 依赖的时期

另一个有关技术债务的指示器就是代码库中存在多少过时的依赖。这个度量可能很有意思。

技术债务很正常，每个项目都会出现，而质量的标志很主观。类似于这一条的度量能帮你跟团队一起定义一系列的规则，以了解团队工作的质量。

本文的主要观点是，如果你衡量项目或衡量整个团队，你的开发者就不会在度量上弄虚作假。正如@raffi所说（https://twitter.com/raffi/status/725044879097782274），“不衡量的东西是没法作假的。”而度量作假是最容易的。

如果你有不同意见，请告诉我。希望这篇文章能起到抛砖引玉的作用。

原文：https://anaxi.com/blog/2018/11/25/do-not-measure-developers-measure-projects/

作者：John Lafleur

译者：弯月，责编：屠敏

推荐阅读：

点击“阅读原文”，打开 APP 阅读更顺畅