版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
作者:Scott Berkun; rotter_pal
原文地址:
http://www.onlamp.com/pub/a/onlamp/2005/08/11/fixingbugs.html
中文地址:
http://www.matrix.org.cn/resource/article/43/43819_bug.html
关键词： project bugs
通常关于处理bug的准则是：修复bug使得结果尽可能的正确。这个道理似乎是显而易见的，但是确实是这样吗？不，不是这样的。我敢打赌在你使用过的那些存在很多bug，性能极不可靠的软件中，大多数并不是因为开发者没有时间改善它们，而是因为他们只是简单地修复了错误的bug。想要修复正确的bug和知道如何修复是两件不同的事情。
要做出准确的处理bug的决定，需要回答两个问题：首先，要明白如何才能做出一个好的修复bug的决定；其次，制定一个步骤，要求这个步骤能够在项目压力大的情况下也能很容易得到执行，并且执行这个步骤。
明智的领导者和有经验的团队知道，每当项目快结束，或者出现重大转机，或者项目重复循环中，他们将非常容易疲惫不堪。在这个过程中，他们可能睡得更少，更努力工作，并且消耗无数的咖啡。聪明的领导者如果提前考虑的话，就会订制简单的规则，在适当的位置预先放置急救装置。那么当时间紧迫的时候，就能很容易的定制快速简单的bug修复方案。
这篇论文分为两个部分，简单描述了上面说的定制的规则和那些预先放置的急救装置。更重要的是，我将提供让你制定自己的规则所需要的核心思想。我们将这个建议分为四个等级，从简单急救(第一等级)到高性能计划(第四等级)。但是首先，要避免那些看上去有趣但是完全没有必要的方法。
十种最糟糕的处理方法：
10.只修复那些让你的CEO苦恼的bug。
9.修复每一个bug。(总也不交货)
8.不修复任何bug。
7.只修复那些让CEO的配偶，女儿或其宠物感觉烦恼的bug。
6.需要将每个决定让团队中最令人讨厌，最愚蠢的人批准(这点和第十点比较起来有点多余)。
5.没有规律地开始修复一个bug，当你做到一半的时候，又转向另一个bug。一直重复循环如此。
4.看待bug就如同一个烫红薯。不修复它，只是将你的bug委托给其他人。
3.给bug编号，按照字母顺序由A到Z，跳过元音字母。(如果你重新将它们适当的编号，这一条和第八条是相同的)
2.成立一个复杂的议会机构，并从三分之二的主要成员中选举出代表，来起草一个规章制度作为小组委员会的正式文件，使得将来与管理人员谈论项目中的缺点时，可以有缓冲的余地。
1.花费所有的时间来讨论当前的操作是否在上面这些列表里。
真心的希望，你从来没有在实际的工作中遇到这些行为。现在你已经得到了警告，所以你们在将来能够避开它们。如果你的上司建议你做上面所说的任何一条，那么你可以马上站起来，安静地转身，然后跑得能有多快就跑多快。
第一等级：急救
在最好的网站和软件开发公司，bug管理就如同医学上的优先治疗选择(译者注：将受伤人员按轻重缓急或立即治疗的可能性进行分类的过程)。一些人根据一些规则将收到的bug归为三到四个基本的种类里。(这叫做：治疗等级选择，bug竞争，或者叫做缺陷管理。)就像那些你可能大量拥有的事物，比如CD碟片、书籍、债务、或者女朋友，组织管理bug的唯一方式就是将它们归结成更高一级的组群。这将能使你更容易的了解到你得到的到底是什么，使你更加方便的同其他人讨论它，并且找到合适的处理它的专家。一个普遍的规则是，把事物归为三到四个组群比成千上万个独立的个体更容易管理和工作。
当bug数量增加到严重影响工作的时候，最好的急救是停下你手中的所有工作，拿出一个下午来做修复归类。(如果你记不起来上一次做修复归类工作是什么时候，那么你现在应该停止阅读这篇文章，马上去做这件事情。)你无法使用魔法让你的bug数据库自动变得整齐规律，必须要有某个人亲自动手，忙的满头大汗的将它们归类整理好。我向你保证在这件事情上没有其他的路可走。如果你曾经受过训练，你有能力非常有规律的将它们归类，直到整个工程结束，没有任何事情超出你的控制；或者你能鼓励每一个程序员经常对他们自己负责的bug进行归类。这非常的好。但是无论你用什么方式来处理，这件任务是必须要完成的。
你跳过前面的这段，并且说：“我知道归类，但是我从来不这么做，因为这样做无聊透顶了。要知道，对于任何急救工作，要想成功有效的话，归类是必须的，无论是在医学领域还是在技术领域。如果病人的背部被射中十来支毒箭，那么你在他擦破的膝盖上贴上邦迪创可贴是没有任何意义的。如果没有归类，你没有办法知道如何让你的团队在最恰当的地方花费精力。在受伤的人身上你能很明显的看到那支箭还颤抖地插在他的肩头上，但是你的代码是不同的，代码不会告诉你它的哪个部位受伤最严重。你必须亲自将它们查出来。
归类还能导致一些其他有用的事情发生。负责归类的成员能够通过通查所有的bug使得每个人都能够更好的了解整个项目。他将发现许多bug是重复出现的、已经被修复的、信息不完整的(这需要将这个bug返回给它的发现者)、允许忽略的、或者非常简单可笑的。比如，有客户抱怨这个网站不能预报下一期的乐透开奖号码。通常，在初次归类后，bug的数量可以减少30%，很明显这一点能大大的提高团队的士气。但是你如果不做这些工作的话，是无法这么轻松的得到这样的成果的。
最简单的归类
在归类的时候，会有无数的方式来组织bug，而每一个有经验的人都有他自己认为是最佳方式的看法。通常，这个问题没有唯一正确的答案。使用一些简单的方法，并且计划在下回改进要取决于在这期间你学到的东西和下一个项目是如何改变的。
最简单的安排是划分成三个类：必须得到修复的，可能需要修复的和不需要修复的。当给每一个bug归类的时候，将它们放入这三类中的其中一类。你放入后两类的bug越多，你归类的效率就越高。这些类的名称已经很明显的解释了原因。
当然最糟糕的情况就是99%的bug都被归到必须被修复的那一类中；这种行为被称为“胆小鬼的归类。如果每件事都是必须被修复的，那就是说你认为所有的事情都有着完全相同的重要性，这是没有任何意义的。因为过于胆小谨慎，你这项工作是失败的。如果所有的bug的地位是相等的，这表示没有顺序，成功是不可能的。
如果你在做bug急救过程，你的目标是将50%的bug归为必须修复，而其他的归为可能需要修复和不需要修复。做个警戒标记让自己认真严肃的对待你的bug。在你做判断的时候，需要考虑到目前可以使用的资源(包括时间和人员)和你认为对于一个项目最重要的因素(客户和业务)。在一个项目的后期，没有其他的行为能比预先有效的bug管理和公开问题来的有效果。将目标定为将50%的bug归为必须修复，如果目标没有达到50%则需要寻找其他类中的bug归入此类，只有当你觉得这么做令你痛苦的时候，才能说明你所做的确实是bug归类。急诊室中的医生没有办法摇白旗说不干了，也没有叫暂停的时间，他们只能不停的将一个接一个的病人区分病情的优先处理顺序。既然他们能够为了人们的生命这么做，你也能够为了你的bug这么做。所以，不要做无用的畏首畏尾的“胆小鬼的归类：认真起来，强硬起来，领导你的团队做的更好。
最简单的归类的规则
三类归类法的基本规则是：
1.如果一个bug要归为必须修复类，那么它必须比其他两类中的bug更重要。
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.
优先权很简单：将必须修复类改为优先权一；将可能需要修复类改为优先权二；将不需要修复类改为优先权三。有些团队还定义了优先权四，他们将原先的优先权三分为两个部分，优先权三表示：可能不需要修改；优先权四表示：不需要修改，直到地狱全被冻住，然后变暖和，然后再次被冻上。我目前还没有看到有成功的团队使用超过四个优先权等级，所以如果有人坚持要分为15个优先权等级，那这就什么也别想做了。
严重度描述了当bug发作时它对客户的损害程度。在优先权下再分出严重度能让你更好的理解这个bug,因为你能了解当bug发作的效果。举例来说，可能当bug发作的时候，它的效果是使用户的显示器爆炸(严重度为一)，但是这个bug发作的条件是当且仅当用户使用德语来唱澳大利亚国歌的同时三次点击菜单，这是一个低优先权问题(优先权三)。
要让这个分级运作起来，需要一些人来定义严重度一、二和三之间的区别，最好使用实际bug的例子来帮助人们理解。那么，当一个新bug被发现，就被正确地划分。需要有人去将这个信息添加到原先已经存在的旧bug中去(而这个人有可能就是你)。
这有一个基础的严格的系统，我建议你和你的团队一起来讨论一下：
严重度一：数据丢失。用户丢失了数据或者严重影响了客户的工作。损坏可能无法修复，或者需要重装系统(或者刷新浏览器)。
严重度二：功能无法实现或者很难实现。一个重要的特征就是系统不像预期的那样工作，或无法使用，或是需要一个重要的临时解决方法。
严重度三：令人烦恼的。在一些次要的功能上不像预期的那样工作。可能有临时解决方法，但其令人烦恼，或是要想找到临时解决方法可能非常困难。
使用这样的两级信息，就可以将剩下的bug用更巧妙的方式来分类。同仅仅将bug归为三大类不同，现在你就能问一些更加细致的问题了。你现在不仅能将bug在所有bug中排出它的优先等级，而且在每个优先等级中，你能确定出这个bug的严重度如何。这样就能很快速的在任何优先等级中列出bug。
要向Bug信息中添加的第三个重要的信息是它们影响到项目中的哪个模块。你的团队越大，这个信息就越重要。这个信息能显示出项目中的哪个部分受到这个bug的影响。是打印特性？还是搜索引擎？如果将一个项目分为四到五个块，那么其中一个部分就是bug库。这提供了让你了解你的项目的一些途径：你能得出项目中哪个模块出了最多的bug，你能知道项目中那些对于你和你的客户最重要的模块的优先级别。如果每个程序员负责一个模块，那么这个信息能让他们知道哪些bug是和他们没有关系的。
还有其他一些信息需要加入。通常有：重现bug的重要步骤，发现bug的软件版本，bug的统一ID号，一句话(可以被理解的)的描述，发现bug的人名。每个项目都是不同的，你要记录的信息也会随着项目的变化而变化。
第二部分的内容
在令人期待的下一个部分，我将提到以下一些内容：
第三等级：退出标准
第四等级：早期计划
对于这些规则的一些例外
FAQ
做出bug处理决定的参考书目和资料
资源和关于作者
2005年4月, O'Reilly 多媒体公司发布了The Art of Project Management.
第3章: How to figure out what to do (PDF)，可以线阅读。
也可以阅读该书的目录, 索引, 以及所有书评。
更多信息，或要订购本书，单击这里.
Scott Berkun 是《项目管理艺术》一书的作者。目前，他是项目管理和产品设计独立顾问。他还维护一个讨论关于项目管理问题的论坛pmclinic，地址是：www.scottberkun.com.
Java, java, J2SE, j2se, J2EE, j2ee, J2ME, j2me, ejb, ejb3, JBOSS, jboss, spring, hibernate, jdo, struts, webwork, ajax, AJAX, mysql, MySQL, Oracle, Weblogic, Websphere, scjp, scjd
标签：
