スクラム プロセス テンプレートの作業項目の種類とワークフロー

チームがスクラムを使用してソフトウェア プロジェクトを計画し、ソフトウェアの不具合を追跡する場合は、プロダクト バックログ項目 (PBI) とバグの作業項目の種類 (WIT) を使用します。 製品所有者とプログラム マネージャーは、機能、シナリオ、またはユーザー エクスペリエンスのポートフォリオを把握するために、PBI とバグを機能に割り当てることができます。 チームがスプリントで作業する場合は、PBI とバグに自動的にリンクされるタスクを定義します。

テスト担当者は Microsoft Test Manager および TWA (Team Web Access) を使用してテスト ケースを作成および実行し、バグを作成して、コードの不具合を追跡します。 "懸案事項" によって、処理を妨げる懸案事項が追跡されます。

PBI およびバグを使用したバックログの定義

プロダクト バックログ項目を定義する場合は、顧客が得られる価値にフォーカスし、チームが機能を開発する方法の説明は省略します。 製品所有者は、各項目のビジネス価値、工数および他のバックログ項目との相対依存関係に基づいて、製品バックログに優先度を付けることができます。 ビジネス要件の進化に伴って、プロダクト バックログも増加します。 通常、チームは優先度が最も高い項目か、現在および次のスプリントに割り当てられた項目に対してのみ詳細を指定します。

プロダクト バックログ ページのクイック追加パネルから PBI およびバグを作成できます。

後で、各 PBI またはバグを開いて詳細を提供し、工数を見積もることができます。 また、バックログ ページ ("バックログ優先順位" フィールドでキャプチャ) で PBI とバグの優先度を設定することで、製品所有者が、どの項目の優先度を高くするかを指定することもできます。

PBI とバグの [作業量] を定義すると、チームが、予測機能とベロシティ グラフを使用して、機能スプリントや作業工数を見積もることができます。 [ビジネス価値] を定義すると、製品所有者が、変更可能なバックログ スタックの順位付けとは別に優先度を指定できます。

これらの必須フィールドには、次のガイダンスを使用します。 バグの作成の詳細については、後述の「コード障害の追跡」を参照してください。

フィールド/タブ	使用方法
作業	PBI の完了に必要な量をチームの好みに応じた測定単位で見積もります。たとえば、T シャツのサイズ、ストーリー ポイント、時間などを測定単位として使用できます。 このフィールドの値は、アジャイルのベロシティ グラフと予測ツールによって参照されます。 これは、リリース バーンダウン レポートと 速度 レポートを生成するための必須フィールドです。 追加のガイダンスについては、ホワイト ペーパー「見積もり」を参照してください。
ビジネス価値	1 つの PBI について、他の PBI と比較した相対的価値を表す数字を指定します。 数字が大きいほど、ビジネス価値は大きくなります。
説明 (PBI)	項目の実装に必要な作業量を見積もるのに十分な詳細情報を提供します。 だれにとっての機能か、その機能で何を達成したいのか、およびその理由に焦点を当てる必要があります。 機能の開発方法を記述しないでください。 チームが、項目を実装するためのタスクとテスト ケースを作成できるように、十分な詳細情報を提供する必要があります。
受け入れ基準	PBI またはバグ修正が完全に実装されたかどうかを確認するためにチームで使用する条件を記述して、何をもって "完了" とするかを定義します。 PBI またはバグについて作業を開始する前に、顧客の受け入れ基準をできる限り明確に記述します。 受け入れ基準を決定するためにチームと顧客との間で行われた会話は、顧客の期待に応えるためのチーム内の共通理解を確立するうえで役に立ちます。 受け入れ基準は受け入れテストの土台として使用できるため、チームはユーザー ストーリーを完成させることができたかどうかをより効果的に評価できます。

プロダクト バックログ ページの使用方法の詳細については、こちらを参照してください。

進行状況の追跡

チームはかんばんボードを使用して、PBI およびバグの進行状況を追跡できます。また、スプリント タスク ボードを使用して、タスクの進行状況を追跡できます。 項目を新しい状態列にドラッグすると、ワークフローの "状態" フィールドと "理由" フィールドが更新されます。

PBI およびバグの一般的なワークフローの進行は次のとおりです。

• 製品所有者が PBI を作成するか、テスト担当者が既定の理由である [新しいバックログ項目] を使用して [新規] 状態のバグを作成します。

• 項目について十分に記述され、チームが作業量レベルを見積もることができるようになったら、製品所有者は、項目を [承認済み] に移動します。 ほとんどの場合、プロダクト バックログの先頭付近の項目は [承認済み] 状態にあり、中間から末尾へかけての項目は、[新規] 状態にあります。

• チームは、スプリントの作業を完了したと判断した時点で、状態を [コミット済み] に更新します。

