私の会社では、次の規則が適用されます。
どのバグ追跡フローを使用していますか? それはあなたにとってうまくいきますか？
バグ追跡には BugZilla を使用しており、次のようなルールがあります。
誰でもバグを報告でき、小さな変更はすべてバグ追跡システムを通過する必要があります。製品の拡張である場合は、バグを拡張としてマークし、バグ追跡システムに従う必要があります。
誰でもバグを他の人に割り当てることができます。つまり、バグが他の人のコードに存在する場合、問題を他の人に簡単にルーティングできます。バグを複数の場所で修正する必要がある場合があります。つまり、最初に他の人のコードに依存して修正され、その後、他の人が自分のコードを修正します。このような場合、バグは最初に作業を行う必要がある人に割り当てられ、その人はバグを再割り当てすることで適切な人に再ルーティングします。
問題が複数の場所で発生し、コード ビハインドは異なるが問題が明らかに同じである場合、バグは複製され、すべての変更を個別に追跡できるようになります。
テクニカル リードは、特定の修正の要求に基づいてバグに優先順位を付ける責任があります。
テスター/QAE は、バグに重要度 (クリティカル/メジャー/マイナーなど) を割り当てる責任があります。
すべてのバグは、バグ追跡システムを通過します。顧客からのバグは、カスタム フラグによって個別に分類され、顧客のバグであることを示します。顧客のバグはほとんどが以前にリリースされたビルドにあり、パッチはそれらに対して作成されるため、それらは別々に保持されます。
このようにして、ソース管理システム (TFS である) と Bugzilla ですべての変更を同時に追跡し、将来必要に応じて元のコード変更/所有者に変更を追跡できるようにします。
かなり複雑に聞こえます。おおまかに次のプロセスを使用しています。
これは、開発者が問題に責任を持つことを奨励する軽量プロセスです。
これとは別に、変更要求のソースやタイプに関係なく、ソフトウェア内のすべてを変更するプロセスに対して、いくつかの品質保証措置が講じられています。これには特に次のものが含まれます。
ブヨ (うわー!)、Bugzilla (少しうーん)、Trac、Jira、そして今では FogBugz など、数多くの問題追跡システムを使用してきました。私は何よりも Trac が好きですが、それはおそらく、私が FogBugz の管理者ではなく、現在の化身で悲しいことにひどく悪用されているためです。
ワークフローを正しく設定することは非常に重要です。奇妙なことに、バグ トラッカーに何を入れるか、そこに入れるものにどのようにラベルを付けるかを決めるところから始まります。顧客を獲得するとすぐに、すべての開発チームが次の 3 種類の問題を実際に追跡します。
実際の顧客によって指摘された問題 (ライブ バグ)。
現在開発中の新しいソフトウェアの問題 (開発バグ)。
今後やりたいこと（特徴）。
もちろん、これら 3 つのクラスの問題には、それぞれ独自の優先順位があります。ボタンの単なるスペルミスである「ライブバグ」は、公式に発表されたリリースをブロックしたり、他の開発やテストなどを妨げたりする「開発バグ」よりもはるかに重要ではない可能性があります.
問題の重大度は、副作用がどれほど恐ろしいものであるかを表します。私の経験では、これは次のように要約されます。
プログラムが何かを台無しにしています。データ、顧客への不正請求、間違った薬の調剤。これは最悪です。私はかつて、ソフトウェア コマンドがサービスマンの真ん中で油圧アームを引っ込めるシステムに取り組んだことがあります。これは最悪です。
プログラムがクラッシュしており、回避策はありませんが、その間は (ダウンする以外に) 何も台無しにはなりません。ダウンタイムによって何かが台無しになった場合は、重大度 #1 を使用します。
プログラムは正しく動作していませんが、実際に使用できる特定の回避策があります。
プログラムは迷惑な方法で誤動作していますが、結果には影響しません。
プログラムは、明確に定義された方法で改善する必要があります: 使いやすく、新しい機能を実装し、より速く実行するなど.
これらのシステムでよく発生するもう 1 つの問題は、「役割」の概念です。問題追跡システムに適用されるように、役割は要約すると、誰が実行を許可されているかということになります。問題を作成できるのは誰ですか? 誰がステータスを変更できるか、誰がステータスを別のユーザーに再割り当てできるか、誰がステータスを閉じることができるかなど。
私が緊密に協力してきた小規模から中規模のチームでは、この一般的な一連のルールがうまく機能しています。
誰でも問題を作成できます。作成者は、課題の作成時に任意の (またはほとんどの) 受信者に課題を割り当てることができます。デフォルトの受信者は問題トリアージ チームです。開発者は、この方法でコードの作業中に見つけたバグをメモし、そのバグを自分自身に割り当てて、コードを変更する理由を追跡できます。
トリアージ チームが集まり (ここで間隔を指定)、問題を評価して割り当てます。トリアージ チームは特に重複レポートを探します。その場合、新しい問題は既存の問題チェーンに「ロールアップ」されます。再現のために QA に割り当てられた、フィールドからの再現されていない問題。お客様からの重大度の高い問題の場合。
バグをクローズできるのは、バグの作成者だけです。QA または CSR によって開始されたバグ レポートは、開発者がクローズすることはできません。はい、これは、CS と開発チームが同意しないバグが未解決のままであることを意味します。人々が同意していないのに、問題トラッカーが問題を解決済みとして報告するのはなぜですか? 嘘のデジタル リポジトリが必要な場合は、C-SPAN があります。
一部のチームは、ある部門から別の部門への問題の移動をマネージャーに予約したい場合があります。他のチームは、チームメンバーが問題を別のチームに移動 (または戻る) することを許可する場合があります。これは経営陣の疑念、または単に誰が作業時間を割り当てることが許可されているかという問題に帰結する可能性があります。
トリアージプロセスが鍵です。トリアージ チームは基本的に、組織内で誰が何に取り組み、次に何に取り組むかを決定する人です。チームが定期的にミーティングを行うことで、本当に重要なことを見逃したり、不注意によって平凡なことを忘れたりしないようにすることができます。Triage キューに何もない場合、会議 (concall、netmeeting、実装が何であれ) は、会議のリーダーによってキャンセルされる可能性があります。
スクラムを使用している場合、トリアージ チームはおそらくスクラム マスターであり、問題が現在のスプリントに取り込まれるかどうかを決定し、バックログに入る場合は適切に優先順位を割り当てます。
バグレポートと機能リクエストを分離することなく、お客様も問題を作成できるはずだと思います。
問題の割り当ては開発者自身が行うべきではありません。次のリリースで修正する必要のある問題を決定するのは、顧客とマネージャーの責任です。
他の方法は、JoelSpolskyによる痛みのないバグ追跡にあります。
バグのロギングは速度に関するものです - バグを調査/再現するために必要な最小限の情報です
Web プロジェクトの場合、これは次のようになります: 1) 説明的なバグのタイトル、2) エラーが発生したページ、3) 問題の説明 + スクリーンショット、または問題を再現するための段階的な手順 (スクリーンショットの場合)提供されていません）
スクリーンショットは次の 2 つの理由で非常に強力です: 1) 写真は百聞は一見にしかず、2) バグレポートに信頼性を与えます (再現できないバグを調査して、「クライアントがまたでっちあげているように見える」と思ったことはありませんか?)
私はさらにトピックに入るブログ記事を持っています: Logging Bugs Like a Pro
過去 10 年間、何もない、Word ドキュメント、FogBugz、Bugzilla、Remedy など、さまざまな種類のバグ追跡システムを使用してきました。FogBugz は群を抜いて最高のものです。その仕事では、誰でもバグを入力することができ、誰でも他の人にバグを割り当てることができました。コードに小さなバグが見つかった場合は特に、これがうまく機能することがわかりました。電子メールを書いたり、フォームに記入したり、他の何人かを巻き込んだりするのに 1 時間も費やす代わりに、バグを見つけて修正したことをすぐに記録することができました。これにより、見つけたすべてのバグを入力してすばやく修正することができました。バグに多くの作業が必要な場合は、マネージャーに割り当てて、他の作業で優先順位を付けられるようにします。
私が Bugzilla を使用していた仕事では、バグが作成、割り当て、または変更されるたびに、電子メールがすべての開発者とマネージャーに送信されました。これは逆の効果があり、システムのバグを見つけて入力することを思いとどまらせました。
待って、次のように書きます。
開発者の問題が別の開発者のコードによってブロックされている場合、開発者はバグ追跡システムの外でこの問題を解決する必要があります。
そのため、通常のバグ フローから外れるバグがあります。それらのバグを追跡するための 2 つ目のシステムがありますか、それともすべてアドホックですか?
あなたのバグ追跡システムは、実際にはユーザーの欠陥を追跡するシステムのようです。
それはあなたにとってうまくいきますか、それとも代替案を検討していますか?
私の小さなショップでは、非常に単純なワークフローを使用しています。
このようにして、すべてがバグ追跡システムに記録され、更新を制限しないことで効率が維持されます。この方法では、多少の「バグ スパム」が発生する可能性がありますが、私の経験では、ボトルネックを作成するよりはましです。
私たちはバグ追跡ツールとして JIRA を使用しています。JIRA であらゆる種類のカスタム ワークフローを設定して、特定のプロセスを強制することができますが、小規模な組織でそれを行う必要があるとは思いませんでした。
どのバグ追跡フローを使用していますか?