Azure Boards での CMMI プロセス作業項目の種類とワークフロー

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

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

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

テスト担当者は Microsoft Test Manager と Web ポータルを使って、テスト ケースを作成して実行し、バグを定義してコードの欠陥を追跡します。

チームは、その他の CMMI プロセスをサポートするために、レビュー会議で取り込む変更要求、リスク、問題、メモを追跡できます。 CMMI プロセスを初めて使う場合は、まずセクション「CMMI を使った作業の計画と追跡」を参照してください。

要件の定義

プロダクト バックログ ページでクイック追加パネルから要件を作成します。 後で、各要件を開いて詳細を指定し、そのサイズを見積もることができます。

また、cvs ファイルを使って要件を一括追加することもできます。

重要

Microsoft Project Integration および TFSFieldMapping コマンドは、以下ではサポートされていません。

• Visual Studio 2019 および Azure DevOps Office Integration 2019。
• Azure DevOps Server 2019 以降のバージョン (Azure DevOps Services を含む)。

Microsoft Excel 統合の完全なサポートは維持され、作業項目の一括インポートと更新がサポートされます。 Microsoft Project を使用する代わりに、次のような方法があります。

• 配信計画。
• Marketplace 拡張機能 (Project Connect または GANTT チャートなど)。

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

フォームに入力するときは、次のガイダンスを参考にしてください。複数の作業項目の種類で共通して使われるフィールドについて説明しています。 詳細については、「プロジェクトの計画」を参照してください。

フィールド

使用方法

---

説明

要件の実装に必要な作業量を見積もるのに十分な詳細情報を提供します。 要件の対象者、達成したい内容、およびその理由に焦点を当てます。 要件の開発方法は記述しないでください。 チームが、項目を実装するためのタスクとテスト ケースを作成できるように、十分な詳細情報を提供する必要があります。

HTML フィールドで、リッチ テキストおよびイメージを追加できます。

影響の評価

この要件を実装しなかった場合の顧客への影響。 この要件が Surprise カテゴリ、Required カテゴリ、または Obvious カテゴリにあるかどうかについて、Kano モデルから詳細を含めることができます。 この情報は、影響の評価に対応するリッチテキスト HTML フィールドに取り込みます。

要件の種類 (必須)

実装する要件の種類。 次のいずれかの値を指定できます。

• ビジネス目標
• 機能 (既定値)
• 機能
• Interface
• 操作性
• サービスの品質
• 安全性
• シナリオ
• Security

価値の分野

エピック、機能、要件、またはバックログ項目で扱う顧客価値の領域。 次の値が含まれます。

• アーキテクチャ: ソリューションを実現するビジネス機能を実装する技術サービス
• ビジネス: 顧客価値を直接提供してビジネスをサポートする顧客または利害関係者のニーズを満たすサービス (既定値)

[サイズ]

チームが好む任意の数値の測定単位を使って、要件を完成するために必要な作業量を見積もります。 要件の [サイズ] を定義すると、チームはアジャイルのベロシティ グラフと予測ツールを使い、今後のイテレーションや作業工数を見積もることができるようになります。 かんばんの累積フロー ダイアグラムはこのフィールドの値を参照します。 詳細については、「見積もり」のホワイト ペーパーを参照してください。

最初の見積もり

このタスクを完了するために必要な見積もり作業量。 通常、このフィールドは割り当てられた後は変わりません。

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

開始日/終了日

作業の開始または完了の目標日。

優先順位 (必須)

業務に関連付けた場合の要件の主観的な評価。 使用できる値は、以下のとおりです。

• 1: 項目のない製品は出荷できません。
• 2: (既定値) 項目のない製品は出荷できませんが、すぐに対処する必要はありません。
• 3: 項目の実装は、リソース、時間、リスクに応じて任意で対応します。

トリアージ (必須)

