技術的な複雑さに備える: アジャイル変更管理Prepare for technical complexity: Agile change management

1 行のコードでデータセンター全体のプロビジョニング解除と再作成が可能な場合、従来のプロセスを保持するのは容易ではありません。When an entire datacenter can be deprovisioned and re-created with a single line of code, traditional processes struggle to keep up. クラウド導入フレームワーク全体のガイダンスは、IT サービス マネジメント (ITSM) や The Open Group Architecture Framework (TOGAF) などのプラクティスに基づいています。The guidance throughout the Cloud Adoption Framework is built on practices like IT service management (ITSM), the open group architecture framework (TOGAF), and others. しかし、ビジネスの変化に対する機敏性と応答性を確保するために、このフレームワークではアジャイル方法論と DevOps アプローチに合わせて、これらのプラクティスを変更します。However, to ensure agility and responsiveness to business change, this framework molds those practices to fit agile methodologies and DevOps approaches.

柔軟性とイテレーションが重視されるアジャイル モデルに移行する場合、技術的な複雑さと変更管理は、線形の一連の移行手順に重点を置く従来のウォーターフォール モデルとは異なる方法で処理されます。When shifting to an agile model where flexibility and iteration are emphasized, technical complexity and change management are handled differently than they're in a traditional waterfall model focusing on a linear series of migration steps. この記事では、アジャイルベースの移行作業での変更管理に対するアプローチの概要について説明します。This article outlines a high-level approach to change management in an agile-based migration effort. この記事の最後には、変更管理のレベルと段階的な移行アプローチに関するドキュメント化を全般的に理解しているはずです。At the end of this article, you should have a general understanding of the levels of change management and documentation involved in an incremental migration approach. その理解に基づいてアジャイル プラクティスを選択して実装するには、トレーニングと意思決定がさらに必要になります。Additional training and decisions are required to select and implement agile practices based on that understanding. この記事の目的は、このアプローチでの変更管理の一般概念を説明するために、プロジェクト管理と円滑に会話できるクラウド アーキテクトを準備することです。The intention of this article is to prepare cloud architects for a facilitated conversation with project management to explain the general concept of change management in this approach.

技術的な複雑さに対処するAddress technical complexity

技術システムを変更する場合、複雑さと相互依存性によって、プロジェクト計画にリスクが生じます。When changing any technical system, complexity and interdependency inject risk into project plans. クラウドへの移行も例外ではありません。Cloud migrations are no exception. 数千 (または数万) の資産をクラウドに移行する場合、これらのリスクが増大します。When moving thousands (or tens of thousands) of assets to the cloud, these risks are amplified. 大規模なデジタル資産全体の依存関係をすべて検出してマッピングするのに、数年かかる場合があります。Detecting and mapping all dependencies across a large digital estate could take years. いくつかのビジネスでは、このような長い分析サイクルを許容できます。Few businesses can tolerate such a long analysis cycle. アーキテクチャの分析とビジネスの加速の必要性のバランスを取るために、クラウド導入フレームワークでは、製品バックログ管理のための INVEST モデルに重点を置きます。To balance the need for architectural analysis and business acceleration, the Cloud Adoption Framework focuses on an INVEST model for product backlog management. 次のセクションは、この種のモデルをまとめたものです。The following sections summarize this type of model.

ワークロードにおける INVESTINVEST in workloads

ワークロード という用語は、クラウド導入フレームワーク全体で示されます。The term workload appears throughout the Cloud Adoption Framework. ワークロードは、クラウドに移行可能なアプリケーション機能の単位です。A workload is a unit of application functionality that can be migrated to the cloud. これは、単一のアプリケーション、アプリケーションの層、またはアプリケーションのコレクションである場合があります。It could be a single application, a layer of an application, or a collection of an application. 定義は柔軟であり、さまざまな移行フレーズで変わる可能性があります。The definition is flexible and may change at various phrases of migration. クラウド導入フレームワークでは、ワークロードを定義する際に INVEST という用語を使用します。The Cloud Adoption Framework uses the term INVEST to define a workload.

