반복 및 릴리스 계획 설정Establish iterations and release plans

Agile 및 기타 반복적인 방법론은 반복 및 릴리스의 개념을 기반으로 빌드됩니다.Agile and other iterative methodologies are built on the concepts of iterations and releases. 이 문서에서는 계획 중에 반복 및 릴리스를 할당 하는 방법을 간략하게 설명 합니다.This article outlines the assignment of iterations and releases during planning. 이러한 할당은 클라우드 전략 팀의 구성원 들 사이에서 대화를 더 쉽게 하기 위해 타임 라인 표시 여부를 결정 합니다.Those assignments drive timeline visibility to make conversations easier among members of the cloud strategy team. 또한 할당은 클라우드 채택 팀이 구현 중에 관리할 수 있는 방식으로 기술 작업을 정렬 합니다.The assignments also align technical tasks in a way that the cloud adoption team can manage during implementation.

반복 설정Establish iterations

기술 구현에 대 한 반복적인 접근 방식에서는 반복 되는 시간 블록에 대 한 기술적 노력을 계획 합니다.In an iterative approach to technical implementation, you plan technical efforts around recurring time blocks. 반복은 1 주마다 6 주 동안의 시간 블록으로 간주 됩니다.Iterations tend to be one-week to six-week time blocks. 합의는 2 주가 가장 많은 클라우드 채택 팀의 평균 반복 기간 임을 나타냅니다.Consensus suggests that two weeks is the average iteration duration for most cloud adoption teams. 하지만 반복 기간은 기술 활동의 유형, 관리 오버 헤드 및 팀의 기본 설정에 따라 달라 집니다.But the choice of iteration duration depends on the type of technical effort, the administrative overhead, and the team's preference.

타임 라인에 대 한 노력 정렬을 시작 하려면 최근 6 개월에서 12 개월까지 반복의 집합을 정의 하는 것이 좋습니다.To begin aligning efforts to a timeline, we suggest that you define a set of iterations that last 6 to 12 months.

속도 이해Understand velocity

반복 및 릴리스에 대 한 작업을 정렬 하려면 속도를 이해 해야 합니다.Aligning efforts to iterations and releases requires an understanding of velocity. 속도는 지정 된 반복에서 완료할 수 있는 작업의 양입니다.Velocity is the amount of work that can be completed in any given iteration. 초기 계획을 세울 때 속도는 예상치입니다.During early planning, velocity is an estimate. 몇 번의 반복 후에는 팀이 자신에 게 적용할 수 있는 약정에 대 한 매우 중요 한 지표가 됩니다.After several iterations, velocity becomes a highly valuable indicator of the commitments that the team can make confidently.

스토리 점수와 같은 추상 용어로 속도를 측정할 수 있습니다.You can measure velocity in abstract terms like story points. 시간과 같은 보다 명확한 용어로 측정할 수도 있습니다.You can also measure it in more tangible terms like hours. 대부분의 반복적인 프레임 워크의 경우 정밀도 및 인식 문제를 방지 하기 위해 추상 측정값을 사용 하는 것이 좋습니다.For most iterative frameworks, we recommend using abstract measurements to avoid challenges in precision and perception. 이 문서의 예는 스 프린트 당 시간 단위를 나타냅니다.Examples in this article represent velocity in hours per sprint. 이 표현은 토픽을 보다 널리 이해할 수 있게 해줍니다.This representation makes the topic more universally understood.

예: 5 인칭 클라우드 채택 팀은 2 주 스 프린트에 커밋 했습니다.Example: A five-person cloud adoption team has committed to two-week sprints. 다른 프로세스에 대 한 모임 및 지원과 같은 현재 의무를 고려 하 여 각 팀 멤버는 도입 활동에 매주 20 시간을 지속적으로 제공할 수 있습니다.Given current obligations like meetings and support of other processes, each team member can consistently contribute 20 hours per week to the adoption effort. 이 팀의 초기 속도 예상 시간은 스 프린트 당 100 시간입니다.For this team, the initial velocity estimate is 100 hours per sprint.

