2014년 1월 26일 일요일

프로젝트 관리 기법 - 타임박싱(Timeboxing) 관리 기법

 이번 포스팅에서는 지난번 포스팅했던 서적소개 - 실전 반복형 개발에서 잠깐 언급하였던 타임박싱에대해서 설명해 보고자 한다.

 타임박싱(Timeboxing)이란 반복형 개발에서 쓰이는 프로젝트 기획/관리 기법으로,  이터레이션에 할당된 작업을 완수하지 못하였을 경우 다음 이테레이션으로 넘긴다는 지극히 단순하고 간단한 일종의 규칙(discipline)이다.

프로젝트의 4요소

 프로젝트 매니지먼트 협회에서 발간하는 PMBOK(A Guide to the Management Body of Knowledge)에 따르면 프로젝트는 작업범위(Scope), 시간(Time), 비용(Cost) 그리고 품질(Quality)의 네가지 요소를 지닌다.  이 네가지 요소들은 상호 연관성을 지니며 프로젝트의 내용에 따라 우선순위가 달라진다.

 타임박싱은 이 네가지 요소중에 우선순위가 낮은 작업범위에 대해 유동성을 줌으로서 나머지 세가지 요소를 지켜내는것을 선택한다. 타임박싱을 사용하지 않는 프로젝트 매니지먼트의 경우에는 작업이 완료되지 않으면 이터레이션이 종료되지 않으므로 나머지 세가지 요소인 시간, 비용, 품질에 변경이 오게 되는데 일반적으로 이 세가지 요소는 동시에 나빠지는 경향이 있다. 

 즉, 납기를 맞추자면 동일한 시간에 더 많은 일을 해야 하고 이는 개발인원의 증가로 이어져 예산증가로 이어진다. 만약 예산을 맞추자면 이번에는 개발자 부족으로 인한 품질이 문제가 되게 되어 납기가 연장되는 악순환이 반복되게 되는데, 이러한 악순환은 원인에 대한 인식이 잘못된 경우가 많기 때문에 끊어내기가 대단히 어려울 뿐더러 한가지를 막아낸다 해도 나머지 두 요소에 치명적인 손실을 가져오는 경우가 많다.

작업범위의 우선순위가 낮은이유

 바로위의 문단에서 작업범위의 우선순위가 낮다고 하였는데 이에대해 조금더 설명해 보겠다.
 작업범위에 포함되는 내용은 크게 납품물로 지칭되는 프로젝트 작업범위(Project Scope)와 기능으로 지칭되는 제품 작업범위(Product Scope)를 들 수 있겠다. 이들은 각각 많은 세부 항목들을 지니게 되는데 이들에 대하여 우선순위를 정하고 고객의 승인을 받는 작업을 통해 작업범위의 축소/이관이 가능해진다.

 이러한 작업범위 내의 작업들에 대한 우선순위는 프로젝트 진행상황에 따라서 수시로 바뀌는 경향이 있으므로 프로젝트 매니저는 이러한 우선순위 변동에 대하여 지속적으로 체크해 나가고 이를 이터레이션 계획에 반영시켜 나가는 노력 만으로도 나머지 세가지 요소인 시간,비용,품질을 지켜 낼 수 있게 된다.

작업범위 변경에 대한 힌트

 작업범위는 고객과의 약속이므로 변경 불가능하다는 고정관념을 가지고 있는 PM들이 많지만 이는 사실과 다르다. 고객이 원하는것은 제대로 작동하는 소프트웨어이지 부차적인 절차나 산출물이 아니기 때문이다. 프로젝트 제안서에 적힌 프로젝트 목표에 비추어 나열된 기능들과 산출물들이 어떠한 의미를 지니는지 되새겨 보자.