• チームがすべての関連のタスクを完了し、製品所有者が受け入れ基準に従って項目が実装されたことに同意した場合、その項目が [完了] の状態に移動します。

ワークフローの状態を更新することで、チームは、新しい項目、進行中の項目、完了した項目を見分けることができます。 WIT のほとんどが、各ワークフローの状態から前方と後方の両方向への遷移をサポートしています。

かんばんボードをカスタマイズして、追加のスイムレーンまたは列をサポートできます。 また、PBI およびタスク WIT のワークフローをカスタマイズすることもできます。これにより、既定の列見出しが変更されます。

これらのツールを使用するには、「かんばんボードの操作」および「スプリントでの作業」を参照してください。

機能への PBI の割り当て

一連の製品またはユーザー エクスペリエンスを管理する場合は、製品ポートフォリオ全体の作業のスコープと進行状況を表示することをお勧めします。 これを行うには、機能を定義し、PBI を機能に割り当てます。

機能のバックログ ページでは、PBI を追加したときと同じように、機能を迅速に追加できます。

機能の作業項目には、PBI を対象とした同様のフィールドが用意されています。 優先度やビジネス価値のほかに、目標とする日を指定して、機能をいつまでに実装するかを設定できます。

マッピングが有効になっているバックログ ページから、PBI を、実装する機能にドラッグできます。

このマッピングにより、機能から PBI への親子リンクが作成されます。これは [実装] タブでキャプチャされます。

ポートフォリオ バックログを使用すると、あるバックログから別のバックログへとドリルダウンして、情報を必要な詳細レベルで表示できます。 また、チームの階層を設定するときに、ポートフォリオ バックログを使用して、複数のチームによる進行中の作業のロールアップを表示することもできます。

PBI およびバグの実装に必要なタスクの定義

チームがスプリントで作業を管理する場合、スプリント バックログ ページを使用して、達成する作業を個別のタスクに分割できます。

タスクに名前を付け、必要な作業を見積もります。

スクラムを使用する場合、チームでは、各スプリントの開始時に作業を予測してタスクを定義し、チーム メンバーはそれらのタスクのサブセットを実行します。 タスクには、開発、テストおよび他の作業を含めることができます。 たとえば、開発者は PBI を実装するタスクを定義し、テスト担当者はテスト ケースを記述して実行するタスクを定義します。

時間または日数を使用して作業を見積もる場合は、タスクと、"残存作業" フィールドおよび "アクティビティ" (省略可能) フィールドを定義します。

フィールド	使用方法
残存作業	作業完了まで何時間分または何日分の作業が残っているかを示します。 作業の進行状況に応じて、このフィールドを更新します。 これはキャパシティ グラフ、スプリント バーンダウン チャートおよび スプリント バーンダウン (スクラム) レポートの計算に使用されます。 タスクをサブタスクに分割した場合は、サブタスクについてのみ残存作業を指定します。 作業は、チームで選択した任意の測定単位で指定できます。
アクティビティ	チームでスプリント キャパシティをアクティビティ単位で見積もる場合に、このタスクが表すアクティビティの種類を選択します。 メニューの選択を変更する場合は、「選択リストをカスタマイズする」を参照してください。

テスト進行状況の追跡

製品バックログ項目のテスト

テスト マネージャーまたは TWA から、PBI に自動的にリンクされるテスト ケースを作成できます。

テスト ケースには複数のフィールドがあり、その多くが自動化され、テスト マネージャーおよびビルド プロセスと統合されています。 各フィールドの詳細については、「ビルドとテストの統合フィールド参照」を参照してください。

[テストされたバックログ項目] タブに、テスト ケースの PBI とバグの一覧が表示されています。 PBI とバグをテスト ケースにリンクすることで、各項目のテストの進行状況を追跡できます。

バグを使用したコードの不具合の追跡

バグは TWA や Visual Studio から、またはテスト マネージャーでテストを実行しているときに作成できます。

フィールド/タブ	使用方法
再現手順	他のチーム メンバーが問題の影響を正確に理解し、バグが修正済みかどうかを判断するために十分な情報を提供します。 これには、バグの検出や再現に必要な操作と、予想される動作が含まれます。 コードの不具合が修正されたかどうかをチームが検証するときに使用する基準について説明します。
重大度	プロジェクトに対するバグの影響の主観的な評価。 次の値を指定できます。 1 - 重大 2 - 高 3 - 中 4 - 低 メニューの選択を変更する場合は、「選択リストをカスタマイズする」を参照してください。
システム情報 発見されたビルド ビルドに統合	テスト マネージャーがバグを作成するとき、そのバグが発生したソフトウェア環境とビルドに関する情報が、[システム情報] と [発見されたビルド] に自動的に入力されます。 ソフトウェア環境の定義の詳細については、「テスト コンピューターでのテストの実行またはデータの収集の設定」を参照してください。バグを解決するときは、[ビルドに統合] を使用して、バグを修正するコードを取り込むビルドの名前を指定します。 実行が完了したすべてのビルドのドロップダウン メニューにアクセスするには、[発見されたビルド] および [ビルドに統合] の FIELD 定義を更新して、グローバル リストを参照できます。 グローバル リストは、実行するビルドごとに自動的に更新されます。 詳細については、「テスト、ビルド、バージョン管理との統合をサポートするフィールド」を参照してください。 ビルド名を定義する方法については、「完了したビルドにわかりやすい名前を付けるためにビルド番号を使用」を参照してください。

