개발프로젝의 68퍼센트는 주어진 기간내에 기능미달 혹은 불량, 비용초과, 개발중도 포기 등으로 실패 한다고 한다. 그리고 실재로 개발의뢰자도 개발 중간에 프로젝트 수정을 요구하는 등 실재 개발 프로젝트에서는 다양한 변수가 존재한다.
이러한 소프트웨어 개발 프로젝트의 비효율성의 발생원인은 일반 제조업회사들의 프로젝트 운영방식을 개발프로젝트에 그대로 적용해서일 가능성이 크다.
Scrum의 전제
여기서 등장한 방식이 스크럼방식이다. 스크럼방식은 우선 개발과정에서 나오는 불확실성을 부정하지않고 피할 수 없다고 가정하고 여기서 나오는 피해를 최소화하는 것이 목표이다. 사람이 3달의 일정을 정확하게 예측하고 계획하는 것이 불가능하다는 것을 인정한다.
Scrum process
스크럼방식은 단기적 계획인 sprint를 여러번짠다.
- 팀 전체가 한 스프린트동안 할 계획을 세운다.(백로그 설정)
- 각자 주어진 테스크를 진행한다
- 매일 stand-up미팅을 통해서 팀원끼리 진행상황을 공유한다. 여기서 공유할 내용은 '내가 했던 일', '내가 오늘 할 일', '다른 멤버가 처리해주지 않으면 못하는 일(blocker)', 3가지 내용이며 3가지내용을 제외한 다른 길어질 이야기는 stand-up미팅이 끝난 후에 하도록한다.
(stand-up미팅인 이유는 앉아서 해서 길어질 이야기를 일어서서 함으로서 필요한이야기만 하도록 함이다.)- 이런 스프린트를 주기가 끝날 때 마다 반복한다.
초기에 백로그를 설정하고 스프린트 중간에 백로그 수정요청이 생기면 수정사항을 테스크로 만들어 백로그에 업데이트한다. 이 과정을 프로젝트가 끝날 때 까지 반복한다.
Scrum의 장점
-
현실적인 계획이 가능하다. 처음에 했던 한달, 두달단위의 계획은 진행도중에 바뀌거나 예상치못할 상황을 만나게 될 확률이 높지만 짧은단위의 스프린트는 비교적 쉽게 상황을 예측 할 수 있다.
-
피드백을 금방 반영할 수 있다. 스프린트도중 매일 스탠드업미팅을 가져 내부에서 백로그변경이 언제든지 가능하며, 외부에서의 요청도 쉽게 백로그로 반영 될 수 있다.
-
프로젝트 진행상황을 파악하기 쉽다. 즉, 문제를 쉽게 파악할 수 있다. 장기계획으로 지행되었다면 이미 많은 시간이 지난 상태에서 인식될 문제를 스프린트단위로 한다면 바로 파악이가능하다.
예를들어 A맴버가 한달계획을 잡고 하나의 기능을 만들고 있는데 잘못된 방향으로의 작업으로 인해 두달, 세달이 필요한 상황이 되었다고 가정하자. 프로젝트 진행자 입장에서는 A의 계획을 믿고 기다렸지만 A의 실재 진행상황은 계획에서 30%를 못미치는결과를 가져왔다. 여기서 방법을 바꿔 접근하기엔 이미 한달의 시간과 비용이 투자 된 상태이다.
Scrum방식이었다면 짧은 스프린트안에서 여러번의 피드백을 거쳐 해결되었을 상황이다.
앞으로 4주간 스크럼 방식으로 2가지 프로젝트를 진행하게 되며, 과정에서의 효율성을 체험해보자
