酷应用

3个月，度量驱动研发效率提升之路

百家作者：InfoQ 2017-11-03 02:16:07

下图是一个某研发团队近半年的数据，您看到这三张图尤其是框了红色的部分，会得到什么样的信息呢？大家可以先看一下然后再往下面去看我对这些数据的认识。

根据上面这三张图的数据，我们可以得到的关于这个团队的信息是：

3 月份完成的需求数量是最多的，比其它最高的月份也要高 40% 左右。
3 月份的缺陷数也是各个月份最高的。
3 月份线上发布的成功率是最低的。

结合 3 月份这个对于我们阿里很特别的日子，我们可以大胆做一些推测：这个月份我们研发人员的负载其实是相当重的，大家可能会去赶工完成更多的工作（需求），赶工干活可能引起的副作用就是质量上的下滑，增多了很多的缺陷数和下降了不少的发布成功率也是印证了这一点。

so 数据是会说话的，那我们该怎么去听它说话呢？如果你觉得，哎呦，这个挺有意思，那么，就让我带着你走一遍如何利用云效上的这些研发数据，去了解团队现状、发现团队中可能存在的问题、再结合团队具体实际情况去做调整和改进，从而达到提升团队整体效率和质量的目标。

注：本文中所有数据都来自云效度量数据功能页面截图（部分数据功能云效暂未开放给所有用户，所以截图会有些许区别）。

数据展现

先直接给大家数据，我是 4 月份开始进入这个团队的。大家重点看这个团队 3 月份的数据：

问题分析

上面几张图比较容易看出来，其实跟引子里面提到的情况差不多，这个团队明显特征是：

3 月份完成需求数明显上升，且团队负载较重
质量不高 - 缺陷数、reopen 率以及线上发布成功率
需求平均完成时长特别长，很多需求都是很久之前的 3 月份才完成
突增故障

于是我们带着数据暴漏出来的这几个问题走进了团队，和团队一线研发人员、PD、TL 都进行了沟通，并把数据展现给他们和大家一起去分析数字背后的意义，大家比较快的达成了一致，发现团队存在的主要问题是：

需求 deliver 传统瀑布模型，要 1 个半到 2 个月去完成一个特别大的需求，最后却和用户期望偏差较大，数据表征上就是之前需求数量较少，3 月份突然完成了很多而且时间很长的需求。
大家加班加点的干活，负载较重，引入的缺陷也较多，PD 和用户不满意带来的修改又会加重工作量，如此恶性循环。
缺陷重视度不高，管理不规范，优先级划分不清楚，甚至残留重要缺陷留在 bug 列表里面未解决而流到了线上引发故障。

上面三点相当于形成了个闭环，恶性循环，其结果就是，越做越多，越多越错，越错越改，越改越多。

解决方案落地和数据运营

发现了大家的问题之后，有针对性的进行解决和落地就相对容易，给到团队的解决方案是：

需求细化，拆分成最小可交付产出，尽量避免一个需求做了 1 个多月才去和 PD 和用户验收。
随时拥抱用户，迭代式产出，交付即验收，让不准确性降到最低，在错误误差最小的时候修正。
重点跟进质量管理和运营，透明数据，鼓励团队尽早尽快修复 bug，并有严格的上线前 bug 解决率标准。
尽最大力量保证线上发布成功率。

同时辅助于团队的决策，我们进行定期的数据运营，每周都会去统计和分析数据，包括质量和效率相关的，确保我们能在第一时间发现问题，纠正偏差，所以我这边在整个 3 个多月的过程中，重点关注了如下的数据，这些数据都在云效上可以得到，云效还包括别的较为丰富的数据，期间如果别的数据反应或者暴漏了问题，我也会纳入进来进行整体分析，关于这些数据的解读和分析，其内容也比较深入，可以专门开一篇文章来讲了，我这里只做简单的概括性介绍：

