領域パスとイテレーション パス

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

エリア パスは、作業項目をチーム、製品、または機能エリアごとにグループ化します。 イテレーション パスは、作業をスプリント、マイルストーン、またはその他の時間に関連した期間にグループ化します。 どちらのフィールドも階層パスをサポートしています。

プロジェクトにエリア パスおよびイテレーション パスを定義すると、チームはバックログおよびアジャイル ツールで使用するパスを選択できます。 アジャイル ツールがこれらのパスをどのように使用するかは、アジャイル ツールによるエリア パスとイテレーション パスの使用方法に関する説明を参照してください。

エリアおよびイテレーションは、プロジェクトの作成に使用されるプロセスによって異なります。 この例では、スクラム プロセスの既定の設定を示します。 日付は既定では設定されません。スプリントまたはリリース スケジュールに合わせて日付を設定する必要があります。

イテレーション	Areas

エリア パスの定義と割り当て

プロジェクトとチームの管理を初めて使用する場合は、次の手順に従ってプロジェクトとチームを構成します。

1. [エリア パスの決定]: 作業を分類するために必要なエリア パスの数と名前を特定します。 定義する各チームに対して、少なくとも 1 つのエリア パスを追加します。
2. [チームの決定]: サポートするチームの数と名前を決定します。 詳細については、「 チームとアジャイル ツールについて」を参照してください。
3. [エリア パスの定義]: プロジェクト レベルで手順 1 および 2 をサポートするためのエリア パスを定義します。 「エリア パスの追加」の手順に従ってください。
4. [チームの定義]: 手順 2. をサポートするために必要なチームを定義します。 詳細については、チームの追加、既定チームから複数チームへの移行に関する説明を参照してください。
5. [チーム設定の構成]: これらの手順を使用して、各チームに既定およびその他のエリア パスを割り当てます。
6. [作業項目の割り当て]: 定義したエリア パスに作業項目を割り当てます。 [一括変更] を使用すれば、複数の作業項目をまとめて変更できます。

次の操作はいつでも実行できます。

• 子ノードの追加
• エリア パスの名前を変更する (ルート エリア パスを除く)
• 子ノードを別のノードの下に移動する
• 子ノードを削除する
• チームの名前を変更する
• チームに割り当てられたエリア パスを変更する

詳細については、「チーム階層を構成する」を参照してください。

1 つのチームが定義するエリアはどのくらいが適切ですか?

エリアは、チームのトレーサビリティとセキュリティ要件をサポートするために追加します。 エリアを論理コンポーネントまたは物理コンポーネントとして表し、特定の機能を表す子エリアを作成します。

次の作業が必要な場合は、エリアを追加します。

• 製品または機能領域に基づいてクエリをフィルター処理する
• 作業項目をチームまたはサブチーム別に整理またはグループ化する
• エリアに基づいて作業項目へのアクセスを制限する

各チームはエリア階層を作成して、バックログ アイテム、ユーザー ストーリー、要件、タスク、およびバグを整理できます。

過度に複雑なエリア構造を作成しないでください。 エリアを使用して、作業項目のアクセス許可を区分できますが、複雑なツリーではアクセス許可の管理に多大なリソースが必要です。 他のプロジェクトに構造とアクセス許可を複製するのは手間がかかることがあります。

イテレーション パスを定義して割り当てる

プロジェクトおよびチームに対してイテレーション パスを構成するには、次の手順を実行します。

1. 「エリア パスの定義とチームへの割り当て」の説明に従って、エリア パスとチームを定義します。
2. サポートするイテレーションの長さを決定します。 すべてのチームで同じスプリント 周期を使用することをお勧めします。
3. フラットな構造にするか、スプリントおよびリリースの階層にするかを決定します。
4. プロジェクト レベルで手順 2 および 3 をサポートするためのイテレーション パスを定義します。 「イテレーションの追加とイテレーションの日付の設定」の手順に従って操作します。
5. チーム構成を開き、各チームに既定、バックログ、およびその他のイテレーション パスを割り当てます。 チーム設定を開き、チームの既定のイテレーション パスを設定します。
6. 各チームは、バックログ イテレーション パスの配下にあるイテレーション パスを作業項目に割り当てる必要があります。 これらの作業項目は、製品バックログおよびボードに表示されます。 [一括変更] を使用すれば、複数の作業項目をまとめて変更できます。 「バックログ アイテムをスプリントに割り当てる」も参照してください。

次の操作はいつでも実行できます。

• 子イテレーション ノードを追加する
• イテレーション パスの名前を変更する (ルート パスを除く)
• 子イテレーション パスを別のノードの下に移動する
• 子イテレーション パスを削除する
• チームに割り当てられた既定および選択済みのイテレーション パスを変更する

1 つのチームが定義するイテレーションはどのくらいが適切ですか?

プロジェクト ライフサイクルを反映するために必要な数だけ、子イテレーションを定義してください。 これらのイテレーションは、スプリント、プレベータ、ベータ フェーズ、その他のリリース マイルストーンなど、さまざまなイベントを表すことができます。 通常、チームは作業やリリースのスケジュールがまだ決まっていない作業項目を、チームの既定イテレーションに割り当てたままにしておきます。

イテレーションは、次の要件に対応するために追加します。

• スクラム チームがスプリントを計画および実行するためにスプリントを定義する
• より複雑なマルチリリースおよびスプリント サイクルをセットアップする
• プロジェクトのスプリント、マイルストーン、またはサイクル時間に基づいてクエリをフィルター処理する
• ターゲット リリース サイクルに割り当てる準備ができていない将来の作業をサポートする。

次の例では、MyApplication プロジェクトに対して Beta 1、Beta 2、Release 1.0、Release 2.0 が定義されています。

製品機能やタスクのバックログを作成する際、チームが完了を見込んでいる時期に基づいて、それらをマイルストーンに割り当てます。 ニーズの変化に応じて、各主要マイルストーンの下にイベントを追加し、チームのスケジュールや作業の管理方法を反映できます。

たとえば、Beta 1 イテレーションには現在、Beta 1 期間中の各スプリントに対応する 3 つの子ノードが含まれています。

イテレーションにはいかなるルールも強制されません。 たとえば、タスクをイテレーションに割り当てても、そのイテレーション中に必ずしも完了またはクローズする必要はありません。 イテレーションの最後に、アクティブまたは未完了のまま残っているすべての作業項目を特定し、適切に対応します。 それらを別のイテレーションに移動することも、バックログに返すこともできます。

クエリを実行して、特定のイテレーションまたは一連のイテレーションに割り当てられている機能や作業項目を検索し、その後、一括変更で作業項目のイテレーション パスを変更できます。 詳細については、「日付または現在のイテレーションによるクエリ」を参照してください。

名前に関する制限

[エリア パス] フィールドおよび [イテレーション パス] フィールド (データ型 = TreePath) は、バックスラッシュ (\) で区切られた複数のノード項目で構成されます。 子ノードを追加する際は、ノード名を最小限に抑え、次の制限に従ってください。

関連コンテンツ

• エリア パスを定義してチームに割り当てる
• イテレーション パスの定義とチーム イテレーションの構成
• アジャイル ツールを使用してスプリントを定義する
• 日付または現在のイテレーションによるクエリの実行