玩转效能度量，驱动敏捷改进

提起研发效能度量，大家都说好，我也要。对于敏捷团队来说，效能度量能直观的体现团队持续快速交付价值的能力，更重要的是，效能数据能指导团队持续改进。

但往往效能度量做的徒有其形而无其神，仅完成数据统计。效能数据虽然统计了，但既没有体现团队交付价值的能力，也没能帮助团队持续改善，甚至成为团队的负担，毕竟仅仅统计一下数据对团队毫无意义还在更新数据上浪费了大量时间。究其原因，效能度量难做好，主要是两座大山横梗在前：

• 效能指标难定。研发效能指标太多，团队在不同时期关注的数据不一样，团队内各种角色关注的数据也不一样，选定合适的指标并非易事；

• 团队消极参与。效能数据分析似乎是SM的专职，团队成员仅更新数据，数据的好坏成员无感，团队难以从数据中找到改进方向。

看到这两座大山SM是不是要开始叹气了，哎。。。难搞。

不要慌！本文接下来将分享在酷家乐我们如何移山，玩转效能度量。

群核科技（酷家乐）是全球领先的云设计软件平台和SaaS服务提供商。公司现有员工超2000人，研发团队占据总人数的1/3以上，产研团队采用Scrum框架进行敏捷开发。笔者20年12月开始接手硬装业务线的项目管理，并作为SM辅助和引导硬装业务线三个敏捷组。通过访谈和2周的活动参与，我们发现硬装敏捷组也存在效能度量难落地的两个共性问题：

• 团队成员对效能数据不敏感，数据好坏均无法引起团队的共鸣；

• 团队内没有建立大家认可的度量标准。

基于这种情况，我们采取了如下措施：

• 强化团队效能度量意识；

• 提升团队效能度量参与感；

• 建立团队效能度量标准；

• 数据反馈驱动团队改进。

强化团队效能度量意识

通过强化团队效能度量意识，让团队从对数据无感发展到接受效能度量。强化团队效能意识，主要从两个个层面着手：

• SCRUM TEAM内，在回顾会议上，SM介绍效能度量价值和意义，并引导团队分析迭代数据，系统总结团队健康度。而在日常站会上，SM带领团队分析当前数据，指出我们现在的状态和可能的风险问题；

• 在OWENERS（PO/TO）层面，同步每个迭代的数据的同时分析数据背后的问题，提出需要OWENERS介入支持的环节。

SM通过与团队分享分析效能数据，能让团队直接感受到效能度量的价值。OWNERS关注效能数据后，也会间接影响团队成员关注度。双管齐下，团队对效能度量的重视逐步提升。

提升团队效能度量参与感

通过提升团队效能度量参与感，让团队从被动接收数据发展到主动看数据，分析数据。提升团队参与感，我们主要做了两件事情：

• 通过提问引导团队分析数据。SM在分享数据时，有意的抛出一些问题，让团队成员思考分析。诸如“我们任务完成率目前是40%，迭代时间已经过半，迭代任务的按时完成会有风险么？”，“我们的燃尽图中间有一个凸起点，这中间发生了什么变化呢？”。

• 硬装MVP/MGP活动。硬装MVP/MGP活动旨在提升硬装同学在敏捷迭代的健康度、参与积极性和趣味性。根据月度数据，我们每月评选一次硬装MVP（最强王者奖、卓越贡献奖）和MGP（黑锅奖，达到一定条件才颁发）。MVP将颁发奖杯和证书以及奶茶福利，MGP收获小黑锅一个（真·小黑锅，PDD 9.9包邮）。

建立团队效能度量标准

经过2个迭代不断的效能度量宣导。团队提出2个非常棒的问题，效能指标这么多，我们要看哪些？怎么根据数据判断我们做的好不好？

每个组织关注的效能指标可能都不一样。当前我们选取了三个最基本的指标：迭代任务完成率、迭代平均速率以及燃尽图。

• 迭代任务完成率标志着我们的目标完成情况；

• 迭代平均速率则代表着我们的持续交付的能力；

