[북리뷰] 스크럼

 

보통 소프트웨어 개발 프로젝트를 진행하다보면, 변화무쌍한 사용자의 요구사항과 프로젝트 진행 중에 느닷없이 투척되는 추가 요구사항으로 인해 골머리 앓기가 다반사다. 어느 경우에는 개발자와 친하다고 PM 몰래 슬쩍 와서 요건을 추가해 놓고 가는 경우도 있다. 제한된 기간안에 개발을 완료해야 하는 입장에서 보면 리스크가 늘어나는 것이다.

 

공학적 접근법의 핵심은 단연 설계와 시공의 분리인데, 소프트웨어 개발 세계에서는 요원해 보인다. 그래서 무심코 던진 돌에 개구리 맞아 죽는다고, 추가된 요건으로 인해 설계가 변경되고, 개발되었던 것이 모조리 수정되어야 하는 지각변동도 발생할 수 있다. 하지만, 이런 경우라면 처음부터 설계를 의심해봐야 하겠다.

 

 

 

출처 : http://pragmaticstory.com 

 

이런 국내 개발 환경에서 애자일 방법론으로, 스크럼이라는 것이 소개됐다. 제품 백로그라는 것을 통해 각종 요건사항들을 우선순위별로 관리하고, 한 달 기간 제품에 반영할 부분을 미리 영역을 지정하여 그 단위를 스프린트라고 명명한다. 이 스프린트 백로그를 완성하기 위해 전담팀을 구성하는데, 스크럼이라고 부른다. 이 팀에는 스크럼 마스터가 존재하고, 스크럼의 규칙선언과 대담한 결정 권한이 위임된다고 보면된다. 매일 스크럼회의를 하게되는데, 15분정도 소요되는 간단한 회의임에도 할일,한일,문제점 등을 나누게한다. 외부의 모든 요건에 대한 사항은 스크럼 마스터와 상의해야 하며, 스크럼 팀 내의 개발환경은 철저히 보호되도록 한다. 즉, 스크럼팀은 스프린트 백로그를 철저히 완수하기 위해 몰입하는 환경이 구성된 셈이다. 스프린트가 진행중일 때 추가되는 요건은 스크럼 마스터와 제품 관리자와 상의하고 우선순위를 고려하여 다음 스프린트에 추가할지를 결정하면 된다.

 

그렇다면 왜 이름이 스크럼일까? 그것은 미식축구에서 선수들이 스크럼을 짠 모습에서 착안했다고 하는데, 스크럼 내부의 긴밀한 개발환경이 방해받지 않도록 함에 있는 것 같다.

 

다음은 이런 스크럼의 탄생배경을 설명한다.

"스크럼은 시스템 개발 프로젝트에서 똑같은 작업이란 거의 없고, 똑같은 결과를 만들어 내는 경우도 거의 없다는 믿음에서 시작한다. 스크럼은 모든 프로젝트가 예상하기 힘든 것이라고 생각한다.
작업을 미리 정의하거나 반복하기 너무 복잡한 경우에는 경험주의적인 프로세스 제어 모델이 필요하다. 스크럼은 경험주의적인 프로세스 제어 모델을 채택한다. 스크럼은 주기적으로 어떤일이 벌어지고 있는지를 관찰하고 원하는 결과를 도출하기 위해 경험에 기반을 두어 작업을 조정한다." (146)

 

고객에게 스크럼을 이해시키고, 업무협의만 잘 한다면, 매우 성과지향적이고 성공적인 프로젝트를 이루어낼거라는 생각을 해본다. 아울러 스크럼의 가치인 집중, 개방성, 존중과 용기를 되집어 보는데, 역시나 내 마음에 드는 가치는 "집중"인 듯 싶다.

"할 일을 하라. 모든 노력과 기술은 맡은 일을 해내는 데 다 집중하고, 그 외의 것들에 대해서는 걱정하지 마라" (220)