애자일 프로젝트 일정 계획에 대해 알아보겠습니다. 애자일 프로젝트는 세부적인 요구 사항과 세부적인 일정 계획을 확인하는 것으로 시작하지 않고 프로젝트가 진행됨에 따라 요구 사항과 일정을 지정하고 세부적으로 설명하는 특별한 유형의 프로젝트입니다. 따라서 애자일 프로젝트 일정 계획은 일반적인 프로젝트 일정 계획과 다른 특별한 특징이 있습니다. 적응형 개발 방법인 애자일 프로젝트 일정 계획에 대해 자세히 설명하겠습니다.
Agile 프로젝트 일정 계획 설명
애자일 프로젝트는 주어진 일정과 리소스로 구현할 수 있는 최대 범위에 초점을 맞춘 프로젝트 진행 방법입니다. 애자일 프로젝트는 적응형 개발 방법의 가장 대표적인 개발 방법론입니다. 애자일 프로젝트 일정 계획은 폭포수 프로젝트 일정 계획과 다릅니다. 예측 개발 방법인 폭포수 프로젝트는 계획을 강조하고 범위와 일정 목표를 달성할 수 있는 리소스를 추정하는 데 최대한 집중합니다. 그러나 애자일 프로젝트는 주어진 일정과 리소스로 최대 효과를 창출하는 데 더 집중합니다.기민한스케줄의 개발 방법을 Agile Release Planning이라고 합니다. Agile Release Planning은 Agile 프로젝트의 스케줄을 상위 레벨에서 계획하는 기법입니다. 하위 레벨은 임원 및 관리자 레벨에 맞춰져 있고 상위 레벨은 보다 실용적인 계획입니다. Agile Release Planning은 Agile 프로젝트에서 궁극적으로 구축하고자 하는 제품과 서비스의 진화에 대한 비전과 이를 달성하기 위한 로드맵을 기반으로 Agile 프로젝트 반복 주기를 반복하기 위한 릴리스 스케줄과 반복 계획을 수립하고 상위 레벨의 프로젝트 스케줄을 만드는 것입니다. 릴리스에 필요한 반복 횟수에 대한 상위 레벨의 스케줄을 만드는 것입니다. 스케줄의 경우 Agile Sprint가 끝날 때 해당 기능을 사용할 수 있는지 여부를 정의하므로 프로젝트 스케줄을 보다 쉽게 잡을 수 있습니다. Agile Release Planning에서 제품 비전과 제품 로드맵은 가장 중요한 계획 요소입니다. 그리고 릴리스 계획을 기반으로 여러 릴리스와 여러 반복 주기로 나뉩니다. 각 반복 주기에는 반복 계획과 각 기능이 있습니다.[애자일 릴리즈 기획 구분 요소들]
Agile Release Planning에서 Product Vision은 제품이 회사의 전략을 어떻게 지원할 것인지를 표현합니다. Product Vision은 제품과 서비스를 개발하는 목적이며, 이를 통해 달성해야 할 미래 상태를 의미합니다. 따라서 Product Vision은 Agile 프로젝트의 시작점입니다. Agile Release Planning의 Product Roadmap은 프로젝트 일정에 따라 결과물의 예상 릴리스 순서를 표현합니다. Agile Release Planning은 Product Vision과 Roadmap을 기반으로 중요한 기능을 릴리스해야 하는 시간을 예약하는 것입니다. 또한 릴리스를 가능하게 하기 위해 필요한 반복 횟수도 계획합니다. 적응형 개발 방법인 Agile 프로젝트에서 릴리스 계획은 프로젝트 시작 시 수립한 상위 릴리스 계획과 프로젝트가 진행됨에 따라 세부적으로 지정되는 반복(스프린트) 계획으로 나뉩니다. 릴리스 계획은 얼마나 많은 반복을 어떤 일정으로, 어떤 요구 사항에 따라 개발할 것인지 결정합니다. 각 반복 계획에서 각 반복에서 생성해야 할 요구 사항을 확인하고 반복에서 수행해야 할 세부적인 작업 계획을 정의합니다. 릴리스 계획에서 각 반복에서 구현할 요구 사항은 확인하지 않고도 반복이 시작되기 전에 확인할 수 있습니다. 릴리스 계획은 전체 프로젝트를 계획하는 반면 반복 계획은 각 반복을 계획합니다. 릴리스 계획은 프로젝트 시작 시에 시작되고 반복 계획은 반복이 시작되기 전에 시작됩니다. 릴리스 계획은 반복 주기, 일정, 일반 요구 사항, 개발 우선순위 및 반복 개발 규모를 계획 항목으로 정의합니다. 반복 계획은 반복 속도, 반복 개발 목표, 세부 요구 사항(사용자 스토리), 수행할 작업 및 일정을 계획 항목으로 계획합니다.
Agile 프로젝트 일정 계획 프로세스
Agile 프로젝트에서 릴리스 계획 기반 일정 계획 프로세스는 5단계로 분류할 수 있습니다. Agile 프로젝트 일정 계획 프로세스의 5단계는 다음과 같습니다. 제품 백로그 생성, 스토리 포인트 추정, 스프린트 기간 설정, 평균 개발 속도 추정, 전체 일정 추정.[애자일 프로젝트 일정 기획 프로세스]
애자일 프로젝트에서는 먼저 제품 비전을 정의한 다음 백로그를 만들어야 합니다. 백로그가 생성되면 스토리 포인트라는 추정 단계를 거칩니다. 그런 다음 스토리 포인트가 추정된 후 스프린트 기간을 설정하여 몇 주 동안 반복할지 결정합니다. 스프린트 기간을 타임 박스 사이클이라고 합니다. 스프린트 기간이 결정되면 평균 개발 속도가 추정됩니다. 여기서 백로그는 요구 사항 목록을 의미합니다. 제품 백로그는 애자일 프로젝트에서 구현할 전체 요구 사항이고 반복 백로그는 특정 반복에서 개발할 요구 사항입니다. 프로젝트 소유자는 제품 백로그를 결정하고 우선순위를 조정할 책임이 있습니다. 백로그 정제도 수행되며 백로그 정제는 프로젝트 중에 백로그 콘텐츠를 자세히 설명하거나 백로그 개발의 우선순위를 조정하는 활동입니다. 스토리 포인트와 평균 개발 속도가 추정되면 결과에 따라 전체 일정을 추정할 수 있습니다. 스토리 포인트는 특정 요구 사항의 크기를 의미합니다. 스토리 포인트는 스토리의 크기와 크기입니다. 스토리 포인트는 애자일 프로젝트에서 복잡성을 고려한 작업량을 표현하는 개념입니다. 스토리 포인트가 클수록 더 많은 작업이 필요하다는 것을 의미합니다. 스토리 포인트는 절대적인 값의 개념이 아니라 많은 사람들의 의견을 수집하여 만든 상대적인 개념입니다. 많은 사람들의 의견을 수집하는 과정을 거칩니다. 스토리 포인트를 추정할 때 프로젝트 팀의 중간 레벨 팀원이 스토리를 구현하는 데 걸리는 일수를 1포인트에 해당하는 평균 노동력으로 추정합니다. 스토리 포인트를 추정할 때 주로 플래닝 포커 기법을 사용합니다. 그리고 스토리 포인트는 나중에 지속적인 검사를 통해 다시 추정할 수 있습니다. 플래닝 포커 기법은 스토리 포인트를 추정할 때 사람들의 의견을 통해 만들어지기 때문에 의견이 다를 때 반복적인 과정을 통해 합의된 결과를 얻는 기법입니다. 플래닝 포커는 제품 소유자가 수행합니다. 제품 소유자가 추정할 항목을 제안하면 해당 기능이 정확히 무엇인지 파악하고 논의합니다. 멤버들은 추정치를 적은 카드를 내려놓고, 다른 모든 멤버들이 카드를 내려놓으면 가장 높은 값과 가장 낮은 값을 제안한 팀원들이 그렇게 생각한 이유를 설명한다. 그들은 의견 차이를 계속 논의하고, 기능을 지정하고, 반복한다. 개발 속도 추정치는 애자일 팀이 2주간의 스프린트에서 완료할 수 있는 총 스토리 포인트의 합계를 의미한다. 이는 팀의 역량 또는 용량을 의미한다. 각 스프린트 실행을 통해 실제로 완료된 스토리 포인트를 통해 성과를 확인하면 보다 정확하게 업데이트할 수 있다. 여기서 일정한 수준을 유지하는 것이 가장 바람직하며, 일정한 수준을 유지함으로써 예측이 가능하다. 속도는 생산성의 개념이며 특정 팀이 한 번의 반복에서 구현할 수 있는 평균 스토리 포인트를 의미한다. 속도를 사용하면 전체 반복과 각 반복에서 개발할 수 있는 사용자 스토리의 크기를 추정할 수 있으며, 속도에 대한 정보를 사용하여 전체 요구 사항을 개발하는 데 필요한 노력과 기간을 추정할 수 있다. 전체 일정 추정치는 제품 백로그의 스토리 포인트와 개발 속도를 고려하여 제품 개발에 필요한 전체 일정 계획을 수립하는 것이다. 전체 일정을 추산할 때 적절한 완충 기간으로 버퍼 기간을 추가하는 것을 고려해야 합니다. 백로그 그루밍은 이전 스프린트의 검토 프로세스에서 변경된 사항을 기반으로 기존 백로그에 변경 사항을 추가, 수정 및 삭제한 다음 사용자 스토리를 더 작은 단위로 나누고 정제하여 우선순위를 다시 지정하는 작업을 말합니다. 백로그 그루밍은 다음 스프린트를 시작할 때 수행되지 않지만 이전 스프린트가 끝나기 전에 완료되고 수행됩니다.[단위 스프린트 계획 수립 프로세스]
전체 백로그를 제품 백로그라고 하며, 특정 스프린트에서 구현할 사용자 스토리만 포함된 백로그를 스프린트 백로그라고 합니다. 스프린트 백로그에 있는 사용자 스토리를 구현하기 위해서는 이를 구현하는 데 필요한 작업 단위를 나누고, 가장 중요한 수용 기준을 정하고, 이를 나중에 검토를 실시할 때 스프린트를 완료할 수 있는지 여부를 판단하는 기준으로 사용합니다. 하지만 완료 기준을 결정하기 위해서는 제품이 실제 운영되는 소프트웨어 수준이어야 하며, 제품이 운영 가능한지 여부가 구현이 완료되었는지 판단하는 기준으로 포함되어야 합니다. 단위 스프린트를 계획할 때는 관리자가 결정하는 것이 아니라 개발팀에서 결정합니다. 개발팀 내에서 상호 협의를 통해 담당자를 지정하면 스프린트의 목표 워크로드를 결정하고 계획을 수행합니다. 애자일에서는 수용 기준을 DOD(Definition of Done)라고 합니다. 이는 완료 또는 수용 기준에 대한 정의를 표현한 것입니다. 반복에 기반한 애자일 계획을 수립할 때 고려해야 할 필수적인 사항이 있습니다. 각 애자일 팀은 수용 능력이 다르고 각 제품 소유자는 기본 스토리 크기가 다릅니다. 애자일 팀이 여러 개인 경우 각 팀의 속도는 스토리 포인트로 측정할 수 있지만 스토리 포인트가 가장 큰 팀이 최고라고 판단해서는 안 됩니다. 각 애자일 팀의 용량이 다르기 때문입니다. 일부 팀은 경험이 풍부한 팀원으로만 구성될 수 있고, 다른 팀은 경험이 부족한 팀원으로만 구성될 수 있습니다. 또한 제품 소유자와 협의하여 수행되므로 속도만으로 성과를 측정하거나 판단해서는 안 됩니다. 애자일의 성과는 궁극적으로 제품이 작동하는지 여부의 관점에서 평가되고 판단됩니다. 각 반복에서 스토리를 완료하기 위해 애자일 팀의 용량을 초과하려고 시도해서는 안 됩니다. 애자일 프로젝트에서 반복은 한 번 완료되지 않고 여러 번 반복됩니다. 따라서 반복이 너무 많으면 팀이 지치게 됩니다. 반복 프로세스 중에 팀의 용량이 감소할 수 있습니다. 예상치 못한 장애물에 부딪히거나 팀원이 휴가를 가거나 병가를 내거나 회사를 떠나면 팀의 수용률이 떨어질 수 있습니다. 이런 일이 발생하면 이전과 같은 양의 작업을 완료할 수 없으므로 용량이 줄어든 상태에서 완료할 수 있는 작업에 대해서만 계획해야 합니다. 프로젝트 관리자는 이 상황을 알고 있어야 합니다. 제품 소유자는 스토리를 더 작은 조각으로 나누고 팀이 수행한 작업이 완성된 제품 형태의 작동하는 제품인지 여부를 판단하여 팀이 미래에 무엇을 할 것인지 이해할 수 있어야 합니다. Agile은 전체 단위를 한 번에 계획하는 것이 아니라 스프린트이는 ‘단계’라고 불리는 작은 단위로 계획을 세우고, 프로세스가 진행됨에 따라 진행 상황에 맞춰 계획을 다시 수립하는 방법입니다.