质量度量之定性分析

质量度量之定性分析

从关注工具到关注人

在前文中我们讨论了软件全生命周期的质量度量,以及迭代内的定量分析,本文主要讨论的是跨迭代的定性分析。

定性分析也是度量

之前我们讨论过定性分析和定量分析的区别:定量分析研究数量和频率,而定性分析研究意义和影响。有小伙伴可能有疑问了,定性分析也是度量吗?以下是维基百科对度量的定义:

“度量是指对于一个物体或是事件的某个性质给予一个数字,使其可以和其他物体或是事件的相同性质比较。度量可以是对一物理量(如长度、尺寸或容量等)的估计或测定,也可以是其他较抽象的特质。”——维基百科

定义中“物理量的估计或测定”指的就是定量分析,而“其他较抽象的特质”指的就是定性分析了。由此可见,定性分析也是度量的一种。进一步讲,当我们做了质量的定量分析之后,一定会发现一些需要进一步讨论的数据现象,如某一时期缺陷数量的井喷,大量返工的代码实现,亦或是迭代开发速率的持续减缓……这些现象都需要进一步挖掘,找到根因并持续改进,才能对质量提升有所帮助。我们把这些基于定量分析的结果、某些突发事件、或者团队的状态进一步分析意义和影响的质量分析工作统称为质量度量的定性分析。

*.png

全生命周期的定性分析

我们先回顾一下第一篇《全生命周期的质量度量》中提到的内容,当软件处在生命周期中的不同阶段时,我们应当采取不同的度量策略。原因在于处在不同阶段,我们的度量目的不同,能够参考的历史信息不同,能够调用的资源配置也不同。但有一点可以肯定,哪怕我们当下没有条件做全方位的定量分析,也可以采取定性分析来快速评价和初步判断软件质量,定性分析可以贯穿始终。

*.png

既然不管处在什么阶段都可以定性分析,那我们可以采用的定性分析方法有哪些呢?常见的主要有五种:访谈、根因分析、成熟度评估、回顾和复盘。

*.png

访谈

访谈是最简单、成本最低的定性分析。确定好访谈目标,设计好问题后就可以直接实施。

*.png

一般来说访谈会分为内部访谈和外部访谈。

内部访谈主要由团队领导、项目经理、敏捷教练或 Scrum Master 来采访研发团队成员,倾听大家当前的工作状态和心声,响应问题和诉求。而外部访谈可以由项目经理或业务分析师采访项目干系人或直接用户,目的在于收集他们对软件的质量反馈、使用体验,或是痛点和新需求。

访谈虽然方式简单,但经过专业的设计实施后,效果往往很赞。原因一方面在于,由于访谈目标明确,关键信息能够得到有效的收集;而另一方面,在访谈的过程中,每个受访者自身的状态和情绪也有被积极聆听,这对团队整体的合作氛围、或是干系人和直接用户的体验都能起到积极的效果。

成功的访谈需要预先设计访谈提纲。访谈提纲需列出访谈目标、一般性问题和深入问题、访谈的大致过程、问题扩展的思路等等。如何设计访谈不在质量度量范围内,在此就不展开讨论了。

根因分析

我们在质量度量过程中会发现一些有趣的现象:改过的缺陷反复出现,某个团队明显比其他团队代码质量差很多,某服务部署后经常回滚代码……这些表面现象引起我们的关注,需要对其进行根因分析,以挖掘背后的真正原因,从而找到有效预防的方法。

*.png

下面举两个“5Why法”的实例,来看一下通常怎样做根因分析。遇到的问题是一样的:在生产环境遇到事故级别的重大缺陷。

例1:分析为什么让重大缺陷逃逸到生产环境,找到根因并改进,进行反向验证。 Snipaste_2020-11-24_10-18-07.jpg

例2:分析为什么引入这个重大缺陷,找到根因并改进,进行反向验证。 Snipaste_2020-11-24_10-19-17.jpg

有趣的现象产生了,针对同一个问题采用“5Why法”进行根因分析,问问题的方向不同,会导致根因的确定和相应的改进项完全不同。那么哪种是对的呢?其实都对,但我们认为第二种更好,为什么呢?因为站在缺陷预防的角度,引入缺陷的原因,比缺陷逃逸原因的价值要大得多。分析缺陷逃逸的原因并改进,最好的结果是缺陷不再逃逸,而分析缺陷引入,最好的结果是减少缺陷引入,孰优孰劣一目了然。站在解决问题的角度去分析,不如站在避免引入问题的角度,破坏掉引入问题的回路是最有效的预防。

在做根因分析的时候,首先要朝着解决问题的方向分析,举一个反例:“为什么生产环境遇到重大缺陷?因为开发/测试水平差。” 这就不是解决问题的角度,而是为了追责,容易引起团队成员的防御心理,造成分析失效。其次要同时寻找内因和外因,“都是我的错” 和 “都是你的错” 是在根因分析时需要避免的误区。最后要找可控的因素进行分析,多关注可以改进的做事方式,少关注不可控的主观因素。

成熟度评估

质量成熟度评估模型,是以定量分析结果去做定性判断,从多个维度全方位的帮助我们快速了解团队质量现状。通过评估过程,能够获得团队质量改进的方向。经过一段时间的持续改进和再次评估,观察到成熟度曲线的变化,即团队的质量成熟度和质量能力获得整体提升。

对团队来讲,质量成熟度评估是一个绝佳的自我审视的机会。由于不同团队的上下文和限制条件不同,所以在各个维度所能达到的上限也是不同的,质量成熟度切忌无意义的横向比较。只要团队自身在持续度量成熟度的过程中,观察到积极的成熟度提升,那就是有效的度量。还需强调一点,由于质量成熟度的提升需要一段时间的作用和磨合,所以改进之后的持续观察很有必要,成熟度的提升绝非一朝一夕之功,水滴石穿重在坚持。

*.png

回顾

回顾会议一般用于团队一段时间的总结和梳理,一个迭代、一个季度、大型版本发布等关键节点后都可以进行。在回顾会议中,我们总结过去的闪光点、待改进的事项、疑惑和问题,制定出下一阶段的改进项。值得注意的一点是,改进项要落实到责任人和截止日期,才能获得有效改进。

*.png

复盘

发生重大线上事故,影响很不好。除了紧急修复,我们还能做什么?复盘,学到教训就好。

复盘的主流程如下,它是访谈、根因分析、回顾的综合运用,属于复合型定性分析。同样的,一场有效的复盘需要过程设计和引导,以及结果的跟进和经验的传递。

*.png

总结

定性分析的结果通常对团队整体质量的改进有重大价值贡献,可以作为组织过程资产不断的积累和传递下去,形成团队独有的质量文化。

本文介绍了有助于质量提升的五种定性分析方法,适用于大部分需要质量度量的场景。受限于笔者个人经验,针对不同的度量需求,还请大家具体问题具体分析,酌情设计符合团队上下文的度量模型。

All rights reserved
Except where otherwise noted, content on this page is copyrighted.