为了不逼疯产品经理，我们建立了一个缺陷管理（2）

lsekfe

　比如：
　　· 如果开发团队收到的缺陷是重复的，或者与其他正在进行中的缺陷问题相似，可以标注为“重复”。
　　·   对于部分不紧急的缺陷问题，比方说可能会随着日后的产品迭代中进行修复，对于这类缺陷可以标注为“延期”。
　　待测试
　　当开发团队修复缺陷后，应将缺陷状态标记为“待测试”，交给测试人员再次进行测试。测试不通过，测试人员再次将状态更改为未解决，并添加说明。
　　关闭
　　在测试通过后，缺陷状态修改为“关闭”或者完成。
　　你看，缺陷管理这样来走，什么“还剩一个是不是Bug”的，在走流程的过程中已经得到处理了。
　　设置合理的缺陷处理优先级
　　刚才在讲解流程的时候我们提到一个关键词“优先级”。我们都知道，软件产品就中的缺陷是难以避免。 这些缺陷有轻有重，有一些缺陷如果没有得到及时和有效的解决，可能会造成非常严重后果，而另一些轻微的缺陷，即便没有修复几乎所有人都不会注意到。
　　对于这些缺陷，我们真心没必要去浪费时间，除非你有无限的资源来分配好所有的缺陷修复任务，否则你需要优先将资源集中投资回报的缺陷修复上。
　　制定一套缺陷处理准则
　　要高效的处理缺陷问题，就需要建立流程，要建立流程，就需要有制定一套团队间通用的缺陷处理准则。这样，我们不用再对每一个缺陷问题进行详细的评估，而是可以直接按照我们制定的准则，通过管理工具快速处理。

下面这一套缺陷等级准则范例，大家可以参考，并依据自身的实际情况来设置自己的等级标准。
　　·   低：无关紧要的问题或某些功能不可用，但有一个简单的解决方法
　　· 中：辅助功能不可用，但有合理的解决方法
　　·   高：重要功能不可用，但有一个合理的解决方法
　　·   严重：数据丢失、数据损坏或系统不可用

　然后，我们就可以根据优先级别设置缺陷处理准则：
　　·  严重：必须立即处理，插入到当前的产品迭代版本中，高于其他需求开发。
　　·  高：快速处理，插入到当前的产品迭代中，但是低于部分本次迭代需求开发任务。
　　·  中：处理，可以随着下一次产品迭代进行处理。
　　·  低：选择性处理，根据迭代进度可放入下次迭代或者下几次迭代中进行处理。
　　这种方法的关键优势在于，它大大减少了用于讨论如何处理每一个缺陷的时间。另外，团队考虑的两个因素影响范围和严重程度是相对客观的，减少了我们由于主观因素带来的误差，让衡量标准更容易判断，也就可以更简单和高效的制度缺陷处理优先级别。
　　关于如何建立一个缺陷管理，就和大家分享到这儿。
　　最后不得不说，众多缺陷处理完成后团队需要有数据支撑，以及时的发现问题，解决问题，改进缺陷管理流程。同时，可以很好的衡量团队工作成果，工作进度，检测产品各个模块的缺陷变化趋势等。因此，一款好的缺陷管理工具应该有多种维度的数据报告能全局查看修复情况，有效预防风险。

　真是应了那句话“工欲善其事，必先利其器”，一个有效的缺陷管理，离不开一个方便的实用的管理工具。因为有它的协助，测试缺陷管理的每一个环节变得更加清晰直观；因为有它的协助，我们可以更快速、更精准地处理缺陷，提升产品品质。
　　CORNERSTONE
　　全行业覆盖的一站式项目协作平台
　　官网链接，收好不谢！
　　www.cornerstone365.cn