加班越久故障越多，如何跳出程序员的恶性循环？

2018-05-03 本文已影响53人技术边城

导读：如何让每一位可爱的工程师少加班、不加班？阿里巴巴技术专家张冠楠，在质量保障体系建设、持续集成领域、敏捷实践领域和研发效能领域方面具有丰富的经验和心得。今天，冠楠将用阿里研发团队的实际案例，生动说明如何用数据驱动研发效率提升。

本文是我利用云效公有云度量功能，加上敏捷部分的方法指导，实践于某事业部几十人团队沉淀的成果，希望能给大家一些借鉴意义。我会就各种具有关键表征的数据进行介绍，但是详细数据，包括具体研发团队的数据，还需要访问云效公有云度量功能页面。

注：本文图片数据来自云效度量数据功能，有兴趣的童鞋可点击文末“阅读原文”了解更多。

数据展现

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

问题分析

上面几张图比较容易看出来，这个团队的明显特征是：

（1） 3月份完成需求数明显上升，且团队负载较重。

（2）质量不高-缺陷数、reopen率以及线上发布成功率。

（3）需求平均完成时长特别长。

（4）突增故障。

于是我们带着数据暴露出来的这几个问题，和团队一线研发人员、PD、TL进行沟通，分析数字背后的意义。大家很快达成一致，发现团队存在的主要问题是：

（1）需求deliver传统瀑布模型，要1个半到2个月去完成一个特别大的需求，最后却和用户期望偏差较大，数据表征上就是之前需求数量较少，3月份突然完成了很多而且时间很长的需求。

（2）大家加班加点干活，负载较重，引入的缺陷也较多，PD和用户不满意带来的修改又会加重工作量，如此恶性循环。

（3）缺陷重视度不高，管理不规范，优先级划分不清楚，甚至残留重要缺陷，留在bug列表里未解决而流到了线上引发故障。

上面三点形成了恶性循环，结果就是越做越多，越多越错，越错越改，越改越多。

解决方案落地和数据运营

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

（1）需求细化：拆分成最小可交付产出，尽量避免一个需求做了1个多月，才去找PD和用户验收。

（2）随时拥抱用户：迭代式产出，交付即验收，让不准确性降到最低，在错误误差最小的时候修正。

（3）重点跟进质量管理和运营：透明数据，鼓励团队尽早尽快修复bug，并有严格的上线前bug解决率标准。

（4）尽全力保证线上发布成功率。

同时辅助于团队的决策，我们进行定期的数据运营，每周都会去统计和分析数据，包括质量和效率相关的，确保我们能在第一时间发现问题，纠正偏差。所以在3个多月的时间里，我重点关注了如下数据。关于这些数据的解读和分析，内容比较深入，我这里只做简单的概括性介绍：

（1）需求的吞吐量：团队指定时间段内完成的需求数，可大体反应出团队的产出趋势。

（2）需求的平均完成时长：需求从创建到终态的平均时长，时间越多，需求交付粒度越小效率越高。

（3）新增缺陷的数量：统计时间段内团队被新增指派的缺陷数量，结合存量缺陷以及缺陷平均解决时长，反应团队产品的质量以及对于缺陷解决的效率。

（4）缺陷的平均解决时长：缺陷从创建到解决的平均时长，表征解决缺陷的效率。

（5）线上发布的成功率：线上发布成功次数与总次数之比，越高证明产品上线质量越高。

（6）缺陷的reopen率：缺陷被reopen的次数与缺陷数目之比，该值越高证明修复缺陷的质量越差，reopen率是表征产品质量的一个重要指标。

结果分析和总结

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

（1）团队的负载得到了控制，需求的完成数下降了，后续3个月保持一个相对平稳的状态。

（2）需求细化拆分后，交付的时长下降了，团队以更快的速率去和用户交付需求。

（3）缺陷的数量下降，reopen率下降，线上发布成功率上升，质量在好转。

（4）缺陷的平均解决时间明显上升，团队更快的交付，更快的反馈问题，更快的解决问题。

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

如何进一步提升？

根据对需求数量以及平均完成时长的数据显示，团队还是有上升空间的，对于需求的交付粒度和速率上，还是略显波动，要想更快的知道我们做的是否是用户需要的，就要快速的、迭代式的交付需求，以免用户想要个车，我们给了他4个轮子。

所以能否彻底解决此团队需求的交付和用户期望偏差的问题，还是需要再向前走一步，需求继续细化，提升交付速率。参见敏捷中推荐的，快速迭代，快速交付，快速得到用户反馈，只为了更快更准确。

总结

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

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

（1）关注数据，读懂数据。

（2）重点问题重点解决，优先解决，一段时间只关注一个或很少的几个问题。

（3）相信团队的自驱能力，同时结合TL的管理与激励，养成良好的团队建设力。

欢迎交流讨论

研发团队每天打交道最多的就是需求、缺陷、代码、发布、应用、测试等等，这些和我们研发人员息息相关的数据，云效现在以研发大盘、团队空间、人员效能、质量分布等多种维度数据整合到了数据平台上，后续更会以定制化的方式满足研发团队对于研发数据的需求。利用好这个工具，能帮助我们清晰的了解团队的现状，暴露问题，找到改进措施，提升团队效率和产品质量。

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

最后贴几张我在度量上截的某研发团队的数据展示，这个团队是我们最近接触的团队，通过数据我们对这个团队的推测是：团队在质量上需要提升，在缺陷的管理上需要加强。首先团队缺陷的数量逐月上升，这已经是质量不好的趋势体现。