애자일 프로세스 모델 - 스크럼

애자일 프로세스 모델은 변경사항에 민첩하게 반응을 할 수 있는 개발방법이다. 아마도 애자일 중 스크럼 방식이 제일 잘 알려진 것 같다. 스크럼 모델에 대해 알아본다.

스크럼은 원래 럭비에서 사용되는 용어이다. 경기가 중단되었다가 다시 시작 할 때, 양쪽편은 서로 스크럼을 짜고 상대 팀에 대항해 밀집대형을 갖춘다. 이후 경기가 시작되면 공격하는 쪽에서 공을 들고 질주(스프린트)를 한다. 상대팀의 인골지역까지 공을 들고 달리다가 땅에 찍으면 득점한다. 물론 상세한 럭비의 규칙은 잘 모르지만, 진행되는 방식을 보면 스크럼이라는 모델의 진행방식이 보인다.

사실 스크럼은 소프트웨어 개발 보다는 프로젝트관리에 중점을 둔 애자일 방법론이다. 

 

스크럼의 진행 과정

단계	절차	내용
1	제품 기능 목록 작성	요구사항 목록에 우선순위를 매기고 제품 개발 기능 목록 작성
2	스프린트 계획 회의	스프린트 구현 목록 작성 스프린트 개발 기간 추정
3	스프린트 수행	스프린트 개발 일일 스크럼 회의 스프린트 현황판 변경 소멸차트 표시
4	스프린트 개발 완료	실행 가능한 최종 제품 생산
5	스프린트 완료 후	스프린트 검토 회의 스프린트 회고 다음 스프린트 계획 회의

 

 

스크럼 용어

- 제품 기능 목록(Product Backlog) : 사용자가 요구하는 제품의 기능 목록이며 제품에 관한 요구사항에는 우선순위가 매겨진다. 제품 책임자가 요구사항 목록에 우선순위를 매겨 제품 기능 목록을 작성한다. 개발중에도 수정이 가능한데 보통은 한 주기가 끝날 때 까지는 수정을 되도록 하지 않는다.

- 사용자 스토리(User Story) : 제품기능 도출 후 각 기능을 간략하게 서술할때 사용하는 방법으로 보통 한장의 인덱스 카드로 작성한다.(포스트잇) 개발자 입장이 아닌 사용자의 입장에서 필요로 하는 내용을 간략하게 기술한다.

- 스토리 포인트(Story Point) : 요구사항의 규모를 측정하는 단위로 업무량을 이용해 산정한다. 스토리 간 업뮤량을 비교해 제일 작은 단위가 1이 되고 이에 대비해 얼마나 일이 많은지로 포인트를 산출한다. 주로 개발자가 산출한다.

- 스프린트(Sprint) : "전력질주"라는 의미에서 알 수 있듯이 작은 단위의 개발 업무를 단기간에(보통 1~4주간 수행) 전력 질주하듯이 수행한다. 

- 스프린트 계획 회의 : 스프린트를 어떻게 수행할 것인지를 계획하는 것으로 크게 두 가지가 있다.

  1) 전체적인 스프린트 계획 회의 : 사용자의 대변인인 제품 책임자가 사용자가 원하는 바를 설명하고 스크럼 마스터는 제품기능목록을 검토하면서 우선순위 확인 팀원들과의 회의를 통해 사용자의 의도를 파악한다.

  2) 세부적인 스프린트 계획 회의 : 우선순위가 높은 항목을 어떻게 구현할 것인지 구체적인 작업 계획을 수립한다. 제품기능 목록에서 개발 항목을 결정하고 구현 목록을 작성한다. 팀원들은 해당 작업을 수행하는데 소요되는 시간을 추정한다.

- 스프린트 구현 목록(Sprint Backlog) : 제품 기능 목록에 있는 스토리 중에서 선택해서 작성되는데 선택 기준은 스프린트 기간 내에 완료할 수 있는만큼의 스토리인지, 실행 가능한 결과물이 나올 수 있는 수준인지이다. 이를 통해 각각의 스프린트 주기에서 개발할 작업목록이 작성 된다. 세부작업 항목, 작업자, 예상작업 시간 등의 정보가 담겨 있다.

