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

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

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

1

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

数据展现

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

2


问题分析

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

  • 3月份完成需求数明显上升,且团队负载较重。
  • 质量不高-缺陷数、reopen率以及线上发布成功率。
  • 需求平均完成时长特别长。
  • 突增故障。

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

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

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

解决方案落地和数据运营

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

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

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

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


结果分析和总结

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

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


3

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

如何进一步提升?

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

总结

数据有魅力,研发数据也一样,我们使用它就是为了两个目的:一是保证质量;二是确保交付的速率。行走过程中深度使用了云效度量新功能,结合敏捷中部分理念,配合传统测试方式保障,来助力研发团队。
可能有的人会质疑,需要用这么冰冷冷的数字去衡量我们可爱的程序员哥哥吗? 我的回答是:这不是衡量。数据只是手段,是帮助我们去诊断团队的一个切实有效的手段。学会利用它并驾驭它。因此我们只需要:

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


欢迎交流讨论

研发团队每天打交道最多的就是需求、缺陷、代码、发布、应用、测试等等,这些和我们研发人员息息相关的数据,云效现在以研发大盘、团队空间、人员效能、质量分布等多种维度数据整合到了数据平台上,后续更会以定制化的方式满足研发团队对于研发数据的需求。利用好这个工具,能帮助我们清晰的了解团队的现状,暴露问题,找到改进措施,提升团队效率和产品质量。
我是一个敏捷爱好者,在深入研发团队做测试以及质量管理的时候,也是吸取和借鉴了敏捷的部分思想去落地。我的感受是:拿最切实有用比如站会、看板、快速迭代式交付需求,再加上数据辅助,都是能帮助到团队更快、更准确的交付高质量产品的手段。
最后贴几张我在度量上截的某研发团队的数据展示,这个团队是我们最近接触的团队,通过数据我们对这个团队的推测是:团队在质量上需要提升,在缺陷的管理上需要加强。首先团队缺陷的数量逐月上升,这已经是质量不好的趋势体现。

4

另外缺陷的解决时间也没有加快,这样会导致越来越多的缺陷流到线上去,可见团队除去1月份无故障,后续几个月都有故障。而且这个团队的线上发布成功率持续走低,开发对上线的代码把控程度较低。 所以,找到这些数据表征的背后原因,并且着手去解决掉,是这个团队近期最迫切的事情了。
养成良好的研发习惯,保持高效的团队协作,应该是每个研发同学持之以恒的追求。

原文发布时间为:2017-10-30
本文作者:冠楠
本文来自云栖社区合作伙伴“阿里技术”,了解相关信息可以关注“阿里技术”微信公众号

相关实践学习
流水线运行出错排查难?AI帮您智能排查
本实验将带您体验云效流水线Flow的智能排查能力,只需短短1-2分钟,即可体验AI智能排查建议。
ALPD云架构师系列 - 云原生DevOps36计
如何把握和运用云原生技术,撬动新技术红利,实现持续、安全、高效和高质量的应用交付,并提升业务的连续性和稳定性,这是云原生时代持续交付共同面对的机会和挑战。本课程由阿里云开发者学堂和阿里云云效共同出品,是ALPD方法学云架构师系列的核心课程之一,适合架构师、企业工程效能负责人、对DevOps感兴趣的研发、测试、运维。 课程目标 前沿技术:了解云原生下DevOps的正确姿势,享受云原生带来的技术红利 系统知识:全局视角看软件研发生命周期,系统学习DevOps实践技能 课程大纲: 云原生开发和交付:云研发时代软件交付的挑战与云原生工程实践 云原生开发、运行基础设施:无差别的开发、运行环境 自动部署:构建可靠高效的应用发布体系 持续交付:建立团队协同交付的流程和流水线 质量守护:构建和维护测试和质量守护体系 安全保障:打造可信交付的安全保障体系 建立持续反馈和持续改进闭环
相关文章
|
存储 缓存 文件存储
如何保证分布式文件系统的数据一致性
分布式文件系统需要向上层应用提供透明的客户端缓存,从而缓解网络延时现象,更好地支持客户端性能水平扩展,同时也降低对文件服务器的访问压力。当考虑客户端缓存的时候,由于在客户端上引入了多个本地数据副本(Replica),就相应地需要提供客户端对数据访问的全局数据一致性。
32698 79
如何保证分布式文件系统的数据一致性
|
前端开发 容器
HTML5+CSS3前端入门教程---从0开始通过一个商城实例手把手教你学习PC端和移动端页面开发第8章FlexBox布局(上)
HTML5+CSS3前端入门教程---从0开始通过一个商城实例手把手教你学习PC端和移动端页面开发第8章FlexBox布局
17752 20
|
设计模式 存储 监控
设计模式(C++版)
看懂UML类图和时序图30分钟学会UML类图设计原则单一职责原则定义:单一职责原则,所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变,那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。bad case:IPhone类承担了协议管理(Dial、HangUp)、数据传送(Chat)。good case:里式替换原则定义:里氏代换原则(Liskov 
36683 19
设计模式(C++版)
|
存储 编译器 C语言
抽丝剥茧C语言(初阶 下)(下)
抽丝剥茧C语言(初阶 下)
|
机器学习/深度学习 人工智能 自然语言处理
带你简单了解Chatgpt背后的秘密:大语言模型所需要条件(数据算法算力)以及其当前阶段的缺点局限性
带你简单了解Chatgpt背后的秘密:大语言模型所需要条件(数据算法算力)以及其当前阶段的缺点局限性
24758 14
|
机器学习/深度学习 弹性计算 监控
重生之---我测阿里云U1实例(通用算力型)
阿里云产品全线降价的一力作,2023年4月阿里云推出新款通用算力型ECS云服务器Universal实例,该款服务器的真实表现如何?让我先测为敬!
36661 15
重生之---我测阿里云U1实例(通用算力型)
|
SQL 存储 弹性计算
Redis性能高30%,阿里云倚天ECS性能摸底和迁移实践
Redis在倚天ECS环境下与同规格的基于 x86 的 ECS 实例相比,Redis 部署在基于 Yitian 710 的 ECS 上可获得高达 30% 的吞吐量优势。成本方面基于倚天710的G8y实例售价比G7实例低23%,总性价比提高50%;按照相同算法,相对G8a,性价比为1.4倍左右。
|
存储 算法 Java
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的限流器RateLimiter功能服务
随着互联网的快速发展,越来越多的应用程序需要处理大量的请求。如果没有限制,这些请求可能会导致应用程序崩溃或变得不可用。因此,限流器是一种非常重要的技术,可以帮助应用程序控制请求的数量和速率,以保持稳定和可靠的运行。
29838 52

热门文章

最新文章

下一篇
开通oss服务