共通の作業項目フィールドとタブの定義

次のフィールドとタブは、ほとんどの作業項目フォームに表示されます。 それぞれのタブは、[履歴]、[リンク]、または [添付ファイル] など、特定の情報の追跡に使用されます。 この 3 つのタブには、変更の履歴、リンクされた作業項目の表示、およびファイルの表示と添付機能がそれぞれ用意されています。

必須フィールドは [タイトル] のみです。 作業項目を保存すると、一意の ID がシステムによって割り当てられます。

フィールド/タブ	使用方法
タイトル (必須)	説明を 255 文字以下で入力します。 タイトルは、いつでも後から変更できます。
担当者	作業の実行を担当するチーム メンバーに、作業項目を割り当てます。 操作のコンテキストによっては、ドロップダウン メニューに、チーム プロジェクトのチーム メンバーまたは共同作成者のみが表示されます。
状態	まず既定値を使用します。 作業の進行状況に応じて、現在の状態を反映するように更新します。 状態のドロップダウン リストを変更する方法については、「作業項目の種類に関するワークフローの変更」を参照してください。
理由	まず既定値を使用します。 状態を変更したときに更新します。 各状態には、既定の理由が関連付けられます。 理由のドロップダウン リストを変更する方法については、「作業項目の種類に関するワークフローの変更」を参照してください。
領域	製品またはチームに関連付けられている区分パスを選択するか、計画会議で割り当てられるまでの空白のままにします。 区分のドロップダウン リストを変更する方法については、「区分およびイテレーション パスの追加および変更」を参照してください。
イテレーション	作業を完了させる必要があるスプリントまたはイテレーションを選択するか、空白にしておいて後で計画会議で割り当てます。 イテレーションのドロップダウン リストを変更する方法については、「区分およびイテレーション パスの追加および変更」を参照してください。
バックログ優先順位	PBI およびバグの相対的な順位付けを追跡するために使用します。 プロダクト バックログ ページでの項目のシーケンスによって、どこに従って項目を追加したり、ページの項目を移動したかが特定されます。 項目をドラッグすると、バックグラウンド プロセスによってこのフィールドが更新され、ProcessConfiguration ファイルの type="Order" に割り当てられます。
すべてのリンク	ハイパーリンク、変更セット、ソース ファイルなど、すべての種類のリンクを追加します。 このタブでは、他のリンク コントロール タブで定義されているリンクを含め、作業項目に定義されているすべてのリンクが一覧表示されます。
Attachments	作業項目にファイル (電子メール スレッド、ドキュメント、イメージ、ログ ファイルなど) を追加して、詳細情報を共有します。
History	システムで記録された監査証跡を確認し、追加情報を記録します。 作業項目が更新されるたびに、情報が履歴に追加されます。 履歴には、変更が行われた日付、変更を行った人、および変更されたフィールドが含まれます。 書式設定されたテキストを [履歴] フィールドに追加することもできます。

他のフィールドに関する情報を検索する方法については、「Index of work item fields (作業項目フィールドの索引)」を参照してください。

追跡作業の開始

追跡作業を開始する前に、チーム プロジェクトが必要です。 こちらで作成します。

追跡作業を開始するには、次のタスクを 1 つ以上実行します。

• 一般的な作業項目タスクについて理解するには、「作業項目の使用の開始」を参照してください。

• バックログを作成するには、TWA を使用します。 「バックログの作成」を参照してください。

• 作業分解構造を作成するには、Project または Excel を使用します。

• 使用するクライアントの詳細については、「タスクをサポートするための Team Foundation クライアントの選択」を参照してください。

Q & A

Q: スクラムでサポートされているのはどのようなワークフローの状態ですか。

A: これらの図は、機能、製品バックログ項目、バグ、およびタスクの主要な進行と回帰の状態を示しています。 ワークフローをカスタマイズするには、ここを参照してください。

機能

プロダクト バックログ項目

バグ

タスク

Q: バグを重複として解決するにはどうしますか。

A: [状態] を [削除済み] に設定し、[理由] を [重複] として指定します。

Q: テスト ランナーから既存のバグへリンクするにはどうしますか。

A: 「テスト ランナーの使用中に既存のバグを更新する」を参照してください。