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

チームは、MSF for CMMI Process Improvement 2015 (CMMI) プロセス テンプレートに用意されている作業項目の種類 (WIT) を使用して、ソフトウェア プロジェクトを計画し、その進行状況を追跡します。 チームは、作業のバックログを管理する要件を定義したうえで、かんばんボードを使用して、要件の状態を更新することで進行状況を追跡します。

製品所有者は、要件のポートフォリオを把握するために、要件を機能に割り当てることができます。 チームがイテレーションで作業する場合は、要件に自動的にリンクされるタスクを定義します。

テスト担当者は Microsoft Test Manager および Web ポータルを使用してテスト ケースを作成および実行し、バグを定義して、コードの不具合を追跡します。

チームは、追加の CMMI プロセスをサポートするために、レビュー会議でキャプチャされる変更要求、リスク、懸案事項、およびメモを追跡できます。

要件の定義と工数見積もりによるプロジェクトの計画

プロダクト バックログ ページでクイック追加パネルから要件を作成します。 また、Excel または Project を使用して、要件を一括追加することもできます。

後で、各要件を開いて詳細を指定し、そのサイズを見積もることができます。

要件では、チームによる作成が必要な機能および製品要素を指定します。 通常、要件の定義と順位付けは製品所有者がプロダクト バックログ ページで行います。 チームはそれに基づいて、最も優先度の高い項目を実現するための工数を見積もります。

要件の [サイズ] を定義すると、チームで予測機能とベロシティ グラフを使用して、今後のイテレーションや作業工数を見積もることができるようになります。 次のフィールドおよびタブを使用して、重要な情報を把握できます。 追加のガイダンスについては、「プロジェクトの計画」を参照してください。

フィールド/タブ	使用方法
サイズ (メモ 1 を参照)	必要条件を完了するために必要な作業量を見積もります。測定単位は、T シャツのサイズ、ストーリー ポイント、時間など、チームに適したものを使用できます。 このフィールドの値は、アジャイルのベロシティ グラフと予測ツールによって参照されます。 これは、ベロシティ グラフを生成するための必須フィールドです。
優先順位 [必須] (2)	業務に関連付けた場合の要件の主観的な評価。 次の値を指定できます。 1: 項目のない製品は出荷できません。 2: (既定) 項目のない製品は出荷できませんが、すぐに対処する必要はありません。 3: 項目の実装は、リソース、時間、およびリスクに応じて任意で対応します。
トリアージ [必須] (2)	作業項目が保留中であるトリアージ決定の種類を示します。 このフィールドは作業項目の状態が [提案済み] の場合に使用し、[保留中] (既定値)、[詳細]、[情報取得済み]、[トリアージ済み] のいずれかの値を指定します。
ブロック (2)	チーム メンバーの要件やタスクの実装が妨げられていないかどうか、またはバグ、懸案事項、タスク、変更要求の解決が妨げられていないかどうかを示します。 懸案事項を開いてブロッキングの問題を追跡している場合は、その懸案事項へのリンクを作成できます。 [はい] または [いいえ] を指定できます。
コミット [必須] (2)	プロジェクト内で要件がコミットされているかどうか。 [はい] または [いいえ] (既定) を指定できます。
(必要条件) 種類 [必須] (2)	実装する要件の種類。 次のいずれかの値を指定できます。 ビジネス目標 機能 (既定) 機能性 インターフェイス 操作性 サービス品質 安全性 シナリオ セキュリティ
説明	要件の実装に必要な作業量を見積もるのに十分な詳細情報を提供します。 要件の対象者、達成したい内容、およびその理由に焦点を当てます。 要件の開発方法は記述しないでください。 チームが、項目を実装するためのタスクとテスト ケースを作成できるように、十分な詳細情報を提供する必要があります。 HTML フィールドで、リッチ テキストおよびイメージを追加できます。
分析 (影響の評価)	この要件を実装しなかった場合の顧客への影響。 この要件が Surprise カテゴリ、Required カテゴリ、または Obvious カテゴリにあるかどうかについて、Kano モデルから詳細を含めることができます。 この情報は、影響の評価に対応するリッチ テキスト HTML フィールドでキャプチャします。
その他	[その他] タブにある次のフィールドは必須ではありません。 統合: 要件や変更要求を取り込んだり、バグを修正したりする製品ビルド番号。 ユーザー受け入れテスト [必須] (2): ユーザー受け入れテストの状態。 成功 失敗 準備不完了 (既定) 準備完了 スキップ 受信した情報 [準備不完了] は要件がアクティブのときに指定し、[準備完了] は要件が解決済みのときに指定します。 最初の見積もり (3): タスクの完了に必要な時間数または日数。 領域の専門家: この要件が表す顧客の区分に精通しているチーム メンバーの名前。 開始日、終了日 (3): 目標とする作業開始日または終了日。 Microsoft Project を使用してスケジュールすると、これらのフィールドが入力されます。