作業項目が保留中であるトリアージ決定の種類を示します。 このフィールドは作業項目の状態が [提案済み] の場合に使い、[保留中] (既定値)、[詳細]、[情報取得済み]、[トリアージ済み] のいずれかの値を指定します。

ブロック

チーム メンバーの要件やタスクの実装が妨げられていないかどうか、またはバグ、懸案事項、タスク、変更要求の解決が妨げられていないかどうかを示します。 懸案事項を開いてブロッキングの問題を追跡している場合は、その懸案事項へのリンクを作成できます。 [はい] または [いいえ] を指定できます。

コミット済み (必須)

プロジェクト内で要件がコミットされているかどうか。 [はい] または [いいえ] (既定値) を指定できます。

統合

要件や変更要求を取り込んだり、バグを修正したりする製品ビルド番号。

ユーザー受け入れテスト (必須)

要件のユーザー受け入れテストの状態。 次のいずれかの値を指定できます。

• 合格
• 失敗
• 準備不完了 (既定値)
• Ready
• スキップ
• 受信した情報

[準備不完了] は要件の状態がアクティブのときに指定し、[準備完了] は要件の状態が解決済みの場合に指定する必要があります。

対象分野の専門家

この要件が表す顧客の区分に精通しているチーム メンバーの名前。

---

[ディスカッション] セクションでコメントを取り込む

実行されている作業に関するコメントを追加および確認するには、[ディスカッション] セクションを使います。

リッチ テキスト エディターのツール バーは、テキスト入力領域の下に表示されます。 テキストの書式設定をサポートする各テキスト ボックスを選ぶと表示されます。

注意

[ディスカッション] の作業項目フィールドはありません。 [ディスカッション] 領域に入力されたコメントで作業項目のクエリを実行するには、[履歴] フィールドでフィルター処理します。 [ディスカッション] テキスト ボックスに入力したテキストの完全な内容が [履歴] フィールドに追加されます。

他のユーザー、グループ、作業項目、または pull request についてメンションする

他のユーザーにメンションするために行った最近の入力、作業項目へのリンク、または pull request へのリンクのメニューを開くには、 または を選ぶか、@、#、または ! を入力します。

名前または番号を入力すると、入力に合わせてメニュー リストがフィルター処理されます。 追加するエントリを選びます。 グループをディスカッションに参加させるには、@ とグループ名 (チームやセキュリティ グループなど) を入力します。

コメントを編集または削除する

ディスカッションのコメントを編集または削除するには、[編集] を選ぶか、 アクション アイコンを選んでから [削除] を選びます。

コメントを更新したら、[更新] を選びます。 コメントを削除するには、削除の意思を確認します。

編集および削除されたすべてのコメントの完全な監査証跡は、作業項目フォームの [履歴] タブに保持されます。

コメントにリアクションを追加する

コメントにリアクションを追加するには、コメントの右上隅にあるスマイル アイコンを選びます。 または、コメント下部の既存のリアクションの横にあるアイコンから選びます。 リアクションを削除するには、コメントの下部にあるリアクションを選びます。 次の図は、リアクションを追加するエクスペリエンスの例と、コメントに対する反応の表示を示したものです。

作業項目を保存せずにコメントを保存する

Note

この機能は、Azure DevOps Server 2022.1 以降で使用できます。

作業項目のディスカッションに追加するアクセス許可しかない場合は、コメントを保存することで追加できます。 このアクセス許可は、区分パス ノードと、[Edit work item comments in this node] (このノードの作業項目のコメントを編集する) アクセス許可によって制御されます。 詳細については、作業追跡アクセス許可の設定、子ノードの作成、区分またはイテレーション パスの下の作業項目の変更に関する記事を参照してください。

コメントを保存したら、作業項目を保存する必要はありません。

注意

[ディスカッション] コントロールで行った変更を保存すると、コメントのみが保存されます。 作業項目の種類に対して定義されている作業項目ルールは実行されません。

作業の進行状況を追跡する

