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

核心提示：通常关于处理bug的准则是：修复bug使得结果尽可能的正确，这个道理似乎是显而易见的，如何在恰当的时间处理恰当的bug一(图)，但是确实是这样吗？不，不是这样的，这是不普遍的策略),大多数bug修复都是在项目工作压力很大的时候进行的，要知道，我敢打赌在你使用过的那些存在很多bug，性能极不可靠的软件中

　　通常关于处理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，你需要很恰当的数据来让你