• 燃尽图体现了我们迭代进展的状态。

对于迭代完成率，我们约定80%是基线，是我们最低要达到的要求。而迭代平均速率，8SP是我们理想的目标。必须指出的是，这些标准是团队内部的约定，而非绩效标准。

数据反馈驱动改进

无论是强化效能度量意识，还是建立效能度量标准，都是为数据反馈驱动团队改进打下基础。只有当数据能指导团队持续改进时，效能度量才能体现价值。那我们是如何利用数据指导团队改进的呢？这里举三个例子。

例1:在20年底的一次迭代回顾会议上，我们在看燃尽图走势的时候发现，有近一周的时间我们的燃尽图基本没有变化。最后定位到原因是任务颗粒太大，包含工作内容多，点数较大，直到所有工作完成才能看到数据变化。深入讨论之下，团队认为任务不做详细拆分有进度不可控、进展不透明、缺少检查点等弊端。最后团队确定了一条原则，需求评估后需要拆分为合理粒度的任务，最大粒度的任务不超过3SP。

例2:我们连续3个迭代完成率达到100%后，在迭代回顾会议上SM提出一个问题“为什么我们能保持这么高的迭代完成率？”。刚开始讨论时，大家一顿互夸，我们的规划做的好、我们的节奏控制比较好之类。直到有一位同学提出一个细节，我们的产品需求有点少。大家开始讨论最近迭代的任务安排，产品需求偏少，迭代内排入了大量的优化和调研任务，这些任务可控性更强，但业务价值相比产品需求要低。PO跟团队同步最近在准备几个重要的项目，迭代需求产出较少，后续会加大迭代需求的投入。到了下一个迭代，产品需求迅速增多。

例3:SM通过任务完成数据发现，有一位同学连续两个迭代完成率都不高。考虑到这是一位新入职的同学，可能是业务不熟练导致。在跟开发同学私下沟通后发现，业务不熟练是原因之一，看到其他同学plan时领走大量任务，萌新同学不好意思领太少，因此在迭代规划时认领了超出处理能力的任务量。了解这一情况后，SM与开发同学开诚布公，上手需要一定的时间，合理评估工作量，完成承诺比高完成量更重要。同时SM也与TO沟通，需要辅助萌新同学评估工作量。

例1中，数据异常明显，团队能快速定位原因找到改进方向。例2中，数据看起来很优秀，背后隐藏的问题需要深入挖掘才能发现，往往这时需要SM做一些引导。例3中，涉及到个人数据问题不适合公开讨论，这时SM就需要私下跟对应成员沟通，找到问题所在，并协助改进。数据反馈驱动改进，首先SM要能发现数据的问题，然后引导团队做出分析，找到改进点。

通过对数据的分析讨论，团队定位到诸多待改善的问题，例如：

• 需求需要在kaptain附上PRD文档，不能只有一个标题，防止时间长了遗忘；

• 需求下面创建子任务，我们跟踪子任务完成情况；

• 需求评估点数过大，需要拆分的更细；

• 需求/独立发布的任务需要在kaptain上更新测试，测试时间及上线时间；

• 需求变更需要团队内同步，特别是相关同学都应知晓；

• 跨组协作的需求，首先需要PO、TO（技术负责人）评估；

• 。。。

最终我们产出第一版团队公约，用于系统的指导团队进行协作。

我们来看一下硬装数据反馈驱动改进的效果。在硬装精准设计敏捷组中，任务完成度从80%以下已连续5个迭代完成度达到80%以上；迭代平均速率，则从5SP以下达到6.5SP左右（Sprint87跨春节，时间较长，平均产出偏高）。通过效能度量驱动敏捷改进，取得了明显的成果。

总结

效能度量对于敏捷团队来说是一个很好的工具，能指导团队持续改进。在酷家乐硬装业务线，我们通过强化团队效能度量意识、提升团队效能度量参与感、建立团队效能度量标准等手段落地了效能度量，达到了数据反馈驱动团队改进的效果。我们在此将实践历程分享给大家，也欢迎大家一起来分享更多的敏捷实践活动。