INVEST は、ユーザー ストーリーまたは製品バックログ項目 (どちらもアジャイル プロジェクト管理ツールの出力単位) を書き込むための多くのアジャイル方法論における一般的な頭字語です。INVEST is a common acronym in many agile methodologies for writing user stories or product backlog items, both of which are units of output in agile project management tools. 移行の測定可能な出力単位は、移行されたワークロードです。The measurable unit of output in a migration is a migrated workload. クラウド導入フレームワークでは、頭字語の INVEST を少し変更し、ワークロードを定義するための構造体を作成します。The Cloud Adoption Framework modifies the INVEST acronym a bit to create a construct for defining workloads:

  • 独立している: ワークロードでは、アクセスできない依存関係を持つことはできません。Independent: A workload should not have any inaccessible dependencies. ワークロードを移行したものと見なすには、すべての依存関係がアクセス可能であり、移行作業に含まれる必要があります。For a workload to be considered migrated, all dependencies should be accessible and included in the migration effort.
  • ネゴシエート可能である: さらに検出が行われると、ワークロードの定義が変わります。Negotiable: As additional discovery is performed, the definition of a workload changes. 移行を計画しているアーキテクトは、依存関係に関する要因をネゴシエートできます。The architects planning the migration could negotiate factors regarding dependencies. ネゴシエーション ポイントの例として、機能のプレリリースが考えられ、ハイブリッド ネットワーク経由で機能にアクセスできるようにする、あるいは単一リリースですべての依存関係をパッケージ化します。Examples of negotiation points could include prerelease of features, making features accessible over a hybrid network, or packaging all dependencies in a single release.
  • 価値がある: ワークロードにおける価値は、運用ワークロードへのアクセス権をユーザーに提供する機能によって測定されます。Valuable: Value in a workload is measured by the ability to provide users with access to a production workload.
  • 見積もり可能である: 依存関係、資産、移行時間、パフォーマンス、およびクラウドのコストはすべて見積もり可能である必要があり、移行前に見積もる必要があります。Estimable: Dependencies, assets, migration time, performance, and cloud costs should all be estimable and should be estimated prior to migration.
  • 小さい: 目標は、単一のスプリントにワークロードをパッケージ化することです。Small: The goal is to package workloads in a single sprint. しかし、これが必ずしも可能であるとは限りません。However, this may not always be feasible. 代わりに、ワークロードを運用環境に移行するのに必要な時間を最小限に抑えるために、チームでスプリントとリリースを計画することをお勧めします。Instead, teams are encouraged to plan sprints and releases to minimize the time required to move a workload to production.
  • テスト可能である: ワークロードの移行の完了をテストまたは確認する方法が常に定義されている必要があります。Testable: There should always be a defined means of testing or validating completion of the migration of a workload.

この頭字語は、厳格な遵守の基礎とすることを意図するものではありませんが、"ワークロード" という用語の定義に役立つはずです。This acronym is not intended as a basis for rigid adherence but should help guide the definition of the term workload.

移行バックログ:ビジネスの優先順位とタイミングの整合Migration backlog: Aligning business priorities and timing

移行バックログでは、移行可能なワークロードの最上位レベルのポートフォリオを追跡できます。The migration backlog allows you to track your top-level portfolio of workloads that can be migrated. 移行前に、クラウド戦略チームとクラウド導入チームは、現在のデジタル資産を確認し、移行するワークロードの優先順位リストに同意することをお勧めします。Prior to migration, the cloud strategy team and the cloud adoption team are encouraged to perform a review of the current digital estate, and agree to a prioritized list of workloads to be migrated. このリストにより、最初の移行バックログの基礎が形成されます。This list forms the basis of the initial migration backlog.

最初は、移行バックログのワークロードが、前のセクションで概説した INVEST の条件を満たす可能性が低くなります。Initially, workloads on the migration backlog are unlikely to meet the INVEST criteria outlined in the previous section. 代わりに、これらは今後の作業のプレースホルダーとして、最初のインベントリからの資産の論理グループとして機能します。Instead, they serve as a logical grouping of assets from an initial inventory as a placeholder for future work. これらのプレースホルダーは、厳密には正確ではない可能性がありますが、ビジネスとの調整の基礎として機能します。Those placeholders may not be technically accurate, but they serve as the basis for coordination with the business.

