在计划和优先考虑发布的内容时，您是否区分错误、功能增强和新功能？
例如，错误是否总是优先考虑——在开始新功能之前修复所有已知错误？您是否使用正式系统来比较待办列表中每个更改的成本与价值？如果是这样，您是否使用相同的公式比较错误和功能？对于商业软件、开源软件和内部企业软件，情况是否不同？
编辑：非常感谢大家的回答。虽然我之前的看法是需要将错误、功能增强和新功能视为同等重要，根据每个更改的成本/效益选择工作，但实际情况可能因情况而异。
10个回答
20
这个选择被称为分流，它源于医院急诊部门的术语，他们在那里必须决定谁应该接受治疗（有时候，不幸的是，决定谁生谁死）。
与所有商业决策一样，这是一个成本/效益问题。修复错误或添加功能的好处是什么？它将花费多少（包括不做其他事情的机会成本）？
选择那些收益最大、成本最小的。你要追求的是最大的性价比。资源是有限的，欲望是无限的，这是资本主义的永恒难题 :-)
如果解决一个bug只涉及一个客户，并且如果这意味着同时放弃了可以销售数百份副本的功能，那就没有意义。
值得一提的是，我们公司有一个请求更改的数据库，客户可以在其中投票以表达他们希望在我们产品的即将推出的版本中看到的内容。这些请求更改的实际创建工作由销售团队负责，因为我们不希望所有请求都出现在数据库中，而没有经过评估并至少与客户进行了一点讨论。
此外，我们定期与营收最高的客户（按照创造的收入计算）接洽，以确定应该添加哪些功能（他们也可以提出自己的需求，这些需求也会被输入数据库中 - 显然投票权取决于收入大小）。
这与我们的漏洞系统完全分开，尽管经常会提出实际上是新功能请求的漏洞，它们会被转移到新功能数据库中。对于被认为影响不大或已有适当解决方法的实际漏洞，这种情况甚至可能发生。
- paxdiablo
3
3除了最后一句话要小心以外，我同意你所说的一切。如果你不为那个客户修复错误，他开始对人们谈论你，那么你可能会开始失去生意。 - Martin
1这是一个很好的观点（也是不修复漏洞可能成本的一部分）。 - paxdiablo
我会让社区选择“最佳答案”。 - Ed Schembor
4
我们向用户提问。
我们有一个小众产品和少量用户群体。
认真地说，用户组正在支付维护费用或考虑购买。
因此，我们询问他们想要什么。
他们建议修复问题，要求新功能。
我们告诉他们开发路线图：因为我们有一些想要对产品进行的事情，随着时间的推移，设计理念会发生变化。法规也会发生变化。
如果每个客户都说“我们真的需要X功能”：那么它将紧接着实现。
如果他们说“您需要修复我点击那里时无法执行某项操作的错误”，那么该错误将被修复。
商业软件：由客户投票决定更改。
当然，我们会考虑他们的选择：公司还有其他事情要考虑。
认真地说，用户组正在支付维护费用或考虑购买。
因此，我们询问他们想要什么。
他们建议修复问题，要求新功能。
我们告诉他们开发路线图：因为我们有一些想要对产品进行的事情，随着时间的推移，设计理念会发生变化。法规也会发生变化。
如果每个客户都说“我们真的需要X功能”：那么它将紧接着实现。
如果他们说“您需要修复我点击那里时无法执行某项操作的错误”，那么该错误将被修复。
商业软件：由客户投票决定更改。
当然，我们会考虑他们的选择：公司还有其他事情要考虑。
- Tim Williscroft
3
我们总是会权衡修复错误的成本和由此引起的问题。有时，对每个错误进行正确分类、追根溯源并修复就不值得了。
很多时候，一个特定的增强或新功能是由一个大型/好的客户资助或至少强烈推荐发生，这也会影响事情的发展。
- Coxy
2
我认为，在所有情况下，修复bug应该始终优先于增强和新功能。即使作为开发人员，你并不太在意某个特定的bug，但当你的小错误弹出时，某个地方的某个人的一天都会被毁掉。
- Fiarr
1
3与其应对每天发生一次、可以通过一个 30 秒的解决方案解决的错误，不如实施一个每周可以节省 2 小时工作时间的改进方案，我持有异议。 - Martin
1
区分，是的。
错误优先级最高，是的。
所有关键/正常优先级及以上的错误首先处理，是的。
是的，80/20法则。
不，错误和功能必须以不同的方式处理，因为它们的权重不同。
是的，所有商业、开源和内部应用程序都有自己的做事方式。
例如，FogBugz使用基于证据的调度，是我所知道的唯一使用该公式的管理/跟踪工具。
希望这有所帮助！
- Robert French
1
你必须从一个bug的角度来看待它。一个严重的bug总是第一优先级。如果人们无法登录或关键数据无法输入或调整等等，那么这必须比其他任何事情都要重要。
较不重要的bug可以随需求进行处理。我们可能会延迟修复一个bug，因为我们知道下周我们将在该部分进行增强。然后bug修复将与增强一起进行。如果一个bug很小而计划中的增强将很快完全替换代码，我们可能会推迟修复该bug。如果一个重大增强优先于界面上的某些拼写错误修复，一个主要客户可能会告诉我们这个项目更为重要，要在修复bug之前完成它（我们的软件由客户高度定制）。一旦解决了严重问题，一切都取决于bug的影响以及现有计划和公司政策。即使对开发人员来说它似乎不重要，一个阻碍重要客户的bug可能会优先考虑。如果CEO希望立即修复它，那么与工作负载的其他部分相比，它的重要性如何都无关紧要，它会立即得到修复。
- HLGEM
0
对于程序中的漏洞，解决方法很简单：在编写任何新代码之前，先修复它。为什么呢？因为你添加的代码越多，现有漏洞就会变得越难以发现。
如果你可以接受永远不修复漏洞的想法，那么请将其分类并添加功能。
- kyoryu
0
有 Bug 吗？我们没有 Bug。它们只是未记录的功能。
对我们来说，选择总是基于业务决策，作为开发人员，我除了提供自己的意见之外，没有其他的参与。往往情况下，功能胜过 Bug，因为添加功能“看起来”像是在进步，而我一年前就可以修复的 Bug 仍然存在，因为业务方只想看到“进展”。如果你被允许进行分类，那么这是很好的，但在企业环境中，通常关注的是可见的结果，而不是功能性。
- BBlake
0
到目前为止，有一件事情还没有提到，那就是这个 bug 的严重程度。如果这个 bug 的严重程度很高（比如崩溃、无法通过持续测试等，当然这也取决于你所开发的应用程序类型），那么在添加新功能之前，你应该优先修复它。
- pierrotlefou
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接