若何定义研发 KPI：以团队速度为标准

一年半之前，我一贯在 Bizzabo 领导研发团队。

自从成为卖力人，我就在探求衡量研发团队绩效的最佳方法，从而反响出团队供应的真正代价。
我们最初是利用行业标准度量来跟踪团队绩效：度量操持和交付。

下面是我们的团队 KPI：

偏差最多 20%：为了更好的操持；每项任务均匀两天：我们认为，小任务更好处理，也更好实行；系统正常运行韶光 99.95%

我面临的寻衅是，这些 KPI 与研发团队的真正代价没有直接联系。
我们很随意马虎实现这些 KPI，纵然速率很慢，质量很低。

经由 6 个月的迭代和修正，我决定定义研发 KPI，以便更好地反响一个运转良好的研发团队的代价——团队的速率和质量。

我想停息一下，理解下CodeClimate团队的产品 Velocity。
它帮助我们走到本日。

让我们来回顾一下，术语“研发速率”包含了什么。

事情习气

每周编码天数每天代码推送次数（尽早推送，少量推送）拉取要求（PR）大小从要求审查到合并的韶光

代码质量

代码繁芜度代码文档测试覆盖率Bug 数量系统正常运行韶光

效率

返工比例PR 放弃数量回退次数

为了选出可以实现最快速 ROI 的 KPI 并优先关注，我们深入地理解了每一项。

每周编码天数

团队成员每周编码的均匀天数（定义为至少一个提交的推送）。
你可能认为一个提交不能很好地反响情形，但是，我建议你从大略的开始，或者提出一个更好的、随意马虎量化的指标。

每周编码天数

每天代码推送次数

每一名生动的贡献者在单位韶光内有多少拉取要求（PR）被合并。

每天代码推送次数

PR 大小

对我们来说，PR 多大得当，这须要我们更深入一点地理解。
但是，我们不愿定如何设置一个明确的数值。
关键是找到一个代码行数，我的同事用不到一个小时的韶光就可以完成代码审查和 PR 审批。

代码审查超过一个小时就会成为一项具有寻衅性的任务，这样，审查可能会不彻底。
反过来，随着更多的 Bug 进入生产环境，节省 33 小时将成为一项寻衅。
最佳的 PR 大小是小于 250 行代码。
实际上，我们大部分的 PR 都更小一些。

PR 大小分布

从要求审查到合并的韶光

把 PR 为发布莅临盆环境须要经由的每个步骤想象成一个漏斗：审查韶光 > 审批韶光 > 合并韶光。

我们希望有一个明确的内部 SLA，这样，80% 的 PR 将在已知的韶光内通过这个漏斗。
这是一种平衡，可能每个团队的心态和文化会有所不同。
一方面，我们不肯望开拓职员由于审查等待太永劫光，另一方面，我们希望防止审查职员被迫暂停当前任务进行高下文切换。
我们的目标是：

审查韶光：12 小时（同一天审查）审批韶光：第一次审查后 3 小时合并韶光：审批后 12 小时

我们还规定，审查职员最多 2 名，以防止厨房里的厨师过多。

代码繁芜度

定义——掌握构造（如 if 语句、循环等）中嵌套深度至少为 4 层的运用程序代码的行数。

KPI—每千行代码中繁芜代码的数量。

从下图中，你可以看到多年来我们是如何简化代码库的。
在很大程度上，这是通过采取新技能（React/Redux、Kotlin、微做事、Dockers 和 K8s）和改进我们的代码文化来实现的。

代码繁芜度随韶光的变革

代码文档

我们秉承“无文档”的理念。
我们认为，该当编写大略的代码，每个人都能轻松理解（不过，公正地说，我们确实有一些注释）。

测试覆盖率

我们的研发团队没有专门的 QA 团队。
每个开拓职员都自己编写测试（单元测试和端到端测试），Squad 卖力发布质量。
没有覆盖的新代码就不会发布。
全自动化测试会在每个构建上运行。

