반복 및 릴리스 계획 설정

민첩성 및 기타 반복 방법론은 반복 및 릴리스의 개념을 기반으로 합니다. 이 문서에서는 계획 중에 반복과 릴리스의 할당을 간략하게 설명합니다. 이러한 할당은 타임라인 가시성을 높여줘 클라우드 전략 팀 구성원 간의 대화가 더 쉬워집니다. 또한 할당은 클라우드 채택 팀에서 구현하는 동안 관리할 수 있는 방식으로 기술 작업을 조정합니다.

반복 설정

기술 구현에 대한 반복적인 접근 방식에서는 반복되는 시간 블록에 대한 기술적 활동을 계획합니다. 반복은 1~6주까지의 시간 블록일 수 있습니다. 대부분의 클라우드 채택 팀의 평균 반복 기간은 2주 정도가 좋다는 데에 대부분 합의합니다. 그러나 기술적 활동의 유형, 관리 오버헤드 및 팀 선호도에 따라 반복 기간을 다르게 선택할 수 있습니다.

타임라인에 대한 맞춤 활동을 시작하려면 마지막 6~12개월 동안의 반복 세트를 정의하는 것이 좋습니다.

개발속도 이해

반복 및 릴리스에 대한 활동을 맞추려면 개발속도를 이해해야 합니다. 개발속도는 지정된 반복에서 완료할 수 있는 작업의 양입니다. 초기 계획 중에 개발속도는 추정치입니다. 여러 번의 반복 후에 개발속도는 팀의 자신 있는 약속에 대한 매우 중요한 지표가 됩니다.

스토리 포인트와 같은 추상적인 용어로 개발속도를 측정할 수 있습니다. 또한 시간과 같은 보다 실질적인 용어로 측정할 수 있습니다. 대부분의 반복 프레임워크에서는 정밀도와 인식의 문제가 방지되도록 추상 측정값을 사용하는 것이 좋습니다. 이 문서의 예는 스프린트당 개발속도(시간 단위)를 나타냅니다. 이 표현으로 토픽을 보다 보편적으로 이해할 수 있습니다.

예: 5명으로 구성된 클라우드 채택 팀은 2주 스프린트에 전념했습니다. 회의 및 기타 프로세스 지원과 같은 현재의 의무를 감안할 때 각 팀 구성원은 채택 활동에 주당 20시간을 지속적으로 활용할 수 있습니다. 이 팀의 경우 초기 개발속도 추정치는 스프린트당 100시간입니다.

반복 계획

처음에는 우선 순위가 지정된 백로그에 따라 기술 작업을 평가하여 반복을 계획합니다. 클라우드 채택 팀은 다양한 작업을 완료하는 데 필요한 활동을 추정합니다. 그런 다음, 해당 작업을 사용 가능한 첫 번째 반복에 할당합니다.

반복 계획 중에 클라우드 채택 팀은 추정치의 유효성을 검사하고 구체화합니다. 사용 가능한 모든 개발속도를 특정 작업에 맞출 때까지 이 작업을 수행합니다. 이 프로세스는 모든 활동이 예측된 반복에 맞춰질 때까지 우선 순위가 지정된 각 워크로드에 계속됩니다.

이 프로세스에서 팀은 다음 스프린트에 할당된 작업의 유효성을 검사합니다. 팀은 각 작업에 대한 팀 대화에 따라 추정치를 업데이트합니다. 그런 다음, 팀은 사용 가능한 개발속도가 충족될 때까지 예측된 각 작업을 다음 스프린트에 추가합니다. 마지막으로 팀은 추가 작업을 예측하고 다음 반복에 추가합니다. 팀은 해당 반복의 개발속도도 소진될 때까지 이러한 단계를 수행합니다.

이전 프로세스는 모든 작업이 반복에 할당될 때까지 계속됩니다.

예: 이전 예를 기반으로 하겠습니다. 각 워크로드 마이그레이션에 작업이 40개 필요하다고 가정합니다. 또한 각 작업을 예측하는 데 평균 1시간이 소요된다고 가정합니다. 결합된 추정은 워크로드 마이그레이션당 약 40시간입니다. 이러한 추정치가 우선 순위가 지정된 워크로드 10개 모두에 일관성을 유지하는 경우 해당 워크로드에 400시간이 소요됩니다.

이전 예에서 정의된 개발속도는 첫 워크로드 10개를 마이그레이션하는 데 반복 4회가 소요되며 이는 달력 시간으로 두 달입니다. 첫 번째 반복은 두 워크로드의 마이그레이션을 초래하는 작업 100개로 구성됩니다. 다음 반복에서 비슷한 작업 100개의 컬렉션으로 인해 워크로드 3개가 마이그레이션됩니다.

경고

앞의 작업 수와 예상치는 예로만 사용됩니다. 기술 작업은 거의 일관되지 않습니다. 이 예는 워크로드를 마이그레이션하는 데 필요한 시간을 반영하지 않습니다.

릴리스 계획

클라우드 채택 내에서 릴리스는 비즈니스 프로세스 중단 위험을 정당화할 수 있는 비즈니스 가치를 창출하는 결과물 컬렉션으로 정의됩니다.

워크로드 관련 변경 사항을 프로덕션 환경에 릴리스하면 비즈니스 프로세스가 약간 변경됩니다. 이상적으로 이러한 변경 사항은 원활하며 회사는 심각한 서비스 중단 없이 변경의 가치를 확인합니다. 그러나 비즈니스 중단 위험은 변경과 함께 존재하며 가볍게 받아들여서는 안 됩니다.

변경이 잠재적 수익에 통해 정당화되게 하려면 클라우드 전략 팀이 릴리스 계획에 참여해야 합니다. 작업이 스프린트에 맞춰지면 팀은 각 워크로드가 프로덕션 릴리스에 준비되는 시기에 대한 대략적인 타임라인을 결정할 수 있습니다. 클라우드 전략 팀에서 각 릴리스의 타이밍을 검토합니다. 그런 다음, 팀은 위험과 비즈니스 가치 사이의 변곡점을 식별합니다.

예: 이전 예를 계속합니다. 클라우드 전략 팀에서 반복 계획을 검토했습니다. 검토에서 릴리스 지점 2개가 확인되었습니다. 두 번째 반복 중에는 총 워크로드 5개를 마이그레이션할 수 있습니다. 이러한 워크로드 5개는 상당한 비즈니스 가치를 제공하며 첫 번째 릴리스를 트리거합니다. 다음 릴리스는 이후 워크로드 5개가 릴리스될 수 있으면 반복 2회로 제공됩니다.

반복 경로 및 태그 할당

Azure DevOps에서 클라우드 채택 계획을 관리하는 고객의 경우 이전 프로세스는 각 작업과 사용자 스토리에 반복 경로를 할당함으로써 반영됩니다. 또한 특정 릴리스를 사용하여 각 워크로드에 태그를 지정하는 것이 좋습니다. 해당 태그 지정과 할당은 타임라인 보고서의 자동 채우기를 제공합니다.

다음 단계

타임라인을 예측하여 기대치를 올바르게 전달합니다.