移行プロセス中に使用される、移行、リリース、イテレーション バックログ間の関係

移行、リリース、イテレーション バックログでは、移行プロセス中にさまざまなレベルのアクティビティが追跡されます。The migration, release, and iteration backlogs track different levels of activity during migration processes.

移行バックログでは、変更管理チームは、計画のすべてのワークロードについて、以下の情報を取得する努力が必要です。In any migration backlog, the change management team should strive to obtain the following information for any workload in the plan. 少なくとも、このデータは、次の 2 つまたは 3 つのリリースで移行について優先順位が付けられたワークロードで使用できる必要があります。At a minimum, this data should be available for any workloads prioritized for migration in the next two or three releases.

移行バックログのデータ ポイントMigration backlog data points

  • ビジネスへの影響。Business impact. 予想されるタイムラインの欠落やウィンドウのフリーズ時の機能低下のビジネスへの影響の理解。Understanding of the impact to the business of missing the expected timeline or reducing functionality during freeze windows.
  • 相対的なビジネスの優先順位。Relative business priority. ビジネスの優先順位に基づいてランク付けされたワークロードのリスト。A ranked list of workloads based on business priorities.
  • ビジネス所有者。Business owner. このワークロードに関するビジネス上の決定を行う 1 人の担当者についてドキュメント化します。Document the one individual responsible for making business decisions regarding this workload.
  • 技術所有者。Technical owner. このワークロードに関する技術的な決定を行う 1 人の担当者についてドキュメント化します。Document the one individual responsible for technical decisions related to this workload.
  • 予想されるタイムライン。Expected timelines. 移行の完了がスケジュールされているタイミング。When the migration is scheduled for completion.
  • ワークロードのフリーズ。Workload freezes. ワークロードの変更の対象外とする必要がある期間。Time frames in which the workload should be ineligible for change.
  • ワークロード名。Workload name.
  • 初期インベントリ。Initial inventory. VM、IT アプライアンス、データ、アプリケーション、デプロイ パイプラインを含む、ワークロードの機能を提供するために必要なすべての資産。Any assets required to provide the functionality of the workload, including VMs, IT appliances, data, applications, deployment pipelines, and others. この情報は正確でない可能性があります。This information is likely to be inaccurate.

リリース バックログ:ビジネス変更と技術的な調整の整合Release backlog: Aligning business change and technical coordination

移行のコンテキストでは、リリース は、1 つまたは複数のワークロードを運用環境にデプロイするアクティビティです。In the context of a migration, a release is an activity that deploys one or more workloads into production. リリースは一般的に、いくつかのイテレーションまたは技術的な作業が対象となります。A release generally covers several iterations or technical work. しかし、これはビジネス変更の単一のイテレーションを表します。However, it represents a single iteration of business change. 運用促進のための 1 つまたは複数のワークロードの準備ができた後、リリースが発生します。After one or more workloads have been prepared for production promotion, a release occurs. リリースのパッケージ化の決定は、移行するワークロードによって、ビジネス環境への変更の導入を正当化するのに十分なビジネス価値が示された場合に行われます。The decision to package a release is made when the workloads migrated represent enough business value to justify injecting change into a business environment. ビジネス テストが完了した後、ビジネス変更計画と組み合わせてリリースが実行されます。Releases are executed in conjunction with a business change plan, after business testing has been completed. クラウド戦略チームは、必要なビジネス変更が確実にリリースされるように、リリースの実行の計画と監視を担当します。The cloud strategy team is responsible for planning and overseeing the execution of a release to ensure that the desired business change is released.