반복 계획Iteration planning

처음에는 우선 순위가 지정 된 백로그를 기준으로 기술 작업을 평가 하 여 반복을 계획 합니다.Initially, you plan iterations by evaluating the technical tasks based on the prioritized backlog. 클라우드 채택 팀은 다양 한 작업을 완료 하는 데 필요한 작업량을 예측 합니다.Cloud adoption teams estimate the effort required to complete various tasks. 이러한 작업은 사용 가능한 첫 번째 반복에 할당 됩니다.Those tasks are then assigned to the first available iteration.

반복 계획 중에 클라우드 채택 팀은 예측을 확인 하 고 구체화 합니다.During iteration planning, the cloud adoption teams validate and refine estimates. 사용 가능한 모든 속도를 특정 작업에 맞출 때까지이 작업을 수행 합니다.They do so until they have aligned all available velocity to specific tasks. 이 프로세스는 모든 노력이 예측 된 반복에 맞춰 보일 때까지 우선 순위가 지정 된 각 워크 로드에 대해 계속 됩니다.This process continues for each prioritized workload until all efforts align to a forecasted iteration.

이 프로세스에서 팀은 다음 스 프린트에 할당 된 작업의 유효성을 검사 합니다.In this process, the team validates the tasks assigned to the next sprint. 팀은 각 작업에 대 한 팀의 대화에 따라 예상치를 업데이트 합니다.The team updates its estimates based on the team's conversation about each task. 그런 다음 사용 가능한 속도가 충족 될 때까지 팀은 다음 스 프린트에 각 예상 작업을 추가 합니다.The team then adds each estimated task to the next sprint until the available velocity is met. 마지막으로 팀은 추가 작업을 예측 하 고 다음 반복에 추가 합니다.Finally, the team estimates additional tasks and adds them to the next iteration. 팀은 해당 반복의 속도도 모두 사용 될 때까지 이러한 단계를 수행 합니다.The team performs these steps until the velocity of that iteration is also exhausted.

이전 프로세스는 모든 태스크가 반복에 할당 될 때까지 계속 됩니다.The preceding process continues until all tasks are assigned to an iteration.

예: 앞의 예제를 살펴보겠습니다.Example: Let's build on the previous example. 각 워크 로드 마이그레이션에는 40 태스크가 필요 합니다.Assume each workload migration requires 40 tasks. 또한 각 작업의 평균을 1 시간으로 추정 한다고 가정 합니다.Also assume you estimate each task to take an average of one hour. 결합 된 예측은 워크 로드 마이그레이션 당 약 40 시간입니다.The combined estimation is approximately 40 hours per workload migration. 이러한 예상치는 우선 순위가 지정 된 모든 워크 로드에 대해 일관 되 게 유지 되는 경우 해당 작업은 400 시간이 소요 됩니다.If these estimates remain consistent for all 10 of the prioritized workloads, those workloads will take 400 hours.

앞의 예제에서 정의 된 속도는 처음 10 개의 워크 로드를 마이그레이션하는 데 4 개의 반복이 소요 되는 것을 제안 합니다 .이는 두 달의 일정 시간입니다.The velocity defined in the previous example suggests that the migration of the first 10 workloads will take four iterations, which is two months of calendar time. 첫 번째 반복은 두 작업의 마이그레이션을 발생 시키는 100 작업으로 구성 됩니다.The first iteration will consist of 100 tasks that result in the migration of two workloads. 다음 반복에서 100 작업의 비슷한 컬렉션은 세 가지 워크 로드를 마이그레이션합니다.In the next iteration, a similar collection of 100 tasks will result in the migration of three workloads.

경고