メモ:

1. フィールドの割り当てを変更するには、「チーム プロジェクトに合わせたアジャイル プランニング ツールの構成とカスタマイズ」を参照してください。

2. メニューの選択を変更する場合は、「選択リストをカスタマイズする」を参照してください。

3. 時間数または日数で作業を指定できます。 このフィールドに関連付けられた固有の時間単位はありません。

   Microsoft Project を使用してリソース割り当てまたはスケジュール管理を行うと、Project を使用して、これらのフィールドを更新できます。

進行状況の追跡

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

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

要件の通常のワークフローの流れを次に示します。

• 製品所有者は、既定の理由である [新しい要件] を使用して、[提案済み] 状態の必要条件を作成します。

• 実装作業が開始されると、製品所有者は状態を [アクティブ] に更新します。

• コードの開発が完了し、システム テストに合格すると、チームは状態を [解決済み] に更新します。

• 最後に、受け入れ基準に従って必要条件が実装され、すべての検証テストが成功したことに製品所有者が同意すると、チームまたは製品所有者は必要条件を [終了] に変更します。

機能への要件の割り当て

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

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

次の表に示すように、機能の作業項目には同様のフィールドが要件に対して用意されているほか、追加のフィールドも含まれます。

[必要条件] タブは、割り当てられた要件へのリンクをキャプチャします。

フィールド	使用法
ビジネス価値	1 つの機能について、他の機能と比較した相対的価値を表す数字を指定します。 数字が大きいほど、ビジネス価値は大きくなります。
目標とする日	機能の実装期限を指定します。

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

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

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

要件の実装に必要なタスクの定義、およびチーム キャパシティとバーンダウンの追跡

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

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

チームが作業を見積もるときは、タスクを定義し、タスクが完了するまでの時間数または日数を見積もります。 チームがイテレーションの開始時に作業を予測してタスクを定義し、各チーム メンバーはそのタスクのサブセットを実行します。 タスクには、開発、テストおよび他の作業を含めることができます。 たとえば、開発者は必要条件を実装するタスクを定義でき、テスト担当者はテスト ケースを記述して実行するタスクを定義できます。 タスクを必要条件やバグにリンクすると、これらの項目の進行状況を確認できます。 追加のガイダンスについては、「Iteration activities (イテレーションのアクティビティ)」を参照してください。

フィールド	使用方法
タスクの種類 (メモ 1 を参照)	許可値から実装するタスクの種類を選択します。 是正措置 軽減活動 計画済み
作業分野 (1)	チームでスプリント キャパシティをアクティビティ単位で見積もる場合に、このタスクが表す作業分野を選択します。 分析 開発 テスト ユーザー教育 ユーザー体験 このフィールドも、作業分野ごとにキャパシティを計算するために使用されます。 これは ProcessConfiguration ファイルの type="Activity" に割り当てられます。 (2) 追加のガイダンスについては、「Implement development tasks (開発タスクの実装)」を参照してください。
最初の見積もり (3)	このタスクを完了するために必要な見積もり作業量。 通常、このフィールドは、割り当てられた後は変更されません。
残存作業 (3)	作業完了まで何時間分または何日分の作業が残っているかを示します。 作業の進行状況に応じて、このフィールドを更新します。 これはキャパシティ グラフ、スプリント バーンダウン チャート、およびバーンダウンとバーン レート レポート レポートの計算に使用されます。 タスクをサブタスクに分割した場合は、サブタスクごとに時間を指定します。 作業は、チームで選択した任意の測定単位で指定できます。
実績作業 (3)	タスクの実行に費やされた作業量。

