Category: Uncategorized

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

如何选择软件工程相关的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...