错误与增强与新功能

Question

在规划和优先处理发布中包含的内容时，您是否区分错误，功能增强和新功能？

例如，错误总是优先考虑 - 在处理新功能之前，您是否修复了所有已知的错误？您是否使用正式系统来比较待办事项中每项变更的成本与价值？如果是这样，你是否使用相同的公式比较错误和功能？商业软件与开源与内部企业软件的区别是不同的？

编辑：一些很棒的回复 - 谢谢。虽然我有一个先入为主的观点，你需要对错误，功能，增强功能进行同样的处理，并根据每个的成本/优势选择工作，但我认为现实情况是这取决于你的情况。

Answer 1

这种选择被称为分诊，这是一个来自医院急诊科的术语，他们必须决定谁接受治疗（有时，不幸的是，他们的生命和死亡）。

与所有业务决策一样，这是一个成本/收益问题。修复错误或添加功能有什么好处？它会花多少钱（包括不做其他事情的机会成本）？

选择那些以最低成本获益最多的人。你的目标是最大的爆炸效果。资源是有限的，欲望不是，资本主义的长期问题： - ）

没有必要修复只有一个客户遇到的错误，如果这意味着在此期间会丢弃销售数百​​份副本的功能，那么他们永远不会再按照自己的方式投入更多重复业务。

对于它的价值，我们公司有一个请求更改的数据库，客户可以在这些数据库中基本上投票支持他们希望在即将推出的产品版本中看到的内容。在数据库中实际创建这些请求的更改仅限于销售人员，因为我们不希望出现所有类型的请求，而不会对客户进行评估和讨论。

此外，我们定期与我们的最大客户（产生的收入）联系，以确定应添加哪些功能（他们可以自由地建议自己的愿望，也可以输入数据库 - 显然，投票权取决于收入。）

这与我们的错误系统完全不同，尽管经常会出现错误，这些错误实际上是新的功能请求，并且它们被传送到新功能数据库。对于被认为影响较小或具有合适解决方法的真正错误，甚至可能发生这种情况。

Answer 2

我们询问用户。 我们有一个利基产品和一个小用户群。

说真的，用户组正在支付维护费用，或者考虑购买。

所以我们问他们想要什么。

他们建议修复，请求新功能。

我们告诉他们有关开发路线图的信息：因为我们有想要对产品做的事情，  由于时代的变迁，设计理念。法规变更。

如果每个客户说“我们真的需要功能X”：那么下一步就会出现。

如果他们说“你们需要修复我点击那里的错误，那就不会发生错误：”那么这个错误就会得到解决。

商业软件：客户投票支持变更。 当然，我们会根据建议做出选择：公司还有其他正在考虑的事情。

Answer 3

我们总是关注修复bug的成本与由此引起的问题。有时候，让每一个错误正确地进行分类，根本导致然后修复是不值得的。

很多时候，特定的增强功能或新功能正在被大型/优质客户资助或至少强烈推荐，这也会影响事宜。

Answer 4

在所有情况下，我都认为错误修复应始终在增强功能和新功能之前进行。即使特定的错误并没有像开发人员那样困扰你，但是当你的小错误弹出时，某个地方的某个人正在毁掉他们的一天。

Answer 5

区分，是的。

错误优先，是的。

所有关键/正常优先级以及首先是错误，是的。

是的，80/20规则。

不，错误和功能必须区别对待，因为它们的权重不同。

是的，所有商业，开源和内部应用程序都有自己的做事方式。

例如，FogBugz使用基于证据的调度，并且是我所知道的唯一使用该公式的管理/跟踪器。

希望有所帮助！

Answer 6

你必须从bug的角度来看待它。 show-stopper bug始终是第一要务。如果人们无法登录或无法输入或调整关键数据等，则必须优先于几乎所有内容。

可以根据需要使用较低重要性的错误。我们可能会延迟修复一个错误，因为我们知道我们正在处理该部分，以便下周进行增强。然后错误修复将与增强功能一起使用。我们可能会延迟修复一个bug，如果它是次要的，计划的增强将很快取代代码。一个主要的增强可能优先于修复界面上的一些拼写错误。客户可能会告诉我们这个其他项目更为关键，并且在修复错误之前要做到这一点（我们的软件是由客户高度定制的）。这一切都取决于错误的影响，现有的计划和企业政治，一旦你超过显示塞子。一个困扰主要客户端的错误可能会占用更高的优先级，即使它对开发人员来说似乎很小。如果首席执行官现在想要解决这个问题，那么与其他工作量相比，它看起来并不重要，它现在就得到了修复。

Answer 7

The Joel Test: 12 Steps to Better Code的第5点提出了一个引人注目的论点（在我看来），在编写新代码之前修复错误是个好主意。

Answer 8

对于错误，它非常简单：如果你要修复它，请在编写更多代码之前修复它。为什么？您添加的代码越多，现有的错误就越难找到。

如果您对从未修复过的bug的想法感到满意，请务必对其进行分类并添加功能。

Answer 9

错误？我们没有错误。它们是无证件的。

对我们而言，选择总是基于业务决策，作为开发人员，除了提供我应该优先考虑的意见外，我没有任何意见。通常情况下，功能会赢得错误，因为在业务领域“添加”功能就像正在取得进展一样，并且我可能在一年前修复的错误仍然存​​在，因为业务方只希望看到“进展”。如果允许的话，分类是很好的，但在企业环境中，往往是关于可见结果，而不是功能。

Answer 10

到目前为止，有一件事没有提到bug的严重性。如果错误具有高严重性（如崩溃，无法通过持续时间测试，并且肯定取决于您拥有的应用程序类型），则应在添加新功能之前先确定错误。