リリース バックログ は今後のリリースを定義する将来の状態の計画です。A release backlog is the future state plan that defines a coming release. リリース バックログは、ビジネス変更管理 (移行バックログ) と技術的な変更管理 (スプリント バックログ) の間のピボット ポイントとなります。Release backlog is the pivot point between business change management (migration backlog) and technical change management (sprint backlog). リリース バックログは、ビジネス成果の実現の特定のサブセットに合わせて調整する、移行バックログからのワークロードのリストで構成されます。A release backlog consists of a list of workloads from the migration backlog that align to a specific subset of business outcome realization. リリース バックログの定義とクラウド導入チームへの送信は、より深い分析と移行の計画のためのトリガーとして機能します。Definition and submission of a release backlog to the cloud adoption team serve as a trigger for deeper analysis and migration planning. クラウド導入チームは、リリースに関連付けられている技術的な詳細を確認した後、リリースへのコミットを選択することができ、これにより、現在のナレッジに基づいてリリース タイムラインが確立されます。After the cloud adoption team has verified the technical details associated with a release, it can choose to commit to the release, establishing a release timeline based on current knowledge.

リリースを確認するためにある程度の分析が必要な場合、クラウド戦略チームは、次の 2 つから 4 つのリリースの実行中のリストを維持する必要があります。Given the degree of analysis required to validate a release, the cloud strategy team should maintain a running list of the next two to four releases. また、チームでは、リリースを定義して送信する前に、できるだけ多くの以下の情報の確認を試みる必要があります。The team should also attempt to validate as much of the following information as possible, before defining and submitting a release. 次の 4 つのリリースを維持できる、統制の取れたクラウド戦略チームであれば、リリース タイムラインの見積もりの一貫性と精度を大幅に向上させることができます。A disciplined cloud strategy team capable of maintaining the next four releases can significantly increase the consistency and accuracy of release timeline estimates.

リリース バックログのデータ ポイントRelease backlog data points

クラウド戦略チームとクラウド導入チーム間のパートナーシップにより、連携して、リリース バックログのすべてのワークロードに以下のデータ ポイントを追加することができます。A partnership between the cloud strategy team and the cloud adoption team collaborates to add the following data points for any workloads in the release backlog:

  • 詳細なインベントリ。Refined inventory. 移行される必要な資産の確認。Validation of required assets to be migrated. 標準的な負荷がかかる各資産のネットワークとハードウェアの依存関係に対する正確な理解を確実にするために、多くの場合、ホスト、ネットワーク、または OS レベルでのログまたは監視データを使用して確認されます。Often validated through log or monitoring data at the host, network, or OS level to ensure an accurate understanding of network and hardware dependencies of each asset under standard load.
  • 使用パターン。Usage patterns. エンド ユーザーの使用パターンの理解。An understanding of the patterns of usage from end users. 多くの場合、これらのパターンには、エンドユーザーの地理的な分散、ネットワーク ルート、季節的な使用量の急増、毎日/毎時の使用量の急増、およびエンドユーザー構成 (内部と外部) の分析が含まれます。These patterns often include an analysis of end-user geographical distribution, network routes, seasonal usage spikes, daily/hourly usage spikes, and end-user composition (interval versus external).
  • パフォーマンスの期待値。Performance expectations. スループット、ページビュー、ネットワーク ルート、およびエンドユーザー エクスペリエンスのレプリケートに必要なその他のパフォーマンス データをキャプチャする、使用可能なログ データの分析。Analysis of available log data capturing throughput, page views, network routes, and other performance data required to replicate the end-user experience.
  • 依存関係。Dependencies. シーケンス処理および環境の準備に組み込む必要がある、追加のワークロードの依存関係を識別するためのネットワーク トラフィックとアプリケーションの使用パターンの分析。Analysis of network traffic and application usage patterns to identify any additional workload dependencies, which should be factored into sequencing and environmental readiness. 次の条件のいずれかを満たせるまで、リリースにはワークロードを含めないでください。Don't include a workload in a release until one of the following criteria can be met:
    • 依存するワークロードがすべて移行されている。All dependent workloads have been migrated.
    • 既存のパフォーマンスの期待値に合わせてすべての依存関係にワークロードでアクセスできるように、ネットワークおよびセキュリティの構成が実装されている。Network and security configurations have been implemented to allow the workload to access all dependencies in alignment with existing performance expectations.
  • 必要な移行アプローチ。Desired migration approach. 移行バックログ レベルでは、想定された移行作業が、分析で使用される唯一の考慮事項となります。At the migration backlog level, the assumed migration effort is the only consideration used in analysis. たとえば、ビジネスの成果が既存のデータセンターからの退去である場合、すべての移行は、移行バックログの再ホスト シナリオであると見なされます。For instance, if the business outcome is an exit from an existing datacenter, all migrations are assumed to be a rehost scenario in the migration backlog. リリース バックログでは、クラウド戦略チームとクラウド導入チームは、追加機能、モダン化、および継続的な開発投資の長期的な価値を評価し、よりモダンなアプローチを含める必要があるかどうかを評価する必要があります。In the release backlog, the cloud strategy team and the cloud adoption team should evaluate the long-term value of additional features, modernization, and continued development investments to evaluate whether a more modern approach should be involved.
  • ビジネス テストの条件。Business testing criteria. ワークロードが移行バックログに追加された後、テスト条件に相互に合意する必要があります。After a workload is added to the migration backlog, testing criteria should be mutually agreed on. 場合によっては、テスト条件を、定義されたパワー ユーザー グループでのパフォーマンス テストに制限できます。In some cases, testing criteria can be limited to a performance test with a defined power user group. しかし、統計的な確認では、自動化されたパフォーマンス テストが必要であり、含まれる必要があります。However, for statistical validation, an automated performance test is desired and should be included. 多くの場合、アプリケーションの既存のインスタンスには、自動化されたテスト機能がありません。The existing instance of the application often has no automated testing capabilities. これが正しいとわかった場合、移行中に使用されるベンチマークを確立するための既存のソリューションに対するベースライン ロード テストを作成するために、クラウド アーキテクトがパワー ユーザーと共に作業を行うことは珍しくありません。Should this prove accurate, it is not uncommon for the cloud architects to work with power users to create a baseline load test against the existing solution to establish a benchmark to be used during migration.

