バグのダッシュボード

[アーティクル]
08/09/2011

バグのダッシュボードを使用して、チームプロジェクトのバグアクティビティを監視できます。このダッシュボードには、次のグラフが表示されます。

バグバーンダウン
時間の経過と共に変化する、チームがバグを発見し、解決して、終了している速度
時間の経過と共に変化する優先度が高いバグの数
現在各チームメンバーに割り当てられているアクティブなバグの数

注意

ダッシュボードへは、チームプロジェクトポータルからアクセスします。バグのダッシュボードにアクセスできるのは、ポータルが有効化され、Microsoft Office SharePoint Server 2007 を使用するようにプロビジョニングされている場合だけです。詳細については、「ダッシュボード (アジャイル)」または「チームプロジェクトポータルおよびプロセスガイダンスへのアクセス」を参照してください。

このトピックの内容

ダッシュボードに表示されるデータ
バグの追跡に必要なアクティビティ
アクティブなバグとバグの傾向の監視

このダッシュボードを使用すると、次の事項を確認できます。

チームはどの程度の速度でバグを解決して、終了しているか。
チームは時間どおりに終了できるように十分に速いペースでバグを修正しているか。
チームが 1 日あたりに報告し、解決して、終了しているバグの数はいくつか。
チームは、優先度 2 および 3 のバグよりも先に優先度 1 のバグを解決しているか。
再配布を保証する優先度 1 のバグのバックログを持っているチームメンバーはいるか。
昨日の夜間ビルドはどのような状態であるか。
最新のチェックインは何であったか。

必要なアクセス許可

ダッシュボードを表示するには、チームプロジェクトの SharePoint 製品に対する [読み取り] アクセス許可が割り当てられているグループに割り当てられているか、そのグループに属している必要があります。ダッシュボードを変更、コピー、またはカスタマイズするには、チームプロジェクトの SharePoint 製品に対する [メンバー] アクセス許可が割り当てられているグループに割り当てられているか、そのグループに属している必要があります。詳細については、「チームプロジェクトへのユーザーの追加」を参照してください。

Office Excel でレポートを変更するには、SQL Server Analysis Services の TfsWarehouseDataReaders セキュリティロールのメンバーであることが必要です。また、チームプロジェクトの SharePoint 製品に対する [メンバー] アクセス許可が割り当てられているグループに割り当てられているか、そのグループに属している必要もあります。詳細については、「Visual Studio ALM 用データウェアハウスのデータベースへのアクセスの許可」を参照してください。

バグまたはその他の種類の作業項目を表示するには、読み取りユーザー グループのメンバーであるか、または [このノードの作業項目を表示します] のアクセス許可が [許可] に設定されている必要があります。バグまたはその他の種類の作業項目を作成または変更するには、貢献者グループのメンバーであるか、または [このノードの作業項目を編集します] のアクセス許可が [許可] に設定されている必要があります。詳細については、「アクセス許可の管理」を参照してください。

ダッシュボードに表示されるデータ

チームは、バグのダッシュボードを使用して、チームがどれほど適切にバグを発見し、解決して、終了しているかを把握できます。具体的には、このダッシュボードには、次の図と表で説明する Web パーツが表示されます。

バグダッシュボード

注意

バーンダウングラフ、傾向表、および棒グラフ ( 手順 1. ～手順 4. のレポート) は、チームプロジェクトの Analysis Services をホストするサーバーが使用できない場合には表示されません。

バグのダッシュボードに表示されるグラフの解釈、更新、またはカスタマイズの方法については、次の表に示されているトピックを参照してください。

