第二章 过程改进，没有灵丹妙药

    优先级别

    对于优先级别意义的讨论一直没完没了，这种级别的范围值通常为0～3。说实在的，你可以把时间更好地用到其他地方去。这里还是说些简单的准则，以此为基础阐明优先级别。

    优先级别一旦设定则不宜再改，除非Bug本身角色变换了。如果级别1意味着：“在目前的冲刺阶段或里程碑期间修复”，级别2意味着：“到下一个冲刺阶段或里程碑期间再修复，”那么在每个冲刺结束时，你必须更新Bug的优先级别，这样不仅很浪费时间，而且改变了Bug的“最后一次变更时间”，这会丧失很多重要信息。

    优先级别必须容易指定并区分。你不会想让你的团队花大量的时间争论每一个Bug的优先级别吧。它必须是显而易见的，不管是在写Bug报告或读Bug报告的时候。

    优先级别必须易记且易操作。人们不需要问：“下一个Pri 2是什么？”，人们也不需要问哪种级别需要做什么。

    基于以上三条准则，一般普遍接受以下优先级别的定义。

    优先级别描述修复时间点

    Pri 0一个需引起严重关注的致命错误。不存在变通办法，是一个不可逾越的Bug只有解决了这个问题或找到了变通办法，你才能安心

    Pri 1一个需引起严重关注的致命错误必须在当前的冲刺阶段或里程碑期间解决

    Pri 2一个严重的错误必须在产品发布前解决

    Pri 3一般性错误或建议最好在产品发布前解决

    Pri 0通常有碍测试、部署或其他对时间敏感的工作。你必须给开发者或团队发邮件并电话告知他们，或者直接过去跟他们谈，直到有人解决这个问题。如果有变通办法，Pri 0就必须改成Pri 1。

    作者注：确实有开发团队对优先级别有非常多的定义。有的从Pri 1开始，而不是Pri 0；有的不遵从我在本章开始时列出的准则，或者在一个单独的区域提示Bug信息。

    如果你查看另一个团队的工作项目数据库，确定你使用的是他们的定义。这些定义通常显示在工具提示上或帮助窗口中。

    严重程度

    严重程度比优先级别简单得多，但是它还是经常被搞混。严重程度指的是问题所产生的影响范围，不关乎“有多么严重”这样的问题。其定义是：

    严重程度1。某问题引起系统崩溃或客户数据丢失。

    严重程度2。某问题引起的故障阻断了后续操作。

    严重程度3。某问题引起操作不便或界面显示不完整。

    注意，严重程度与优先级别是相互独立的——换句话说，严重程度与优先级别毫无关系。优先级别1的Bug比级别2的Bug更重要，不管其严重程度如何。显示一些不合适的内容就是严重程度3但也可能是优先级别1；系统崩溃后用户强行重启就是严重程度1同时也可能是优先级别3。工程师声称一个未致系统崩溃的Bug的严重程度是1，因为严重程度很高。你完全没必要成为他戏弄的笑料。如果你这样就白痴了。

    解决方案

    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作了描述，以说明我们并非蓄意而为。