Agile 프로젝트 퀵가이드(2) : Starting편 - 수행 준비
Updated:
Life Cycle 선택
본격적으로 프로젝트를 시작하는 단계에서 우선 결정해야 할 사항은 여타 다른 방법론과 마찬가지로 프로젝트의 Life Cycle 및 이에 따른 세부 공정입니다.
보통 기존 방법론에서는(회사내에서 구비한 방법론), CBD, 패키지 등의 기술/솔루션 도입 및 프로젝트 Management 영역까지 고려하여 방법론에서 포괄적인 공정을 제시하고 방법론 선택에 따라 세부 공정은 자동적으로 결정되는 구조를 갖고 있지요.
스크럼 방식의 애자일 방법론은 규칙과 지침을 매우 최소화하여 기본적인 내용만 가이드하고 있기에, 애자일 방법론을 채택할 경우 어떤 Life Cycle을 채택해야 할지 초반에 신중하게 고민해야 합니다.
오히려 공정이 Fixed 되어 있지 않으므로 프로젝트 특성과 상황에 맞게 다양한 변주가 가능하며, 애자일 방법론의 기본적인 특성인 Iteration을 반복하며 진행하는 Cycle 구조이므로 수행 도중 발생하는 위험/이슈에 따라 프로세스를 개선할 수 있는 여지가 있다고 보아야 합니다.
시작단계부터 바로 스프린트를 진행시킬지, 아니면 분석·설계를 먼저 진행하여 요구사항 확정 or 설계 결과까지 모두 확정한 후에 개발 스프린트만 진행할 것인지에 따라 다음과 같은 Life Cycle을 고려해볼 수 있습니다.
다음 그림에서 알 수 있듯이 스프린트를 바로 진행하더라도 스프린트 내에서 분석~개발 및 테스트가 모두 수행되는 것이므로 애자일을 한다고 해서 분석이나 설계가 소홀하게 간주되는 것은 아닙니다.
Life Cycle 모델
Pure하게 할 것인가 아니면 Hybrid 방식의 Life Cycle을 수립할 것인가에 대해서는 또한 여러가지 변수를 고려해야 합니다.
기술 및 규모·기간·관리 복잡도 수준 / 요구사항 Fix 수준 외에도 계약서에 명시된 단계별 고객인도 산출물, 비지니스에 대한 개발팀의 이해도 수준에 따라 Life Cycle을 결정해야겠지요.
Life Cycle 선정 주요 기준
기존에 없던 새로운 기능보다 기존에 있던 기능을 거의 유지하면서 새로운 플랫폼/인프라에 전환하는 것이 목표인 프로젝트이면 이 역시 애자일로 하는 것을 다시 고려해봐야 합니다. 비즈니스 기능이 새로와지는 것이 없다면 적극적인 PO(Product Owner:제품 책임자)의 참여가 없을 가능성이 높습니다. PO가 관여하지 않는 스크럼 조직이라면 스프린트마다 리뷰가 정상적으로 이루어지지 않게 될 것이고, 개발팀 스스로 자체적인 리뷰로 끝나게 되는 상황이 초래될 것입니다.
스크럼이 추구하는 고객가치가 높은 작동하는 S/W를 개발하는 것이 아니라, 개발자 중심으로만 제품을 주기적으로 개발해내는 방식이라면 굳이 힘들게 스크럼 프로젝트를 진행할 필요가 없을지도 모릅니다.
또한, 물론 기술복잡도가 높고 검증이 필요한 경우에는 스프린트 Iteration을 통해 기술 이슈를 조기에 발견하여 해결하거나 솔루션을 교체할 수도 있습니다. 그러나 신기술, 아키텍처에 대해 검증이 안된 상태에서 업무 영역의 스프린트가 먼저 진행된다면 오히려 잘못된 개발 방향으로 진행이 될 수 있습니다.
따라서, 아키텍처와 설계 모델이 중요하고 주요 표준이 결정되어야만 개발을 할 수 있는 경우인지를 판단하여 업무 기능의 스프린트를 #1부터 바로 시작하기보다 #2 이후로 미루는 것을 고려하십시오.
전체 요구사항의 범위가 Fix되어 있고, 실제적인 요구사항보다 계약의 이행이 중요하다면, 매 스프린트마다 고객 피드백을 반영하는 대신 백로그를 조절하는 스크럼 기법과는 맞지 않으므로, 분석 단계를 거치면서 구체화한 요구사항을 합의할 것을 권장합니다.
그러나 PO를 포함한 그 누구도 프로젝트 초반에 완전한 요구사항을 파악할 수 없다면, 스프린트를 반복하면서 세부적인 사항을 구체화 해나하는 스크럼 방식이 도움이 될 것입니다.
애자일 방법론과 산출물
스크럼 프레임워크에서 중요하게 여기는 산출물은 두 가지입니다. 바로 제품 백로그와 스프린트 백로그 - 이 부분에 대해서는 뒤에 오는 퀵가이드 4장에서 설명하겠습니다.
그렇다고 해서 기존에 제출하던 산출물을 무시하는 것은 아닙니다. 개발 공정상에 반드시 있어야 하거나 향후 운영을 위해 필요한 산출물은 Iteration별 분석/설계를 거치면서 작성을 해야 합니다. 대신에 산출물의 인도 시기는 기존의 waterfall 마일스톤과 다르게 조정할 필요는 있습니다.
(이 부분은 CNAP 애자일 방법론의 테일러링 부분을 참고하세요)
애자일에서 산출물을 간소화하려는 이유는 실제 동작하는 결과물을 보여주고 고객에게 빠른 피드백을 받기 위해서입니다. 문서 산출물을 납기하고 고객의 확인 서명을 받는 작업이 “실제 작동되는 S/W”와는 엄밀하게 말하면 직접적 관련은 없습니다. 오히려 종종 개발하기도 벅찬 일정임에도 불구하고, 고객에게 인도하여 봤자 사용되지도 않을 문서 산출물을 작성하느라 시간을 허비하는 경우가 많습니다.
애자일로 프로젝트를 하기로 결정했다면 사전에 고객과 합의하여 산출물을 최소화-서로간의 의사소통과 이해를 위해 필요한 수준-하고, 형식적인 작업보다는 시장의 요구사항에 부합하는 기능을 빠르게 구현해내는 것이 애자일 프로젝트의 목적임을 고객에게 이해시키십시오.
그렇지 않다면 애자일로 프로젝트를 하는 것은 의미가 없을지도 모릅니다.
- 애자일 방식에 대해 흔히 갖는 오해
- 스크럼 기법의 이점은 고객가치가 높은 기능을 우선적으로 delivery하면서 빠른 피드백을 반영하여 완성도가 높은 SW를 개발하는 데에 있다.
- 고객의 요구사항을 반영하는 대신에 우선순위가 높지 않은 기능은 Scope-out 할 수 있어야 한다.
- 프로젝트 범위는 줄지 않으면서 요구사항 수정으로 인한 rework, 추가 개발로 인한 공수의 증가는 고려하지 않고, 무조건 고객가치가 높은 기능을 빨리 보여주는 방식으로 오해해서는 안된다.
- 업무범위가 fix되어 계약한 범위의 모든 기능을 빠짐없이 delivery해야 하는 경우라면 Waterfall 또는 Hybrid 모델을 추천한다.
스프린트를 포함한 Life Cycle을 선정하였다면 이제부터 본격적으로 스크럼을 활용한 전체 공정을 살펴보자.
스크럼 공정의 이해
스크럼 프로젝트의 공정은 스프린트를 반복적으로 진행하는 것으로 구성되며, 기본적인 스크럼 프로세스는 다음과 같습니다.
※ 스크럼 프로세스의 각 이벤트 규칙에 대해서는 “스크럼 가이드북”을 참고하기 바람
위 스크럼 프로세스의 활동들은 다음과 같이 전체 프로젝트 공정에 걸쳐 수행됩니다. 당사 방법론에서는 스크럼 프로젝트 공정 중 본격적인 스프린트 시작을 위해 준비 및 Planning하는 단계를 스프린트 제로(Sprint #0)라고 표현합니다. 개발 조직(스크럼팀) 구성, 전체 일감(제품 백로그) 도출 및 스프린트 주기와 회수를 결정하고 전체적인 Release Plan과 이에 맞는 스크럼 환경을 조성하는 것이 스프린트 제로 단계에서 해야 하는 일입니다.
이제 다음 장에서는 스프린트 제로 단계로 진입하여 스크럼 팀을 어떻게 구성할지에 대한 내용을 다루도록 하겠습니다.
< EOF >