区分パスとイテレーション パス
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
エリア パスは、チーム、製品、または機能領域ごとに作業項目をグループ化します。 イテレーション パスは、作業をスプリント、マイルストーン、またはその他の時間関連期間にグループ化します。 どちらのフィールドも階層パスをサポートしています。
プロジェクトの領域とイテレーションのパスを定義し、チームはバックログおよびアジャイル ツールに使用するパスを選択できます。 アジャイル ツールが領域とイテレーションに依存する Agile ツールでこれらのパスを使用する方法について説明します。
Note
エリア パスと反復パスは、 分類ノードとも呼ばれます。 Classification Nodes (REST API)または Azure DevOps CLI コマンド az boards iteration を使用して、プログラムで管理できます。
Note
エリア パスと反復パスは、 分類ノードとも呼ばれます。 分類ノード (REST API) を使用してプログラムで管理できます。
領域とイテレーションは、プロジェクトの作成に使用されるプロセスによって異なります。 この例では、スクラム プロセスの既定の設定を示します。 日付は既定では設定されません。スプリントまたはリリース スケジュールに合わせて日付を設定する必要があります。
| イテレーション | Areas |
|---|---|
 |
 |
重要
- Area パスの削除または Iteration Paths の再構成により、元に戻せないデータ損失が発生します。 たとえば、 Area Paths が変更されたチームのバーンダウンおよびバーンアップ ウィジェット グラフ、スプリント バーンダウン、ベロシティ グラフでは、正確なデータは表示されません。 履歴傾向グラフは、作業項目ごとに定義された エリア パス と Iteration Path を参照します。 一度削除すると、これらのパスの履歴データを取得することはできません。
- 削除できるのは、作業項目で使用されなくなった領域パスと反復パスのみです。
エリア パスの定義と割り当て
プロジェクトとチームの管理を初めて使用する場合は、次の手順に従ってプロジェクトとチームを構成します。
- エリア パスの決定: 作業を分類するために必要な エリア パス の数と名前を特定します。 少なくとも、定義したチームごとに 1 つのエリア パスを追加します。
- チームを決定する: サポートするチームの数と名前を決定します。 詳細については、「 チームとアジャイル ツールについて」を参照してください。
- エリア パスを定義する: プロジェクト レベルで手順 1 と手順 2 をサポートするエリア パスを定義します。 エリア パスの追加の手順に従います。
- チームの定義: 手順 2. をサポートするために必要なチームを定義します。 詳細については、「 チームを追加し、1 つの既定のチームから複数のチームに移行するを参照してください。
- チーム設定の構成: 次の手順を使用して、各チームに既定のパスとその他のエリア パス割り当ててください。
- 作業項目の割り当て: 定義した領域パスに作業項目を割り当てます。 一括変更を使用して、複数の作業項目を一度に変更します。
Note
プロジェクトごとに最大 10,000 個の Area パス を定義し、1 つのチームに最大 300 Area パス を割り当てることができます。 詳細については、「 作業の追跡、プロセス、およびプロジェクトの制限」を参照してください。
同じ Area Path を複数のチームに割り当てることができますが、2 つのチームが同じ作業項目のセットに対して所有権を要求すると、問題が発生する可能性があります。 詳細については、「 マルチチーム ボード ビューの制限を参照してください。
次のアクションはいつでも実行できます。
- 子ノードを追加する
- エリア パスの名前を変更する (ルート エリア パスを除く)
- 子ノードを別のノードの下に移動する
- 子ノードを削除する
- チームの名前を変更する
- チームに対して行われたエリア パスの割り当てを変更する
詳細については、「チームの階層を構成する」を参照してください。
チームはいくつの領域を定義する必要がありますか?
チームの追跡性とセキュリティの要件をサポートする領域を追加します。 領域を使用して論理コンポーネントまたは物理コンポーネントを表し、特定の特徴を表す子領域を作成します。
次のいずれかのタスクを実行する必要がある場合は、領域を追加します。
- 製品または機能領域に基づいてクエリをフィルター処理する
- チームまたはサブチーム別に作業項目を整理またはグループ化する
- 作業項目の領域に基づいて作業項目へのアクセスを制限する
各チームは、バックログ項目、ユーザー ストーリー、要件、タスク、バグを整理するための領域の階層を作成できます。
過度に複雑なエリア構造を作成しないでください。 領域を使用して作業項目のアクセス許可をパーティション分割できますが、複雑なツリーではアクセス許可の管理に大きなオーバーヘッドが必要です。 他のプロジェクトで構造とアクセス許可を複製すると、面倒になる場合があります。
イテレーション パスを定義して割り当てる
プロジェクトとチームの Iteration Paths を構成するには、次の手順に従います。
- 定義領域パスのガイダンスを使用してエリア パスとチームを定義し、チームに割り当てます。
- サポートするイテレーションの長さを決定します。 すべてのチームで同じスプリント 周期を使用することをお勧めします。
- フラット構造とスプリントとリリースの階層のどちらを使用するかを決定します。
- プロジェクト レベルで手順 2 と 3 をサポートするイテレーション パスを定義します。 次の手順に従います イテレーションを追加し、イテレーションの日付を設定します。
- チーム構成を開き、各チームに既定、バックログ、およびその他のイテレーション パスを割り当てます。 次の手順に従います。 チーム設定を開く チームの既定のイテレーション パスを設定 します。
- 各チームは、 バックログ イテレーション パスに該当する作業項目にイテレーション パスを割り当てる必要があります。 これらの作業項目は、製品のバックログとボードに表示されます。 一括変更を使用して、複数の作業項目を一度に変更します。 「 バックログ項目をスプリントに割り当てる」も参照してください。
Note
プロジェクトごとに最大 10,000 Iteration Paths を定義し、1 つのチームに最大 300 Iteration Paths を割り当てることができます。 詳細については、「 作業の追跡、プロセス、およびプロジェクトの制限」を参照してください。
次のアクションはいつでも実行できます。
- 子反復ノードを追加する
- 反復パスの名前を変更する (ルート パスを除く)
- 子イテレーション パスを別のノードの下に移動する
- 子イテレーション パスを削除する
- チームに割り当てられている既定のイテレーション パスと選択したイテレーション パスを変更する
チームで定義する必要があるイテレーションの数はいくつですか?
プロジェクトのライフサイクルを反映するために、必要な数の子イテレーションを定義します。 これらのパスは、スプリント、プレベータ、ベータ結果、その他のリリース マイルストーンなどの一連のイベントを表します。 チームは通常、作業またはリリースのスケジュールが設定されていない場合、チームの既定のイテレーションに割り当てられた作業項目を残します。 プロジェクトのライフサイクルを反映するために、必要な数の子イテレーションを定義します。 これらのイテレーションは、スプリント、プレベータ、ベータ フェーズ、その他のリリース マイルストーンなど、さまざまなイベントを表すことができます。 Teams は通常、作業またはリリースのスケジュールが設定されていない場合、チームの既定のイテレーションに割り当てられた作業項目を残します。
イテレーションを追加して、次の要件をサポートします。
- スクラム チームがスプリントを 計画して実行するためのスプリントを定義する
- より複雑なマルチリリースサイクルとスプリントサイクルを設定する
- プロジェクトのスプリント、マイルストーン、またはサイクル時間に基づいてクエリをフィルター処理する
- ターゲット リリース サイクルに割り当てる準備ができていない将来の作業をサポートします。
次の例では、MyApplication プロジェクトに対して Beta 1、Beta 2、Release 1.0、Release 2.0 が定義されています。
製品の機能とタスクのバックログを作成するときに、チームが完了するタイミングに基づいてマイルストーンに割り当てます。 ニーズの変化に応じて、各主要なマイルストーンの下にイベントを追加して、チームの作業のスケジュールと管理方法を反映できます。
たとえば、ベータ 1 イテレーションには、Beta 1 期間のスプリントごとに 1 つずつ、3 つの子ノードが含まれるようになりました。
繰り返しでは、規則は適用されません。 たとえば、そのイテレーション中にタスクを閉じたり完了したりせずに、イテレーションにタスクを割り当てることができます。 イテレーションの最後に、アクティブな状態または開いているすべての作業項目を特定し、適切なアクションを実行します。 それらを別のイテレーションに移動することも、バックログに返すこともできます。
クエリを実行して、特定のイテレーションまたは一連のイテレーションに割り当てられている特徴と作業項目を検索し、作業項目を一括変更してイテレーション パスを変更できます。 詳細については、「日付または現在のイテレーション別の Query」を参照してください。
名前に関する制限
[エリア パス] フィールドと [反復パス] フィールド (データ型 = TreePath) は、円記号 (\) 文字で区切られた複数のノード項目で構成されます。 ノードの名前を最小限に抑え、子ノードを追加するときに次の制限に準拠していることを確認します。
| 制限の種類 | Restriction |
|---|---|
| ノード名の長さ | 255 文字を超えてはなりません。 |
| 予約済みの名前 | - 1 つまたは 2 つの期間...のみで構成することはできません。- PRN、COM1、COM2、COM3、COM4、COM5、COM6、COM7、COM8、COM9、COM10、LPT1、LPT2、LPT3、LPT4、LPT5、LPT6、LPT7、LPT8、LPT9、NUL、CON、AUX などのシステム予約名にすることはできません。 予約名の詳細については、「 ファイル名、パス、および名前空間」を参照してください。 |
| ノードの特殊文字 | - Unicode 制御文字を含めてはなりません。 - 次のいずれかの文字を含めてはなりません: \ / : * ? " < > | # $ & * +。- ローカル ファイル システムで禁止されている文字を含めてはなりません。 Windows の文字制限の詳細については、「 ファイル、パス、および名前空間の名前付け」を参照してください。 |
| パス名の長さ | 4,000 文字を超える Unicode 文字を含めてはなりません。 |
| パスの階層の深さ | 深さは 14 レベル未満である必要があります。 |