[애자일 방법론] 스크럼 기법(Scrum)
스크럼 기법(Scrum)
애자일 방법론에 대해 들어본 적이 있는가? 폭포수 모델, V 모델, 나선형 모델, 프로토타이핑 모델, 점진적 모델 등 여러 모델이 있지만 그중에서도 최근 개발 트렌드는 애자일이라고 할 수 있다. 왜냐하면 최근에는 소프트웨어 개발 주기가 짧으며 사용자의 요구에 빠른 대응을 하기 위해서는 개발 주기가 짧으며 반복적인 애자일 기법이 적합하기 때문이다.
애자일 방법론에는 여러 기법이 있는데 이번 포스팅에서는 그중에서도 팀의 생산성을 극대화시키는 스크럼 기법에 대해 알아보고자 한다.
먼저 스크럼을 요약 정리하면 다음과 같다.
피드백을 조금 더 일찍, 조금 더 자주, 조금 더 많이, 조금 더 지속적으로 주고받는 것
한줄 요약을 읽고나면 어떤 느낌인지 약간의 감이 왔을 것이다. 사실 스크럼은 단순하니 너무 걱정하지 말자. 다만 왜 스크럼이 필요한지가 중요한 것이니 그 부분을 이해하면 된다. 모든 것은 필요에 의해 등장한 것이고 수요가 많아지면 트렌드가 된다는 것만 기억하고 시작해보자.
+ 필자는 Ken Schwaber, Mike Beedle의 Agile Software Development with Scrum을 읽고 이를 기반한 내용으로 작성한다.
스크럼의 유래
오늘날 소프트웨어 산업 현장을 살펴보면 경쟁이 매우 치열하며 그중에서도 개발 속도와 코드 수정에 관한 유연성은 필수적인 요소이다.
그래서 많은 기업들이 과거 폭포수 모델과 같이 순차적인 모델이 아니라 전체적인 주기를 반복적으로 지향하는 기법을 선호하는데 이는 럭비 경기에서 팀 동료들 간에 공을 재빨리 돌려서 전체 팀이 경기장에서 마치 한 몸처럼 움직이는 것과 비슷하다.
스크럼이란 용어는 제품 개발 프로세스의 한 유형을 가리키는 용어로 일본에서 처음 사용되었고, 경쟁자들을 압도하는 일부 기업들의 제품 개발을 설명하기 위해 스크럼이라는 용어를 사용하였다. 스크럼은 실제 럭비에서 사용하는 용어로 경기의 흐름이 멈추거나 사소한 반칙이 발생했을 경우, 완전히 공정하게 다시 경기를 재개하기 위해 아래와 같이 대열을 취하여 서로 열심히 밀어내는 이 형태가 바로 스크럼이다.
서로 쉴틈없이 경쟁하며 상대를 밀어내는 모습이 제품 개발 프로세스와 매우 흡사하지 않은가? 이러한 이유로 스크럼이라는 용어가 지속적으로 사용되고 있는 것이다.
여하튼 스크럼은 비즈니스 요구를 충족시키는 SW의 개발에 초점을 맞추기 위해 복잡함을 제거하는 관리 및 제어 프로세스이다. 또한 스크럼은 익스트림 프로그래밍(XP)의 실천 방법으로 사용하고 1개월 안에 돌아가는 기능을 만들 수 있게 한다.
스크럼은 주로 팀 수준의 사안들을 다루는데 프로젝트를 진행하는 팀원 간의 협업을 효과적으로 할 수 있도록 해주고 그렇게 함으로써 품질 높은 제품을 생산할 수 있게 해준다.
스크럼의 역사
지금까지 알아본 내용에 의하면 스크럼은 오늘날 기업들의 경쟁이 심화된 상황에서 빠르고 반복적인 개발 주기의 프로세스의 니즈에 의해 생긴 기법인 것을 이해할 수 있다. 그렇다면 사용되는 현장도 머릿 속으로 상상이 될 것이다. 그렇다면 현장에서 스크럼이 어떤 역할을 하는지 살펴보면서 자세히 알아보자.
스크럼을 세계에서 최초로 시험하고 보수한 곳은 1996년의 인디비쥬얼 사(Individual, Inc.)였다. 당시 경영난을 겪고 있었는데 경영진들은 스크럼에게 희망을 걸었다. 인터넷이 출현하자 인디비쥬얼 사는 개인용 웹사이트인 '퍼스널 뉴스페이지'를 제공하기 시작했고, 총 8명의 수준 높은 기술자들이 개발팀으로 구성되었다. 개발팀의 기술자들은 수준이 높았지만 생산성이 기업 내에서 가장 떨어졌다. 왜냐하면 해야할 일을 진행하는 중에 다른 부서의 작업들에게 이리저리 끌려다녔기 때문이다. 예를 들면, 프로젝트에 집중하려 해도 제품 관리자가 갑자기 기능 요구를 변경한다거나 요청한 기능을 어떻게 구현할지 고민한 후 작업에 착수할 즈음이면, 다른 아이디어 구현을 위해 다른 작업에 강제로 끌려가곤 했기 때문이다. 그래서 이 책의 저자는 일을 해야 하는 항목을 정리하고 각 항목별로 우선순위를 정하여 진행하도록 권했다. 그리고 어떤 요청을 받으면 그 목록을 추가했고 중요도와 기간 그리고 목록에 있는 다른 기능들을 기준으로 우선순위를 정하여 일을 수행하도록 하였다. 이때 처리해야 할 일 목록을 '제품 백로그 목록'(Product Backlog list)이라고 부르기 시작했다. 그리고 이 방법과 더불어 반복적이고 점진적인 개발 방법을 저자는 한번 더 인디비쥬얼 사에 제안했고 30일이라는 한 번의 반복주기(iteration)를 '스프린트'(Sprint)라고 불렀다.
또한 매일 매일 팀원과 사내 직원들이 모여서 회의를 진행했는데, 이때 발언은 오직 팀원만 가능했으며 다음과 같은 3가지 주제에 대해서만 말할 수 있었다.
1) 지난 일일 스크럼 회의 이후로 무엇을 했는가, 2) 다음 일일 스크럼 전까지 무엇을 할 계획인가, 3) 작업의 방해요소는 무엇인가
이때 회의실이 부족해서 작은 사무실에서 현황 회의를 진행했고 약 15분간 진행했다. 이 회의를 '스크럼 회의'라고 불렀다.
스크럼의 실천법
아래의 그림은 스크럼 방법을 그림으로 나타낸 것이다. 초반부에 봤던 럭비의 스크림과 같이 스프린트를 중심에 두고 원의 형태로 생겼음을 확인할 수 있다.
스크림의 역사를 꼼꼼히 살펴보면 아래 내용은 당시 스크럼의 흐름을 도식화해 놓은 것임을 한눈에 알 수 있다.
백로그는 해야할 일이고 제품 백로그 중에서 한 번의 스프린트(한 주기)동안 개발 가능하다고 생각하는 스프린트 백로그만 선택하여 스프린트 주기가 반복된다. 또한 해당 주기동안 매일 15분간 스크럼 회의가 진행된다. 이때 발언은 프로젝트를 참여하는 팀원만 가능하다.
그리고 백로그는 제품 백로그와 스프린트 백로그로 나뉘는데 제품의 모든 요구사항을 우선순위에 따라 나열한 목록이고 프로젝트가 끝날 때까지 확정되지 않는다. 다만 우선순위가 가장 높은 항목이 가장 필요한 항목이며 이는 사용자, 고객, 영업 부서, 마케팅 부서, 고객 서비스 부서 등 모두가 제출할 수 있으나 우선순위 부여는 오직 제품 책임자(Product Owner)만이 부여할 수 있다. 그리고 스프린트 백로그는 한 스프린트 동안에 현실적으로 개발 가능하다고 생각한 만큼 제품 백로그(해야할 일의 목록)을 선택한 것이다.
아래 표에서 언급하지 않은 것은 스크럼 마스터인데, 이는 스프린트 주기 동안의 관리자이며 말 그대로 지금까지 살펴본 스크럼 기법이 잘 이루어질 수 있도록 스크럼의 실천법을 실천하도록 강제하고, 중요한 결정을 내리며 필요한 자원을 얻을 수 있도록 돕는 역할을 한다.
한 번의 주기가 끝나면 팀은 스프린트 검토 회의에 제품 책임자와 함께 모여 한 스프린트 동안 만든 결과물에 대해 검토하고 테스트한다. 테스트가 끝나면 제품 책임자는 제품 백로그를 재정리하고 다음 과정이 반복된다.
이 모든 과정이 끝나고 릴리스 시점이 되면 스크럼이 끝나는 것이다.
용어 정리
제품 백로그(product backlog): 프로젝트 동안 해야할 일의 목록을 나열한 것
스프린트 백로그(sprint backlog): 한 스프린트(한번의 반복 주기) 동안에 현실적으로 개발 가능하다고 생각한 양만큼 제품 백로그에서 선택한 목록을 나열한 것
스크럼 팀(scrum team): 스크럼을 실제로 실천하며 제품을 개발하는 개발 팀, 스프린트 동안 스크럼 팀은 외부의 간섭을 받아서는 안 된다.
스크럼 마스터(scrum master): 스크럼 기법이 잘 실천되도록 팀을 관리하는 스크럼 팀의 관리자
제품 책임자(product owner): 제품 백로그 항목에 우선순위를 부여할 권한이 있는 제품의 총 책임자
스프린트(sprint): 30일의 반복주기
일일 스크럼 회의(daily scrum meeting): 매일 15분간 회의 진행(오직 팀원만 발언 가능, 1. 지난 일일 스크럼 회의 이후로 무엇을 했는가, 2. 다음 일일 스크럼 전까지 무엇을 할 계획인가, 3. 작업의 방해요소는 무엇인가에 관해)
스프린트 검토 회의(sprint review meeting): 제품 책임자와 함께 모여 한 스프린트 동안 개발한 제품 결과물에 대해 검토