Release 마감일은 종종 고정되어 있으며, 무역 박람회, 회계 압박, 계약상의 의무 등 외부적인 요인에 의해 부과됩니다. 하지만 목표는 가능한 한 빨리 사용자에게 작동하는 소프트웨어를 제공하여 "과정 수정"을 하는 것이므로, 릴리스 소프트웨어 개발 주기를 최대한 짧게 유지하기 위해 모든 노력을 기울입니다. 애자일 릴리스 주기는 1년보다 확실히 짧아야 하며, 종종 6개월 또는 3개월 정도로 짧습니다. 릴리스는 이터레이션으로 구성됩니다. 특정 프로젝트의 경우, 이터레이션 기간은 일반적으로 1주일에서 1개월 사이로 고정됩니다. 릴리스가 6개월이고 이터레이션이 각각 2주씩 진행될 경우, 릴리스는 13개의 이터레이션으로 구성됩니다.
일부 환경에서는 소프트웨어가 각 반복 작업 또는 몇 번의 반복 작업 끝에 사용자 또는 적어도 일부 사용자에게 점진적으로 제공될 수 있습니다. 초기 기능 목록을 파악하고 우선순위를 정하고 잠재적으로 예상되는 기능을 예측한 후, 팀은 릴리스 계획 회의를 개최하여 전체 릴리스 일정을 수립하고 제공 가능성이 높은 기능을 결정합니다. 우선순위가 매겨진 기능별 전체 릴리스 계획은 개별 반복 작업 계획에 직접적으로 반영됩니다.
일부 애자일 방법론은 프로그래머와 고객 간의 명확한 책임 분리를 강조합니다. 계획 단계에서는 고객만이 비즈니스 의사 결정과 우선순위 지정을 담당하고, 프로그래머만이 작업 예측 및 개발 실행을 담당합니다. 민첩한 방법 또한 경영진이 개발 그룹에 임의로 기술 선택을 강요하는 것을 강력히 금지하고, 대신 개발자에게 시스템과 프로젝트에 가장 적합한 도구를 선택할 수 있는 최대한의 자유를 제공해야 합니다.
예비 출시 계획
초기 출시 계획의 목표는 출시 마감일까지 어떤 기능들이 제공될지 대략적으로 예측하는 것입니다(마감일이 고정되어 있다고 가정할 때). 또는 특정 기능 세트에 대한 대략적인 제공일을 선택하는 것입니다(범위가 고정되어 있을 때). 이 정보를 활용하여 프로젝트가 최소한 자체 투자 비용을 충당할 만큼 충분한 ROI를 창출할 수 있을지, 그리고 그에 따라 진행 여부를 결정합니다.
초기 출시 계획 회의는 하루 이상 지속되는 경우가 거의 없습니다. 하루 종일 회의에 참석하기 어렵다면 이틀 반나절을 꼬박 지새우기도 합니다. 먼저, 고객은 제공할 우선순위 기능을 제시합니다. 이상적으로는 개발자들이 각 기능을 구현하는 데 필요한 작업량을 대략적으로 예측해 놓은 상태여야 합니다.
개발자의 추정치와 고객의 기능 우선순위를 활용하여 팀은 출시 계획을 수립하고, 각 기능을 초기 몇 번의 반복 작업에 대략적으로 매핑합니다. 개발자는 우선순위가 낮은 기능이 설계 또는 아키텍처 위험을 초래할 수 있다는 것을 알게 될 수 있으며, 따라서 프로젝트 초기에 잠재적 위험을 해결하기 위해 고객에게 해당 기능을 이전 반복 작업에 할당하는 것을 고려해 달라고 요청할 수 있습니다.
개발팀의 이전 릴리스 속도가 이미 알려져 있다면 매우 유용합니다. 이 경우, 범위가 고정되어 있다면 필요한 모든 기능에 대한 총 추정치를 팀의 속도로 나누어 기능을 제공하는 데 필요한 대략적인 반복 횟수와 마감일을 계산합니다. 마감일이 고정되어 있다면(일반적으로 그렇듯이), 속도에 반복 횟수를 곱하여 제공 가능한 기능 수를 대략적으로 파악합니다. 개발팀의 속도를 알 수 없다면, 개발팀은 속도에 대한 추정치를 제공해야 하며, 신뢰할 수 있는 속도 수치를 도출할 때까지 처음 몇 번의 반복 작업 동안은 릴리스 계획이 덜 정확하다는 것을 이해해야 합니다.
예비 출시 계획
초기 출시 계획이 모든 당사자를 만족시키는 경우는 드뭅니다. 충분한 기능을 제공하지 못하거나 원하는 기능을 제공하는 데 너무 많은 시간이 필요한 것처럼 보이기 때문입니다. 하지만 애자일 환경에서 팀은 이러한 냉혹한 현실을 직시하고 이를 바탕으로 소프트웨어 개발 계획을 수립합니다. 모두를 만족시킬 수 있는 범위의 기적을 믿는 사람은 아무도 없습니다. 집단적으로 부정하는 대신, 팀은 실제 지표와 협상을 활용하여 프로젝트 시작 직전까지 어려운 결정을 내립니다.
Agile 사상 리더들은 그것이 가능한 주어진 프로젝트의 범위, 마감일, 리소스 및 품질을 조정할 때, 조정에 효과적으로 반응하는 유일한 변수는 마감일과 범위입니다. 광범위한 연구에 따르면 규모가 큰 팀은 품질이 낮은 시스템을 더 느리게 제공하는 반면, 규모가 작은 팀은 품질이 높은 시스템을 더 빨리 제공하는 경향이 있습니다. 실제로 팀에 프로그래머를 추가해야 할 수도 있지만, 이는 팀의 속도를 높이는 것이 아니라 적어도 일시적으로는 속도를 늦출 가능성이 높습니다. 이러한 결과를 받아들이면, 스폰서, 고객, 개발자, 관리자 및 기타 이해 관계자가 실행 가능한 것으로 합의한 릴리스 계획을 수립하기 위해 릴리스 계획에서 범위 또는 마감일을 조정해야 한다는 것을 인정하게 됩니다. 팀이 이러한 어려운 결정을 미리 내리면 프로젝트의 전반적인 위험이 줄어듭니다. 팀이 마감일까지 이해 관계자의 투자에 대한 충분한 보상을 제공하는 기능 세트를 생산할 가능성이 높아집니다.
지속적으로 출시 계획
초기 릴리스 계획은 대략적인 것으로 알려져 있습니다. 프로젝트가 투자 대비 충분한 수익을 낼 수 있을 것이라고 예측하여, 시작하기에 충분할 만큼만 세부적으로 작성해야 합니다. (초기 릴리스 계획에서 예측한 ROI가 프로젝트를 정당화하기에 너무 낮다면, 큰돈을 낭비하기 전에 프로젝트를 취소할 수 있습니다.) 애자일 프로젝트에서는 지속적으로 계획을 세우고 진행하면서 방향을 수정합니다. 방향을 수정하는 주요 메커니즘 중 하나는 다양한 피드백에 따라 릴리스 계획을 발전시키는 것입니다. 팀의 속도가 안정되려면 최소 두 번의 반복 작업이 필요합니다. 반복 작업을 통해 계획보다 기능이 적게 제공되기도 하고, 더 많아지기도 합니다. 기능, 아키텍처, 디자인, 프레임워크 또는 기술 선택이 너무 위험하거나 실행 불가능할 수도 있습니다. 사용자 인터페이스 수정이 필요할 수도 있고, 직원이 감원되거나 추가될 수도 있으며, 기능 우선순위가 변경될 수도 있습니다. 이러한 모든 요소는 릴리스 계획을 지속적으로 수정하고 개선하는 데 도움이 됩니다. 새로운 반복 계획이 발표될 때마다 새로운 현실을 반영하는 수정된 릴리스 계획도 함께 발표되어야 합니다.
시작 및 마무리
많은 애자일 팀은 첫 번째 반복(흔히 "반복 0"이라고 함)에서 적은 양의 기능만 제공하도록 계획합니다. 이는 초기 기술 및 물류 문제를 명확히 파악하고 아키텍처를 처음부터 끝까지 집중적으로 다룰 수 있도록 하기 위함입니다. 이는 애자일 경험이 거의 없거나 전혀 없는 팀에게는 매우 중요할 수 있습니다. 적절한 속도 지표가 없는 팀의 경우, 두 번째 또는 세 번째 반복이 끝나고 나서야 속도가 안정적이고 신뢰할 수 있게 되었음을 의미할 수 있습니다.
일부 팀은 안정화, 시스템 전반의 통합 및 테스트, 버그 수정, 사용자 문서 작성을 위해 프로젝트 종료 시점에 최대 두 번의 반복 작업을 예약하기도 합니다. 이상적인 애자일 프로젝트에서는 이러한 작업이 필요하지 않겠지만, 현실적으로는 팀이 따르는 구체적인 애자일 관행, 조직 구조, 시스템의 전반적인 복잡성, 팀에 기대되는 비코드 결과물, 시스템 배포의 복잡성 등 여러 요인에 따라 달라집니다.
자주 묻는 질문
정말 릴리스와 릴리스 계획을 사용해야 합니까?
일부 팀은 다음과 같은 방법으로도 문제를 해결할 수 있습니다. 민첩한 계획 릴리스 수준에서. 예를 들어, ASP는 매 반복(즉, 몇 주마다)마다 소프트웨어를 프로덕션 환경에 배포할 수 있으므로, 모든 반복은 사실상 릴리스이며, 반복별 간단한 애자일 계획만으로도 충분할 수 있습니다. 반면, 소프트웨어 관리자에게 일정 수준의 가시성이 필요한 경우 릴리스 관리 릴리스 수준(즉, 진행 상황, 상태, 초기 소프트웨어 개발 계획과의 변경 사항 등)을 계획하고 관리하는 것이 매우 중요할 수 있습니다.
릴리스 규모는 얼마나 됩니까?
Release일반적으로 2개월에서 12개월 사이입니다. 더 긴 릴리스의 경우, 여러 개의 하위 릴리스로 나누는 것이 좋습니다.
릴리스에는 몇 개의 반복이 있나요?
릴리스 내 반복 횟수는 일반적으로 일정에 따라 결정됩니다. 릴리스 기간이 6개월이고 반복 횟수가 2주라면, 해당 릴리스에는 13번의 반복 횟수가 예약되어야 합니다.
출시 계획에는 누가 참여하나요?
소규모 팀의 경우, 전체 교차 기능팀이 의견 제시 및 책임 이행을 위해 참여하는 것이 합리적일 수 있습니다. 대규모 팀이나 조직의 경우, 팀의 일부를 대표하도록 선출하거나 선출할 수 있습니다.
출시 계획 회의는 얼마나 오래 진행되나요?
Release 일반적으로 계획 회의는 4~8시간 동안 진행됩니다.
출시 계획 회의를 준비하기 위해 얼마나 많은 작업이 수행됩니까?
일반적으로 프로젝트 승인, 예산, 비전, 팀 구성 등 릴리스 계획 회의에 앞서 상당한 작업이 수행됩니다. 기능과 관련하여 고객은 초기 기능을 식별하기 위해 개발팀과 협력하고, 잠재적으로는 기능을 분석하여 초기 고수준 견적을 제공하는 데 시간을 투자했을 가능성이 높습니다.
출시 중에 출시 계획이 변경되나요?
더 많은 정보가 공개되고, 기능이 제공되고, 시스템에 대한 이해가 깊어지고, 비즈니스 요구가 진화하고, 우선순위가 변경됨에 따라 릴리스의 전반적인 구성은 거의 확실히 변경될 것입니다. 예상된 바이지만, 시간이 지남에 따라 소프트웨어 릴리스 관리가 어떻게 발전할 것인지는 모든 관련 이해관계자에게 전달되어야 합니다.