メモ:

1. メニューの選択を変更する場合は、「選択リストをカスタマイズする」を参照してください。

2. フィールドの割り当てを変更するには、「チーム プロジェクトに合わせたアジャイル プランニング ツールの構成とカスタマイズ」を参照してください。

3. 時間数または日数で作業を指定できます。 このフィールドに関連付けられた固有の時間単位はありません。

   Microsoft Project を使用してリソース割り当てまたはスケジュール管理を行うと、Project を使用して、これらのフィールドを更新できます。

ユーザー ストーリーでのテストの進行状況の追跡と、コードの不具合のキャプチャ

テストの要件

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

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

[テストされた要件] タブに、テスト ケースの要件とバグの一覧が表示されています。 リンクを使用すると、チームは各項目のテストの進行状況を追跡できます。必要条件の概要レポート (CMMI)レポートに表示される情報がサポートされます。

コード障害を追跡

バグは TWA や Visual Studio から、またはテスト マネージャーでテストを実行しているときに作成できます。 追加のガイダンスについては、「Track bugs (バグの追跡)」を参照してください。

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

レビュー会議でキャプチャされる変更要求、リスク、懸案事項、およびメモの追跡

次の WIT を使用すると、チームは CMMI プロセスで推奨される情報を追跡できます。

• 変更制御されている作業生産物に対して変更が提案されるたびに、変更要求を作成します。 追加の使用ガイダンスについては、「変更の管理」と「変更要求フィールド参照 (CMMI)」を参照してください。

  

  [分析] タブで、変更要求がアーキテクチャ、ユーザー エクスペリエンス、テスト、デザイン/開発、または技術発行物に与える影響の詳細を指定します。

• 懸案事項を作成して、作業を妨げる可能性があるイベントや状況、または製品の作業を妨げているイベントや状況を追跡します。 懸案事項がリスクと異なるのは、懸案事項が通常、毎日のチーム ミーティングで自発的に識別される点にあります。

  

  追加のガイダンスについては、「懸案事項の管理」と「バグ、懸案事項、およびリスクのフィールド参照 (CMMI)」を参照してください。

• リスクを作成して、作業を妨げる可能性があるイベントや状況、または製品の作業を妨げているイベントや状況を追跡します。 懸案事項がリスクと異なるのは、懸案事項が通常、毎日のチーム ミーティングで自発的に識別される点にあります。

  

  追加のガイダンスについては、「リスクの管理」と「バグ、懸案事項、およびリスクのフィールド参照 (CMMI)」を参照してください。

• レビューを作成して、デザイン レビューまたはコード レビューの結果を文書化します。 チーム メンバーは、名前の正確性、コードの関連性、拡張性、コードの複雑性、アルゴリズムの複雑性、およびコードの安全性の領域において、デザインまたはコードがどのように標準を満たしているかを詳細に確認できます。

  

  追加のガイダンスについては、「開発タスクの実装」と「レビュー会議のフィールド参照 (CMMI)」を参照してください。

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

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

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

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

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

追跡作業の開始

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

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

• 一般的な作業項目タスクについて理解するには、「作業項目を使用してプロジェクトを管理する」を参照してください。

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

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

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

Q & A

Q: CMMI はどのようなワークフローの状態をサポートしますか。

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

特性

必要条件

バグ

タスク

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

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

Q: どのフィールドがバックログ ページ内のリストの順序の管理に使用されますか。

A: [スタック順位] フィールドが、必要条件の相対的な順位付けを追跡するために使用されます。 プロダクト バックログ ページでの項目のシーケンスによって、どこに従って項目を追加したり、ページの項目を移動したかが特定されます。 項目をドラッグすると、バックグラウンド プロセスによってこのフィールドが更新され、ProcessConfiguration ファイルの type="Order" に割り当てられます。

このフィールドは、作業項目フォームに表示されません。 詳細については、「バックログの作成」を参照してください。

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

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