次の方法で共有


バグのダッシュボード

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

  • バグ バーンダウン

  • 時間の経過と共に変化する、チームがバグを発見し、解決して、終了している速度

  • 時間の経過と共に変化する優先度が高いバグの数

  • 現在各チーム メンバーに割り当てられているアクティブなバグの数

    [!メモ]

    ダッシュボードへは、チーム プロジェクト ポータルからアクセスします。バグのダッシュボードにアクセスできるのは、ポータルが有効化され、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 パーツ

表示されるデータ

関連トピック

手順 1.

過去 4 週間以内のすべてのバグの累積数を状態別にグループ化したビジュアル表現。

バグの進行状況 Excel レポート

バグの進行状況 Excel レポート

手順 2.

過去 4 週間以内にチームが開き、解決して、終了したバグの数のローリング平均を示す折れ線グラフ。ローリング平均は、計算する日の前日までの 7 日間を対象にしています。

バグの傾向レポート

バグの傾向 Excel レポート

手順 3.

過去 4 週間以内のすべてのバグの累積数を優先度別にグループ化したビジュアル表現。

バグ (優先度順) グラフ

バグ (優先度順) Excel レポート

手順 4.

各チーム メンバーに現在割り当てられているアクティブなバグの総数を優先度別にグループ化した水平方向の横棒グラフ。

バグ (割り当て順) グラフ

バグ (割り当て順) Excel レポート

手順 5.

アクティブなバグのリスト。このリストは、Team System Web Access Web パーツから派生します。

バグの傾向レポート

トリアージ ブック

手順 6.

間近に迫っているイベントのリスト。このリストは、SharePoint Web パーツから派生します。

インポート イベント Web パーツ

該当なし

手順 7.

アクティブな作業項目、解決した作業項目、および終了した作業項目の数。それぞれの数字をクリックして、作業項目のリストを開くことができます。このリストは、Team System Web Access Web パーツから派生します。

プロジェクトの作業項目 Web パーツ

作業項目とワークフロー (アジャイル)

手順 8.

最新のビルドおよびその状態のリスト。ビルドをクリックすることで、その詳細を表示できます。このリストは、Team System Web Access Web パーツから派生します。

最新ビルド Web パーツ

凡例:

進行中のビルド: ビルドは進行中です

開始していないビルド: ビルドは開始されていません

成功したビルド: ビルドに成功しました

失敗したビルド: ビルドに失敗しました

停止したビルド: ビルドが停止されました

一部成功したビルド: ビルドが一部成功しました

Managing and Reporting on Builds

9

最新のチェックインのリスト。特定のチェックインをクリックすることで、その詳細を表示できます。このリストは、Team System Web Access Web パーツから派生します。

最新チェックイン Web パーツ

コードの作成と保留中の変更の管理

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

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

  • バグを定義し、バグのイテレーション パスと領域パスを指定します。

  • 各バグを、現在それを解決または終了するために作業しているチーム メンバーに割り当てます。

  • 各バグの優先度を指定します。

  • チームがバグを修正、検証、および終了したところで、バグの状態を更新します。

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

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

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

  • チームのゴールと照らし合わせて、アクティブなバグの数は許容できるか。チームが延期しているバグの数が多すぎないかどうか。

  • チームは、期待に応えられるよう十分に迅速に、前の開発サイクルと同じ速度で、バグを発見し、修正して、終了しているか。

  • チームは、優先度の低いバグよりも先に優先度の高いバグを解決しているか。

  • バグを解決するにあたって、支援の必要なチーム メンバーはいるか。

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

  • バグの進行状況の指標

  • バグの傾向の指標

  • バグの優先度と配分

Dd560860.collapse_all(ja-jp,VS.110).gifバグの進行状況の指標

問題の指標

