Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022
Azure Boardsには、作業項目を管理するためのいくつかのプロセスが用意されています。 適切なプロセスを選択すると、プロジェクト ワークフローを最適化し、チームを成功に導きます。 この記事では、Azure Boardsで使用できるプロセスについて説明し、プロジェクトに適したプロセスを選択するのに役立ちます。
プロジェクトを作成するときは、組織またはコレクションが作成された対象の "プロセス モデル" に基づいて、"プロセス" または "プロセス テンプレート" を選びます。 プロジェクトのプロセスを選ぶ前に、次の用語を理解してください。
| Term | Description |
|---|---|
| プロセス モデル | 組織またはプロジェクト コレクション用に作成されたプロジェクトをサポートするために使われるモデルのことです。 1 つのプロジェクトで一度にサポートされるプロセス モデルは 1 つだけです。 |
| Process | 作業項目追跡システムの構成要素を定義し、Azure Boards の "継承" プロセス モデルをサポートします。 このモデルでは、Azure DevOps Web ポータルのビジュアル エディターを使用したプロジェクトのカスタマイズがサポートされています。 |
| プロセス テンプレート | 作業項目追跡システムの構成要素と、Azure DevOps を介してアクセスする他のサブシステムを定義します。 プロセス テンプレートは、"ホストされた XML" と "オンプレミス XML" のプロセス モデルでのみ使われます。 プロセス テンプレートの XML 定義ファイルを変更してインポートすることで、プロジェクトをカスタマイズできます。 |
既定のプロセスの種類は、 Basic、 Agile、 Capability Maturity Model Integration (CMMI)、 および Scrum です。 既定のプロセスとプロセス テンプレートの作業追跡オブジェクトは同じです。 この記事では、それらを要約します。
Tip
Azure DevOps Server では、 継承されたプロセス モデル または オンプレミスの XML プロセス モデルのいずれかを選択できます。 詳細については、「プロジェクト コレクションのプロセス モデルを選択する」を参照してください 。 既定のプロセスまたはプロセス テンプレートの最新バージョンにアクセスするには:
継承されたプロセス モデル: [プロセス] ページを開きます。 詳しくは、プロセスの管理に関する記事をご覧ください。
オンプレミスの XML プロセス モデル:
- 最新バージョンの Azure DevOps Server をインストールするか、アップグレードします。
- プロセス テンプレート マネージャーを使用して、zip 形式のテンプレート ファイルをダウンロードします。 Azure DevOps Server と同じバージョン レベルで Visual Studio のバージョンを使用します。 Visual Studio Community の最新バージョンを無料でインストールできます。
- Azure DevOps Server にインストールされている最新の既定のプロセス テンプレートにアクセスします (例:
%programfiles%/Azure DevOps Server 2020/Tools/Deploy/ProcessTemplateManagerFiles/1033)。 各ファイルとフォルダーの説明については、プロセス テンプレート ファイルの概要に関する記事をご覧ください。
既定のプロセス
既定のプロセスは、主に作業の計画と追跡に提供される作業項目の種類によって異なります。 次のガイドを使用して、チームに適したプロセスを選択します。
- 最も簡単なエクスペリエンスとして [ Basic ] を選択します。エピック、問題、タスクとして作業を追跡します。
- チームがアジャイル メソッドを使用していて、開発とテストのアクティビティを個別に使用してユーザー ストーリーを追跡する場合は、[ アジャイル ] を選択します。
- チームが スクラム に従い、製品バックログアイテムとバグを追跡する場合は、スクラムを選択します。
- チームで正式な変更管理、意思決定の監査可能な記録、要件、変更要求、リスク、レビューの追跡が必要な場合は、 CMMI を選択します。
適切なプロセスを選択する
チームに適したプロセスがわからない場合は、次のシナリオを出発点として使用します。
プロジェクトのプロセスを決定する
プロジェクトで使用するプロセスを見つけるには:
- Azure DevOps プロジェクトにサインインします。
- Project設定>Process を選択します。
プロセス名は、ページの上部に表示されます ( アジャイル、 スクラム、 Basic、 CMMI など)。
詳細については、「プロジェクトの 管理」を参照してください。
適切なプロセスを選択する
チームに適したプロセスがわからない場合は、次のシナリオを出発点として使用します。
| Scenario | 推奨プロセス | なぜでしょうか |
|---|---|---|
| Azure Boardsを初めて使用する場合や、最も軽量な追跡が必要な場合。 | Basic | 3 種類の作業項目 (エピック、イシュー、タスク) とシンプルな To Do / Doing / Done ワークフロー。 |
| チームはアジャイルを実践し、ユーザー ストーリーを追跡し、開発とテスト作業を分離します。 | Agile | 個別のバグ追跡を使用したユーザー ストーリー。より豊富な状態 (New、 Active、 Resolved、 Closed、 Removed)。 |
| チームは、スプリント、製品バックログ項目、および障害を使用してスクラムを実践します。 | Scrum | ボード上にあるプロダクト バックログ項目とバグでは、Approved 状態と Committed 状態がスクラムイベントに直接対応しています。 |
| 正式な変更管理、意思決定の監査可能な記録、リスクとレビューの追跡を必要とする規制された環境で作業します。 | CMMI | 要件、変更要求、リスク、レビュー作業項目の種類を追加し、正式な変更管理アクティビティをサポートします。 |
Important
プロジェクトの作成後にプロジェクトの基本プロセスを変更することはできません。 継承されたプロセスをカスタマイズしてフィールド、状態、作業項目の種類を追加したり、別のプロセスで新しいプロジェクトを作成したり、プロジェクト間で作業項目を移動したりできます。
Note
プロセスを選択またはカスタマイズするには、Project コレクション管理者グループのメンバーシップが必要です。 詳細については、「 既定のアクセス許可のクイック リファレンス」を参照してください。
| Process | 作業項目階層 |
|---|---|
|
Basic チームが、懸案事項、タスク、エピックの作業項目の種類を使用して作業を追跡する最も単純なモデルが必要な場合は、[基本] を選択します。 タスクは残存作業の追跡をサポートします。 |
|
|
Agile チームがスクラムなどのアジャイル計画手法を使用し、開発とテストのアクティビティを個別に追跡する場合は、アジャイルを選びます。 このプロセスは、ユーザー ストーリーや、必要に応じてボード上のバグを追跡する場合に適しています。 タスクボードでバグやタスクを追跡することもできます。 アジャイル方法論の詳細については、アジャイルアライアンスを参照してください。 タスクでは、最初の見積もり、残存作業、実績作業の追跡がサポートされています。 |
|
|
Scrum チームがスクラムを実践する場合は、スクラムを選びます。 このプロセスは、製品のバックログ項目やボード上のバグを追跡する場合に適しています。 また、製品バックログ項目とバグをタスクボード上のタスクに分割することもできます。 このプロセスでは、スクラム組織で定義されているスクラム手法がサポートされています。 タスクは、残存作業時間の追跡のみをサポートします。 |
|
|
CMMI プロセス改善と監査可能な意思決定の記録のためのフレームワークを必要とする、より正式なプロジェクト手法にチームが従う場合は、CMMI を選びます。 このプロセスでは、要件、変更要求、リスク、レビューを追跡できます。 このプロセスでは、正式な変更管理アクティビティがサポートされます。 タスクでは、最初の見積もり、残存作業、実績作業の追跡がサポートされています。 |
|
2 つまたは 3 つ以上のバックログ レベルが必要な場合は、使用するプロセス モデルに基づいて追加します。
- 継承: プロセスのバックログまたはボードをカスタマイズする
- ホストされた XML またはオンプレミス XML: ポートフォリオ バックログを追加する
既定のプロセスの主な相違点
既定のプロセスは、ほとんどのチームのニーズを満たします。 チームに普通とは異なるなニーズがあり、オンプレミスサーバに接続する場合は、プロセスをカスタマイズしてからプロジェクトを作成します。 または、プロセスからプロジェクトを作成し、プロジェクトをカスタマイズします。
次の表は、4 つのデフォルト プロセスで使用される作業項目の種類と状態の主な違いをまとめたものです。
| トラッキング領域 | Basic | Agile | スクラム | CMMI |
|---|---|---|---|---|
| ワークフローの状態 | - やること - 実行中 -完成です |
- 新規 -アクティブ - 解決済み - クローズ済み - 削除済み |
- 新規 -承認 - コミット済み -完成です - 削除済み |
-提案 -アクティブ - 解決済み - クローズ済み |
| 製品計画 (注 1 を参照) | -問題 | - ユーザー ストーリー - バグ (省略可能) |
- プロダクト バックログ項目 - バグ (省略可能) |
-要件 - バグ (省略可能) |
| ポートフォリオ バックログ (注 2 を参照) | - エピック | - エピック -機能 |
- エピック -機能 |
- エピック -機能 |
| タスクとスプリントの計画 (注 3 を参照) | -タスク | -タスク - バグ (省略可能) |
-タスク - バグ (省略可能) |
-タスク - バグ (省略可能) |
| バグ バックログ管理 (注 1 を参照) | -問題 | -バグ | -バグ | -バグ |
| 問題とリスク管理 | -問題 | -問題 | -障害 | - 変更要求 -問題 -リスク -レビュー |
Note
- product backlogまたはboardから作業項目を追加します。 製品バックログには、動的に並べ替えてグループ化できる作業の現在のバックログの 1 つのビューが表示されます。 製品の所有者は、作業に優先順位を付け、依存関係とリレーションシップの概要を示すことができます。 各チームは、 バックログやボードにバグを表示する方法を構成できます。
- ポートフォリオバックログの階層を定義して、複数のチームにわたる作業範囲を理解し、その作業がより広範なイニシアチブにどのように展開されるかを確認します。 各チームは、どのポートフォリオのバックログを使用するかを設定します。
- スプリント バックログとタスクボードからタスクを定義します。 キャパシティ プランニングを使用すると、チームは、スプリントの容量超過か容量不足かを判断できます。
ワークフローの状態、遷移、および理由
ワークフローの状態は、New 状態から Closed または Done 状態変化する作業状態の追跡をサポートします。 各ワークフローは、一連の状態、状態から状態へ有効な遷移、および選択された状態に作業項目が遷移する理由から構成されます。
Important
ワークフローの遷移:Azure DevOpsの既定のワークフローでは、任意の状態から任意の状態への遷移がサポートされます。 これらのワークフローをカスタマイズして、チームの要件に基づいて特定の遷移を制限できます。 詳細については、「作業追跡エクスペリエンスをカスタマイズする」を参照してください。
ワークフローの視覚化: 作業項目の種類ごとにサポートされているワークフロー遷移を表示するには、 State Model Visualization Marketplace 拡張機能をインストールします。 この拡張機能は、作業項目の種類を選択し、その完全なワークフロー状態モデルを表示できる状態 ビジュアライザー ハブを Boards の 下に追加します。
次の図は、3 つのデフォルト プロセスの作業とコードの欠陥を追跡するために使用される作業項目の種類の一般的な進捗を示しています。 また、以前の状態への回帰や、削除状態への遷移も示しています。
各イメージは、遷移に関連付けられている既定の理由のみを示しています。
ユーザー ストーリー
Feature
Epic
Bug
Task
アジャイル ツールで使用されるほとんどの作業項目の種類 (バックログとボードに表示されるもの) では、Any-to-Any トランジション がサポートされています。 ボードまたはタスクボードを使用して、作業項目の状態を更新します。 作業項目を対応する状態列にドラッグします。
他の状態、移行、および理由をサポートするようにワークフローを変更します。 詳細については、「作業追跡エクスペリエンスをカスタマイズする」を参照してください。
バックログでの削除、終了、完了の状態の動作
作業項目の状態を Removed、Closed、または Done に変更すると、システムは次のように応答します。
-
ClosedまたはDone: この状態の作業項目はポートフォリオバックログページやバックログページには表示されませんが、スプリントバックログページ、ボード、タスクボードに表示されます。 ポートフォリオ バックログ ビューを [ バックログ項目の表示 ] に変更すると (たとえば、製品バックログ項目と共に機能を表示する場合)、ClosedおよびDone状態の作業項目も表示されます。 -
Removed: この状態の作業項目は、どのバックログまたはボードにも表示されません。
Note
既定の CMMI ワークフローには、 Removed 状態は含まれません。 CMMI 作業項目をアクティブな追跡から除外するには、その状態を Closed に設定し、適切な理由 ( 遅延 や 拒否など) を選択します。
継承されたプロセスをカスタマイズして、チームにRemoved状態が必要な場合は追加できます。
プロジェクトがアクティブである限り、プロジェクトは作業項目を保持します。 作業項目を Closed、Done、または Removed に設定した場合でも、データ ストアはレコードを保持します。 このレコードを使用して、クエリまたはレポートを作成できます。
Note
- バックログとボードは、 変更日 が 183 日 (約 6 か月) より古い場合、完了または終了した作業項目を非表示にします。
- クエリを実行して非表示のアイテムを検索します。
- 変更日を更新するためにマイナー更新を行って、バックログまたはボードに項目をもう一度表示します。
Note
- バックログとボードは、 変更日 が 1 年以上経過すると、完了した作業項目または終了した作業項目を非表示にします。
- クエリを実行して非表示のアイテムを検索します。
- 変更日を更新するためにマイナー更新を行って、バックログまたはボードに項目をもう一度表示します。
作業項目を完全に削除する必要がある場合は、作業項目の削除に関する記事をご覧ください。
すべてのプロセスに追加された作業項目の種類
次の作業項目の種類は、基本プロセスを除くすべてのプロセスに追加されます。
チームは、対応するツールを使用して、これらのタイプを作成および操作できます。 これらの作業項目の種類は、互換性の履歴のためにスキーマに残ります。 Microsoftテスト マネージャーとチーム エクスプローラーのマイ ワーク エクスペリエンスは、Web ポータルに大きく置き換えられる従来のツールです。
| Tool | 作業項目の種類 |
|---|---|
| Microsoft テスト マネージャー (レガシ) |
Test Plan、 Test Suite、 Test Case Shared Steps、 Shared Parameters |
| フィードバックを要求する |
Feedback Request、Feedback Response |
| マイ ワーク (チーム エクスプローラー、レガシから)、コード レビュー |
Code Review Request、Code Review Response |
これらの型定義から作業項目を手動で作成することはできません。
Hidden Types カテゴリに追加されます。
Hidden Types カテゴリーにつかされた作業項目は、新しい作業項目を作成するメニューには表示されません。
テスト エクスペリエンスをサポートする作業項目の種類
次の図に示すリンクの種類は、テスト エクスペリエンスをサポートする作業項目の種類を接続し、テスト マネージャーと Web ポータルで動作します。
Web ポータルまたはテスト マネージャー Microsoftから、テスト スイートに対して定義されているテスト ケースを表示し、テスト 計画に対して定義されているテスト スイートを表示できます。 ただし、これらのオブジェクトはリンクの種類を通して相互に接続されることはありません。 他の作業項目の種類と同様に、これらの作業項目の種類をカスタマイズします。 詳細については、「作業追跡エクスペリエンスをカスタマイズする」を参照してください。
テスト計画とテスト スイートのワークフローを変更する場合は、この記事の説明に従ってプロセス構成の更新が必要になる場合があります。 各テスト フィールドの定義については、「 ビルドおよびテスト統合フィールドに基づくクエリの作成」を参照してください。