如何轻松和安全地构建的满足合规要求的智能产品,实现业务需求?4月26日,告诉你答案! 了解详情
写点什么

如何定义研发 KPI:以团队速度为标准

停止度量研发计划与执行,开始度量团队速度

  • 2018 年 11 月 22 日
  • 本文字数:2692 字

    阅读完需:约 9 分钟

如何定义研发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


2018 年 11 月 22 日 11:002605
用户头像

发布了 1008 篇内容, 共 335.1 次阅读, 收获喜欢 314 次。

关注

评论 3 条评论

发布
用户头像
学习
2021 年 01 月 31 日 07:49
回复
用户头像
说实话不看文章,还真不知道PR是什么意思
2018 年 12 月 10 日 19:25
回复
用户头像
我的大老板连PR是什么都不知道~ 好囧。
2018 年 11 月 23 日 10:39
回复
没有更多了
发现更多内容

面试官:什么是死锁?怎么排查死锁?怎么避免死锁?

互联网架构师小马

Java 面试 死锁

​专科出身,2年进入苏宁,5年跳槽阿里,论我是怎么快速晋升的?

码农之家

Java 程序员 互联网 面试 阿里

从零开始写游戏服务器①:前期了解

Integer

c

一不小心,它成为了 GitHub Alibaba Group 下 Star 最多的开源项目

阿里巴巴云原生

Java 微服务 云原生 dubbo Arthas

低代码平台想要实现复杂的业务流程,这4个条件不能少!

优秀

低代码

飞桨与宸曜科技完成兼容性认证

百度大脑

认证 飞桨

c 语言思维地基搭建(vis2013编译+第一个c语言程序)

-jf.

4月日更

Airtest入门及多设备管理总结

行者AI

自动化测试

用AI实践继续探索2050全面数字乡村建设

百度大脑

AI

Apache-Flume的安装及简单应用

慢慢de

win10 flume 日志采集

跨专业?拿到阿里offer?我是如何一步一步做到的?

Java架构师迁哥

一位阿里P8技术大牛的Java面试题总结,在GitHub上仅一天就获赞上万!

Java架构之路

Java 程序员 架构 面试 编程语言

百度交易中台之订单系统架构浅析

百度Geek说

云计算 云原生 后端 云服务 架构·

Linux C/C++ 服务器/后端开发/后台开发学习路线

Linux服务器开发

C/C++ Linux服务器开发 Linux后台开发 Linux后端开发

聪明人的训练(八)

Changing Lin

4月日更

Python OpenCV 泛洪填充,取经之旅第 21 天

梦想橡皮擦

Python OpenCV 4月日更

5G 和云原生时代的技术下半场,视频化是最大最新的确定性

阿里巴巴云原生

人工智能 云原生 5G 存储 调度

大数据作业的工作流调度详解

大数据技术指南

大数据 4月日更

Canalys发布2020 Q4中国云市场报告

百度大脑

百度 AI

解Bug之路-主从切换”未成功”?

无毁的湖光

数据库 主从环境

webrtc 开启新特性

糖米唐爹

mysql事务隔离的研究

这就是编程

面试阿里P6,却被MySQL难倒,二战阿里,挤进天猫团队(Java岗)

Java 程序员 架构 面试

什么是 Jenkins? 运用Jenkins持续集成

信码由缰

DevOps jenkins

如何保护您的SaaS应用程序?

龙归科技

网络安全 SaaS 远程工作 单点登录

Impala简介以及与Hive的异同

五分钟学大数据

4月日更 impala

三次给你讲清楚Redis之Redis是个啥

华为云开发者社区

数据库 nosql redis hash 字符串

百度联合研究成果登上《自然》子刊 推动人才管理大数据智能化转型

百度大脑

百度 AI

第14期师资培训火热招生中尽享国赛智能车一手资料

百度大脑

人工智能

AI开发降本提效之道:云智一体AI开发全栈模式

百度大脑

百度 AI 飞桨

MySQL-技术专题-锁的介绍分析

浩宇天尚

MySQL lock 锁机制

如何定义研发KPI:以团队速度为标准_技术管理_Katz Boaz_InfoQ精选文章