由The Old New Thing上的问题引发，我想问一下：
如何设置错误跟踪器优先级？更一般地说，你的工作规则是什么？您对“先修复错误”有多严格？所有这些？
我已经标记了这个社区wiki，我会将我的帖子作为一个单独的答案发布。 （所以如果你认为他们很糟糕，你可以投票给他们：）
答案 0 :(得分：74)
我们使用这样的东西（实际上意义有点模糊）：
<强> 1。阻止程序 - 保留用于灾难性故障 - 异常，崩溃，损坏数据等，（a）阻止某人完成任务，（b）没有解决方法。这些应该是非常罕见的。必须立即（当天）修复它们并将其部署为修补程序。
<强> 2。严重 - 这些可能涉及未处理的异常或仅在某些特定条件下发生的其他“严重”错误（即可以使用实际的解决方法）。解决时间没有硬性限制，但应在一周内修复（修补程序），并且必须在下一版本中修复。它们之间的关键区别（1）和（2）不是严重性或影响，而是存在解决方法。
第3。主要 - 通常为性能问题保留。任何严重妨碍生产力但实际上并未妨碍工作的事情。修复下一个版本。
<强> 4。轻微 - 这些都是“麻烦”的错误。未应用默认设置，显示为可编辑的只读字段（反之亦然），UI中的竞争条件，误导性错误消息等。如果没有更高优先级的问题，请修复此版本，否则以下版本。
<强> 5。琐碎 - 化妆品问题。滚动条出现在他们不应该的位置，窗口不记得保存的大小/位置，拼写错误，标签的最后一个字符被切断，这种事情。如果修复只需要几分钟而且有人同时在相同的屏幕/功能上工作，它们将被修复，否则，可能永远不会。不保证这些。
<强> 2。设计错误 - 就像在，我们误解了规范，而且功能根本没有做它应该做的事情，或者它做得太差，以至于它无法使用。这是更改请求的最高优先级，但它仍然是优先级2 - 更改请求永远不会优先于阻止程序错误。这些必须在下一个版本中修复。
第3。重要 - 显着节省成本（或利润潜力，取决于软件类型），主要性能增强，任何可使应用更棒的。或管理层升级到此级别的任何内容 - 这是功能的最高升级级别。预计将进入下一个版本，但如果出现时间或现金紧缩，可能会被削减。
<强> 4。正常 - 基本上是很多人想要的东西（或者一个VIP想要的东西），并且它的基本原理是明确和合理的，但没有什么特别之处可以保证它优先于任何其他的运行 - 磨坊的要求。轻微的性能调整，添加此字段或此按钮或此报告，使这种排序为数字而不是按字母顺序排列，这种事情。这些将被分配到下一个版本，但如果出现任何延迟，它们将首先被删除。
<强> 5。低影响 - 布局更改，措辞更改，可能与基线要求相冲突的更改，可能需要数月才能实现的天空特征等等。除非我们自动将其分配给将来的版本'不再做任何更重要的事情（从未......）。通常当下一个版本发布时，随着更重要的请求堆积起来，这些版本将被推迟到更进一步的版本。
<强> 6。可选 - 我们实际上调用它是可选的（我认为它正式是“时间允许”），但这就是它的本质。通常保留用于两类更改：（a）我们知道的愚蠢请求会使大多数人烦恼（“每次用户尝试单击此按钮时显示确认对话框”），以及（b）我们可以内部构思的功能成本合理地高于官方要求。未分配给任何版本。
答案 1 :(得分：6)
我相信Eric Sink的My life as a Code Economist属于这里。其实质是：根据严重性，频率，成本和风险确定错误的优先级。不要修复每个错误，而是列出一些不太严重的错误并在你进行时修复它们。
答案 2 :(得分：5)
到目前为止，我对答案没有错，但是想补充一点关于生产力的观察。如果程序员进入子系统来修复错误，那么花一些时间和精力来重新认识代码。因此，修复看起来来自该子系统的每个错误。首先使用哪个子系统以及何时移动到下一个优先级子系统，可以很好地判断。这种判断肯定受到客户支持的影响以及其他人如何分类错误的影响，但效率也非常重要。
答案 3 :(得分：5)
我的团队不仅仅按优先级对任务进行分类，我们使用三个关键标准：优先级，严重性和可见性。
优先级是指我们的开发时间表。高优先级的错误或功能是计划在当前开发周期中完成的或已在某个相对较快的日期向客户承诺的错误或功能。低优先级任务的一个示例是一个仍处于早期开发阶段的功能中的错误，并且在一段时间内不会出现在官方路线图上。
严重性是指错误的存在或功能缺失的影响（在增强请求的情况下）。可能会破坏用户数据，损坏硬件或创建永久性不可恢复情况的错误具有最高的严重性。如果公司内的另一个重要团队等待我们修复错误或添加功能，那么该任务也将具有相当高的严重性。中等严重性排名被赋予诸如性能优化之类的任务，这些任务是重要的但不是项目运行所必需的。低严重性任务是错误消息中的拼写错误或有助于使内部调试/测试更容易但最终用户不可见的功能。
可见性是指谁可以看到该错误。在启动时为每个用户崩溃软件的错误将是一个高可见性任务。依赖于特定的，不常见的配置或仅在我们（或我们的合作伙伴）实验室中看到的错误具有中等可见性。内部调试和测试功能中的错误（最终用户无法遇到）具有最低的可见性。
对于每个传入的错误，增强请求或计划的功能/新开发，我们将优先级，严重性和可见性（缩写为P / S / V）值分配在1到5之间（其中5为最高）。通常，我们通过将三个值的总和（松散地，它是模糊逻辑系统）对“待办事项”列表进行排序来优先考虑我们的工作。 P / S / V为2/5/4的错误报告将在具有值5/1/3的新开发任务之前进行，但仅在具有值5/2/5的增强请求之后进行。
这（当然）是一门不精确的科学，系统总会有例外。有时处理较低级别的增强请求是优选的，如果它也可以解决更高级别的错误。对于排名为X的所有任务，排名X的错误通常会在排名X的增强之前得到解决。我们通常还会考虑所有排名都有+/- 1误差范围。
这个系统的一个缺点是它没有考虑任务在待办事项列表上的时间长度（一些旧的陈旧任务可以长时间闲置）或估计的长度任务完成所需的时间。幸运的是，我们的团队中有足够多的人，我们可以负担得起让某人花一天时间清理一些低级别的任务。
答案 4 :(得分：4)
我们的优先级系统始终位于当前软件迭代的上下文中，其工作原理如下。
至于“先修复错误”的警告。我们通常这样做，但也适用常识。并非所有错误都是平等创建的。如果系统在超过10,000年时严重格式化日期，那么推回功能以获得修复肯定并不重要。如果它错误地计算了某人的银行余额，那么它就会成为列表的顶部。
答案 5 :(得分：3)
在我们的地方：
我们使用“fix for”和优先级（按此顺序）给出错误和功能请求建议的解决顺序。
我们的优先事项是：
“分配优先级”最高，默认为轻松提交。负责开发人员需要做的最少是评估严重程度，看看他是否可以重现它，解决重复等问题。
大多数情况下，开发人员在他们自己的部分产品中都有足够的参与，他们可能会在评估新案例之前修复showstopepr。一般来说，我希望相应的经理在怀疑的情况下将这些命令放在一个明确的顺序中 - 这不是不是程序员的工作，但他们通常都很擅长。
我们使用FogBugz，顺便说一句。
答案 6 :(得分：3)
我们公司正式有一个严格的“修复错误，然后编写新功能”政策。然而，实际上似乎支持它的少数人也是在新发展方面最重要的人。花了一段时间，但我们意识到修复一个让一个客户满意的错误并不比添加一个让100个客户满意的新功能重要。
此外，我们的产品现在已经很大了，真正修复所有错误需要数年时间，这对于完全缺乏新功能/版本而言是不可接受的时间跨度。
此时，由于我们有一个非常不错的bugtracker和崩溃转储系统，几乎所有容易出错的错误都得到修复，我们已经认识到剩下的很多都很烦人，但没有显示-stoppers。
答案 7 :(得分：2)
Apropos“首先修复bug”，我们发现我们的客户为快速修复（这会破坏系统稳定性）推动我们很多，我们无法推迟，所以我们最终决定采用“冒烟”系统。任何快速修复（即未经适当审查或测试 - 只是推出以满足客户）都算作“冒烟”错误。如果打开的烟雾虫数量增加到5以上，我们就会限制并启动减速驱动器。此外，我们公开宣布，一旦发生这种情况我们就不会做快速修复，并让我们的客户参与整个过程。
不完全回答您的问题，但该方法对我们有用。
答案 8 :(得分：1)
我个人总是首先尝试处理错误，然后作为稳定产品的增强功能更容易实现增强功能。现在它不是一个完美的世界，所以并非总能发生，但这是我达到的目标
答案 9 :(得分：1)
可以在不到2小时内修复的错误，然后是需要更多时间的错误。