开发者学堂课程【如何成为技术大牛？：05加班越久故障越多，如何跳出程序员的恶性循环?】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1240/detail/18424
加班越久故障越多，如何跳出程序员的恶性循环？
内容介绍
一、课时概述
二、问题分析
三、总结
一、课时概述
本文是利用云校公有云度量功能加上敏捷部分的方法指导，实践于某事业部几十人团队沉淀的成果，希望能给予一些借鉴意义。对此会就各种关键表征的数据进行介绍，但是详细数据包括具体研发团队的数据还需要访问云校公有云度量功能页面。
二、问题分析
1、团队特征
这个团队的明显特征是三月份完成需求数明显上升，企业团队负载较重，质量不高，缺陷数 Reopen 率以及线上发布成功率，需求平均完成时长特别长，突增故障，数据表可见文档。于是就数据暴露出的这几个问题和团队一线研发人员 PDTL 进行沟通，分析数字背后的意义。
2、团队主要问题
大家很快达成一致，发现团队存在的主要问题是：
(1)需求 deliver 传统瀑布模型需要一个月到两个月去完成一个特别大的需求，最后却和用户期望偏差较大。
(2)数据表征上就是之前需求数量较少，三月份突然完成了很多而且时间很长的需求。
(3)大家加班加载干活负载较重，引入的缺陷也较多，PD 和用户的不满意带来的修改又会加重工作量，如此恶性循环。
(4)缺陷重视度不高，管理不规范，优先级划分不清楚，甚至残留着重要缺陷，留在 bug 列表中未解决而流到线上引发故障。
上面的三点形成了恶性循环，结果就是越做越多，越多越错，越错越改，越改越多。解决方案落地和数据运营，发现问题之后有针对性地解决运营和落地就相对容易。
3、解决方案
(1)需求细化，拆分成最小可交付产出，尽量避免一个需求做了一个多月才找 PD 和用户验收。
(2)随时拥抱用户，迭代式产出，交付即验收，让不准确性降到最低，在错误误差最小的时候修正。
(3)重点跟进质量管理和运营透明数据，鼓励团队尽早尽快修复 bug，并有严格的上线前 bug 解决率标准，尽全力保证线上发布成功率。
(4)同时辅助于团队的决策进行定期的数据运营，每周都会统计和分析数据，包括质量和效率相关的，确保能够在第一时间发现问题，纠正偏差。
4、数据关注
所以在三个月的时间里重点关注了一下数据。关于这些内容的解读和分析比较深入，这里只做简单的概括性介绍。
(1)需求的吞吐量
团队在指定的时间段内完成的需求数可大体反映出团队的产出趋势。
(2)需求的平均完成时长
需求从创建到终态的平均时长，时间越多，需求交付力度越小，效率越高。
(3)新增缺陷的数量
统计时间段内团队被新增指派的缺陷数量，结合存量缺陷以及缺陷平均解决时长，反映团队产品的质量以及对于缺陷解决的效率。
(4)缺陷的平均解决时长
缺陷从创建到解决的平均时长表征解决缺陷的效率。
(5)线上发布的成功率
线上发布成功次数与总次数之比，越高证明产品上线质量越高。
(6)缺陷的 reopen 率
缺陷被 reopen 的次数与缺陷数目之比，该值越高，证明修复缺陷的质量越差。reopen 率是表征产品质量的一个重要指标。
5、结果分析和总结
大家回到之前的六张图以及下面的一张缺陷解决时间图，三月底进入重点看从四月份开始的数据。团队的负载得到了控制，需求的完成数下降了，后续三个月保持一个相对平稳的状态。需求细化拆分后交付的时长下降了，团队以更快的速率去和用户交付需求。缺陷的数量下降，reopen 率下降，线上发布成功率上升，质量在好转。缺陷的平均解决时间明显上升，团队更快的交付，更快的反馈问题，更快的解决问题，数据图可见文档。
总体而言就是需求交付的快，得到的反馈快，修正错误缺陷的成本低，缺陷也慢慢收敛，质量也随之提升，缺陷修复的也快了，这就是一个良性循环。概括总结就是效率提高了，质量也保证了，团队的人干活也是更加努力了。
6、进一步提升的方法
根据对需求数量以及平均完成时长的数据显示，团队还是有上升空间的，对于需求的交付力度和速率上还是略显波动。要想更快的知道做的是否是用户需要的，就要快速的迭代式的交付需求，以免用户想要个车，却给了四个轮子，能否彻底解决此团队需求的交付和用户期望偏差的问题，还是需要再向前走一步，需求继续细化，提升交付速率，参见敏捷中推荐的快速迭代，快速交付，快速得到用户反馈，只为了更快，更准确。
三、总结
数据有魅力，研发数据也一样，使用它就是为了两个目的：一是保证质量，二是确保交付的速率，行走过程中深度使用了云校度量新功能，结合敏捷中部分理念，配合传统测试方式保障来助力研发团队。可能有人会质疑需要用这么冰冷冷的数字去衡量可爱的程序员哥哥吗？对此的回答是，这不是衡量，数据只是手段，是帮助去诊断团队的一个切实有效的手段，学会利用它并驾驭它。因此只需要关注数据，读懂数据，重点问题重点解决，优先解决，一段时间只关注一个或很少的几个问题。相信团队的自驱能力，同时结合 TL 的管理与激励，养成良好的团队建设力。欢迎交流讨论，研发团队每天打交道最多的就是需求、缺陷、代码、发布、应用、测试等等，这些和研发人员息息相关的数据，云校现在以研发大盘、团队空间、人员效能、质量分布等多种维度数据整合到了数据平台上，后续更会以定制化的方式满足研发团队对于研发数据的需求。利用好这个工具能帮助清晰的了解团队的现状，暴露问题，找到改进措施，提升团队效率和产品质量。本人是一个敏捷爱好者，在深入研发团队做测试以及质量管理的时候，也是吸取和借鉴了敏捷的部分思想去落地，感受是拿最切实有用，比如展会看板，快速迭代式交付需求，再加上数据辅助，都是能帮助到团队更快，更准确的交付高质量产品的手段。
最后贴几张在度量上结的某研发团队的数据展示，这个团队是最近接触的团队，通过数据对这个团队的推测是团队在质量上需要提升，在缺陷的管理上需要加强。首先团队缺陷的数量逐月上升，这已经是质量不好的趋势体现。另外缺陷的解决时间也没有加快，这样会导致越来越多的缺陷流到线上去，可见团队除去一月份无故障，后续几个月都有故障，而且这个团队的线上发布成功率持续走低，开发对上线的代码把控程度较低，所以找到这些数据表征的背后原因，并且着手去解决掉，是这个团队近期最迫切的事情了。数据图可见文档，先直接给大家数据，上边几张图也比较容易看出来就不读了，养成良好的研发习惯，保持高效的团队协作应该是每个研发同学持之以恒的追求。
