Last year we had the same problem, and we figured out that the best solution for us was Jira. With respect our workflow is more robust and complicated than yours.
We have pretty much the same kind of workflow which we are managing using Redmine with email integration. The customer logs bugs into Redmine directly. Notification comes to the project manager who decides which developer can work on the bug. The developer opens the bug and puts it into the Investigating state. If its a feature, he replies to it stating the reasons and puts it into the Replied state which is then revisited later. If its a bug, then the developer starts development. Before this he puts the bug in Coding state. Once the coding is over, he changes the state of bug as Review and the peer reviews happen. If there is any rework, then the developer changes the state to Rework. Once everything is ok, the developer changes the state to Delivered. The QA verifies the bug and the finally closes it by changing the state to Closed.
We've defined all of this workflow in Redmine and have been using this pretty effectively without any hassles. Email integration makes everything easy for the project manager to track whenever any bug changes its state. You can also create and save custom reports, which is a cool feature as well.
发布评论
评论（4）
去年我们遇到了同样的问题，我们发现对我们来说最好的解决方案是 Jira。
恕我直言，我们的工作流程比您的更强大、更复杂。
Last year we had the same problem, and we figured out that the best solution for us was Jira.
With respect our workflow is more robust and complicated than yours.
我们的工作流程与使用 Redmine 和电子邮件集成进行管理的工作流程几乎相同。 客户直接将错误记录到Redmine中。 项目经理收到通知后决定哪个开发人员可以处理该错误。
开发人员打开错误并将其置于调查状态。
如果这是一个功能，他会回复并说明原因，并将其置于“已回复”状态，稍后再重新访问。
如果是错误，那么开发人员就开始开发。 在此之前，他将 bug 置于编码状态。
编码完成后，他会在评审和同行评审时更改错误的状态。
如果有任何返工，那么开发人员会将状态更改为返工。
一旦一切正常，开发人员会将状态更改为“已交付”。
QA 验证错误并最终通过将状态更改为“已关闭”来关闭它。
我们已经在 Redmine 中定义了所有这些工作流程，并且一直非常有效地使用它，没有任何麻烦。 电子邮件集成使项目经理可以轻松跟踪任何错误状态的变化。
您还可以创建并保存自定义报告，这也是一个很酷的功能。
We have pretty much the same kind of workflow which we are managing using Redmine with email integration. The customer logs bugs into Redmine directly. Notification comes to the project manager who decides which developer can work on the bug.
The developer opens the bug and puts it into the Investigating state.
If its a feature, he replies to it stating the reasons and puts it into the Replied state which is then revisited later.
If its a bug, then the developer starts development. Before this he puts the bug in Coding state.
Once the coding is over, he changes the state of bug as Review and the peer reviews happen.
If there is any rework, then the developer changes the state to Rework.
Once everything is ok, the developer changes the state to Delivered.
The QA verifies the bug and the finally closes it by changing the state to Closed.
We've defined all of this workflow in Redmine and have been using this pretty effectively without any hassles. Email integration makes everything easy for the project manager to track whenever any bug changes its state.
You can also create and save custom reports, which is a cool feature as well.
我一直在一个小型个人项目中使用 Trac，在工作中我们使用 Bugzilla 来实现此目的。
您描述的工作流程听起来也类似于 Red Hat 如何利用 Bugzilla。
I've been using Trac for a small personal project, and at work we used Bugzilla for this.
The workflow you described also sounds like how Red Hat utilizes Bugzilla.
正如其他人所说，Jira 非常好。 我特别喜欢它创建自定义问题工作流程的能力
As other's have said, Jira is very good. I especially like its ability to create a custom issue workflow