关于 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 的时候：
- 一个 Bug 越严重，越应该得到优先处理
- 一个 Bug 复现概率越高，越应该得到优先处理
一个 Bug 越容易出现，越应该得到优先处理
跟上一条复现概率对比起来，这里说的是复现 Bug 所需操作的步骤难易程度。
- 比如一开机就出现，意味着用户非常容易碰到，影响面比较广（相当于一块大石头拦在必经之路上）
- 打开 4、5 个窗口，点个 5、6 级菜单，拐了 7、8 个弯之后才出现，意味着用户不容易碰到，影响面比较小
另外，一般来说，优先级决定我们处理 Bug 的顺序，严重性决定产品最后上市的时候，能带着几个严重等级超过某级别的 Bug（比如，S 级以上 Bug（含 S 级）必须全部解干净才能发布，等等）。
很多时候，优先级只是一个参考，在一定范围内，你还是可以按照自己的喜好决定先做哪个 Bug 的。如果你的决定顺序跟你老板的期望差异很大，那你可能需要做一些调整。
另外，团队的实力、人员配比等因素，也是会影响优先级和严重性的意义的。人很多的话，管它什么优先级，我就一个 Bug 分配给一个下属去搞就好了。人手严重不足的话，有可能再怎么讲究优先级，也无法达成目标。
