错误何时成为功能请求？

问题描述：

什么时候一个非重要的bug成为一个功能，或者如果一个bug始终保持为一个bug？错误何时成为功能请求？

例如。是否应该有适当的时效限制。

例如，如果您的定义法规为1年。该错误在18个月前推出，但今天才被发现。如果该错误被定义为“现在这个系统是如何工作的”并且改变它，它应该被放置在积压的优先级上。

取决于它对用户的影响程度以及该修补程序的用处。（或者发现者的年龄有多高）。这是您需要升级到业务中产品所有者的决定。 – Rup 2010-08-10 17:21:02

让我想起以前N64天的这个“bug”：http://blogs.msdn.com/b/shawnhar/archive/2009/12/29/bug-or-feature.aspx – eldarerathis 2010-08-10 17:21:29

这个问题应该是社区维基，因为它开放的性质。 – kurast 2010-08-10 17:38:24

答

“错误”通常被视为阻碍某些执行的障碍，通常是由于创建不可行的情况。除此之外，成功执行的另一种方式只能在不符合给定规范的情况下标记为错误。如果它变得可以接受，那么规范就会改变，因此错误不再存在。

答

您的问题似乎意味着错误修复程序没有得到优先级。我认为优先次序应该经常发生，并且这些特征和错误应该被同等对待为“问题”。错误通常比新功能的优先级高，但这不应该是一个自动决定。

我喜欢这个想法，首先解决错误，然后添加新的错误:-) 首先纠正错误降低了新功能建立在错误修复后可能破坏的错误软件上的风险。 – Kwebble 2010-08-10 19:01:50

@Kwebble：你如何处理计划中的新功能完全消除修复某个bug的需求？你是否首先修正了错误，违反了原则？如果该功能花费的时间比修复该错误所花费的时间更少？ – 2010-08-10 23:41:18

如果该功能消除了修复错误的需要，我将其视为解决错误的另一种方式。 – Kwebble 2010-08-11 19:47:35

答

我相信这个错误仍然是一个错误，无论它在项目生命周期中何时被发现，都应该这样定义和记录。请记住，记录一个错误并不会使它成为一个功能：D

答

您的开发人员是否会给您“这不是一个错误，它是一个功能！”线？

严重的是，一个“错误”会在应用程序中违反项目规范。除非规格发生变化，否则我不会指望一个错误过期。

答

当您更改规格以响应它时。