一年半之前，我一直在Bizzabo领导研发团队。
\n自从成为负责人，我就在寻找衡量研发团队绩效的最佳方法，从而反映出团队提供的真正价值。我们最初是使用行业标准度量来跟踪团队绩效：度量计划和交付。
\n下面是我们的团队KPI：
\n- \n
- 偏差最多20%：为了更好的计划；\n
- 每项任务平均两天：我们认为，小任务更好处理，也更好执行；\n
- 系统正常运行时间99.95%\n
我面临的挑战是，这些KPI与研发团队的真正价值没有直接联系。我们很容易实现这些KPI，即使速度很慢，质量很低。
\n经过6个月的迭代和修改，我决定定义研发KPI，以便更好地反映一个运转良好的研发团队的价值——团队的速度和质量。
\n我想暂停一下，了解下CodeClimate团队的产品Velocity。它帮助我们走到今天。
\n让我们来回顾一下，术语“研发速度”包含了什么。
\n工作习惯
\n- \n
- 每周编码天数\n
- 每天代码推送次数（尽早推送，少量推送）\n
- 拉取请求（PR）大小\n
- 从请求审查到合并的时间\n
代码质量
\n- \n
- 代码复杂度\n
- 代码文档\n
- 测试覆盖率\n
- Bug数量\n
- 系统正常运行时间\n
效率
\n- \n
- 返工比例\n
- PR放弃数量\n
- 回退次数\n
为了选出可以实现最快速ROI的KPI并优先关注，我们深入地了解了每一项。
\n每周编码天数
\n团队成员每周编码的平均天数（定义为至少一个提交的推送）。你可能认为一个提交不能很好地反映情况，但是，我建议你从简单的开始，或者提出一个更好的、容易量化的指标。
\n
\n每周编码天数
每天代码推送次数
\n每一名活跃的贡献者在单位时间内有多少拉取请求（PR）被合并。
\n每天代码推送次数
PR大小
\n对我们来说，PR多大合适，这需要我们更深入一点地了解。但是，我们不确定如何设置一个明确的数值。关键是找到一个代码行数，我的同事用不到一个小时的时间就可以完成代码审查和PR审批。
\n代码审查超过一个小时就会成为一项具有挑战性的任务，这样，审查可能会不彻底。反过来，随着更多的Bug进入生产环境，节省33小时将成为一项挑战。最佳的PR大小是小于250行代码。实际上，我们大部分的PR都更小一些。
\n
\nPR大小分布
从请求审查到合并的时间
\n把PR为发布到生产环境需要经过的每个步骤想象成一个漏斗：审查时间 \u0026gt; 审批时间 \u0026gt; 合并时间。
\n我们希望有一个明确的内部SLA，这样，80%的PR将在已知的时间内通过这个漏斗。这是一种平衡，可能每个团队的心态和文化会有所不同。一方面，我们不希望开发人员因为审查等待太长时间，另一方面，我们希望防止审查人员被迫暂停当前任务进行上下文切换。我们的目标是：
\n- \n
- 审查时间：12小时（同一天审查）\n
- 审批时间：第一次审查后3小时\n
- 合并时间：审批后12小时\n
我们还规定，审查人员最多2名，以防止厨房里的厨师过多。
\n代码复杂度
\n定义——控制结构（如if语句、循环等）中嵌套深度至少为4层的应用程序代码的行数。
\nKPI—每千行代码中复杂代码的数量。
\n从下图中，你可以看到多年来我们是如何简化代码库的。在很大程度上，这是通过采用新技术（React/Redux、Kotlin、微服务、Dockers和K8s）和改进我们的代码文化来实现的。
\n
\n代码复杂度随时间的变化
代码文档
\n我们秉承“无文档”的理念。我们认为，应该编写简单的代码，每个人都能轻松理解（不过，公平地说，我们确实有一些注释）。
\n
测试覆盖率
\n我们的研发团队没有专门的QA团队。每个开发人员都自己编写测试（单元测试和端到端测试），Squad负责发布质量。没有覆盖的新代码就不会发布。全自动化测试会在每个构建上运行。
\nBug数量
\nBug很难度量。你是什么时候跟踪它们？什么算是一个Bug？我们优秀的客户支持团队做得非常好（首次响应时间不到1.5小时），只会将相关问题升级到我们的研发升级团队（我们有一个团队负责人的职位空缺）。我们每个月都要度量Bug的数量和严重程度。但是，随着团队的成长，你会做些什么呢？我们都知道，编写的代码越多，Bug就越多。
\n我们会进行深入分析，查找某个月的代码行数与Bug之间的关系，发布次数（我们有一个完整的CI/CD）与Bug之间的关系，等等。
\n最后，我们决定度量合并的PR总量与Bug数量的比率。
\n
\n客户根据严重程度报告的Bug数量
\n合并的PR总量随时间的变化
\n我们将KPI定义为0.2（每合并5个PR一个Bug），无紧急Bug
系统正常运行时间
\n这个很简单。我们的目标是度量我们每个月的正常运行时间，以确保我们的客户得到最高质量的服务可用性。为此，我们使用了statuscake。
\n返工比例
\n返工代码行是指同一作者在3周内提交并编辑的任何代码行。返工比率使用以下公式计算：（不同返工的总行数）/（不同修改或添加总行数）。
\n度量返工的方法没有对或错，因为这更多的是一个特定于团队或公司的指标。当一些团队的工作从里到外返工率更高时，或者当一些团队在周密计划之后开展工作时，有时正在进行快速的产品迭代，尤其如此。
\n主要的思想是回顾每个特性的开发，看看返工是不是由于需求的变化，或者缺乏足够的技术指导。
\nPR放弃数量
\n如果拉取请求在未合并的情况下打开并关闭，则认为它被“放弃了”。我们还把超过3天不活动的拉取请求包含了进来。这可以确保我们专注于最重要的任务，同时最小化上下文切换，保证我们的工作不会浪费。
\n当我们按年龄来观察放弃的PR时，很明显，超过30天的PR可能有90%永远都不会再合并，换句话说，它是失落的代码。清理完管道后，除去那些从未打算合并的PR（比如POC、测试和其他一些内部需求），我们将回顾任何老去的PR，并理解其原因。我们可以确定这是否是产品优先级的改变，或者我们从来没有因为错误的估计而终止一项计划，等等。
\n你可以看到，专注于这个KPI并制定好流程，使我们的小组工作习惯更加一致；团队之间的偏差变得更小了（自7月份以来，我们就启用了新的KPI流程）。
\n
\n每个Squad放弃的PR
回退次数
\n合并后有多少代码回退？回退通常是即时Bug（质量）或对产品/功能缺失的快速了解所直接导致的结果。我们的目标不是一个特定的数值，但是，我们确实会把每次回退作为一个触发器，进行一次专门的回顾。
\n那么，我们用什么作为我们的KPI？
\n1. 我们定义了良好的研发KPI所具有的属性：
\n- \n
- 从个人到Squad（我们使用了Spotify模型）再到整个团队都可度量；\n
- 反映并能促进吞吐量的增长；\n
- 与工作（代码）质量相关；\n
- 挑战团队，使他们变得更好；\n
- 在最短的时间内交付最高质量的产品。\n
2. 在进行了上述所有分析之后，我们决定使用以下团队KPI：
\n- \n
- 吞吐量：每位贡献者每月有15个PR被合并；（每名活跃贡献者单位时间内被合并的PR数量）\n
- 效率：PR放弃率小于5%；（如果拉取请求在未合并的情况下打开并关闭，则认为它被“放弃了”。我们还把超过3天不活动的PR包含了进来。）\n
- 质量：正常运行时间99.98%；\n
- 质量：每个合并的PR平均0.2个Bug，无紧急工单。\n
查看英文原文：Stop measuring R\u0026amp;D planning VS execution. Start measuring team velocity
\n
扫一扫
2867
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
