随着各产品线新产品开发逐渐进入收尾阶段，反馈缺陷库使用不方便的声音越来越强烈，于是专门找各产品开发、测试负责人访谈。

对于缺陷系统的抱怨主要集中在三部分

1、编辑和查询：新增bug的时候条款复杂、必选项多，检索速度慢，查询视图不方便

2、工作流：流转环节较多，尤其是跨Team跨产品的bug，需要多处审核和确认

3、整合度：和项目管理系统有些数据不能整合，需要人工关联，比如更详细的缺陷所属项目信息

 

相对来说，我们Scrum实验项目是基于禅道管理的，有些测试负责人对这个还是比较眼热的，觉得这样一个简单高效，特别是可以用中文书写缺陷实在太方便了（因为原来系统有个不成文的规则就是英语书写。）

 

实际上，一些测试Team早已变相给自己敏捷了一把，他们使用Excel来制作缺陷列表，他们通过IM来实时更新Excel的缺陷列表，并标识他们认为重要的属性，对一些短期内不能解决的问题填写到正式的缺陷管理系统上。（一个Team，两本账本）

 

于是我反思最近两年中，我们在缺陷系统方面做的调整

 

一个成熟的企业，通常在过程改进中习惯性地做加法，而做减法则要踌躇很多，诸如对原过程的探究，了解为什么要做这些很重要，过程改进人员最了解一个规则前前后后的因果，但铁打的营盘流水的兵，找到规则背后知情人难度很大，所以要靠自己去不断摸索，向各角色提问、证实自己的猜想。因此，我应该了解每个缺陷系统上每个流程是为了什么而设立的。

 

做减法的呼吁很强烈，甚至有测试负责人认为一直依赖格式化的缺陷写法效率都太低（缺陷标题、测试步骤、操作预期、实际结果），最好在一个标题中把所有内容涵盖在内，这样直接打印列表就可以讨论了。不需要一个个缺陷去展开看。

实话实说，我也视图找一个轻系统来替代原来面面俱到的系统。我查了下我们的缺陷库，从投入使用到现在（也许在02年实施该系统的同时，还导入了更早期来自其他系统的缺陷数据呢），超过10万条记录！这一定比当初投入使用的时候慢很多。

加字段容易，减字段难，加流程容易，减流程难，做减法的，要确定一个取舍原则。即使我本着现在的实际需要，大刀阔斧地做减法，甚至我说服别人按照我内心的想法用轻系统替换到现在的重型工具。

 

从我们目前的产品开发模式看，新产品开发阶段前期和中期是以实现新需求为主，质量并非第一重要的因素，而开发后期或更后面OEM定制环节，则质量变成最重要的因素。因此，有些测试负责人提出新产品开发中的缺陷管理要本着效率优先，而产品定型后，OEM项目要本着信息完整优先的思路有一定的科学性。一线工程师务实的要事优先的自然选择，就是日常用Excel，而把不能马上搞定的缺陷放到正式库管理。（我突然想到的是零钱包和皮夹共存的自然选择）

 

但这种实践实际是基于一种权益之计，Excel基于小Team的合作突出其便利性，但对于组织级的使用不是一个好的选择，即使同样是基于数据库的B/S应用，保留两套同时使用也会平添很多事宜。

 

如果舍弃老的成熟的，而换上新的，也许工程师短期感觉新系统很方便，但如果管理思维不变，是否会在两年内又有很多声音呼吁说要增强呢？怀念旧系统的趋势会不会促使我们在新系统上会加载越来越多的信息属性，流程，逻辑，也许过了两年，又会变成一个和现在功能高度相似的系统。

 

如果我做减法，过N年来评价整个先做减法再做加法的行动，是证实敏捷实践的无效？还是无谓的倒退被拨乱反正？