Bug 数量

Bug 很难度量。
你是什么时候跟踪它们？什么算是一个 Bug？我们精良的客户支持团队做得非常好（首次相应韶光不到 1.5 小时），只会将干系问题升级到我们的研发升级团队（我们有一个团队卖力人的职位空缺）。
我们每个月都要度量 Bug 的数量和严重程度。
但是，随着团队的发展，你会做些什么呢？我们都知道，编写的代码越多，Bug 就越多。

我们会进行深入剖析，查找某个月的代码行数与 Bug 之间的关系，发布次数（我们有一个完全的 CI/CD）与 Bug 之间的关系，等等。

末了，我们决定度量合并的 PR 总量与 Bug 数量的比率。

客户根据严重程度报告的 Bug 数量

合并的 PR 总量随韶光的变革

我们将 KPI 定义为 0.2（每合并 5 个 PR 一个 Bug），无紧急 Bug

系统正常运行韶光

这个很大略。
我们的目标是度量我们每个月的正常运行韶光，以确保我们的客户得到最高质量的做事可用性。
为此，我们利用了statuscake。

返工比例

返工代码行是指同一作者在 3 周内提交并编辑的任何代码行。
返工比率利用以下公式打算：（不同返工的总行数）/（不同修正或添加总行数）。

度量返工的方法没有对或错，由于这更多的是一个特定于团队或公司的指标。
当一些团队的事情从里到外返工率更高时，或者当一些团队在周密操持之后开展事情时，有时正在进行快速的产品迭代，尤其如此。

紧张的思想是回顾每个特性的开拓，看看返工是不是由于需求的变革，或者缺少足够的技能辅导。

PR 放弃数量

如果拉取要求在未合并的情形下打开并关闭，则认为它被“放弃了”。
我们还把超过 3 天不活动的拉取要求包含了进来。
这可以确保我们专注于最主要的任务，同时最小化高下文切换，担保我们的事情不会摧残浪费蹂躏。

当我们按年事来不雅观察放弃的 PR 时，很明显，超过 30 天的 PR 可能有 90% 永久都不会再合并，换句话说，它是失落落的代码。
清理完管道后，撤除那些从未打算合并的 PR（比如 POC、测试和其他一些内部需求），我们将回顾任何老去的 PR，并理解其缘故原由。
我们可以确定这是否是产品优先级的改变，或者我们从来没有由于缺点的估计而终止一项操持，等等。

你可以看到，专注于这个 KPI 并制订好流程，使我们的小组事情习气更加同等；团队之间的偏差变得更小了（自 7 月份以来，我们就启用了新的 KPI 流程）。

每个 Squad 放弃的 PR

回退次数

合并后有多少代码回退？回退常日是即时 Bug（质量）或对产品 / 功能缺失落的快速理解所直接导致的结果。
我们的目标不是一个特定的数值，但是，我们确实会把每次回退作为一个触发器，进行一次专门的回顾。

那么，我们用什么作为我们的 KPI？

1. 我们定义了良好的研发 KPI 所具有的属性：

从个人到 Squad（我们利用了Spotify 模型）再到全体团队都可度量；反响并能促进吞吐量的增长；与事情（代码）质量干系；寻衅团队，使他们变得更好；在最短的韶光内交付最高质量的产品。

2. 在进行了上述所有剖析之后，我们决定利用以下团队 KPI：

吞吐量：每位贡献者每月有 15 个 PR 被合并；（每名生动贡献者单位韶光内被合并的 PR 数量）效率：PR 放弃率小于 5%；（如果拉取要求在未合并的情形下打开并关闭，则认为它被“放弃了”。
我们还把超过 3 天不活动的 PR 包含了进来。
）质量：正常运行韶光 99.98%；质量：每个合并的 PR 均匀 0.2 个 Bug，无紧急工单。

查看英文原文：Stop measuring R&D planning VS execution. Start measuring team velocity