需求的吞吐量 - 团队指定时间段内完成的需求数，可大体反应出团队的产出趋势。
需求的平均完成时长 - 需求从创建到终态的平均时长，时间越多，需求交付粒度越小效率越高。
新增缺陷的数量 - 统计时间段内团队被新增指派的缺陷数量，结合存量缺陷以及缺陷平均解决时长，反应团队产品的质量以及对于缺陷解决的效率。
缺陷的平均解决时长 - 缺陷从创建到解决的平均时长，表征解决缺陷的效率。
线上发布的成功率 - 线上发布成功次数与总次数之比，越高证明产品上线质量越高。
缺陷的 reopen 率 - 缺陷被 reopen 的次数与缺陷数目之比，该值越高证明修复缺陷的质量越差，reopen 率是表征产品质量的一个重要指标。

结果分析和总结

大家回到上面的 6 张图以及下面的一张缺陷解决时间图，我们 3 月底进入，重点看从 4 月份开始的数据：

团队的负载得到了控制，需求的完成数下降了，后续 3 个月保持一个相对平稳的状态。
需求细化拆分后，交付的时长下降了，团队以更快的速率去和用户交付需求。
缺陷的数量下降，reopen 率下降，线上发布成功率上升 - 质量上在好转。
缺陷的平均解决时间明显上升，团队更快的交付，更快的反馈问题，更快的解决问题。

总体而言，就是需求交付的快，得到的反馈快，修正错误 / 缺陷的成本低，缺陷也会慢慢收敛，质量也会随之提升，缺陷修复的也快了，这就是一个良性循环，概括总计就是：效率提高了，质量也保证了。团队的人干活也是更加努力啦！~

进一步提升

根据对需求数量以及平均完成时长的数据显示，团队还是有上升空间的，对于需求的交付粒度和速率上，还是略显波动，要想更快的知道我们做的是否是用户需要的，就要快速的、迭代式的交付需求，以免用户想要个车，我们给他了个 4 个轮子。所以能否彻底解决此团队需求的交付和用户期望偏差的问题，还是需要再向前走一步，需求继续细化，提升交付速率。参见敏捷中推荐的，快速迭代，快速交付，快速得到用户反馈，只为了更快更准确。

总 * 结

数据有魅力，研发数据也一样，我们使用它就是为了两个目的：一是保证质量；二是确保交付的速率。行走过程中深度使用了云效度量新功能，结合敏捷中部分理念，配合传统测试方式保障，来助力研发团队。

可能有的人会质疑，说用这么冰冷冷的数字的数字去衡量我们可爱的程序员哥哥吗？我的回答是：这不是衡量，数据只是手段，是帮助我们去诊断团队的一个切实有效的手段。学会利用它并驾驭它。因此只需要我们：

关注数据，读懂数据
重点问题，重点解决，优先解决，一段时间只关注一个或很少的几个问题
相信团队的自驱能力，同时结合 TL 的管理与激励，养成良好的团队建设力

我是一个敏捷爱好者，在深入研发团队做测试以及质量管理时候，也是吸取和借鉴了敏捷的部分思想去落地，我的感受是：拿最切实有用的来，比如站会，比如看板，比如快速迭代式交付需求，再加上数据辅助，都是能切实帮助到团队更快、更准确的交付高质量产品的手段。

絮絮叨叨说了很多，最后贴几张我在度量上截的某研发团队的数据展示，这个团队是我们最近接触的团队，通过数据我们对这个团队的推测是：团队在质量上需要提升，在缺陷的管理上需要加强。首先团队缺陷的数量逐月上升，这已经是质量不好的趋势体现，另外缺陷的解决时间也没有加快，这样会导致越来越多的缺陷流到线上去，可见团队除去 1 月份无故障，后续几个月都有故障。而且这个团队的线上发布成功率持续走低，开发对自己上线的代码把控程度较低。所以，找到这些数据表征的背后原因，并且着手去解决掉，是这个团队近期最迫切的事情了。