|
通常关于处理bug的准则是修复bug使得结果尽可能的正确这个道理似乎是显而易见的但是确实是这样吗？不不是这样的我敢打赌在你使用过的那些存在很多bug性能极不可靠的软件中大多数并不是因为开发者没有时间改善它们而是因为他们只是简单地修复了错误的bug想要修复正确的bug和知道如何修复是两件不同的事情 要做出准确的处理bug的决定需要回答两个问题首先要明白如何才能做出一个好的修复bug的决定其次制定一个步骤要求这个步骤能够在项目压力大的情况下也能很容易得到执行并且执行这个步骤 明智的领导者和有经验的团队知道每当项目快结束或者出现重大转机或者项目重复循环中他们将非常容易疲惫不堪在这个过程中他们可能睡得更少更努力工作并且消耗无数的咖啡聪明的领导者如果提前考虑的话就会订制简单的规则在适当的位置预先放置急救装置那么当时间紧迫的时候就能很容易的定制快速简单的bug修复方案 这篇论文分为两个部分简单描述了上面说的定制的规则和那些预先放置的急救装置更重要的是我将提供让你制定自己的规则所需要的核心思想我们将这个建议分为四个等级从简单急救(第一等级)到高性能计划(第四等级)但是首先要避免那些看上去有趣但是完全没有必要的方法 十种最糟糕的处理方法 只修复那些让你的CEO苦恼的bug 修复每一个bug(总也不交货) 不修复任何bug 只修复那些让CEO的配偶女儿或其宠物感觉烦恼的bug 需要将每个决定让团队中最令人讨厌最愚蠢的人批准(这点和第十点比较起来有点多余) 没有规律地开始修复一个bug当你做到一半的时候又转向另一个bug一直重复循环如此 看待bug就如同一个烫红薯不修复它只是将你的bug委托给其他人 给bug编号按照字母顺序由A到Z跳过元音字母(如果你重新将它们适当的编号这一条和第八条是相同的) 成立一个复杂的议会机构并从三分之二的主要成员中选举出代表来起草一个规章制度作为小组委员会的正式文件使得将来与管理人员谈论项目中的缺点时可以有缓沖的余地 花费所有的时间来讨论当前的操作是否在上面这些列表里 真心的希望你从来没有在实际的工作中遇到这些行为现在你已经得到了警告所以你们在将来能够避开它们如果你的上司建议你做上面所说的任何一条那么你可以马上站起来安静地转身然后跑得能有多快就跑多快 第一等级急救 在最好的网站和软件开发公司bug管理就如同医学上的优先治疗选择(译者注将受伤人员按轻重缓急或立即治疗的可能性进行分类的过程)一些人根据一些规则将收到的bug归为三到四个基本的种类里(这叫做治疗等级选择bug竞争或者叫做缺陷管理)就像那些你可能大量拥有的事物比如CD碟片书籍债务或者女朋友组织管理bug的唯一方式就是将它们归结成更高一级的组群这将能使你更容易的了解到你得到的到底是什么使你更加方便的同其他人讨论它并且找到合适的处理它的专家一个普遍的规则是把事物归为三到四个组群比成千上万个独立的个体更容易管理和工作 当bug数量增加到严重影响工作的时候最好的急救是停下你手中的所有工作拿出一个下午来做修复归类(如果你记不起来上一次做修复归类工作是什么时候那么你现在应该停止阅读这篇文章马上去做这件事情)你无法使用魔法让你的bug数据库自动变得整齐规律必须要有某个人亲自动手忙的满头大汗的将它们归类整理好我向你保证在这件事情上没有其他的路可走如果你曾经受过训练你有能力非常有规律的将它们归类直到整个工程结束没有任何事情超出你的控制或者你能鼓励每一个程序员经常对他们自己负责的bug进行归类这非常的好但是无论你用什么方式来处理这件任务是必须要完成的 你跳过前面的这段并且说我知道归类但是我从来不这么做因为这样做无聊透顶了要知道对于任何急救工作要想成功有效的话归类是必须的无论是在医学领域还是在技术领域如果病人的背部被射中十来支毒箭那么你在他擦破的膝盖上贴上邦迪创可贴是没有任何意义的如果没有归类你没有办法知道如何让你的团队在最恰当的地方花费精力在受伤的人身上你能很明显的看到那支箭还颤抖地插在他的肩头上但是你的代码是不同的代码不会告诉你它的哪个部位受伤最严重你必须亲自将它们查出来 归类还能导致一些其他有用的事情发生负责归类的成员能够通过通查所有的bug使得每个人都能够更好的了解整个项目他将发现许多bug是重复出现的已经被修复的信息不完整的(这需要将这个bug返回给它的发现者)允许忽略的或者非常简单可笑的比如有客户抱怨这个网站不能预报下一期的乐透开奖号码通常在初次归类后bug的数量可以减少%很明显这一点能大大的提高团队的士气但是你如果不做这些工作的话是无法这么轻松的得到这样的成果的 最简单的归类 在归类的时候会有无数的方式来组织bug而每一个有经验的人都有他自己认为是最佳方式的看法通常这个问题没有唯一正确的答案使用一些简单的方法并且计划在下回改进要取决于在这期间你学到的东西和下一个项目是如何改变的 最简单的安排是划分成三个类必须得到修复的可能需要修复的和不需要修复的当给每一个bug归类的时候将它们放入这三类中的其中一类你放入后两类的bug越多你归类的效率就越高这些类的名称已经很明显的解释了原因 当然最糟糕的情况就是%的bug都被归到必须被修复的那一类中这种行为被称为胆小鬼的归类如果每件事都是必须被修复的那就是说你认为所有的事情都有着完全相同的重要性这是没有任何意义的因为过于胆小谨慎你这项工作是失败的如果所有的bug的地位是相等的这表示没有顺序成功是不可能的 如果你在做bug急救过程你的目标是将%的bug归为必须修复而其他的归为可能需要修复和不需要修复做个警戒标记让自己认真严肃的对待你的bug在你做判断的时候需要考虑到目前可以使用的资源(包括时间和人员)和你认为对于一个项目最重要的因素(客户和业务)在一个项目的后期没有其他的行为能比预先有效的bug管理和公开问题来的有效果将目标定为将%的bug归为必须修复如果目标没有达到%则需要寻找其他类中的bug归入此类只有当你觉得这么做令你痛苦的时候才能说明你所做的确实是bug归类急诊室中的医生没有办法摇白旗说不干了也没有叫暂停的时间他们只能不停的将一个接一个的病人区分病情的优先处理顺序既然他们能够为了人们的生命这么做你也能够为了你的bug这么做所以不要做无用的畏首畏尾的胆小鬼的归类认真起来强硬起来领导你的团队做的更好 最简单的归类的规则 三类归类法的基本规则是 如果一个bug要归为必须修复类那么它必须比其他两类中的bug更重要 如果一个bug归为了可能需要修复类那么它必须比不需要修复类中的bug更重要 如果一个bug归为了不需要修复类那么它必须比其他两类中的bug更不重要 所有的bug修复决定都是相关的没有例外定义bug的重要性需要考虑许多因素这些因素会影响到把bug归为三类中的不同的类聪明的团队会设置一些明确的标记称为退出标准(exit criteria)使得做修复决定变得很简单(我会在以后的第二部分的第三等级中解释退出标准)但是如果争论时常发生不用着急我保证每个分类中的只有很少一部分会引起异议让大家把焦点放在那些确定的大家都同意的bug上比如在必须修复类中有个bug属于大家都已经认定的在其他的那些需要讨论的bug提到议事日程前这个bug会花费大家几天到几个礼拜的工作时间 必须修复类是程序员们工作的起始入口如果可能需要修复类中的bug对归类工作没有帮助则没有必要理会它们原因是非常简单的不用担心那些可能需要的东西直到你确定你已经得到了所有你知道的必须得到的东西(比如没有必要考虑餐后的甜点除非你已经吃饱了) 从可能需要修复类中偷点bug出来一直都是很诱惑人的事情因为这些bug中可能会有一些很诱惑你的包括那些使你的团队觉得苦恼的bug那些影响到项目中你喜爱的一些性能的bug或者只是因为修复这些bug修复起来很有意思但是工作的优先级别标准是修复那些对于项目和客户来说最重要的bug一个团队对一个项目的服务结果是经常随着有质量的工作和无效的工作而改变 何时开始归类 通常一个礼拜一次归类已经足够了每个礼拜一早晨你招呼相应的人员来进行归类然后得出这个星期中使你的团队工作最有效率的工作计划必须修复类中的问题应该合理地分配给整个团队——无论他们是自愿的或者被指派为特定模块的程序员并且很乐意做这个工作如果必须修复类过于庞大那么需要对它进行进一步归类这个礼拜必须修复的和最终必须被修复的根据bug报告的速度和客户或者管理者决定的变化你可能需要更加经常的进行你的bug归类工作 第二等级更加巧妙的归类 除非你一边编程一边修复你的bug(很不错但很奇怪这是不普遍的策略)大多数bug修复都是在项目工作压力很大的时候进行的要知道对于每一个bug你需要很恰当的数据来让你 |
