如何在恰当的时间处理恰当的bug一 (3)

　2.如果一个bug归为了可能需要修复类，那么它必须比不需要修复类中的bug更重要。
　　
　　3.如果一个bug归为了不需要修复类，那么它必须比其他两类中的bug更不重要
　　
　　所有的bug修复决定都是相关的，没有例外。定义bug的重要性需要考虑许多因素，这些因素会影响到把bug归为三类中的不同的类。聪明的团队会设置一些明确的标记，称为退出标准(exit criteria)，使得做修复决定变得很简单。(我会在以后的第二部分的第三等级中解释退出标准)但是如果争论时常发生，不用着急。我保证每个分类中的只有很少一部分会引起异议。让大家把焦点放在那些确定的，大家都同意的bug上。比如在必须修复类中有50个bug属于大家都已经认定的，在其他的那些需要讨论的bug提到议事日程前，这50个bug会花费大家几天到几个礼拜的工作时间。
　　
　　必须修复类是程序员们工作的起始入口。如果可能需要修复类中的bug对归类工作没有帮助，则没有必要理会它们。原因是非常简单的：不用担心那些可能需要的东西，直到你确定你已经得到了所有你知道的必须得到的东西。(比如：没有必要考虑餐后的甜点除非你已经吃饱了。)
　　
　　从可能需要修复类中偷点bug出来一直都是很诱惑人的事情。因为这些bug中可能会有一些很诱惑你的，包括那些使你的团队觉得苦恼的bug，那些影响到项目中你喜爱的一些性能的bug，或者只是因为修复这些bug修复起来很有意思。但是工作的优先级别标准是修复那些对于项目和客户来说最重要的bug。一个团队对一个项目的服务结果是经常随着有质量的工作和无效的工作而改变。
　　
　　何时开始归类
　　
　　通常，一个礼拜一次归类已经足够了。每个礼拜一早晨，你招呼相应的人员来进行归类，然后得出这个星期中使你的团队工作最有效率的工作计划。必须修复类中的问题应该合理地分配给整个团队――无论他们是自愿的，或者被指派为特定模块的程序员并且很乐意做这个工作。如果必须修复类过于庞大，那么需要对它进行进一步归类：这个礼拜必须修复的和最终必须被修复的。根据bug报告的速度和客户或者管理者决定的变化，你可能需要更加经常的进行你的bug归类工作。
　　
　　第二等级：更加巧妙的归类
　　
　　除非你一边编程一边修复你的bug(很不错，但很奇怪，这是不普遍的策略),大多数bug修复都是在项目工作压力很大的时候进行的。要知道，对于每一个bug，你需要很恰当的数据来让你很迅速的做出决定。如果你花费了归类的一半时间来费劲地重现这个bug，或者用来试图理解问题到底是什么，那么你是在浪费时间。性质描述和重现信息应该在几天或者几个礼拜前就应该提供好的。
　　
　　那么，你所需要的bug库是一个明亮、干净、整洁的房间，而不是闹鬼的，充满蜘蛛网、老鼠跑来跑去的小阁楼。程序员们走进去，能很容易的得到他们需要的东西，然后走回去开始工作。这需要很有规律的维持这个bug库，并且每个接触、发现bug的人员都需要很细心。在bug库中信息的质量越高，在bug归类中所要花费的时间也就越少，而且团队也会用更多时间来实实在在的处理bug。(警告：通常是由于上一个等级的归类使得bug信息是否有质量或者缺乏。)
　　
　　提高bug信息质量的一个途径是建立更加巧妙的分类。与上面只考虑一个因素(必须/可能需要/不需要)不同，这次考虑两个因素：优先权和严重度。
　　
　　 图 1.
　　
　　优先权很简单：将必须修复类改为优先权一；将可能需要修复类改为优先权二；将不需要修复类改为优先权三。有些团队还定义了优