선행 작업 수와 예상 값은 예제로 엄격 하 게 사용 됩니다.The preceding numbers of tasks and estimates are strictly used as an example. 기술적 작업은 거의 일치 하지 않습니다.Technical tasks are seldom that consistent. 이 예제는 워크 로드를 마이그레이션하는 데 필요한 시간을 반영 하는 것으로 표시 되지 않습니다.You shouldn't see this example as a reflection of the amount of time required to migrate a workload.

릴리스 계획Release planning

클라우드 도입 내에서 릴리스는 비즈니스 프로세스에 미치는 영향을 최소화 하기 위해 충분 한 비즈니스 가치를 제공 하는 결과물 모음으로 정의 됩니다.Within cloud adoption, a release is defined as a collection of deliverables that produce enough business value to justify the risk of disruption to business processes.

작업 관련 변경 사항을 프로덕션 환경으로 해제 하면 비즈니스 프로세스에 대 한 변경 내용이 생성 됩니다.Releasing any workload-related changes into a production environment creates some changes to business processes. 이상적으로 이러한 변경은 원활 하 게 진행 되 고 비즈니스에는 서비스를 크게 방해 하지 않고 변경 값을 표시 합니다.Ideally, these changes are seamless, and the business sees the value of the changes with no significant disruptions to service. 그러나 비즈니스 중단의 위험은 변경 내용과 함께 제공 되며 약간의 작업도 수행할 필요가 없습니다.But the risk of business disruption is present with any change and shouldn't be taken lightly.

잠재적 반품으로 변경을 정당화 하기 위해 클라우드 전략 팀은 릴리스 계획에 참여 해야 합니다.To ensure a change is justified by its potential return, the cloud strategy team should participate in release planning. 작업이 스 프린트에 정렬 되 면 팀은 각 워크 로드가 프로덕션 릴리스에 대해 준비 되는 대략적인 타임 라인을 확인할 수 있습니다.Once tasks are aligned to sprints, the team can determine a rough timeline of when each workload will be ready for production release. 클라우드 전략 팀은 각 릴리스의 타이밍을 검토 합니다.The cloud strategy team would review the timing of each release. 그러면 팀에서 위험과 비즈니스 가치 사이의 변 곡점 지점을 식별 합니다.The team would then identify the inflection point between risk and business value.

예: 이전 예제를 계속 진행 하면 클라우드 전략 팀에서 반복 계획을 검토 했습니다.Example: Continuing the previous example, the cloud strategy team has reviewed the iteration plan. 검토에서 두 개의 릴리스 지점이 식별 되었습니다.The review identified two release points. 두 번째 반복 중에는 총 5 개 워크 로드를 마이그레이션할 준비가 됩니다.During the second iteration, a total of five workloads will be ready for migration. 이러한 다섯 가지 워크 로드는 상당한 비즈니스 가치를 제공 하 고 첫 번째 릴리스를 트리거합니다.Those five workloads will provide significant business value and will trigger the first release. 다음 릴리스는 다음 5 개의 워크 로드가 릴리스할 준비가 되 면 나중에 두 번 반복 됩니다.The next release will come two iterations later, when the next five workloads are ready for release.

반복 경로 및 태그 할당Assign iteration paths and tags

Azure DevOps에서 클라우드 채택 계획을 관리 하는 고객의 경우 각 작업 및 사용자 스토리에 반복 경로를 할당 하 여 이전 프로세스를 반영 합니다.For customers who manage cloud adoption plans in Azure DevOps, the previous processes are reflected by assigning an iteration path to each task and user story. 또한 특정 릴리스를 사용 하 여 각 워크 로드에 태그를 지정 하는 것이 좋습니다.We also recommend tagging each workload with a specific release. 태그 지정 및 할당은 타임 라인 보고서의 자동 채우기를 제공 합니다.That tagging and assignment feed the automatic population of timeline reports.

다음 단계Next steps

예상 일정을 예상 하 여 적절 하 게 전달 합니다.Estimate timelines to properly communicate expectations.