リリース バックログの周期Release backlog cadence

成熟した移行では、リリースは定期的に行われます。In mature migrations, releases come in a regular cadence. 多くの場合、クラウド導入チームのベロシティで正規化され、2 回から 4 回のイテレーションごと (約 1 か月または 2 か月ごと) にリリースが生成されます。The velocity of the cloud adoption team often normalizes, producing a release every two to four iterations (approximately every one or two months). しかし、これは有機的な成果である必要があります。However, this should be an organic outcome. 人工的なリリース周期を作成すると、一貫性のあるスループットを実現するためのクラウド導入チームの能力に悪影響を与える場合があります。Creating artificial release cadences can negatively affect the cloud adoption team's ability to achieve consistent throughput.

ビジネスへの影響を安定させるには、クラウド戦略チームは定期的な対話を維持するために企業と協力して毎月のリリース プロセスを確立するだけでなく、定期的なリリース周期を予測できるまで数か月かかるという予想を立てる必要もあります。To stabilize business impact, the cloud strategy team should establish a monthly release process with the business to maintain regular dialogue but should also establish the expectation that it will be several months before a regular release cadence can be predicted.

スプリントまたはイテレーション バックログ:技術的な変更と作業の整合Sprint or iteration backlog: Aligning technical change and effort

スプリント、または_イテレーション_ は一貫性のある期限付きの作業単位です。A sprint, or iteration, is a consistent, time-bound unit of work. 移行プロセスでは、これは多くの場合、2 週間単位で測定されます。In the migration process, this is often measured in two-week increments. しかし、1 週間または 4 週間のイテレーションが使用される例がないわけではありません。However, it's not unheard of to have one-week or four-week iterations. 期限付きイテレーションを作成することで、作業完了の一貫した間隔が強制され、新しい学習内容に基づき、計画に合わせてより頻繁に調整することができます。Creating time-bound iterations forces consistent intervals of effort completion and allows for more frequent adjustment to plans, based on new learnings. 特定のスプリント中は、通常、移行バックログに定義されたワークロードの評価、移行、および最適化のタスクがあります。During any given sprint, there are usually tasks for the assessment, migration, and optimization of workloads defined in the migration backlog. 各レベルの変更管理での一貫性を向上させるために、移行およびリリース バックログと同じプロジェクト管理ツールでこれらの作業単位を追跡して管理する必要があります。Those units of work should be tracked and managed in the same project-management tool as the migration and release backlog, to drive consistency across each level of change management.