Web パーツ	表示されるデータ	関連トピック
	過去 4 週間以内のすべてのバグの累積数を状態別にグループ化したビジュアル表現。	バグの進行状況 Excel レポート
	過去 4 週間以内にチームが開き、解決して、終了したバグの数のローリング平均を示す折れ線グラフ。ローリング平均は、計算する日の前日までの 7 日間を対象にしています。	バグの傾向 Excel レポート
	過去 4 週間以内のすべてのバグの累積数を優先度別にグループ化したビジュアル表現。	バグ (優先度順) Excel レポート
	各チームメンバーに現在割り当てられているアクティブなバグの総数を優先度別にグループ化した水平方向の横棒グラフ。	バグ (割り当て順) Excel レポート
	アクティブなバグのリスト。このリストは、Team System Web Access Web パーツから派生します。	トリアージブック
	間近に迫っているイベントのリスト。このリストは、SharePoint Web パーツから派生します。	該当なし
	アクティブな作業項目、解決した作業項目、および終了した作業項目の数。それぞれの数字をクリックして、作業項目のリストを開くことができます。このリストは、Team System Web Access Web パーツから派生します。	作業項目とワークフロー (アジャイル)
	最新のビルドおよびその状態のリスト。ビルドをクリックすることで、その詳細を表示できます。このリストは、Team System Web Access Web パーツから派生します。凡例: : ビルドは進行中です : ビルドは開始されていません : ビルドに成功しました : ビルドに失敗しました : ビルドが停止されました : ビルドが一部成功しました	完了したビルドの管理と表示
	最新のチェックインのリスト。特定のチェックインをクリックすることで、その詳細を表示できます。このリストは、Team System Web Access Web パーツから派生します。	[チェックイン] ウィンドウと [保留中の変更] ウィンドウの使用

バグの追跡に必要なアクティビティ

正確で効果的なレポートがバグのダッシュボードに表示されるようにするためには、チームは次のアクティビティを実行する必要があります。

バグを定義し、バグのイテレーション パスと領域パスを指定します。
各バグを、現在それを解決または終了するために作業しているチームメンバーに割り当てます。
各バグの優先度を指定します。
チームがバグを修正、検証、および終了したところで、バグの状態を更新します。

アクティブなバグとバグの傾向の監視

チームメンバーは、バグのダッシュボードを使用して、設定されているチームのゴールおよびアジャイル手法に沿ってチームメンバーがアクティブなバグのリストを管理しているかどうかを判断できます。チェックイン前のコードの各インクリメントを単体テストすることで、チームは発見する必要のある全体的なバグの数を減らすことができます。コードの各インクリメントを提供できることを重視するチームは、欠陥をインクリメント方式で削除し、継続して存在するバグを最小化できます。

バグのダッシュボードを使用すると、チームは次の事項を確認できます。

チームのゴールと照らし合わせて、アクティブなバグの数は許容できるか。チームが延期しているバグの数が多すぎないかどうか。
チームは、期待に応えられるよう十分に迅速に、前の開発サイクルと同じ速度で、バグを発見し、修正して、終了しているか。
チームは、優先度の低いバグよりも先に優先度の高いバグを解決しているか。
バグを解決するにあたって、支援の必要なチームメンバーはいるか。

ダッシュボードに表示されるインジケーターに基づく他の確認事項については、以下のセクションを参照してください。

バグの進行状況の指標
バグの傾向の指標
バグの優先度と配分

バグの進行状況の指標

問題の指標	確認事項
アクティブなバグのバンドの幅が広がってきている。チームのアクティブなバグのバンドの幅が広がってきているということは、バグのバックログが増加していることを意味します。チームは、解決または終了できるバグの数よりも多くのバグを発見しています。アクティブなバグのバンドの幅が広がってきているということは、ボトルネックによって、チームのバグを解決および終了する能力が低下していることを示すことがあります。	チームメンバーが他の優先度の低いタスクに再割り当てされていないか。他の懸案事項がチームのバグを解決および修正する能力を妨げていないか。
アクティブなバグの数に変化がない。アクティブなバグの数の傾向に変化がないということは、チームがバグを検出していないことを意味します。	テストカバレッジは十分であるか。他の懸案事項がチームのバグを発見する能力を妨げていないか。
解決または終了したバグの数に変化がない。チームが解決または終了しているバグの数が長期間フラットのまま変化していないということは、チームメンバーがバグを解決または終了できない可能性があることを意味します。	チームの優先度が正しく設定されているか。チームメンバーが過剰に他のタスクに割り当てられていないか。チームメンバーはバグの状態を正しく追跡しているか。

