2017年4月7日，对cmmi拥有丰富的实践经验以及对架构分析、缺陷分析、配置管理等拥有丰富经验的质量管理工程师于勇带来了主题为《缺陷分析在软件项目中的实践》的Chat交流。以下是文章的主要部分。
2017年4月7日，对cmmi拥有丰富的实践经验以及对架构分析、缺陷分析、配置管理等拥有丰富经验的质量管理工程师于勇带来了主题为《缺陷分析在软件项目中的实践》的Chat交流。以下是文章的主要部分。
众所周知, 程序员最怕的就是加班。人非圣贤孰能无过，而程序员也是人。他们在工作中难免会犯错并引入缺陷，如果任由缺陷发生而不采取分析，补救措施只会让程序员不断地加班、救火解bug。
该如何打破这个恶性循环呢？本文将从缺陷分析基础知识，缺陷分析实践以及总结三个方面，给各位读者介绍如何借助缺陷分析技术，帮助管理和开发人员防患于未然，救程序员于水火之中，同时让员工更smart地工作。
本部分将从缺陷分析流程、分析方法、分析维度以及分析的基础四个方面给各位读者介绍缺陷分析的基础知识。
缺陷分析流程如下图所示。
常见的分析方法主要包括帕累托分析法、5why分析法、鱼骨图分析法。帕累托分析法的核心是找出影响整体效果的关键因素；5why分析法和鱼骨图分析法则是沿着因果关系链条，顺藤摸瓜，直至找出问题的根本原因。
帕累托分析法是制定决策的一种统计方法，主要用于从众多任务中选择有限数量的任务以取得显著的整体效果。帕累托分析法使用了帕累托法则（2/8原则）。下图展示了Exceptional Case和API usage是导致缺陷多的主要原因。这是分析的第一步，接下来需要进行数据抽样和借助5why分析法、鱼骨图分析法一步步打破砂锅问到底找出根本原因。
所谓5why分析法，又称“5问法”，也就是对一个问题点连续以5个“为什么”来自问，以追究其根本原因。虽为5个为什么，但使用时不限定只做“5次为什么的探讨”，主要是必须找到根本原因，有时可能只要3次，有时也许要10次，如古话所言：打破砂锅问到底。5why法的关键是鼓励解决问题的人要努力避开主观或自负的假设和逻辑陷阱，从结果着手，沿着因果关系链条，顺藤摸瓜，直至找出原有问题的根本原因。
鱼骨图分析法是由日本管理大师石川馨先生所提出来的，故又名石川图。鱼骨图是发现问题“根本原因”的一种方法，也可以称之为“因果图”。鱼骨图主要用于工商管理中建立分析模型。业界一般推荐从人、机器、物料、方法、环境和测量这六个方面进行分析。当然将鱼骨图分析法运用到软件行业时就演变成人、方法、系统、工具、流程和制度这六个方面。下图是一张经典的鱼骨图。
俗话说：“擒贼先擒王”，缺陷分析的第一步就是找出导致缺陷的关键因素。根据项目的不同一般会从下面几个维度进行帕累托分析。
下图是典型的软件生命周期图，每个阶段定义了相应的活动，每个活动都会引入问题，通过分析缺陷的引入阶段可以帮助我们有效地定义质量、保证活动并提前发现问题。
软件开发大多采用模块化设计，按模块分析可以帮助我们轻松地知道哪些模块的缺陷较多，在此基础上可以做深入分析并决策是否需要投入更多的资源，一般采用柱状图横向比较各个模块的缺陷。缺陷与模块的关系可以根据对应的代码变更得到。
世上没有无缘无故的恨，也没有无缘无故的爱，缺陷也不会无缘无故地产生。开发人员在解defect同时也会分析这个defect是由什么原因发生的？比如：指针、数组操作不正确，异常流程没有考虑到位还是代码实现与需求不符。在此基础上，我们可以通过初步的分析大致了解缺陷产生的原因，这是后续根因分析的基础。一般我们可以采用帕累托图来呈现分析结果，如下图所示。
按引入阶段、活动分析比较适合使用瀑布模型的项目。但是，如今很多项目采用了敏捷，迭代，讲求的是快速开发和交付。一般我们建议按迭代进行缺陷分析，这样可以帮助我们即时知道哪些方面做的好，哪些方面还需要改善。
前面所提到的这些分析维度，在实际分析过程中可以组合起来使用。这样可以方便管理者多角度地了解项目的质量状况以便采取改善措施。
纵观前面的分析维度，可以清晰地看到缺陷分析主要是从问题以及问题与变更代码间的关系出发。 俗话说得好：“巧妇难为无米之炊”。对软件企业来说要想做好缺陷分析，首先需定义缺陷处理流程并构建缺陷管理系统（如：JIRA、ClearQuest、BugFree、Bugzilla等）。使用好的缺陷管理系统可以帮助我们提高缺陷管理的效率，洞察缺陷处理过程中存在的问题（例如：哪些缺陷解决比较慢，哪些环节效率低下）。 其次，配置管理是一切分析改进的基础,管理好代码变更至关重要（常用代码管理工具：ClearCase，Perforce，SVN，GIT）。有了配置管理系统可以帮助我们记录每次的变更，缺陷分析可以细化到每次变更。 第三，建立变更代码与缺陷变更的关系（如，IBM的ClearCase 与 ClearQuest关联，Perforce 与Swarm，GIT与Gerrit，SVN通过问题的URL建立与BugFree bugzilla间的关系）。通过建立变更与缺陷间的关系，我们可以清晰地知道导致缺陷的代码变更量。针对不同的变更量定义不同的质量保证活动。同时也可以清晰地知道缺陷与模块的对应关系。
第一部分给大家介绍了缺陷分析的基础知识，包括一些常用的分析方法。下面将结合实际给大家介绍在一个实际项目中缺陷分析是如何实施的。
下图是产品的架构示意图，主要分为System、Framework、App三个layer，分别由部门A、B、C进行并行开发。App依赖于Framework的组件，Winset负责提供界面控件，Network负责与远程服务器通讯，FFMPEG负责音视频编解码，IME负责输入法功能。
在产品开发过程中，产品经理进行了缺陷分析。初步得到下图所示的分析结果，从这张图我们可以发现随着迭代的进行每个App的defect都是在不断地增长,另外每个迭代开发的需求和人员固定。
为了找出defect产生的原因，产品经理分析了各个迭代中各模块的cause category构成，如下图所示。可以看出，Incorrect API usage & inconsistent with GUI.占到近70%的比例。
通过访谈、缺陷抽样、5why分析法挖掘出找出了根本原因，如下表所示。
下表是提出的改善措施。
下表是实现与GUI不符的原因分析。
下表是进一步改善措施。
监控方法主要包括甄别监控各模块的缺陷数量；监控依赖模块的接口变化情况。
较前面几个迭代，改善方案实施后，Defect数量有明显的下降趋势，下图是前后对比效果对比图。
当然，改善措施是否有效，取决于是否找到根本原因。很多企业会用缺陷来考核员工，在这样的环境下员工很难乐意去找出根本原因，所以说为了缺陷分析能更有效地分析结果不应该与考核挂钩。分析只是一种手段，不是目的。给员工一个轻松的氛围去做缺陷分析这一点非常重要。
本文主要介绍了缺陷分析的基础知识并结合一个案例，介绍了如何使用分析方法找出其根本原因。在此基础上提出改善措施，措施的提出是第一步，然后还得定期监控措施的执行情况和有效性。希望通过本文，各位读者能够了解缺陷分析的大致流程，应用到工作中去。
（以上内容转自GitChat，版权归GitChat所有，转载请联系GitChat，微信号：GitChat，原文： 《于勇：缺陷分析在软件项目中的实践》）