问题跟踪优先事项和政策
在“新旧事物”问题的触发下，我想问一下：
你如何设置bug跟踪器的优先级？ 更普遍的是，你有什么规则来处理它们？ 你有多“严格地修复bug”？ 他们全部？
我已经标记了这个社区维基，我将作为一个单独的答案张贴我的。 （所以你可以投下他们，如果你认为他们吸:)
我们用这样的东西（实际上意义有点模糊）：
错误：
1.阻止器 – 为灾难性故障保留 – 例外，崩溃，损坏的数据等（a）阻止某人完成他们的任务，和（b）没有解决方法。 这些应该是非常罕见的。 必须立即（当天）修复它们并将其作为修补程序进行部署。
2.严重 – 这些可能是指未经处理的exception或仅在某些特定条件下才会发生的其他“严重”错误（即可用的实用解决方法）。 没有parsing时间的硬性限制，但应该在一周内（修补程序）修复，并且必须在下一个版本中修复。 （1）和（2）之间的关键区别不是严重性或影响，而是解决方法的存在 。
主要 – 通常保留为性能问题。 任何严重阻碍生产力的事情，实际上并不妨碍工作的完成。 下一个版本修复。
4.轻微 – 这是“滋扰”的错误。 未应用的默认设置，显示为可编辑的只读字段（反之亦然），UI中的争用条件，误导性错误消息等。如果没有更高优先级的问题，则修复此版本，否则下面的发布。
5.微不足道的 – 美容问题。 滚动条出现在不应该的地方，窗口不记得保存的大小/位置，拼写错误，标签的最后一个字符被切断，这种事情。 如果修复只需要几分钟，而且有人在同一屏幕/function上同时工作，那么他们将得到修复，否则，可能永远不会。 没有保证是附加到这些。
更改请求（function）
2.devise错误 – 正如我们误解了规范，这个function并没有做它应该做的事情，或者做得太差，以至于无法使用。 这是更改请求的最高优先级，但仍然是优先级2 – 更改请求永远不会优先于阻塞程序错误。 这些必须在下一个版本中修复。
3.重要 – 显着的成本节省（或盈利潜力，取决于软件的种类），主要的性能增强，任何将使应用程序更真棒 。 或者由pipe理层升级到这个级别 – 这是一个function的最高升级级别。 预计将进入下一个版本，但可能在时间或现金紧缩的情况下被切断。
4.正常 – 基本上是很多人想要的东西（或者一个VIP想要的），其基本原理是清楚而合理的，但没有什么特别的东西可以保证它优先于其他任何先发制人，工厂要求。 微小的性能调整，添加此字段或此button或此报表，使这种sorting而不是按字母顺序，这种事情。 这些被分配到下一个版本，但是如果有任何延迟出现，则是第一个被删除的版本。
5.低影响 – 布局更改，措辞更改，可能与基准要求相冲突的变化，可能需要几个月才能实现的天空特征等。除非我们能够自动将其分配到未来版本没有在更重要的事情上工作（这是…从来没有）。 通常当下一个版本发布的时候，随着更多重要的请求的堆积，这些版本将会被推迟到更多版本。
6.可选 – 我们实际上并没有把它称为可选的（我认为它正式是“时间允许”），但是这几乎就是这样。 通常保留两种types的变化：（a）我们知道的愚蠢的请求只会让大多数人恼火（“每次用户尝试点击这个button时显示一个确认对话框”）;（b）我们可以在内部构想的特征高于官方要求的成本理由。 未分配给任何发行版。
我相信Eric Sink 作为一名代码经济学家的生活就属于这里。 它的本质是：根据严重性，频率，成本和风险优先考虑错误。 不要修复所有的错误，而应该列出一些不太严重的错误，并且随着时间的推移修复错误。
到目前为止，我对这个答案没有任何错误，但是想补充一下关于生产力的观察。 如果一个程序员正在进入一个子系统来修复一个bug，那么花费一些时间和精力重新获得代码。 因此，修复每个似乎来自该子系统的错误。 首先要对哪个子系统进行工作，以及何时移到下一个优先级子系统，做出正确的判断。 这个判断肯定是受到客户支持的想法和其他人如何分类错误的影响，但效率也是非常重要的。
我的团队不会按照优先级对任务进行分类，我们使用三个关键标准： 优先级 ， 严重性和可见性 。
优先级是指我们的发展计划。 高优先级的错误或特征是计划在当前开发周期中完成的，或者在某个相对快的date已经被许诺给客户。 一个低优先级任务的例子是一个function上的错误，这个function还处于早期开发阶段，并且在一段时间内不会出现在官方的路线图上。
严重性是指错误存在或function缺失（在增强请求的情况下）的影响。 可能导致用户数据错误，损坏硬件或造成永久不可恢复的错误的错误程度最高。 如果公司内部的另一个重要团队等待着我们修复一个bug或添加一个function，那么这个任务也会有相当高的严重程度。 中等严重性排名被赋予诸如性能优化之类的任务，这些重要性对于项目来说是重要的但不是必需的。 低严重性的任务就像错误消息中的拼写错误或者function，这些function有助于使内部debugging/testing更容易，但对最终用户不可见。
可见性是指谁可以看到这个错误。 一旦启动，每个用户的软件都会崩溃，这是一个高度可见的任务。 依赖于特定的，不常见的configuration或仅在我们（或我们的合作伙伴）实验室中看到的错误具有中等可见性。 内部debugging和testingfunction中的错误（并且不能被最终用户遇到）具有最低的可见性。
对于每个传入的错误，增强请求或计划的特性/新的开发，我们都会在1和5之间（其中5为最高）指定优先级，严重性和可见性（缩写为P / S / V）值。 一般来说，我们通过三个值（松散的，这是一个模糊的逻辑系统）的总和来排列“待办事项”清单，以此来优先考虑我们的工作。 P / S / V为2/5/4的错误报告将在值为5/1/3的新开发任务之前进行，但是仅在具有值5/2/5的增强请求之后。
这当然是一个不准确的科学，系统总是有例外。 有时候处理一个较低级别的增强请求，如果它也可以解决更高级别的错误，那么它是最好的。 对于排名为X所有任务，排名为X的缺陷通常在排名X的增强之前处理。 我们通常也会考虑所有的排名都有+/- 1的误差。
这个系统的一个缺点是它没有考虑任务在待办事项列表上的时间长度（一些旧的，陈旧的任务可能会长时间滞留）或者估计的时间长度任务将完成。 幸运的是，我们队中有足够多的人，我们可以让人花费一天的时间清理一些低级别的任务。
正式的，我们公司有严格的“先修补，再写新function”的方针。 但是，实际上似乎坚持的人也是新发展中最重要的人。 这花了一段时间，但是我们意识到修复一个能够让一个客户开心的错误并不比添加一个能让100个客户开心的新function要重要。
另外，我们的产品到目前为止还是很大的，要真正解决所有的错误需要花费很多年的时间，对于完全缺乏新function/版本来说，这是不可接受的时间跨度。
在这一点上，由于我们有一个非常体面的错误跟踪和崩溃转储系统，几乎所有的简单的错误已经修复，我们已经认识到，其余许多烦人的概念，但没有显示停止。
我们的优先级系统总是在当前的软件迭代的情况下，工作如下。
- 优先级1 – 除了这个项目之外的所有工作都停止，我们在testing后立即发布修复程序。
- 优先级2 – 如果没有解决这个问题，下一个版本将不会出去。
- 优先级3 – 在这个版本中真的很希望，但是如果我们用完了，我们会推迟它。
- 优先级4 – 我们真的不希望在这个版本中达到这个目标，但是如果你没有完成任务，那就去做吧。
- 优先级5 – 不要处理它。
至于“修补臭虫第一”的告诫。 我们一般这样做，但也应用常识。 不是所有的错误都是平等的创造的。 如果系统在过了一万年的时候严重格式化了date，那么推回function来修复这个问题当然并不重要。如果它错误地计算了某个人的银行余额，那么它就会到达列表的顶部。
在我们的地方：
我们使用“修复”和优先级（按此顺序）给错误和function请求推荐的解决顺序。
我们的重点是：
- 分配优先级 – 这是最高和默认。
- 紧急！ 紧急！ – 这是为了“放弃其他所有”的情况下，有点愚蠢的名字被选中，使人们不要滥用它。 到目前为止，运作良好。
- Showstopper – 这个阻止某人高效地工作，防止演示一些function，或类似的。
- 必要的 – 它是分配给下一个版本所必需的。 我们承诺的或者是客户特定项目里程碑的一部分
- 预期 – 应该在下一个版本，但可以被删除的东西。
- 如果时间有点儿固定的话 ，就定下来，因为“当我们有很多时间的时候这样做”就是“不要屏住呼吸”的地方。
“分配优先级”是最高的，默认为便于提交。 负责的开发人员最less需要评估的严重性，看他是否可以重现，解决重复等
大多数情况下，开发者在他们的产品中涉及到足够多的东西，他们可以自己弄清楚订单，在评估一个新的案例之前，他可能会定下一个展示台。 一般来说，如果有疑问的话，我希望各自的pipe理者能够把这些安排成一个明确的顺序 – 这不是程序员的工作，但是他们通常很擅长。
我们使用FogBugz，顺便说一句。
Apropos“先修复错误”，我们发现我们的客户推动我们做了很多快速修复（这使系统不稳定），我们不能推回来，所以我们最终决定build立一个“烟雾”系统。 任何快速修复（即没有正确的审查或testing – 只是推出来满足客户）作为一个“烟雾”的错误。 如果开放式烟雾的数量增加到5以上，我们将夹紧并开始减速驱动。 另外，我们公开宣布，一旦发生这种情况，我们不会做出快速修复，并将整个stream程与客户联系起来。
不完全回答你的问题，但这种方法certificate对我们有用。
我个人试图总是先处理错误，然后作为一个稳定的产品的增强更容易实现增强。现在它不是一个完美的世界，所以并不总是发生，但这是我的目标达成。
可以在不到2小时内修复的错误，那些需要更多时间的错误。