スプリント バックログ、または_イテレーション バックログ_ は、個々の資産の移行を処理する、単一のスプリントまたはイテレーションで完了する技術的な作業で構成されています。A sprint backlog, or iteration backlog, consists of the technical work to be completed in a single sprint or iteration, dealing with migrating individual assets. その作業は、移行されるワークロードのリストから派生される必要があります。That work should be derived from the list of workloads being migrated. プロジェクト管理に Azure DevOps (以前の Visual Studio Online) などのツールを使用する場合、スプリントの作業項目は、リリース バックログの製品バックログ項目の子になり、移行バックログのエピックになります。When using tools like Azure DevOps (previously Visual Studio online) for project management, the work items in a sprint would be children of the product backlog items in a release backlog and the epics in a migration backlog. このような親と子の関係により、すべてのレベルで変更管理がわかりやすくなります。Such a parent-child relationship allows for clarity at all levels of change management.

単一のスプリントまたはイテレーション内では、クラウド導入チームは、定義されたワークロードの移行に向けて、コミットされた量の技術的な作業を提供できるよう努めます。Within a single sprint or iteration, the cloud adoption team would work to deliver the committed amount of technical work, driving toward the migration of a defined workload. これは、変更管理戦略の最終的な結果です。This is the end result of the change management strategy. 完了したら、クラウドでステージされたワークロードの運用環境の準備を確認し、これらの作業をテストできます。When complete, these efforts can be tested by validating production readiness of a workload staged in the cloud.

大規模または複雑なスプリントの構造Large or complex sprint structures

自己完結型の移行チームによる小規模な移行の場合、単一のスプリントに、単一のワークロードの移行の 4 つのフェーズ ("評価"、"移行"、"最適化"、"セキュリティ保護と管理") をすべて含めることができます。For a small migration with a self-contained migration team, a single sprint could include all four phases of a migration for a single workload (Assess, Migrate, Optimize, and Secure and manage). より一般的には、これらの各プロセスは、多数のスプリントにまたがる個別の作業項目で複数のチームによって共有されます。More commonly, each of these processes shared by multiple teams in distinct work items across numerous sprints. 作業の種類、作業のスケール、およびロールに応じて、これらのスプリントはいくつかの異なる形式になる場合があります。Depending on the effort type, effort scale, and roles, these sprints can take a few different shapes.

  • 移行ファクトリ。Migration factory. 大規模な移行では、実行モデルのファクトリに似たアプローチが必要になる場合があります。Large-scale migrations sometimes require an approach that resembles a factory in the execution model. このモデルでは、さまざまなチームが特定の移行プロセス (またはプロセスのサブセット) の実行に割り当てられます。In this model, various teams are allocated to the execution of a specific migration process (or subset of the process). 完了後、1 つのチームのスプリントの出力に、次のチームのバックログが取り込まれます。After completion, the output of one team's sprint populates the backlog for the next team. これは、評価、アーキテクチャ、修復、移行のフェーズを移動する数千もの仮想マシンに関連する、多くの潜在的なワークロードの大規模な再ホスト移行の効率的なアプローチです。This is an efficient approach for large-scale rehost migrations of many potential workloads involving thousands of virtual machines moving through phases of assessment, architecture, remediation, and migration. しかし、このアプローチを使用するには、変更管理と承認プロセスが合理化された新しい同種環境が必須となります。However, for this approach to work, a new homogenous environment with streamlined change management and approval processes is a must.
  • 移行ウェーブ。Migration waves. 大規模な移行に適しているもう 1 つのアプローチは、ウェーブ モデルです。Another approach that works well for large migrations is a wave model. このモデルでは、作業はまったく明確ではありません。In this model, division of labor isn't nearly as clear. チームは、個々のワークロードの移行プロセスの実行に専念します。Teams dedicate themselves to the migration process execution of individual workloads. しかし、各スプリントの性質は変わります。However, the nature of each sprint changes. あるスプリントでは、チームが評価およびアーキテクチャ作業を完了する可能性があります。In one sprint, the team may complete assessment and architecture work. 別のスプリントでは、移行作業を完了する可能性があります。In another sprint, it may complete the migration work. さらに別のスプリントでは、最適化と運用リリースに重点が置かれます。In yet another sprint, the focus would be on optimization and production release. このアプローチでは、コア チームがワークロードに合わせて調整された状態が保たれるため、プロセスの全体像を見ることができます。This approach allows a core team to stay aligned to workloads, seeing them through the process in its entirety. このアプローチを使用する場合、スキルとコンテキストの切り替えの多様性により、チームの潜在的なベロシティが減少し、移行作業が遅くなり可能性があります。When using this approach, the diversity of skills and context switching could reduce the potential velocity of the team, slowing the migration effort. さらに、承認サイクル中の障害により、大幅な遅延が発生する可能性があります。Additionally, roadblocks during approval cycles can cause significant delays. このモデルでは、ブロック期間中にチームが作業を続けられるように、リリース バックログでオプションを維持することが重要です。It is important to maintain options in the release backlog to keep the team moving during blocked periods, with this model. また、チーム メンバーのクロストレーニングを行うことと、スキル セットが各スプリントのテーマに確実に合っているようにすることも重要です。It is also important to cross-train team members and to ensure that skill sets align with the theme of each sprint.