確認事項

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

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

  • チーム メンバーが他の優先度の低いタスクに再割り当てされていないか。

  • 他の懸案事項がチームのバグを解決および修正する能力を妨げていないか。

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

  • テスト カバレッジは十分であるか。

  • 他の懸案事項がチームのバグを発見する能力を妨げていないか。

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

  • チームの優先度が正しく設定されているか。

  • チーム メンバーが過剰に他のタスクに割り当てられていないか。

  • チーム メンバーはバグの状態を正しく追跡しているか。

Dd560860.collapse_all(ja-jp,VS.110).gifバグの傾向の指標

問題の指標

確認事項

チームが各期間で多くのバグを解決している。解決率が高いということは、一般に、チームが順調に作業を進めていることを意味します。

  • チームは解決したバグを迅速に終了しているか。終了率は解決率と近似している必要があります。

  • チームは許容される率でバグを再アクティブ化しているか。

チームはバグを迅速に解決しているが、終了していない。バグ修正の検証に割り当てられているチーム メンバーが不足しているか、別の優先事項が原因でこれらのメンバーが解決済みのバグを終了していない可能性があります。

  • テスト リソースを過剰に割り当てていないか。

  • チームはテストの優先度を見直す必要があるか。

    これらの測度の詳細については、「テストのダッシュボード (アジャイル)」を参照してください。

チームが各期間でほとんどバグを発見していない。チームは、高品質のソリューションの場合や効果の薄いテストを実行している場合は、バグの発見に苦労する場合があります。

  • コード カバレッジ、コード チャーン、およびテストの進行状況の各測度は、コードまたはテストに問題があることを示しているか。

    これらの測度の詳細については、「品質のダッシュボード (アジャイル)」を参照してください。

チームは連続する期間に同じ数のバグを発見している。チームが同じ数のバグを連続した週または連続したイテレーションで発見する場合は、根本的な原因を究明する必要があります。テスト サイクルの早い時期に実施したテストの厳密さやレベルが不足していたために、多くのバグを発見できなかった可能性があります。この状況は、一連のイテレーションの早い時期に起こることが想定されます。ただし、製品が完成に近づくにつれて、テストではより広範囲のシナリオや統合を実行する必要があります。

  • テスト ケースは、チームが開発中のユーザー ストーリーをテストするのに適切であるか。

  • テストは古くなっていないか、または予定されていた機能とは異なる機能をテストしていないか。

  • テスト チームは各ユーザー ストーリーを厳密にテストしているか。

    これらの測度の詳細については、「テストのダッシュボード (アジャイル)」を参照してください。

チームは各期間で多くのバグを発見している。粗雑なコードや新規に統合されたコード内で、または効果的なテストの実行時やバグ バッシュなどの特定のイベント発生時に、バグを簡単に発見できる場合があります。

  • コード カバレッジ、コード チャーン、およびテストの進行状況の各測度は、コードまたはテストに問題があることを示しているか。

    これらの測度の詳細については、「品質のダッシュボード (アジャイル)」を参照してください。

Dd560860.collapse_all(ja-jp,VS.110).gifバグの優先度と配分

問題の指標

確認事項

優先度の高いアクティブなバグの数が、優先度の低いアクティブなバグの数を上回っている。優先度の高いバグの数が優先度の低いバグの数を上回っているということは、チームが優先度の低い項目を優先している可能性があることを意味します。

  • チームは、チームが設定した優先度の順にバグを修正しているか。

  • 他の懸案事項がチームの優先度の高いバグを修正する能力を妨げていないか。

バグの割り当てが均等に配分されていません。多くのバグが 1 人または 2 人のチーム メンバーに割り当てられ、他のチーム メンバーには少量のみ割り当てられている場合、チームは作業の再割り当てを検討する必要があります。

  • チームはバグの再割り当てによって作業負荷を適切に分散させる必要があるか。

参照

概念

トリアージ ブック

バグ (アジャイル)

ダッシュボード (アジャイル)

成果物 (アジャイル)