バグの優先順位付け
概要
このページでは、クロスファンクショナルな優先順位付けプロセスの一環として品質エンジニアリングサブ部門が行うバグの優先順位付けプロセスについて説明します。
プロセス全体の概要は クロスファンクショナルな優先順位付け ハンドブックページにあります。
タイムライン
Product Development Timeline に定義されているとおり、優先順位付けには特定のデッドラインがあります。月 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) | オープンバグを、それぞれの Issue へのリンク付きで、重大度の降順（severity::1 〜 severity::4）にソートして一覧表示します。各重大度グループ内では、古いものから新しいものへとバグの経過時間でソートされます。 |
| Open bugs (missing severity label) | 重大度ラベルが付いていないオープンバグを一覧表示します。 |
| Avg MRs per milestone (6mo) | 過去 6 か月間のマイルストーンあたりの平均オープン MR 数。 |
| Bugs MRs merged per bug issue closed (6mo) | 過去 6 か月間で、クローズされたバグ Issue 1 件あたりにマージされたバグ MR の数。 |
優先順位付けのガイドライン
どのバグを優先するかを決める際に、以下の観点を考慮すると役立ちます。
- 経過時間（古いものか、新しいものか）
- 重大度（高いか、低いか）
- 期限切れのバグ（以前のマイルストーンからずれ込んだもの、SLO を逃したものなど）
- 顧客からの報告か社内か（
customerでタグ付けされた Issue） - 多数の顧客チケットが存在することを示す「Support Priority」または「Support Efficiency」
- 人気度/影響を受けるユーザー数
- 現在アクティブに作業されていない
- すでに将来のマイルストーンにアサインされていない（エスカレーションが必要な場合を除く）
- 現在ブロックされていない
- グループの現在の機能作業やロードマップと整合している（例:
feature Aが将来のマイルストーンで更新される間に、feature Aに関連するバグをまとめて修正する方が効率的な場合がある）
また、以下の 製品の優先順位付けフレームワーク と整合するよう意思決定することも目指します。
c955a93f)