増分型の移行作業での変更を管理するManage change in an incremental migration effort

この記事では、移行プロセスが本質的に増分型であり、管理プロセスと並列に実行されることを前提にしています。This article assumes that migration processes are incremental in nature, running parallel to the govern process. ただし、同じガイダンスを、従来のウォーターフォール変更管理アプローチで作業分解構造の初期タスクを設定するために使用することもできます。However, the same guidance could be used to populate initial tasks in a work breakdown structure for traditional waterfall change management approaches.

リリース バックログRelease backlog

_リリース バックログ_は、ワークロードをクラウドの運用環境で使用するためにリリースする前に移行する必要がある一連の資産 (特に、VM、データベース、ファイル、およびアプリケーション) で構成されます。A release backlog consists of a series of assets (VMs, databases, files, and applications, among others) that must be migrated before a workload can be released for production usage in the cloud. 各イテレーション中に、クラウド導入チームは、各資産をクラウドに移動するために必要な作業を文書化して見積もります。During each iteration, the cloud adoption team documents and estimates the efforts required to move each asset to the cloud. 後に続く「イテレーション バックログ」のセクションを参照してください。See the "iteration backlog" section that follows.

イテレーション バックログIteration backlog

_イテレーション バックログ_は、特定の数の資産を既存のデジタル資産からクラウドに移行するために必要な詳細な作業の一覧です。An iteration backlog is a list of the detailed work required to migrate a specific number of assets from the existing digital estate to the cloud. この一覧にあるエントリは多くの場合、Azure DevOps などのアジャイル管理ツールで作業項目として格納されます。The entries on this list are often stored in an agile management tool, like Azure DevOps, as work items.

最初のイテレーションを開始する前に、クラウド導入チームはイテレーション期間 (通常は 2 から 4 週間) を指定します。Prior to starting the first iteration, the cloud adoption team specifies an iteration duration, usually two to four weeks. この時間ボックスは、コミットされたアクティビティのセットごとの開始および完了期間を作成するために重要です。This time box is important to create a start and finish time period for each set of committed activities. 一貫した実行ウィンドウを維持すると、速度 (移行のペース) や変化するビジネス ニーズへの整合の測定が容易になります。Maintaining consistent execution windows makes it easy to gauge velocity (pace of migration) and alignment to changing business needs.

各イテレーションの前に、チームはリリース バックログをレビューし、移行される資産の作業と優先順位を見積もります。Prior to each iteration, the team reviews the release backlog, estimating the effort and priorities of assets to be migrated. その後、特定の数の合意された移行を実現することをコミットします。It then commits to deliver a specific number of agreed-on migrations. これがクラウド導入チームによって同意されると、アクティビティの一覧が "現在のイテレーション バックログ" になります。After this is agreed to by the cloud adoption team, the list of activities becomes the current iteration backlog.

各イテレーション中に、チーム メンバーは現在のイテレーション バックログのコミットメントを実現するために、自己組織化チームとして作業します。During each iteration, team members work as a self-organizing team to fulfill commitments in the current iteration backlog.

次のステップNext steps

イテレーション バックログが定義され、クラウド導入チームによって承認された後、変更管理の承認が完了します。After an iteration backlog is defined and accepted by the cloud adoption team, change management approvals can be finalized.