플래닝 포커를 이용한 프로젝트 일정 산정

플래닝 포커를 이용한 프로젝트 일정 산정

조대협 (http://bcho.tistory.com)

프로젝트 진행을 하거나, 애자일 방법론 기반으로 스프린트 기반의 프로젝트를 진행할때도 항상 문제가 되는 것이, 일정 산정이다. 먼저 정확한 일정 산정이 어려울 뿐더러, 프로젝트를 진행하는 외부의 인원이 보기에 일정 산정의 근거가 약해서 “왜 저일이 왜 그렇게 오래 걸려요?” 라는 등의 비난을 받을 수 가 있다.

그래서 정확한 일정 산정 프로젝트 일정 관리와 함께, 팀의 일정 산정에 대한 정당성을 확보하는 것 두 가지의 목적을 가지고 있다. 

그러나 이러한 일정 산정은 불확실한 미래를 예측하는 작업이기 때문에 매우 어려운데, 이러한 일정 산정의 좋은 기법의 하나로 “플래닝포커(Planning Poker)”라는 기법을 소개하고자 한다.

플래닝 포커는 애자일 기법으로 대략적인 방식은 다음과 같다.

먼저 다음과 같은 역할이 필요하다.

• 기획자(Product Owner) : 요구 사항을 정의하는 사람
• 진행자 : 플래닝 포커를 진행하는 사람
• 참석자 : 실제 개발을 진행하는 사람

그리고, 그 스프린트에서 개발을 진행할 요구 사항 목록이 필요하다.  (User story backlog)

준비가 되었으면 다음과 같은 순서로 진행한다.

기획자가 먼저 사용자 스토리를 전체적으로 쭈욱 훝어가면서 설명한다. 이를 통해서 참석자들이 무엇을 개발할것인지 사용자 관점에서 이해를 하게 된다. (전체 그림을 이해하는 단계.) 이때 가급적이면 사용자 스토리는 사용자가  사용하는 시간순으로 나열되는게 좋다.

예를 들어 다음과 같은 스토리가 있다고 하자

• 글쓰기
• 글목록보기
• 로그인

사용자 시나리오 순서는 사용자가 로그인 한후, 글 목록을 본후에, 새로운 글을 글쓰기로 올린다. 라고 했을때 위의 백로그는 시간 순서에 맞지 않는다.

그래서 백로그를 정리하면 다음과 같이 정리가 되는게 좋다. 

• 로그인
• 글 목록 보기
• 글쓰기

(참고. 이렇게 시간 순서대로 사용자 스토리를 배치하는 기법을 사용자 스토리 맵핑이라고 한다.)

전체 컨택스트(문맥)을 이해했으면 각각의 스토리에 대해서 걸리는 시간을 Estimation (산정)한다.

하나의 스토리를 올리고, 기획자가 기능에 대해서 다시 설명을 한다. 참석자는 기능에 대해서 궁금한점이 있으면 기획자에게 물어보고 설명을 듣는다. 어느정도 기능이 이해가 되면 그 스토리에 대해서 참석자들이 구현에 걸릴 시간을 투표한다. 기간은 디자인, 구현 과 “테스트”를 포함한 시간을 예측해서 투표한다.

이 기간은 전체 구현기간이다. 예를 들어 “로그인”이라는 기능을 앱에 구현할 경우, 앱 개발 기간, 뒷단의 API 서버 백앤드 개발 기간을 예측 산정해야 한다. 참석자가 당연히 풀스택은 아니겠지만 그간의 경험을 기반으로 예측 산정을 한다. (정확하지 않을거 같은데.. 직접 해보면 생각보다 정확도가 높다.)

예측치를 상대방에게 보이지 않고 포커에서 카드를 뒤집듯이 한꺼번에 뒤집기 때문에, 플래닝 포커라고 이야기 하고, 이렇게 함으로써 상대방의 예측에 관여하지 않고 각 참석자의 의견을 객관적으로 들을 수 있다.

요즘은 시스템이 발전해서 이러한 플래닝포커를 실제 카드로 하지 않고 웹/앱의 온라인 시스템을 사용할 수 있다.

 

<그림. http://www.planitpoker.com/ >

본인의 경우http://www.planitpoker.com/을 이용해서 실제 플래닝 포커를 수행했는데, 사용하기가 그다지 어렵지 않다. 

단, 여러개의 스토리를 손으로 일일이 입력해야 하고(액셀 업로드가 있었으면 좋았을듯..) 반대로 끝나고 나서 결과를 액셀로 다운로드가 불가하다. (수기로 적었다.)

(혹시나 더 좋은 툴을 발견하면 알려주시기를..)

투표가 끝났으면 제일 낮은 점수와 제일 높은 점수의 사람으로 부터 그렇게 점수를 준 이유를 설명을 듣는다.

낮은 점수를 준 사람은 몬가 빠른 해결책을 가지고 있을 수 있고, 반대로 높은 점수를 준 사람은 다른 사람이 놓치고 있는 것을 알고 있을 가능성이 많다. 충분히 의견을 듣고, 같은 스토리에 대해서 투표를 재 진행한다.

주의할점은 투표를 하기전에 얼마의 일정이 걸릴지를 다른 사람에게 절대 이야기 하지 않는다. (아이고 이장님~~~!! 이 뜻을 아시는분은 있을듯..). 그러면 그쪽으로 의견이 쏠리기 때문에 객관적인 일정 산정이 어렵다.

이 과정이 중요한것이, 일정 산정시 내가 놓치고 있는 부분에 대한 의견 교환이 가능하다는 것이다.

재 투표는 대략적으로 포인트가 비슷한 포인트로 수렴할때 까지 계속해서 반복한다. (8번까지도 해봤다는..)

여기에 몇가지 팁이 있는데, 스토리가 복잡할 경우, 먼저 스토리를 구현하기 위한 대략적인 아키텍쳐를 설계 해보는 것이 좋다. (종이에… 본인의 경우에는 3M 에서 나오는 테이프가 달린 4절지를 애용하는데..) 이 과정에서 전체 팀원이 대략적인 아키텍쳐에 대한 협의가 이루어지고 같은 컨택스트에 들어오는 효과가 있다.

아래 그림의 뒤의 벽에 붙어 있는 사진이 각 스토리를 구현하기 위한 아키텍쳐 흐름이다.

이렇게 모든 과정이 끝나면, 전체 스토리 포인트를 합산하여 걸리는 시간을 예측한다. 본인의 경우 1포인트를 “한사람이 하루에 할 수 있는 양”으로 정하는데, 60포인트가 산정이되고 팀원이 4명이라면 총 15포인트. 워킹데이로 3주가 소요되고, 스토리가 빠질 수 있는 가능성이나 버퍼를 감안해서 20~30% (야근을 피하고 싶다면 50%)를 곱해서 전체 기간으로 산정한다. 

20개 내외의 스토리에 대한 일정 산정은 전체 스토리 설명 (1시간) 투표 (1~1.5시간) 정도가 소요된다.

몇가지  경험을 공유하면

내가 구현하지 않는 부분에 대해서 상대방에게 가혹하게 짧은 일정을 줄 수 있다.

수평적인 커뮤니케이션이 가능해야 한다. 아니면 주니어 엔지니어가 시니어 엔지니어 의견에 밀려서 객관적인 산정이 깨질 수 있다.

그리고 생각보다 잼있다. 

:)