Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
この記事では、管理チームと機能チーム用にカスタマイズされたバックログ ビューをサポートするチームの階層を構成する方法について説明します。 階層的なチーム構造は、組織がアジャイルであり、集中し、戦略的な目標に沿っていることを保証するのに役立ちます。
Teams では、カスタマイズされたバックログ ビューを使用して、特定の目標と責任に基づいて独自の作業に優先順位を付け、管理できます。 管理チームは、機能チームのバックログとプロジェクト全体の進捗状況を把握できます。 この構造には、次の利点があります。
- さまざまな機能にわたるコラボレーション、コミュニケーション、チームワークを強化します。
- ワークフロー管理を合理化してプロセスを簡素化し、ボトルネックを軽減し、意思決定とプロジェクトの実行を高速化します。
- 各チームのワークロードの可視性を高めることで、プロジェクト全体のアカウンタビリティ、効率性、生産性をサポートします。
- 組織の目標に合わせて、すべてのチームが共通の目標に向かって作業できるようにします。
効果的なチーム構成により、各チームは責任と優先順位を明確かつ重点的に見ることができます。 機能チームは、関連のない作業項目に圧倒されることなく、重要なタスクに集中できます。 カスタマイズされたバックログにより、可視性が向上し、ワークロードと進行状況に関する明確な分析情報が提供されます。 チームがバックログを使用して最も重要な作業項目に優先順位を付け、集中する方法の詳細については、「 製品とポートフォリオのバックログを管理する」を参照してください。
前提条件
| カテゴリ | 必要条件 |
|---|---|
| プロジェクト アクセス | プロジェクト メンバー。 |
| アクセス許可 | プロジェクト管理者 セキュリティ グループのメンバー。 |
エリアごとにチームを追加する
階層的なチーム構造の設定を開始するには、機能と管理領域ごとにチームを追加するか、既に存在するチームの名前を変更します。 チームを追加するには:
Azure DevOps プロジェクトで、左側のナビゲーション メニューから [プロジェクトの設定>Teams ] を選択し、[ 新しいチーム] を選択します。
[ 新しいチームの作成 ] フォームで、チームに名前を付け、必要に応じて説明、メンバー、管理者を追加し、[ 作成] を選択します。
Note
チームを適切に定義するには、他のチーム管理者を追加して、他のチーム設定を確認または構成します。 詳細については、「チーム ツールの管理と構成」を参照してください。
各チームを追加するにはそれぞれ新しいチームを選択します。 既存のチームの名前を変更することもできます。 Teams リストでチームを選択し、[設定] タブを選択し、チームの詳細>チーム名の下に新しい名前を入力して、[保存] を選択します。
区分パスを階層構造に移動する
次に、管理チームの下にある機能チームを使用して、領域パスを階層構造に移動します。 次の例は、階層領域パス構造と比較した領域パスのフラット リストを示しています。
| フラット区分構造 | 階層区分構造 |
|---|---|
|
|
階層構造を作成するには:
[プロジェクト設定]で、[ボード]>[プロジェクト構成]を選択し、[領域]タブを選択します。
いずれかの機能チームに関連付けられているエリア パスの横にある [ その他のアクション ] アイコンを選択し、[ 編集] を選択します。
[場所] の [領域の編集] 画面で、管理チームエリアのパスを選択し、[保存して閉じる] を選択します。
すべての機能チーム エリア パスに対して、このプロセスを繰り返します。
プロジェクト設定>プロジェクト構成>Areas を使用して、各チームに割り当てられているエリア パスを確認し、必要に応じて割り当てを変更できます。
管理チームのサブ区分パスを含める
チーム バックログの既定の設定は、サブエリア パスを除外することです。 管理チームの場合は、機能チームのバックログ 項目が管理チームのバックログに自動的に含まれるように、サブエリア パスを含めることができます。
Note
サブエリア パスを含めると、チームがバックログのアイテムを並べ替えたり、親を変更したりする機能が妨げられる可能性があります。 サブエリア パスを含めると、バックログの [列]、[ 完了]、および [ レーン ] フィールドの割り当てに不確定性が生じる可能性もあります。 詳細については、「 共有領域パスに関する問題を理解する」を参照してください。
管理チームのエリア パスを定義するには:
[プロジェクトの設定>Teams] で、設定を変更する管理チームを選択します。
チームのページで、[ イテレーション] と [エリア パス] を選択します。
[Team Configuration>Boards] ページが開きます。 [ 領域 ] タブを選択し、[ 領域の選択] を選択します。
[ 領域の選択 ] 画面で、含めるチーム名の領域パスを選択し、[ サブ領域を含める ] チェック ボックスをオンにして、[ 保存して閉じる] を選択します。
[ 領域 ] ページで、チームに対してこのエリア パスのみが選択され、既定のエリア パスであることを確認します。 その他のエリア パスを削除します。
すべての管理チームに対してこの手順を繰り返します。 チームを切り替えるには、画面上部の階層リンク ナビゲーションでチーム セレクターを使用します。
すべての機能チームと管理区分で最上位レベルの区分へのロールアップを有効にする場合は、既定のチームに対してこのステップを繰り返します。
すべてのチームに対して 1 つのスプリント周期を定義する
機能チームがスクラムを使用している場合、またはスプリントを使用して作業を割り当てる場合は、すべてのチームが使用する一連のスプリントを設定できます。 プロジェクト設定>Boards>Project 構成ページには、既定で定義済みのスプリントのセットが表示されます。 「イテレーションの追加とイテレーションの日付の設定」の説明に従って、スプリントをさらに追加し、 プロジェクト設定 から 日付を設定できます。 必要に応じて、既定のスプリントの名前を変更および編集することもできます。
1 回のスプリント 周期を維持すると、プロジェクト管理が簡単になりますが、必要に応じて異なる周期を作成できます。 たとえば、月単位の周期に従うチームもあれば、3 週間の周期に従うチームもあります。
Fabrikam Fiber/CY2025 や Fabrikam Fiber/3Week Sprints など、各周期の最上位プロジェクト ノードの下にノードを定義し、それらのノードの下にスプリントを定義できます。 次の例では、3 週間の周期に対応する最初の 3 つのスプリントの開始日と終了日を定義します。
共有領域パスに関する問題を理解する
2 つ以上のチーム間でエリア パスを共有すると、次の場合に競合が発生する可能性があります。
- バックログまたはボード上の作業項目の並べ替えまたは親の変更。
- 項目を別の列にドラッグして、 ボード列、 ボード列完了、 およびボード レーン フィールドを更新します。
作業項目の並べ替えと親要素の再設定
バックログとボードでは、作業項目の並べ替えや親の変更を行うために、ドラッグ&ドロップ機能がサポートされています。 1 つのチームのバックログとボードで行われた変更は、同じ区分パスを共有する他のチームのバックログとボードに自動的に反映されます。 これらの更新内容を確認するには、ページの更新が必要な場合があります。
ドラッグ アンド ドロップを使用すると、チームのエリア パスに割り当てられている作業項目のみを並べ替えたり、親を変更したりできます。 [保護者] ビュー オプションが有効になっている場合、チームが所有していない作業項目がバックログに表示されることがあります。 これらの項目の横にある情報アイコンは、別のチームがアイテムを所有しているため、アイテムの並べ替えや親の変更ができないことを示します。
ボード列の更新
各チームはボード列とスイムレーンをカスタマイズできるため、チームが別のボードから作業項目を更新すると、ボード フィールドに割り当てられる値が異なる場合があります。 管理チームと機能チームが同じワークフロー マッピングを使用して ボード列 を構成した場合でも、あるチームのボード上の作業項目の更新は、別のチームのボードに自動的に反映されません。 ワークフロー状態にマッピングされた列に作業項目が移動した場合にのみ、すべてのボードでカード列が一貫して更新されます。
設計上、最も長いエリア パスを持つチームが競合解決の優先権を持ち、ボード列の、ボード列完了の、そして ボードレーンの フィールドの値を決定します。 複数のチームが同じ階層の区分パスを共有している場合、結果は不確定になります。
主な回避策は、 領域パスを定義し、特定のチームに割り当てることによって、作業項目の単一の所有権を維持することです。 または、すべてのチームが共通で使用できるカスタム ワークフロー状態を追加することもできます。 詳しくは、「ワークフローをカスタマイズする (継承プロセス)」を参照してください。