Agile 열풍이 휘몰아 치던 시절에 조금 들어 본 스크럼을 우리가 일하는 방법 가운데에 놓았다.
3명이지만 프로세스는 필요하다고 판단했다. CMM Level 5를 준수하는 프로세스는 우리가 지구에서 가장 큰 소프트웨어 회사가 되면(구글과 MS와 애플을 합친 정도) 당연히 사용할 생각이다.(물론 관심없다의 다른 표현이다)
소프트웨어 개발 뿐만 아니라 일반적인 일하는 방식을 잡아줄 필요성에 많은 Agile 방법론 중에서 스크럼을 선택했다. 실제로 회사 설립과 관련한 일들도 백로그로 관리하고 스프린트 태스크로 설정하여 처리했다. 심지어는 마우스와 원두 커피 구매까지...
스크럼을 파악하려고 여러 글들을 읽었는데 그 중 아래 글들이 도움이 되었다.
* 책은 읽지 못했고, 다른 글들은 조금 오래되었거나.. 별로 감흥이 없었다.
첫번째 글은 철학(철학은 시류를 타지 않고 오래간다)을 다루고 두번째 글은 초보자를 위한 스크럼 안내서 같은 역할을 한다.
그리고 도구를 찾았다. 포스트잇을 사용하는 건 조금 어색하고 부끄럽다.
처음에 구글 Doc 스프레드쉬트를 사용했다. Burndown 차트 표현도 가능했고 탭으로 스프린트를 나누어 관리할 수도 있어서 나쁘진 않았다.(엑셀을 생각하면 된다) 그러나 백로그를 체계적으로 관리하기가 쉽지 않았다.
구글 Doc으로는 백로그를 User Story 혹은 Use Case로 기술하기가 쉽지 않다.
스프린트 2까지는 구글 Doc을 사용하다 스프린트 3 중간에 Rally로 전환했는데(이 역시 미리 정해놓은 태스크였다) 스프린트 3 종료와 함께 다시 구글 Doc으로 돌아갔다.
선무당이 Rally를 잡은 격이나... Rally 좋지 않다.
다음은 스프린트 1 Burndown 차트이다.
2주 혹은 4주가 아닌 업무일 기준으로 10일을 스프린트 기간으로 잡았다. 하루 실제 업무 가능한 시간을 5시간으로 정했으니 3명이 한 스프린트에서 사용할 수 있는 시간은 150 시간이다. 하지만 아직 완전한 셋업이 되지 않아 100시간 조금 넘는 규모로 스프린트 태스크를 구성했다.
지금까지 적용 과정에서 얻은 스크럼에 대한 생각은 긍정적이다.
- 길을 잃지 않게 해준다.
- 프로세스 자체에 소요되는 시간이 부담이 되지 않는다.(구글 Doc과 Rally를 왔다 갔다 하면서 낭비한 시간을 제외하면)
반면 좀 어렵게 다가오는 점은 백로그에 대한 관리이다. Uncle Bob 지적처럼...
- 어떻게 백로그를 체계적(계층적)으로 관리할 수 있을까?
- 백로그와 스프린트 태스크 간의 상관 관계는?
- 특정 스프린트에서 완료하지 못한 태스크를 어떻게 처리해야 하는가?
(저렴하면서) 구미에 맞는 도구가 없다는 것이 아쉽다. 시간이 나면 스크럼 도구도 고민해봐야겠다.
