关于 Bug 的优先级、严重性

–今天在学习 Django 的时候,看到这个社区希望大家通过帮它“Triage tickets”来对社区做出贡献,特意查了一下 Triage 这个单词的意思,“根据紧迫性和救活的可能性等在战场上决定那些人优先治疗的方法”。

因些想起来分享一下关于这个话题的一些经验。

我在以前的公司工作的时候,有一天领导让我一起去讨论一下 Bug 系统(当时我们用的是 mantis)的管理策略。

当时该 Bug 系统的问题,简单地说,是我们有一个打分公式,相当复杂,没有人能说得清楚,大家认为不合理,意见比较大。

之前把这个公式引入进来的领导自己也讲不明白,只说是他以前工作的外企就是这么干的,而且当时这个领导已经离职了(引入一个公式却讲不清楚道理,可见其能力可能有问题)。

这个公式大概是这样的:P = X * 25% + Y * 30% + Z * 45%(具体百分数值可能有出入,X/Y/Z 的顺序也可能有出入,其中 P 代表优先级 Priority,X/Y/Z 分别代表 严重性/复现概率/复现步骤复杂性中的某一个)。

围绕这个公式,我们几个同事展开了激烈的讨论,最后变成了争吵,谁也说服不了谁,为什么要有这几个变量,为什么要这样定义这些参数。

其实这个问题很简单,如果你理解了背后的道理的话。我后来上 wikipedia 搜了一下相关的名词,很快就弄清楚了背后的原理。

一般来讲,在处理 bug 的时候:

  1. 一个 Bug 越严重,越应该得到优先处理
  2. 一个 Bug 复现概率越高,越应该得到优先处理
  3. 一个 Bug 越容易出现,越应该得到优先处理

    跟上一条复现概率对比起来,这里说的是复现 Bug 所需操作的步骤难易程度。

    • 比如一开机就出现,意味着用户非常容易碰到,影响面比较广(相当于一块大石头拦在必经之路上)
    • 打开 4、5 个窗口,点个 5、6 级菜单,拐了 7、8 个弯之后才出现,意味着用户不容易碰到,影响面比较小

另外,一般来说,优先级决定我们处理 Bug 的顺序,严重性决定产品最后上市的时候,能带着几个严重等级超过某级别的 Bug(比如,S 级以上 Bug(含 S 级)必须全部解干净才能发布,等等)。

很多时候,优先级只是一个参考,在一定范围内,你还是可以按照自己的喜好决定先做哪个 Bug 的。如果你的决定顺序跟你老板的期望差异很大,那你可能需要做一些调整。

另外,团队的实力、人员配比等因素,也是会影响优先级和严重性的意义的。人很多的话,管它什么优先级,我就一个 Bug 分配给一个下属去搞就好了。人手严重不足的话,有可能再怎么讲究优先级,也无法达成目标。