Azure DevOps サービス |Azure DevOps Server |Azure DevOps Server 2022
チームを追加したり、既存のチームを再編成したりする場合は、エリア パスを更新して、あるチームから別のチームに作業項目を転送する必要があります。 Azure DevOps内のすべての作業項目はエリア パスに割り当てられます。これはチームの所有権を決定し、バックログやボードでの作業項目の表示方法に影響します。
[要件] カテゴリに分類された作業項目は、チームエリアパスへの割り当てに基づいてチームバックログに表示されます。 同様に、その他の作業項目もチームのエリア パスに割り当てることで、チーム所有に基づいたクエリやレポートに対応できます。
ヒント
この記事の後半で、AI を用いてこのタスクを補助することができます。または、Azure DevOps MCP Server で AI 支援を有効にする方法を参照して作業を開始してください。
チーム間で作業項目を移動する理由
作業項目を移動する一般的なシナリオは次のとおりです。
- チームの再編成: 組織がチームを再構築したり、責任を再配布したりする場合
- ワークロードの分散: チーム間で容量のバランスを取るために作業項目を再配布する
- スキルの調整: 適切な専門知識を持つチームにアイテムを移動する
- 機能の所有権の譲渡: 機能が変更されたときに所有権を譲渡する
- プロジェクトの統合: 複数のチームの作業を 1 つのチームにまとめる
前提条件
| カテゴリ | 要求事項 |
|---|---|
| Permissions | - 作業項目を表示、フォロー、編集するには: [このノードの作業項目の表示] および [このノードの作業項目の編集] アクセス許可を [許可] に設定します。 デフォルトでは、 Contributors グループにこれらの権限が与えられます。 詳細については、「作業追跡権限を設定する」を参照してください。 - 作業項目にタグを追加するには、プロジェクト レベルの [新しいタグの定義を作成] アクセス許可を [許可] に設定します。 デフォルトでは、 Contributors グループにこの権限が与えられます。 |
| アクセス レベル | プロジェクト メンバー。 作業項目に新しいタグを追加したり、プルリクエストを表示またはフォローしたりするには、少なくとも Basic アクセスが必要です。 - 作業項目を表示またはフォローするには:最低でも ステークホルダー アクセス権が必要です。 詳細については、「アクセス レベルについて」を参照してください。 - 閲覧者 グループのメンバーを含むすべてのプロジェクト メンバーは、作業項目を含む電子メールを送信できます。 |
| エリアパス権限 | [エリア パス]ノードの下の作業項目を表示および編集します。 詳細については、エリア パスまたはイテレーション パスにある作業項目の変更に関する記事を参照してください。 |
| 構成済みのエリア パス | ターゲット チームは、エリア パスを正しく構成しました。 そうでない場合は、作業項目を転送する前に必要なエリア パスを設定します。 |
| 一貫性のあるプロセス モデル | チームは、互換性のあるプロセス モデル (継承、ホストされた XML、またはオンプレミスの XML) を使用して、作業項目のシームレスな移動を保証します。 |
| バックアップされた作業項目 | エラーが発生した場合にデータが失われないように、一括移動を実行する前に作業項目をバックアップまたはエクスポートすることをお勧めします。 |
| ツール | Azure CLIコマンドを使用するには:Azure DevOps CLI。 |
| カテゴリ | 要求事項 |
|---|---|
| Permissions | - 作業項目を表示、フォロー、編集するには: [このノードの作業項目の表示] および [このノードの作業項目の編集] アクセス許可を [許可] に設定します。 デフォルトでは、 Contributors グループにこれらの権限が与えられます。 詳細については、「作業追跡権限を設定する」を参照してください。 - 作業項目にタグを追加するには、プロジェクト レベルの [新しいタグの定義を作成] アクセス許可を [許可] に設定します。 デフォルトでは、 Contributors グループにこの権限が与えられます。 |
| アクセス レベル | プロジェクト メンバー。 作業項目に新しいタグを追加したり、プルリクエストを表示またはフォローしたりするには、少なくとも Basic アクセスが必要です。 - 作業項目を表示またはフォローするには:最低でも ステークホルダー アクセス権が必要です。 詳細については、「アクセス レベルについて」を参照してください。 - 閲覧者 グループのメンバーを含むすべてのプロジェクト メンバーは、作業項目を含む電子メールを送信できます。 |
| エリアパス権限 | [エリア パス]ノードの下の作業項目を表示および編集します。 詳細については、エリア パスまたはイテレーション パスにある作業項目の変更に関する記事を参照してください。 |
Web ポータルを使用して作業項目を移動する
チーム間で複数の作業項目を移動する最も効率的な方法は、Web ポータルでの一括編集です。
手順 1: 作業項目を識別するクエリを作成する
新しいチームに移動するすべての作業項目を検索するクエリを作成します。
- BoardsQueries新しいクエリに移動します
- 作業項目を識別するクエリ条件を定義します。次に例を示します。
- エリア パス = 現在のチームのエリア パス
- 作業項目の種類 = ユーザー ストーリー (またはその他の関連する種類)
- 状態 = アクティブ (またはその他の関連する状態)
- クエリを実行して、正しい作業項目が返されたことを確認する
- 後で参照するためにクエリを保存する
手順 2: エリア パスを一括編集する
作業項目を新しいチームに移動するには:
割り当てを変更するすべての作業項目のクエリを作成します。
各チームに属するアイテムを複数選択し、 エリア パスを一括編集します。
Web ポータルの [クエリ] ページで、選択した作業項目を選択して一括変更しているスクリーンショット。
[一括編集] ダイアログで、次の手順を実行します。
- フィールド ドロップダウンから [エリア パス ] を選択する
- ターゲット チームの Area Path を選択する
- 必要に応じて、[割り当て先] や [反復パス] などの他のフィールドを更新します
項目を一括変更したら、それらを一括保存します。
編集した作業項目を一括保存しているスクリーンショット。
手順 3: 移動を確認する
保存後、作業項目がターゲット チームのバックログに表示されることを確認します。
- ターゲット チームのバックログに移動する
- 移動した作業項目が正しいバックログに表示されたことを確認する
- [エリア パス] フィールドに新しいチームの割り当てが反映されていることを確認します
Azure CLIを使用して作業項目を移動する
az boards work-item update を使用して、そのエリア パスを更新することで、1 つの作業項目を移動できます。
az boards work-item update --id
[--area]
[--assigned-to]
[--description]
[--discussion]
[--fields]
[--iteration]
[--open]
[--reason]
[--state]
[--title]
パラメーター
- id: 必須。 更新する作業項目の ID。
- area: 任意。 エリアの絶対パス。 例: --area "\ProjectName\Area\AreaName"
- assigned-to: 任意。 作業項目が割り当てられているユーザーの名前 ("Jamal" など)。
- description: 任意。 作業項目の説明。
- discussion: 任意。 作業項目のディスカッションに追加するコメント。
- fields: 任意。 設定するカスタム フィールドの "フィールド=値" のペアを半角スペースで区切って指定。
- iteration: 任意。 イテレーションの絶対パス。 例:「\ProjectName\Iteration\IterationName」。
- open: 任意。 作業項目を既定の Web ブラウザーで開きます。
- reason: 任意。 作業項目の状態に対する理由。
- state: 任意。 作業項目の状態 ("アクティブ" など)。
- title: 任意。 作業項目のタイトル。
例
Azure DevOps CLI を使用して一度に移動できる作業項目は 1 つだけです。 この例では、作業項目 ID=148 を Fabrikam Fiber\Production Planning のエリア パスに移動します。
az boards work-item update --id 148 --area "Fabrikam Fiber\Production Planning" --output yaml
次の YAML 出力には、対象の作業項目の各フィールドに定義されている情報が含まれています。
fields:
Microsoft.VSTS.Common.Priority: 2
Microsoft.VSTS.Common.StackRank: 1500000001.0
Microsoft.VSTS.Common.StateChangeDate: '2021-11-23T22:26:28.27Z'
Microsoft.VSTS.Common.ValueArea: Business
System.AreaPath: Fabrikam Fiber\Production Planning
System.AssignedTo:
_links:
avatar:
href: https://fabrikamprime.visualstudio.com/_apis/GraphProfile/MemberAvatars/aad.NDEwY2FkMDQtOWQyOS03NDFlLTk2MmEtNGZlYmU2NGE1NTM4
descriptor: aad.NDEwY2FkMDQtOWQyOS03NDFlLTk2MmEtNGZlYmU2NGE1NTM4
displayName: Jamal Hartnett
id: d291b0c4-a05c-4ea6-8df1-4b41d5f39eff
imageUrl: https://fabrikamprime.visualstudio.com/_apis/GraphProfile/MemberAvatars/aad.NDEwY2FkMDQtOWQyOS03NDFlLTk2MmEtNGZlYmU2NGE1NTM4
uniqueName: fabrikamfiber4@hotmail.com
url: https://spsprodeus27.vssps.visualstudio.com/A5d5b8da6-3db7-4829-baf9-1e500c21cc12/_apis/Identities/d291b0c4-a05c-4ea6-8df1-4b41d5f39eff
System.BoardColumn: Backlog
System.ChangedBy:
_links:
avatar:
href: https://fabrikamprime.visualstudio.com/_apis/GraphProfile/MemberAvatars/aad.NDEwY2FkMDQtOWQyOS03NDFlLTk2MmEtNGZlYmU2NGE1NTM4
descriptor: aad.NDEwY2FkMDQtOWQyOS03NDFlLTk2MmEtNGZlYmU2NGE1NTM4
displayName: Jamal Hartnett
id: d291b0c4-a05c-4ea6-8df1-4b41d5f39eff
imageUrl: https://fabrikamprime.visualstudio.com/_apis/GraphProfile/MemberAvatars/aad.NDEwY2FkMDQtOWQyOS03NDFlLTk2MmEtNGZlYmU2NGE1NTM4
uniqueName: fabrikamfiber4@hotmail.com
url: https://spsprodeus27.vssps.visualstudio.com/A5d5b8da6-3db7-4829-baf9-1e500c21cc12/_apis/Identities/d291b0c4-a05c-4ea6-8df1-4b41d5f39eff
System.ChangedDate: '2022-05-19T22:58:52.93Z'
System.CommentCount: 0
System.CreatedBy:
_links:
avatar:
href: https://fabrikamprime.visualstudio.com/_apis/GraphProfile/MemberAvatars/aad.NDEwY2FkMDQtOWQyOS03NDFlLTk2MmEtNGZlYmU2NGE1NTM4
descriptor: aad.NDEwY2FkMDQtOWQyOS03NDFlLTk2MmEtNGZlYmU2NGE1NTM4
displayName: Jamal Hartnett
id: d291b0c4-a05c-4ea6-8df1-4b41d5f39eff
imageUrl: https://fabrikamprime.visualstudio.com/_apis/GraphProfile/MemberAvatars/aad.NDEwY2FkMDQtOWQyOS03NDFlLTk2MmEtNGZlYmU2NGE1NTM4
uniqueName: fabrikamfiber4@hotmail.com
url: https://spsprodeus27.vssps.visualstudio.com/A5d5b8da6-3db7-4829-baf9-1e500c21cc12/_apis/Identities/d291b0c4-a05c-4ea6-8df1-4b41d5f39eff
System.CreatedDate: '2021-11-23T22:26:28.27Z'
System.Description: <div>This user story is for documentation purposes. </div>
System.IterationPath: Fabrikam Fiber\Release 2\Sprint 1
System.Reason: New
System.State: New
System.TeamProject: Fabrikam Fiber
System.Title: Test the Request feedback functionality
System.WorkItemType: User Story
WEF_10182DA5BCCD4CE2A43629FFBD290EF2_Kanban.Column: Backlog
id: 148
relations:
- attributes:
isLocked: false
name: Child
rel: System.LinkTypes.Hierarchy-Forward
url: https://fabrikamprime.visualstudio.com/854a3f67-9962-43d1-a968-2e5f2eb66c99/_apis/wit/workItems/152
- attributes:
isLocked: false
name: Child
rel: System.LinkTypes.Hierarchy-Forward
url: https://fabrikamprime.visualstudio.com/854a3f67-9962-43d1-a968-2e5f2eb66c99/_apis/wit/workItems/153
- attributes:
isLocked: false
name: Child
rel: System.LinkTypes.Hierarchy-Forward
url: https://fabrikamprime.visualstudio.com/854a3f67-9962-43d1-a968-2e5f2eb66c99/_apis/wit/workItems/151
- attributes:
isLocked: false
name: Child
rel: System.LinkTypes.Hierarchy-Forward
url: https://fabrikamprime.visualstudio.com/854a3f67-9962-43d1-a968-2e5f2eb66c99/_apis/wit/workItems/149
rev: 5
url: https://fabrikamprime.visualstudio.com/854a3f67-9962-43d1-a968-2e5f2eb66c99/_apis/wit/workItems/148
Azure CLIでの一括移動
Azure CLIを使用して複数の作業項目を移動するには、複数の個別の更新をスクリプト化する必要があります。 PowerShell スクリプト パターンの例を次に示します。
# Example: Move multiple work items to a new area path
$workItemIds = @(148, 149, 150, 151)
$newAreaPath = "Fabrikam Fiber\Production Planning"
foreach ($id in $workItemIds) {
az boards work-item update --id $id --area $newAreaPath
Write-Host "Moved work item $id to $newAreaPath"
}
作業項目を移動するためのベスト プラクティス
チーム間で作業項目を移動する場合は、次のガイドラインを考慮してください。
移動の計画
- コミュニケーション: 作業項目を移動する前に影響を受けるチーム メンバーに通知する
- タイミング: 中断を最小限に抑えるためにスプリント境界の間に項目を移動する
- 依存関係: 移動する前に作業項目間の依存関係を確認する
- 容量: ターゲット チームに追加作業の容量があることを確認する
移動中
- バッチ処理: 関連する作業項目を一緒に移動してコンテキストを維持する
- 履歴を保持する: 項目を移動すると、その履歴とリレーションシップが保持されます
- 割り当ての更新: 作業項目をターゲット チームのメンバーに再割り当てすることを検討する
- イテレーションのレビュー: チームが異なるスプリント スケジュールを使用している場合はイテレーション パスを更新する
移行後
- 可視性の確認: 作業項目が正しいチーム バックログに表示されていることを確認する
- ドキュメントの更新: 移動されたアイテムを参照するすべてのチーム ドキュメントを更新する
- レポートの確認: チーム レポートとダッシュボードに変更が反映されていることを確認する
- 補足情報: 転送された作業についてチーム メンバーが把握していることを確認する
トラブルシューティングと検証
作業項目をあるチームから別のチームに移動した後、作業項目が表示されない場合は、次の手順に従います。
一般的な問題と解決策
| 問題点 | 解決策 |
|---|---|
| 作業項目がバックログに表示されない | エリア パスがチームの構成済みエリア パスと一致するかどうかを確認する |
| 移動中のアクセス許可エラー | ソースエリアパスとターゲットエリアパスの両方に対する編集権限があることを確認します |
| スプリントに不足している作業項目 | ターゲット チームのスプリント スケジュールに合わせてイテレーション パスを更新する |
| 作業項目を非表示にするフィルター | バックログ フィルターと作業項目の種類の設定を確認する |
確認手順
- 更新: ボードを更新するか、新しく追加した作業項目が表示されない場合は 「その他のアイテムを表示」を選択します。
- チームを確認する: 正しいチームを選択して、アイテムがバックログに表示されることを確認します。
- エリア パスの確認: 移動された作業項目が、チームのバックログに対応する適切なエリア パスに割り当てられていることを確認します。 各チームには、バックログに表示される作業項目を決定する特定のエリア パスがあります。 この検証は、バックログの可視性を確保するために重要です。
- イテレーション パスの確認: スプリントのイテレーション パスを確認します。 スプリント バックログには、選択したスプリントのイテレーション パスに割り当てられた作業項目のみが表示されます。
- 作業項目の種類とフィルターを確認する: バックログ フィルターを確認し、作業項目の種類に適切な分類が設定されていることを確認して、関連するすべての項目を表示します。
詳細については、「 バックログの作成」を参照してください。
大規模な移動に関する考慮事項
多数の作業項目を移動するとき、または複数のチームを再編成する場合:
計画に関する考慮事項
- 影響評価: 影響を受けるレポート、ダッシュボード、クエリを分析する
- 変更管理: 影響を受ける利害関係者のコミュニケーション計画を策定する
- ロールバック計画: 問題が発生した場合に変更を取り消す計画を準備する
- テスト: 作業項目の小さなサブセットを最初に使用して移動プロセスをテストする
実行戦略
- 段階的なアプローチ: 作業項目を一度にすべてではなく段階的に移動する
- 時間外の実行: アクティビティの少ない期間中に大きな移動を実行する
- 監視: 一括操作中のパフォーマンスへの影響を監視する
- 検証: 次のフェーズに進む前に各フェーズを確認する
代替アプローチ
作業項目の代わりにチームを移動する
個々の作業項目を移動するのではなく、チームエリアパスを再構成する方が効率的な場合があります。
- チームの作業項目の大部分を移動する必要がある場合
- エリア パスの再編成が組織的により理にかなっている場合
- 作業項目の量が非常に多い場合
段階的な遷移にクエリを使用する
作業項目を段階的に切り替えるクエリを作成します。
- 作成日でフィルター処理して新しい項目を最初に移動する
- 作業項目の状態を使用して完了したアイテムを個別に移動する
- 体系的な切り替えのための作業項目の種類別のグループ化
AI を使用してチーム間で作業項目を移動する
Azure DevOps MCP Server を構成する場合は、エリア パスを手動で更新するのではなく、自然言語を使用してチーム間で作業項目を移動できます。
| Task | プロンプトの例 |
|---|---|
| アイテムを別のチームに移動する | Move all active user stories in area path <Contoso\\TeamAlpha> to <Contoso\\TeamBeta> |
| 作業項目の種類別に再割り当てする | Change the area path for all bugs assigned to <Jamal> from <Contoso\\Frontend> to <Contoso\\Backend> |
| 移動するアイテムを検索する | List all work items in area path <Contoso\\OldTeam> grouped by work item type |
| 移動後に確認する | Show all work items moved to area path <Contoso\\NewTeam> in the last 7 days |
| 移動の影響をプレビューする | How many work items are currently under area path <Contoso\\TeamAlpha> and what are their states? I'm planning to move them to <Contoso\\TeamBeta> |
| 移動と再割り当て | Move all active tasks under <Contoso\\Platform> to <Contoso\\Infrastructure> and reassign them from <Raisa> to <Christie> |
| 再編成後に孤児になったアイテムを検索する | List work items whose area path doesn't match any active team's configured area paths in project <Contoso> |
| スプリントによる一括移動 | Move all incomplete work items from Sprint 11 in area path <Contoso\\TeamAlpha> to area path <Contoso\\TeamBeta> and assign to Sprint 12 |
| チーム間の移動を監査する | Show all work items that changed area path in the last 30 days in project <Contoso>, grouped by source and destination team |
| 子項目を使用して移動する | Move feature #4500 and all its child user stories and tasks from <Contoso\\Frontend> to <Contoso\\FullStack> |
注
Visual Studio Codeを使用している場合、agent モードは、チーム間での一括移動に特に役立ちます。
関連コンテンツ
- チームを作成または追加する
- チームとアジャイル ツールについて学習する
- チームの設定を構成する
- チームのエリア パスを設定する
- 作業項目を一括で変更する