项目管理之bug数减少原因分析和解决办法

前言：

离开原来项目组快有两个月了，现在突然回想起项目组的对缺陷(bug)管理的一些方法。ps：在这个项目组待了快三年，因为个人原因离开。见证了原来的杂乱无章到现在的相对比较正规，但是缺陷的数量和缺陷问题的质量都提高的很多。项目管理人员也有换过。下面就总结一下。

1、bug分类：

a、需求本来就有问题而产生的代码缺陷。这类问题源头是需求或产品这一块没有分析清楚。

b、代码实现和需求相差很大的缺陷。这类问题也是比较常见的，开发人员的思维与需求或产品人员的思维还是有很大差距的。

c、很复杂的需求代码实现在某些逻辑上有缺陷。这类问题有可能是开发人员不想实现完全，也有可能需求过于复杂，在系统设计阶段就没有分析出所有情况。

d、对框架特性不熟悉、对数据结构、开发语言的数据类型不熟悉，导致出现缺陷。这类问题对开发经验比较少的开发人员容易出现。

e、粗心导致的缺陷。人孰能无过。

f、系统架构上的缺陷。这类问题一般很少，出现的话是大面积的。

2、我们的解决办法：

2.1、如果是a类解决方法，我在项目中是碰见很多，也可能和我接触的需求人员经验有关。他们有很多需求并没有从客户那边完全挖掘出来，这样导致当开发完代码到整个流程测试阶段出现很多问题没有考虑的隐藏的需求，往往导致整个代码从写，代价非常惨烈。我这边解决方法是：因为我对项目开发的系统非常了解，当需求人员讨论需求的时候组长也参与讨论，多和他们沟通尽量将需求点分析透彻。那如果对系统不是很了解的话，这个时候就需要经验来进行判断和对需求人员的一个考验。要求需求人员不仅要专注于自己负责的功能的需求也要对其他功能的需要也要了解。

2.2、b类问题，这类问题应该每个项目中都会碰到，我们是通过编写系统设计和画流程图的方式，达到开发人员对需求的彻底理解，而且我们使用集中办公的方式减少电话、邮件沟通的语言歧义。还有是通过开发组长对组员代码的一个逻辑检查，其实后面的问题也使用到这一方法。

2.3、c类问题，这类问题是b类问题的轻微版，还是系统设计、流程图没有很细化。导致代码考虑不周全。如果是开发人员不想实现的话，这个时候就需要约喝茶了。这类缺陷是很致命，因为这类的问题需要大量的测试案例才能测试出来。或者需要非常细致的组类代码检查，才能发现。

2.4、d类问题，这类问题主要是通过代码检查来进行发现，还有通过测试也可能发现，还有通过培训提高开发人员的基础知识。我在这个项目中真实的碰到一个，因为作为开发组长，帮组员看的一个问题。问题现象大致是：一个订单完成的条件，正常是订单发货的数量大于等于实际下单的数量表示订单已经完成，但是代码表现为订单发货的数量小于订单下单时的数量也将订单置为完成。而且测试那边不是每次都能呈现该问题，只有该订单有多个商品的时候，并且每个商品都发货了才会出现。这个问题就是因为使用了错误的数据结构导致的。对框架的不了解我这边也碰到过，spring框架中service层的类默认是单例的，也就是线程不安全的，不能有类的局部变量，但是在项目开发中出现过类的局部变量。

2.5、e类问题，这个首先一个养成对自己开发完代码的检查习惯，我们这边有进行组内检查、组与组之间检查还有架构师亲自检查。这三种检查对检查的粒度也不一样，组内检查的话会很细时间也很长，组组检查，主要是听，听被检测者对代码的一个描述。架构师亲自检查的话，只能核心代码进行检查，也是核心功能的代码。

2.6、f类问题，首先这种问题很少出现，而且改起来也很快。加强对整个项目的架构框架的熟悉，关注使用的框架是否有漏洞。这类问题我们项目中也碰到过，就是2016年的struts2的两个重大漏洞。乌云网都有详细的介绍。我们只能将lib包升级。