3

現在、バグトラッカーとして Mantis を使用していますが、これにはかなりうんざりしています。開発者はより多くの SVN 統合を望んでおり、顧客はより簡単に操作できるシステムを望んでいます。

そのため、新しいバグトラッカーを探しており、現時点では Redmine を検討しています。ただし、デフォルトの設定では、望ましいワークフローと一致しないか、少なくとも Mantis よりも優れているとは言えません。

次のワークフローがあり、それに一致するバグトラッカーが必要です。

  • バグが (多くの場合顧客によって) 報告され、「新規」と見なされます。これらのバグは定期的にレビューされ、承認されるか (バグである)、機能としてマークされ (顧客は多くの場合、料金を支払う必要があります)、金銭的な部分が解決されるまで延期されます。
  • バグは開発者によって割り当てられ、処理されます。
  • 完了すると、「レビュー準備完了」とマークされます (別の開発者による)。
  • レビューされると、「レビュー済み」としてマークされます
  • 「レビュー済み」としてマークされた場合、元の開発者は新しいコードをステージング環境に配置し、バグを「テスト準備完了」としてマークします (バグ報告者によって)。
  • バグレポーターはバグを「解決済み」としてマークします
  • 本番環境に置かれると、バグレポーターはバグをクローズします

もちろん、特に初期段階ではフィードバックが必要になることがよくあります。誰が次のステップに進む必要があるのか​​、誰にバグが割り当てられているのか (開発者) を区別する方法を探しています。また、お客様には簡単な GUI を使用して、担当者を自分のアカウントから開発者に変更するよう依頼するか、さらに難しい: サードパーティ (デザインエージェンシーと考えてください) は、通常のギの。GUIは、何をすべきか、どのオプションがあるかを表示する必要があります-それらを検索するのではありません。

このように機能するバグトラッカーの経験がある人はいますか? 私たちのワークフローは本当におかしなことですか? バグがどこにあり、誰がどのステップを踏む必要があるかを、関係者全員が理解できるようにするにはどうすればよいでしょうか?

4

4 に答える 4

3

昨年も同じ問題が発生し、最適なソリューションはJiraであることがわかりました。私たちのワークフローは、あなたのワークフローよりも堅牢で複雑です。

于 2008-11-18T11:13:48.400 に答える
2

Redmine と電子メールの統合を使用して管理しているワークフローとほぼ同じ種類のワークフローがあります。顧客は Redmine に直接バグを記録します。通知は、バグに取り組むことができる開発者を決定するプロジェクト マネージャーに届きます。開発者はバグを開き、調査中状態にします。それが機能である場合、彼は理由を述べてそれに返信し、後で再訪する返信済み状態にします。バグの場合は、開発者が開発を開始します。この前に、彼はバグを Coding 状態にします。コーディングが完了すると、彼はバグの状態をレビューとして変更し、ピア レビューが行われます。やり直しがある場合、開発者は状態をやり直しに変更します。すべて問題がなければ、開発者は状態を [配信済み] に変更します。QA はバグを検証し、状態をクローズドに変更して最終的にバグをクローズします。

このワークフローはすべて Redmine で定義しており、手間をかけずに非常に効果的に使用しています。電子メールの統合により、プロジェクト マネージャーは、バグの状態が変化するたびにすべてを簡単に追跡できます。カスタム レポートを作成して保存することもできます。これも優れた機能です。

于 2008-11-18T11:22:50.253 に答える
0

他の人が言っているように、Jiraはとても良いです。カスタム発行ワークフローを作成する機能が特に気に入っています

于 2008-11-18T12:22:34.910 に答える
0

私は小さな個人的なプロジェクトに Trac を使用しており、職場では Bugzilla を使用しています。

あなたが説明したワークフローは、Red Hat が Bugzilla をどのように利用しているかにも似ています。

于 2008-11-18T11:26:24.990 に答える