如何选择软件工程相关的Metric并据此来设置相关的KPI

软件工程的KPI是一个很重要的指标，它可以用来衡量软件团队的performance。因此，他需要比较稳定，并且能够覆盖没一个人所做的工作，最重要的是，可测量的。

因为他是用来展示整个团队的工作的，所以选择正确的metrics来测量很关键，否则就没有用了。

一些我所常见到的错误就是看提交了多少行代码，有多少个commits，甚至deploy了多少次等等。当然，不是所看deploy多少次是有错的，主要还是看你想要观察的是什么（有可能和生产率没有关系）

通常，很多关于KPI的文章都关注了很多metrics，但是很少在现实中能够使用。因此，这篇文章中，我将会选择5个工程师KPI metrics，如下面所示，供大家参考。

从commit到deploy的时间

测试从一个程序的第一个commit的时间，到这个commit被deploy到production的时间是一个最方便的衡量整个开发流程的方法。主要是因为你可以很方便地看看git commit的history就可以得到这个信息。

很多manager都只看user stroy上的时间，比如他会看backlog中你创建一个任务到最后这个任务完成的时间。这里有一个问题，因为一个任务在看板上，并不代码我们开始做这个任务了，有可能是需求还没有明确，spec还没有做好，各种各样的原因。

当然他可以很好的来看看整个产品的流程如何，不过作为一个程序员，我们其实更关注的是开发的流程，而这个流程的起点是开始写代码，而终点是代码deploy到production上。

因此这个metric可能和很多指标相关，我这里举例列出几个：

• 减少一个新的feature从开始到上线的时间
• 减少浪费和重做的时间
• 减少延迟的消耗
• 提高工程效率

Deploy的频率

其实只有deploy了，这个feature才最终会被用户所感知，所以他和productivity是密切相关的，因为每一次deploy其实都会对应到相关的任务。

当然，发布的特性有时和商业上的项目并不是一一对应的，所以不能单纯使用deploy的频率来测试productivity，但是我们可以用它来衡量下面这些指标：

• 减少新feature到上线的时间
• 改建失败的response以及由于bug导致的outage
• 减轻安全性相关的问题

代码覆盖率

代码覆盖率是用来表示自动化测试所覆盖的代码，这个覆盖率当然越高越好。它其实可以很好的表示代码的质量。当然他也可以用来体现下面的指标：

• 增加产品/平台的稳定性
• 减少波动
• 扩展技术领域
• 减少功能上线的时间（手动测试需要更多的时间）
• 减少长时间运行得消耗

Pull Request metrics

帮忙review peer的代码，在这个过程中的讨论其实是很好的衡量合作的指标。Pull request metrics有很多内容可以衡量，下面我列出几个：

• review的时间：一个工程师open一个pull request到merge这个pull request的时间
• 第一个comment的时间：多少时间一个pull request能收到第一个comment
• comments的数目：pull request收到了多少个comments
• 跨团队的合作：有没有review别的团队的代码

下面这些内容，pull request metrics可以用来协助测试：

• 团队内部知识的传播
• 代码主人翁的文化
• 减缓初级工程师的学习曲线
• 创建一个和谐的相互学习的环境

关注于紧急bug

我看到很多公司都有设定下个季度“零bug”的目标。所以，这里的KPI就是有多少个bug。

这个方法是有问题的，因为，首先几乎不可能说消除所有的bug。我们都是人，是人就有可能犯错误。第二，bug也有轻有重，我们不能把一个显示颜色的错误和一个没法付款的错误放在一起比较。第三，假如你只测试bug的数量，人们往往不会注册他们。没有bug以为这你的商业目的已经达到了。

所以，测量是否专注于严重的bug可以解决这个问题。这样的话，你就可以把一些metric集合起来，比如严重问题的数量，以及团队解决这样问题的时间等等。

当然，你还可以加入别的指标值，这样可以保证团队没有什么捷径可以掩盖我们真正需要测量的值：

关注紧急bug可以体现下面这些指标：

• 改进最终用户感知的产品价值
• 减少增加更多功能的消耗
• 培养和谐有效的文化
• 培养合作的文化

总结

有很多文章都会讲工程师相关的KPI，但我们仍然会看到很多managers选择了错误的metric来进行衡量，从而最终伤害到团队的成员。

这就是为什么我们说KPI要和最终的商业目的相关，这就相当于一个方向，有了这个指引，manager可以选择合适的KPI metrics。

这篇文章的最终想法其实希望你能够看看相关的KPI和最终的目的是不是相符合的，思考这个问题，我想一定能够选择出合适的KPI metrics。

参考文章： https://hackernoon.com/how-to-select-software-engineering-metrics-and-set-kpis-that-matter-rx2w3uir