기술 복잡성 준비: Agile 변경 관리Prepare for technical complexity: Agile change management

한 줄의 코드로 전체 데이터 센터의 프로비저닝을 해제하고 다시 만들 수 있는 경우 기존 프로세스를 유지하기가 어려워집니다.When an entire datacenter can be deprovisioned and re-created with a single line of code, traditional processes struggle to keep up. 클라우드 채택 프레임 워크 전반에 대 한 지침은 ITSM (IT 서비스 관리), 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.

유연성과 반복이 강조 되는 agile 모델로 이동 하는 경우 기술적 복잡성과 변경 관리가 선형 일련의 마이그레이션 단계에 초점을 맞춘 기존 폭포 모델에 있는 것과 다르게 처리 됩니다.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. 아키텍처 분석 및 비즈니스 가속화의 필요성을 분산하기 위해 클라우드 채택 프레임워크는 제품 백로그 관리를 위한 투자 모델에 중점을 둡니다.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.

워크로드의 투자INVEST 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. 클라우드 채택 프레임 워크는 작업을 정의 하는 데 투자 라는 용어를 사용 합니다.The Cloud Adoption Framework uses the term INVEST to define a workload.

투자는 사용자 스토리 또는 제품 백로그 항목을 작성하기 위한 많은 민첩한 방법론에서 일반적으로 사용되는 약어로, 민첩한 프로젝트 관리 도구의 출력 단위입니다.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. 클라우드 채택 프레임워크는 투자라는 약어를 약간 수정하여 워크로드를 정의하기 위한 구성을 만듭니다.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: 종속성, 자산, 마이그레이션 시간, 성능 및 클라우드 비용은 모두 estimable 되어야 하며 마이그레이션 전에 예상 되어야 합니다.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.

처음에는 마이그레이션 백로그의 워크로드가 이전 섹션에서 설명한 투자 기준을 충족하지 못할 수 있습니다.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. 최소한이 데이터는 다음 두 가지 또는 세 가지 릴리스에서 마이그레이션에 대해 우선 순위가 지정 된 워크 로드에 사용할 수 있어야 합니다.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. 이 워크로드와 관련하여 비즈니스 의사 결정을 담당하는 한 명을 문서화합니다.Document the one individual responsible for making business decisions regarding this workload.
  • 기술 소유자.Technical owner. 이 워크로드와 관련하여 기술적 의사 결정을 담당하는 한 명을 문서화합니다.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

마이그레이션과 관련하여 릴리스 는 하나 이상의 워크로드를 프로덕션에 배포하는 활동입니다.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. 프로덕션 승격을 위해 하나 이상의 워크로드가 준비된 후 릴리스가 발생합니다.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

자체 포함 마이그레이션 팀을 사용 하는 소규모 마이그레이션의 경우 단일 스 프린트에는 단일 작업 (평가, 마이그레이션, 최적화관리)에 대 한 마이그레이션의 네 단계가 모두 포함 될 수 있습니다.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). 완료 후 한 팀의 스프린트 출력은 다음 팀의 백로그를 채웁니다.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. 대규모 마이그레이션에 효과적인 또 다른 접근 방식은 웨이브 모델입니다.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