- 소멸차트(Burndown Chart) : 계획 대비 작업이 어떻게 진행되고 있는지를 날짜별로 남은 작업의 양으로 나타낸다. 시간이 지남에 따라 차트가 감소한다(남은 작업량을 나타내므로...) 계획그래프와 실제 그래프의 기울기 차이로 계획대비 작업이 얼마나 빠르게 혹은 느리게 진행되고 있는지를 알 수 있다.

- 일일 스크럼 회의(Daily Scrum Meeting) : 스프린트 기간 내내 하는 일단위 회의를 말한다. 15분 내외로 짧게 진행하는데 스프린트 작업 목록의 진행상황점검을 간단히 한다. 한 사람씩 전날 한 일과 당일 할 일을 이야기 한다. 스크럼 마스터는 일의 전체적인 진행상황을 확인하고 소멸차트에 남은 작업량을 표시하며 방해요소를 파악하여 제거해 주는 역할을 한다.

-  스프린트 현황판(Task Board) : 개발팀의 개발현황을 나타낸다. 진척도, 남은 작업 등

- 스프린트 진척관리 : 각 Task별 작업 시간, 남은 시간 등을 기록해 진척관리를 한다. 

- 스프린트 검토회의(Sprint Review) : 하나의 스프린트 반복주기가 끝난 후 생성된 실행가능한 산출물을 시연하고 검토한다. 사용자들은 이를 보고 요구사항에 부합하는지, 개선사항이 무엇인지 등을 피드백한다.

- 스프린트 회고(Sprint Retrospective) : 스프린트에서 수행한 활동과 개발산출물을 살펴보고 잘된 점, 아쉬운 점, 개선할 사항 등을 확인한다.

 

스크럼 관련자 역할

담당자	역할
제품 책임자	제품 기능 목록 작성 비즈니스 관점에서 우선순위와 중요도를 매기고 새로운 항목 추가 스프린트 계획 수립 까지 수행, 팀 운영에는 관여 안함
스크럼 마스터	제품 책임자를 돕는 역할 업무를 배분, 스크럼팀이 스스로 관리할 수 있도록 지원 스크럼의 원칙과 가치를 지킬 수 있도록 지원 개발 과정에 방해요소 파악하여 제거
스크럼 팀	보통 5~6명으로 구성되며 사용자 요구사항을 사용자 스토리로 도출하고 구현 기능을 작업단위로 나누고 일정, 작업속도 등을 추정하여 제품 책임자에게 알려줌 스프린트에서 생산된 결과물을 시연 스크럼 회의에 참석하여 진척상황을 점검

  

스크럼방식의 장점

- 반복 주기마다 생산되는 실행 가능한 제품을 통해 사용자와 의사소통을 원활히 할 수 있다

- 일일 회의를 통해 팀원 간 협조와 조율을 신속히 할 수 있다.

- 일일 회의 시 자신의 일정을 발표함으로써 업무에 집중할 수 있는 환경을 조성 할 수 있다.

- 타 방법론에 비해 실행중심적이다.

- 개발에 방해되는 사항들을 스크럼 마스터를 통해 제거해 나갈 수 있다.

- 프로젝트의 진행현황을 파악하기 쉬우므로 목표관리를 하기 수월하다.

 

스크럼 방식의 단점

- 반복주기마다 실행가능한 산출물을 만들어야 하므로 작업시간이 더 필요하다.

- 일일회의가 길어질 수 있으므로 오히려 매일하는 회의가 작업에 부담이 될 수 있다.

- 투입공수를 측정하지 않아 작업의 효율성을 알 수 없다.

- 프로세스의 품질을 평가하지 않으므로 품질관리 활동이 상대적으로 미약하다.