スプリント バックログのデータ ポイントSprint backlog data points

スプリントの成果により、ワークロードに対して行われた変更がキャプチャされ、ドキュメント化されます。したがって、変更管理ループが閉じられます。The outcome of a sprint captures and documents the changes made to a workload, thus closing the change-management loop. 完了時に、少なくとも以下をドキュメント化する必要があります。When completed, at a minimum, the following should be documented. スプリントの実行を通して、このドキュメント化を技術的な作業項目と共に完了する必要があります。Throughout the execution of a sprint, this documentation should be completed in tandem with the technical work items.

  • デプロイされた資産。Assets deployed. ワークロードをホストするためにクラウドにデプロイされたすべての資産。Any assets deployed to the cloud to host the workload.
  • 修復。Remediation. クラウドへの移行準備のための資産のすべての変更。Any changes to the assets to prepare for cloud migration.
  • 構成。Configuration. 構成スクリプトへの参照を含む、デプロイされたすべての資産の選択された構成。Chosen configuration of any assets deployed, including any references to configuration scripts.
  • デプロイ モデル。Deployment model. デプロイ スクリプトまたはツールへの参照を含む、クラウドへの資産のデプロイに使用されるアプローチ。Approach used to deploy the asset to the cloud, including references to any deployment scripts or tools.
  • アーキテクチャ。Architecture. クラウドにデプロイされたアーキテクチャのドキュメント化。Documentation of the architecture deployed to the cloud.
  • パフォーマンス メトリック。Performance metrics. デプロイ時のパフォーマンスを確認するために行われる自動テストまたはビジネス テストの結果。Output of automated testing or business testing performed to validate performance at the time of deployment.
  • 固有の要件または構成。Unique requirements or configuration. ワークロードの運用に必要なデプロイ、構成、または技術的な要件の固有の側面。Any unique aspects of the deployment, configuration, or technical requirements necessary to operate the workload.
  • 運用の承認。Operational approval. アプリケーション所有者と、デプロイ後のワークロードの管理を担当する IT 運用スタッフによる、運用準備確認の承認。Sign-off of validating operational readiness from the application owner and the IT operations staff responsible for managing the workload after deployment.
  • アーキテクチャの承認。Architecture approval. ワークロード所有者とクラウド導入チームによる、各資産をホストするために必要なアーキテクチャ変更の確認の承認。Sign-off from the workload owner and the cloud adoption team to validate any architecture changes required to host each asset.

次のステップNext steps

変更管理アプローチが確立されたら、最後の前提条件である移行バックログの確認に対処します。After change management approaches have been established, its time to address the final prerequisite, migration backlog review