错误与增强与新功能的对比

Question

在计划和优先考虑发行版中包含的内容时，您是否区分错误，功能增强功能和新功能？

例如，不要错误总是优先 - 你对新功能的工作之前解决所有已知的错误？您是否使用正式系统比较您的积压中每次更改的成本与价值？如果是这样，你是否使用相同的公式比较错误和功能？商业软件与开源软件还是企业内部软件不同？

编辑：一些很好的回复 - 谢谢。虽然我有一种先入为主的观点，即您需要对错误，功能和增强功能进行相同的处理，并根据每项成本/好处来选择工作，但我认为现实情况取决于您的情况。

Answer 1

这种选择被称为分流，从急诊部门，他们必须决定谁得到治疗（有时，不幸的是，谁的生活和死亡）医院的术语。

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

挑选那些以最低成本获得最大收益的产品。你的目标是最大的降价。资源是有限的，欲望不是，资本主义的长期问题:-)

修复一个只有一个客户经历过的错误是毫无意义的，这个客户永远不会抛弃更多的重复业务，如果这意味着一个功能可以销售数百个同时丢弃副本。

对于它的价值，我们的公司有要求的变化，客户基本上可以投票选出他们希望在我们的产品的未来版本，看看有什么数据库。在数据库中实际创建这些请求的更改仅限于销售人员，因为我们不希望所有类型的请求都显示出来，而没有经过评估和与客户讨论至少一点点。

此外，我们会定期与我们的最大客户（产生的收入）进行比较，以确定应添加哪些功能（他们也可以自由提出自己的需求，也可以输入数据库 - 显然投票权力取决于收入）。

这是我们的错误系统完全分离，虽然常常错误是提出这实际上是新的功能需求，他们正在跨运到新功能的数据库。有可能这种情况甚至可能发生在被认为影响较小或有适当解决方法的实际错误上。

Answer 2

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

Answer 3

我们总是看看修复bug的成本与其造成的问题。有时候，每个错误都进行了适当的分类，造成根源，然后修复，这是不值得的。次特定的增强或新功能

大量被资助或至少强烈推荐由大/良好的客户出现，这样也影响的事项。

Answer 4

区分，是的。

错误优先，是的。

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

是的，80/20规则。

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

是的，所有商业，开源和内部应用程序都有自己的办法。

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

希望有帮助！

Answer 5

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

严重的是，用户组正在付费维护或考虑购买。

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

他们建议修复，要求提供新功能。

我们告诉他们关于发展的路线图：因为我们想要对产品做的事情， 由于时代变化，设计思路。法规变更。

如果每个客户都说“我们真的需要功能X”，那么它会接下来。

如果他们说“你们需要修复我在那里点击的错误，那么它不会做错误：”然后那个错误得到修复。

商业软件：与客户投票的变化。 当然，我们会根据建议选择他们的选择：公司有其他想法的东西。

Answer 6

你必须从错误的角度来看它。展示瓶塞的缺陷始终是首要任务。如果人们无法登录或者无法输入或调整关键数据等，那么这些数据必须优先于所有内容。

重要性较低的错误可以根据需要进行处理。我们可能会延迟修复一个bug，因为我们知道我们正在为下一周的增强工作做好准备。然后，错误修复将与增强功能一起进行。如果它很小，我们可能会延迟修复这个bug，并且计划的增强将很快完成代码。主要的增强可能会优先于修复界面上的一些拼写错误。客户可能会告诉我们，这个其他项目更加关键，并且在修复这个bug之前做到这一点（我们的软件是客户高度定制的）。这一切都取决于错过的影响以及现有的计划和企业政治，一旦你超过了展会的限制。一个困扰大客户的错误可能会被优先考虑，即使它对开发者来说似乎很小。如果CEO现在想要修复它，与其余工作量相比似乎并不重要，它现在已经得到修复。

Answer 7

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

如果您对错误从未被修复的想法没有问题，可以通过所有方式对它进行分类并添加功能。

Answer 8

错误？我们没有错误。他们是无证的功能。

对于我们来说，选择总是基于商业决策，作为开发者，除了提供我的意见之外，我没有任何意见。通常情况下，功能会胜过bug，因为增加功能“出现”到业务领域，例如正在取得进展，而我一年前可能修复的错误仍然存​​在，因为业务部门只想看到“进度”。如果允许，分类很好，但在企业环境中常常会出现明显的结果，而不是功能。

Answer 9

有一件事迄今为止没有提到bug的严重性。如果这个bug的严重程度很高（比如崩溃，无法通过持续时间测试，并且肯定取决于您使用的是哪种应用程序），那么在添加新功能之前，您应该首先修复它。

Answer 10

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