アクティブなバグのバンドの幅が広がってきている。チームのアクティブなバグのバンドの幅が広がってきているということは、バグのバックログが増加していることを意味します。チームは、解決または終了できるバグの数よりも多くのバグを発見しています。

アクティブなバグのバンドの幅が広がってきているということは、ボトルネックによって、チームのバグを解決および終了する能力が低下していることを示すことがあります。

チームメンバーが他の優先度の低いタスクに再割り当てされていないか。
他の懸案事項がチームのバグを解決および修正する能力を妨げていないか。

アクティブなバグの数に変化がない。アクティブなバグの数の傾向に変化がないということは、チームがバグを検出していないことを意味します。

テストカバレッジは十分であるか。
他の懸案事項がチームのバグを発見する能力を妨げていないか。

解決または終了したバグの数に変化がない。チームが解決または終了しているバグの数が長期間フラットのまま変化していないということは、チームメンバーがバグを解決または終了できない可能性があることを意味します。

チームの優先度が正しく設定されているか。
チームメンバーが過剰に他のタスクに割り当てられていないか。
チームメンバーはバグの状態を正しく追跡しているか。

バグの傾向の指標

問題の指標	確認事項
チームが各期間で多くのバグを解決している。解決率が高いということは、一般に、チームが順調に作業を進めていることを意味します。	チームは解決したバグを迅速に終了しているか。終了率は解決率と近似している必要があります。チームは許容される率でバグを再アクティブ化しているか。
チームはバグを迅速に解決しているが、終了していない。バグ修正の検証に割り当てられているチームメンバーが不足しているか、別の優先事項が原因でこれらのメンバーが解決済みのバグを終了していない可能性があります。	テストリソースを過剰に割り当てていないか。チームはテストの優先度を見直す必要があるか。これらの測度の詳細については、「テストのダッシュボード (アジャイル)」を参照してください。
チームが各期間でほとんどバグを発見していない。チームは、高品質のソリューションの場合や効果の薄いテストを実行している場合は、バグの発見に苦労する場合があります。	コードカバレッジ、コードチャーン、およびテストの進行状況の各測度は、コードまたはテストに問題があることを示しているか。これらの測度の詳細については、「品質のダッシュボード (アジャイル)」を参照してください。
チームは連続する期間に同じ数のバグを発見している。チームが同じ数のバグを連続した週または連続したイテレーションで発見する場合は、根本的な原因を究明する必要があります。テストサイクルの早い時期に実施したテストの厳密さやレベルが不足していたために、多くのバグを発見できなかった可能性があります。この状況は、一連のイテレーションの早い時期に起こることが想定されます。ただし、製品が完成に近づくにつれて、テストではより広範囲のシナリオや統合を実行する必要があります。	テストケースは、チームが開発中のユーザーストーリーをテストするのに適切であるか。テストは古くなっていないか、または予定されていた機能とは異なる機能をテストしていないか。テストチームは各ユーザーストーリーを厳密にテストしているか。これらの測度の詳細については、「テストのダッシュボード (アジャイル)」を参照してください。
チームは各期間で多くのバグを発見している。粗雑なコードや新規に統合されたコード内で、または効果的なテストの実行時やバグバッシュなどの特定のイベント発生時に、バグを簡単に発見できる場合があります。	コードカバレッジ、コードチャーン、およびテストの進行状況の各測度は、コードまたはテストに問題があることを示しているか。これらの測度の詳細については、「品質のダッシュボード (アジャイル)」を参照してください。

バグの優先度と配分

問題の指標	確認事項
優先度の高いアクティブなバグの数が、優先度の低いアクティブなバグの数を上回っている。優先度の高いバグの数が優先度の低いバグの数を上回っているということは、チームが優先度の低い項目を優先している可能性があることを意味します。	チームは、チームが設定した優先度の順にバグを修正しているか。他の懸案事項がチームの優先度の高いバグを修正する能力を妨げていないか。
バグの割り当てが均等に配分されていません。多くのバグが 1 人または 2 人のチームメンバーに割り当てられ、他のチームメンバーには少量のみ割り当てられている場合、チームは作業の再割り当てを検討する必要があります。	チームはバグの再割り当てによって作業負荷を適切に分散させる必要があるか。