您的错误跟踪工作流程如此独特吗？

Question

我们目前正在使用Mantis作为我们的错误跟踪器，我们对此非常厌倦。开发人员需要更多的SVN集成，客户希望系统更易于使用。

因此，我们正在寻找一个新的bugtracker，目前我们正在寻找Redmine。但是，在默认设置中，它与我们所需的工作流程不匹配，或者至少不比Mantis好。

我们有以下工作流程，并希望找到匹配它的bugtracker。

• 报告错误（通常由客户报告），并被视为“新”。 这些错误会定期进行审核并确认（这是一个错误）或标记为功能（客户经常需要付费）并延迟到财务部分计算完毕。
• 然后由开发人员分配和处理错误
• 完成后，它被标记为“准备审核”（由另一位开发者提供）
• 审核时标记为“已审核”
• 当标记为“已审核”时，原始开发人员将新代码放置在暂存环境中，并将错误标记为“可以进行测试”（由bug报告者提供）
• bug-reporter将错误标记为“已解决”
• 投放生产时，bug-reporter关闭了错误

当然，特别是在早期阶段，通常需要反馈。我们正在寻找一种方法来区分谁需要采取下一步措施，以及将错误分配给谁（开发人员）。我们还希望客户使用一个简单的gui - 要求他们将受让人从他们自己的帐户更改为开发人员，或者甚至更难：第三方（想想：设计机构）有太多要求使用常规贵的。 gui应该告诉他们该做什么以及有哪些选择 - 不要搜索它们。

有没有人对使用这种方式的bugtracker有任何经验？我们的工作流程真的很糟糕吗？你如何确保每个参与者都了解bug的位置，以及谁需要采取哪一步？

Answer 1

去年我们遇到了同样的问题，我们发现对我们来说最好的解决方案是Jira。 尊重我们的工作流程比您的工作流程更加强大和复杂。

Answer 2

我们使用Redmine与电子邮件集成管理的工作流程几乎相同。客户直接将错误记录到Redmine中。通知来自项目经理，他决定哪个开发人员可以处理错误。 开发人员打开错误并将其置于调查状态。 如果它是一个特征，他回复它说明原因并将其置于Replied状态，然后再重新访问。 如果它是一个bug，那么开发人员就会开始开发。在此之前，他将错误置于Coding状态。 编码结束后，他将错误的状态更改为Review和同行评审。 如果有任何返工，则开发人员将状态更改为返工。 一切正常后，开发人员将状态更改为已交付。 QA验证错误，最后通过将状态更改为Closed来关闭它。

我们已经在Redmine中定义了所有这些工作流程，并且使用它非常有效，没有任何麻烦。电子邮件集成使项目经理可以轻松跟踪任何错误何时更改其状态。 您还可以创建和保存自定义报告，这也是一个很酷的功能。

Answer 3

我一直在使用Trac进行小型个人项目，在工作中我们使用了Bugzilla。

您描述的工作流程听起来像是Red Hat如何使用Bugzilla。

Answer 4

正如其他人所说，Jira非常好。我特别喜欢它创建自定义问题workflow

的能力