作業の進行に応じて、[状態] フィールドを変更して状態を更新します。 必要に応じて理由を指定できます。 状態と理由のフィールドは作業項目フォームのヘッダー領域に表示されます。

CMMI ワークフローの状態

これらのダイアグラムは、要件、バグ、タスクの WIT の主な進行と回帰の状態を示しています。

要件	Bug	タスク

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

• 製品所有者は、既定の理由である [新しい要件] を使って、[提案済み] 状態の要件を作成します。
• 実装作業が開始されると、製品所有者は状態を [アクティブ] に更新します。
• コードの開発が完了し、システム テストに合格すると、チームは状態を [解決済み] に更新します。
• 最後に、受け入れ基準に従って要件が実装され、すべての検証テストが成功したことに製品所有者が同意すると、チームまたは製品所有者は要件を [終了] に変更します。

かんばんまたはタスクボードを使って作業状態を更新する

チームはかんばんボードを使って要件の状態を更新し、スプリント タスクボードを使ってタスクの状態を更新できます。 項目を新しい状態列にドラッグすると、[状態] フィールドと [理由] フィールドの両方が更新されます。

かんばんボードをカスタマイズして、その他のスイムレーンまたは列をサポートできます。 その他のカスタマイズ オプションについては、「作業追跡エクスペリエンスをカスタマイズする」を参照してください。

機能への要件の割り当て

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

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

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

タスクを定義する

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

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

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

フィールド

使用方法

タスクの種類

許可値から実装するタスクの種類を選択します。

• 是正措置

• 軽減活動

• 対応予定

規範

チームでスプリント キャパシティをアクティビティ単位で見積もる場合に、このタスクが表す規範を選択します。

• 分析

• 開発

• テスト

• ユーザー教育

• ユーザー エクスペリエンス

このフィールドも、規範ごとにキャパシティを計算するために使用されます。 これは ProcessConfiguration ファイルの type="Activity" に割り当てられます。 (2)

詳細については、「開発タスクを実装する」を参照してください。

最初の見積もり

このタスクを完了するために必要な見積もり作業量。 通常、このフィールドは割り当てられた後は変わりません。

残存作業

このタスクを完了するための残存作業量。 作業の進行状況に応じて、このフィールドを更新します。 これはキャパシティ グラフ、スプリント バーンダウン チャート、スプリント バーンダウン レポートの計算に使用されます。 タスクをサブタスクに分割した場合は、サブタスクごとに時間を指定します。 作業は、チームで選択した任意の測定単位で指定できます。

実績作業

タスクの実行に費やされた作業量。

テスト進行状況の追跡

テストの要件

Web ポータルまたは Test Manager から、要件またはバグに自動的にリンクするテスト ケースを作成できます。 または、 (リンク タブ) から要件をテスト ケースにリンクできます。

テスト ケースには多数のフィールドがあり、その多くが自動化され、Test Manager とビルド プロセスに統合されています。 各フィールドの説明については、「ビルドとテストの統合フィールドに基づいてクエリを作成する」を参照してください。

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

コード障害を追跡

バグは Web ポータルや Visual Studio から、または Test Manager でテストを実行しているときに作成できます。

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

要件、機能、タスク、バグの WIT と共に、CMMI プロセスで推奨される情報を次の WIT を使って追跡できます。

• 変更要求: 変更の管理下にある任意の作業製品に対する変更案を管理します。
• 問題: 作業を妨げる可能性がある、または製品の作業を妨げているイベントや状況を追跡します。 問題がリスクと異なるのは、通常、毎日のチーム ミーティングで、チームが自発的に問題は特定する点にあります。
• リスク: 実際の結果と望ましい結果の差異の確率と程度を追跡します。 リスクを管理するときは、期待する結果と実際の結果の間の相違を戦略的に最小限に抑えます。
• レビュー: デザイン レビューまたはコード レビューの結果を文書化します。 チーム メンバーは、名前の正確性、コードの関連性、拡張性、コードの複雑性、アルゴリズムの複雑性、コードの安全性の領域において、デザインまたはコードがどのように標準を満たしているかを詳細に取り入れることができます。
  
  問題は、チーム ダッシュボードに追加された [新しい作業項目] ウィジェット、または [クエリ] ページの [新規] メニューから追加できます。