고객의 요구는 의외로 단순한 경우가 많다. 갑과 을의 관계에만 얽메여서 생각하지 말고 고객의 입장에서 프로젝트를 바라보고 우선순위를 다시 살펴봄으로서 윈윈할 수 있는 타협점을 찾아야 한다.



 작업범위 변경에 대해서 고려해야 하는경우(우선순위 재 배치) 다음과 같은 항목들이 우선적인 고려의 대상이 될 수 있을것이다.

 쓸데없는 납품물: 작동하는 소프트웨어와 별개의 부분들. 특히 문서화 작업에 대해 다시한번 생각해 보자. 이미 작업과 상관없게 되어 버린 상세설계서를 유지해 나가는것은 고객에게 있어서 아무런 도움이 되질 않는다. 무거운 문서화를 피하는 방법에 대해서는 문서화에 대한 이전 포스팅이 도움이 될 것이다.

 혹시나 기능: 미래에 이러이러한 일이 있을지도 몰라 추가로 만들어 놓는 기능들이 있다. 이러한 기능들은 프로젝트 중간에 고객과의 재 검토를 갖는것 만으로도 필요 없는것으로 판명되는경우가 많다.

 기술적 부채: 기술적 부채도 이관이 가능한 작업범위중 하나이다. 기술적 부채에 대한 자세한 사항은  기술적 부채에 대처하는 자세를 참고해 보기 바란다.


요구사항을 동결시키는 효과




물위를 걷는 것은 쉽다. 만약 물이 얼어 있다고 한다면 말이다.

 위의 문구는 인터넷에 떠도는 사양 변경에 대한 어려움을 물위를 걷는것에 비유한 글 이다.
 많은 개발자들이 고객의 요구사항 대응이 어렵다고 말을 한다.
하지만 열심히 해서 그러한 대응에 모두 대응 할 수 있는가? 현실적으로 불가능한 경우가 대부분일 것이다. 납기를 지키면 품질에 문제가 생기고 품질을 지키면 납기를 지연 시킬 수 밖에 없다. 이것은 명백한 사실이다.

 이것저것 변경을 요구해 오는 고객에 대해서 "예. 알겠습니다. 어떻게든 열심히 해서 다 구현해 보이겠습니다" 라고 말 해 놓고 정작 프로젝트 말미에 가서 "열심히 했지만 납기를 지킬 수 없습니다. 정말 죄송합니다."라고 말 하면 좋아할 고객이 있을까?

 "이번 프로젝트(또는 이터레이션)에서는 현재 가능한 최선의 일정으로 일 하고 있습니다. 만약 이러한 변경을 이번에 반영하고 싶다면 동등한 기능을 다음 개발로 넘기셔야 합니다" 라고 알리고 현실적인 대응 반안을 제시하는 것이 훨씬 나은 방법일 것이다.

 물론 이러한 대화가 이루어지려면 현실적인 스케줄에 대한 추정이 있어야 하며 작업 범위에 대한 정확한 산출과 프로젝트 현황에 대한 파악이 있어야 할 것이다. 수치를 제시하지 못하는 설명은 설득력을 지니지 못한다는 사실을 명심하라.

타임박싱을 이용하지 않을 이유가 하나도 없다!

반복형 개발을 기반으로 하는 스크럼이나 간반과 같은 애자일 개발은 물론이고 전통적인 폭포수형 개발에 있어서도 타임박싱은 매우 유용하다.  폭포수형 프로젝트에서도 그 나름의 시간 구획이 존재하기 때문이다.

타임박싱은 성공한 많은 프로젝트 들에서 채택되어 그 효용성을 입증 받았으며 DSDM(Dynamic systems development method), RAD(Rapid application development software development), Scrum, Extreme programming과 같은 프로젝트 관리 방법론에서 기본적으로 채택되고 있다. 사실상 SI에 에자일방법론을 적용 시킬 때 필수적인 기법이라 할 수 있겠다.

Trac이나 Redmine과 같은 이슈추적 시스템을 사용해 프로젝트 관리를 하고 있다면 티켓(테스크)의 타겟버전을 변경하는 것 만으로도 손쉽게 작업을 다음 이터레이션으로 이관하는것이 가능해진다.