缺陷、增强和新功能

这种选择被称为分流,这是医院急诊科的一个术语,他们必须决定谁接受治疗(有时,不幸的是,谁生死攸关)。

如同 全部的 商业决策,这是一个成本/效益问题。修复bug或添加功能的好处是什么?成本是多少(包括不做其他事情的机会成本)?

修复一个只有一个客户体验过的bug是没有意义的,如果这意味着一个可以销售数百份拷贝的功能同时被删除,那么这个客户永远不会向你的方式抛出更多的重复业务。

值得一提的是,我们公司有一个请求变更的数据库,客户基本上可以在该数据库中投票选择他们希望在我们产品的未来版本中看到的内容。在该数据库中实际创建这些请求的更改仅限于销售人员,因为我们不希望在没有与客户进行评估和讨论的情况下显示所有类型的请求。

此外,我们定期向最大的客户(就产生的收入而言)提供列表,以确定应该添加哪些功能(他们也可以自由提出自己的愿望,这些愿望也会被输入数据库-显然,投票权在一定程度上取决于收入)。

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

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

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

我们告诉他们开发路线图:因为我们想对产品做一些事情, 由于时代的变迁,设计理念也随之改变。法规的变化。

如果每个客户都说“我们真的需要功能X”:那么接下来就是了。

如果他们说“你们需要在我点击的地方修复bug,但它不起作用”之类的话:“那个bug就会被修复。

商业软件:客户投票支持更改。

我们总是关注修复bug的成本和由此引起的问题。有时候,让每一个bug都被正确地分类、根源导致、然后修复是不值得的。

很多时候,某个特定的增强功能或新功能正被大型/优秀客户资助或至少强烈推荐,因此这也会影响到问题的解决。

是的。

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

是的,80/20规则。

不,bug和特性必须以不同的方式处理,因为它们的权重不同。

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

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

你必须从错误是什么的角度来看待它。一个“止步秀”的错误总是第一位的。如果人们无法登录,或者关键数据无法输入或调整,等等,那么这必须优先于几乎所有事情。

重要性较低的bug可以根据需要处理。我们可能会推迟修复一个bug,因为我们知道下周我们将对该部分进行增强。然后缺陷修复将与增强一起进行。如果bug很小,我们可能会延迟修复,并且计划中的增强将很快完全替换代码。一个主要的增强可能比修复界面上的一些打字错误更重要。客户可能会告诉我们,另一个项目更为关键,在修复bug之前就完成它(我们的软件是客户高度定制的)。这一切都取决于缺陷和现有计划的影响,以及一旦你超越了展会的障碍,公司政治。困扰主要客户机的bug可能具有更高的优先级,即使它对开发人员来说是次要的。如果首席执行官希望现在就把它修好,不管它与其他工作量相比显得多么不重要,现在就修好。

第5点 The Joel Test: 12 Steps to Better Code 提出令人信服的论点( )在编写新代码之前修复bug是个好主意。

对于bug,它非常简单:如果要修复它,请在编写更多代码之前修复它。为什么?添加的代码越多,发现现有bug就越困难。

如果你同意这个bug永远不会被修复的想法,那么一定要对它进行分类并添加特性。

漏洞?我们没有虫子。它们是未记录的特性。

对于我们来说,选择总是基于业务决策,作为一名开发人员,我除了就什么应该是最优先事项提供我的意见之外,没有其他意见。通常情况下,功能战胜了bug,因为向业务领域添加功能“似乎”取得了进展,而我本可以在一年前修复的bug仍然存在,因为业务方只希望看到“进展”。如果允许的话,分类是很好的,但在公司环境中,它通常是关于可见的结果,而不是功能。

到目前为止,有一件事没有提到这个bug的严重性。如果bug的严重性很高(比如崩溃,无法通过持续时间测试,这当然取决于您的应用程序类型),那么在添加新功能之前,您应该首先明确地修复它。