ウィジェットから追加した作業項目のスコープは、チームの既定の区分パスとイテレーション パスに自動的に設定されます。 チーム コンテキストを変更するには、「チーム コンテキストの切り替え」を参照してください。

一般的な作業追跡フィールドの定義

次のフィールドとタブは、ほとんどの作業項目に表示されます。 各タブは、[履歴]、[リンク]、または [添付ファイル] など、特定の情報の追跡に使われます。 この 3 つのタブでは、変更の履歴、リンクされた作業項目の表示、ファイルの表示と添付機能を使用できます。

すべての作業項目の種類で必須である唯一のフィールドは [タイトル] です。 作業項目を保存すると、システムによって一意の ID が割り当てられます。 フォームでは、必須フィールドが黄色で強調表示されます。 その他のフィールドの詳細については、「作業項目フィールドのインデックス」を参照してください。

注意

プロセスとプロジェクトに加えられたカスタマイズによって、追加のフィールドが必要になることがあります。

フィールド/タブ

使用方法

---

タイトル

説明を 255 文字以下で入力します。 タイトルは、いつでも後から変更できます。

割当先

作業の実行を担当するチーム メンバーに、作業項目を割り当てます。

State

作業項目が作成されたときの、状態の既定値はワークフローの最初の状態です。 作業の進行状況に応じて、現在の状態を反映するように更新します。

理由

まず既定値を使用します。 状態を変更したときに更新します。 各状態には、既定の理由が関連付けられます。

領域

製品またはチームに関連付けられている区分パスを選択するか、計画会議で割り当てられるまでの空白のままにします。 区分のドロップダウン リストを変更するには、区分パスの定義とチームへの割り当てに関する記事を参照してください。

反復

作業を完了させる必要があるスプリントまたはイテレーションを選択するか、空白にしておいて後で計画会議で割り当てます。 イテレーションのドロップダウン リストを変更するには、「イテレーション パス (スプリント) の定義とチーム イテレーションの構成」を参照してください。

(履歴)

システムで記録された監査証跡を確認し、追加情報を記録します。

作業項目が更新されるたびに、情報が履歴に追加されます。 履歴には、変更が行われた日付、変更を行った人、および変更されたフィールドが含まれます。 書式設定されたテキストを [履歴] フィールドに追加することもできます。

(リンク)

ハイパーリンク、変更セット、ソース ファイルなど、すべての種類のリンクを追加します。

このタブには、作業項目に定義されているすべてのリンクも一覧表示されます。

(添付ファイル)

作業項目にファイル (電子メール スレッド、ドキュメント、イメージ、ログ ファイルなど) を追加して、詳細情報を共有します。

作業項目の種類のカスタマイズ

ほとんどの作業項目の種類の場合、作業項目フォームに対してフィールドの追加、ワークフローの変更、カスタム ルールの追加、カスタム ページの追加を行うことができます。 カスタム作業項目の種類を追加することもできます。 詳細については、「 継承プロセスをカスタマイズする」を参照してください。

関連記事

• プロジェクトの作成
• 作業項目を追加してプロジェクトを管理する
• バックログを作成する
• かんばんボードを追加する
• スプリントを計画する

バックログ リストの順序

[スタック順位] フィールドは、要件、機能、またはエピックの相対的な順位付けを追跡するために使われます。 ただし、既定では作業項目フォームに表示されません。 バックログ ページに表示される項目のシーケンスは、ページで項目を追加または移動した場所に従って決まります。 項目をドラッグすると、バックグラウンド プロセスでこのフィールドが更新されます。

このフィールドは、作業項目フォームに表示されません。