バグ優先順位付け
概要
このページでは、クロスファンクショナルな優先順位付けプロセスの一環として品質エンジニアリングサブ部門が実施するバグ優先順位付けプロセスについて説明します。
プロセス全体の概要は、クロスファンクショナル優先順位付け ハンドブックページにあります。
タイムライン
製品開発タイムライン に定義されているように、優先順位付けには特定のデッドラインがあります。月 M のリリース日に出荷されるマイルストーン m が与えられた場合:
- マイルストーン開始の 19 日前の月曜日まで:
- バグ優先順位付けトリアージレポートが、各グループのプロダクトマネージャーに優先された
type::bugIssue のリストとともに作成されます。
- バグ優先順位付けトリアージレポートが、各グループのプロダクトマネージャーに優先された
- マイルストーン開始の 12 日前の月曜日まで:
- 各カウンターパートグループの Quad（PM、EM、UX、Quality）が、次のマイルストーンに含める Issue について議論します。
- プロダクトマネージャーは、Quad からの優先順位付けの入力を考慮に入れ、次のマイルストーンの Issue 計画を作成します。
バグ優先順位付けトリアージレポート
自動化されたバグ優先順位付けトリアージレポート は、~"type::bug" のトップ 10 のオープン Issue を含み、月次で各グループに対して作成されます。レポートは以下の条件に基づいて優先された Issue で生成されます:
severity::*ラベルに基づく重大度bug::vulnerabilityラベルに基づくセキュリティ脆弱性customerラベルに基づく顧客 Issue- Issue の経過時間（最も古いもの）
バグ優先順位付けトリアージレポートは、グループ定義ファイルにリストされているか、トリアージレポートポリシーファイルのポリシー YAML ファイルに直接記載されている各グループの特定の PM と EM に自動的にアサインされます。
Issue がアサインされる対象を変更するには、上記のファイルに対してマージリクエストを開きます。グループ定義ファイルが変更された場合、生成されたファイルを更新するためにいくつかのスクリプトを実行する必要があります。
バグ優先順位付けダッシュボード
バグ優先順位付けダッシュボード は、各グループの推奨バグリストをまとめるためにも使用できます。 ダッシュボードは各マイルストーンで再確認する必要があります。データは時間とともに変化するためです。
一般的なガイドラインとして、提案されたバグの総数は、あなたの特定のグループのダッシュボードのバーンダウン計画と一致させる必要があります。 この合計は Milestone planning (bug counts to schedule) というタイトルのチャートの Total Bugs で確認できます。
また、Milestone planning (bug % of scheduled issues) チャートにある Total Bug % も含めると役立ちます。 このメトリクスにより、リストにあるすべてのバグに取り組む余力がない場合に、グループが適切な割合のバグをスケジュールするよう目標設定できます。
このプロセスは一律に適用されるものではなく、グループはチームに最適な方法を見つけることが奨励されています。
ダッシュボードのウォークスルー
この表には、バグ優先順位付けダッシュボードに見られるチャートの一覧と各チャートが何を表しているかの説明が含まれています。
バグ優先順位付けダッシュボードウォークスルー 動画でも、例とともにダッシュボードの概要を確認できます。
| チャート名 | 説明 |
|---|---|
| Bugs per milestone (6mo avg) | 過去 6 ヶ月間で平均してバグだったマイルストーンあたりの作業 Issue の割合。 |
| Bug Growth Rate (6mo total) | 過去 6 ヶ月間のバグ成長率の合計割合。 |
| Bugs opened and closed by severity (6mo totals) | 過去 6 ヶ月間に重大度別にオープンおよびクローズされたバグの総数。 |
| Open bugs by severity | 重大度別のオープンバグの総数。SLO を超過した数と割合を含む。 |
| Selected burndown plan | フィルターで選択されたバーンダウン計画のサマリー。 |
| Milestone planning (bug counts to schedule) | このチャートは、選択されたバーンダウン計画を達成するためにマイルストーンに引き込む必要があるバグ数を決定するのに役立ちます。 「Open Bugs (Total)」列は「Open bugs by severity」チャートと同じデータを使用します。 「Burndown Bugs」列は、バックログの削減を開始するために重大度別にマイルストーンごとに引き込む必要があるバグ数を示します。 「New Bugs」列は、特定のマイルストーンで新たにオープンになる各重大度のバグ数を概算します。ここでの新しいバグの総数は、バックログを増やさないためにスケジュールする必要がある最低数です。 |
| Milestone planning (bug % of scheduled issues) | このチャートは Milestone planning (bug counts) チャートと同じ概念を表しますが、時間の経過とともにマージされた MR の総数の割合として表します。 「New Bug %」列は、バーンダウンなしでバックログを増やさないために次のマイルストーンで対処する必要があるバグの割合です。 「Total Bug %」列は、バックログをバーンダウンするために次のマイルストーンで対処する必要があるバグの割合です。 |
| Open bugs over time | このグラフは、重大度別に時間の経過とともにオープンになったバグ数を可視化します。 |
| S1 Bug Backlog Over Time | このグラフは、時間の経過とともにバックログ内のオープンな S1 バグ数を可視化します。 |
| S2 Bug Backlog Over Time | このグラフは、時間の経過とともにバックログ内のオープンな S2 バグ数を可視化します。 |
| Open bugs (with severity label) | 重大度の降順（severity::1 〜 severity::4）でソートされた、それぞれの Issue へのリンクとともにオープンバグをリストします。各重大度グループは、最も古いものから新しいものの順にバグの経過時間でソートされます。SET / QEM はこのリストを使用して、カウンターパートグループの推奨バグリストをまとめることができます。 |
| Open bugs (missing severity label) | 重大度ラベルがないオープンバグをリストします。 |
| Avg MRs per milestone (6mo) | 過去 6 ヶ月間のマイルストーンあたりの平均オープン MR 数。 |
| Bugs MRs merged per bug issue closed (6mo) | 過去 6 ヶ月間でバグ Issue がクローズされるごとにマージされたバグ MR の数。 |
優先順位付けガイドライン
どのバグを優先するかを決定する際に、以下の考慮事項が役立ちます。
- 経過時間（古い vs 新しい）
- 重大度（高い vs 低い）
- 期限切れバグ（前のマイルストーンからスリップしたバグ、SLO の遅延など）
- 顧客報告 vs 内部（
customerでタグ付けされた Issue） - 大量の顧客チケットがあることを示す「Support Priority」または「Support Efficiency」
- 人気度/影響を受けるユーザー数
- 現在アクティブに取り組まれていない
- 将来のマイルストーンにまだアサインされていない（エスカレーションが必要な場合を除く）
- 現在ブロックされていない
- グループの現在の機能作業とロードマップに一致する（例:
feature Aが将来のマイルストーンで更新されている間に、feature Aに関するバグをまとめて修正する方が効率的な場合がある）
また、以下の製品優先順位付けフレームワークに合わせて決定することも目指してください。
