타임박싱의 원칙
타임박싱(Timeboxing)이란 반복형 개발에서 쓰이는 프로젝트 기획/관리 기법으로, 이터레이션에 할당된 작업을 완수하지 못하였을 경우 다음 이테레이션으로 넘긴다는 지극히 단순하고 간단한 일종의 규칙(discipline)이다. 타임박싱의 내용을 구체적으로 명시하자면 다음과 같다.- 반복형(Iteration) 개발 방식으로 프로젝트를 진행한다.
- 작업내용을 잘게 나누고 각각의 작업에 소요될 시간을 추정한다. 작업소요시간 추정의 대표적인 기법으로는 플래닝 포커가 있다.
- 이렇게 추정된 작업들은 팀원들의 타임라인에 중요도와 상호 의존관계를 고려하여 적절하게 배치한다.
- 상자를 쪼갤 수 없듯이 개별적인 작업들은 각각의 이터레이션 안에 완전히 들어갈 수 있도록 배치하여야 한다. 조금이라도 넘어간다면 다음 이터레이션으로 넘겨야 하는데 왜 그런지는 뒤에서 자세히 설명하겠다.
시간과 비용, 그리고 품질을 위해 작업범위를 희생하라
프로젝트 매니지먼트 협회에서 발간하는 PMBOK(A Guide to the Management Body of Knowledge)에 따르면 프로젝트는 작업범위(Scope), 시간(Time), 비용(Cost) 그리고 품질(Quality)의 네가지 요소를 지닌다. 이 네가지 요소들은 상호 연관성을 지니며 프로젝트의 내용에 따라 우선순위가 달라진다.
타임박싱은 이 네가지 요소중에 우선순위가 낮은 작업범위에 대해 유동성을 줌으로서 나머지 세가지 요소를 지켜내는것을 선택한다. 타임박싱을 사용하지 않는 프로젝트 매니지먼트의 경우에는 작업이 완료되지 않으면 이터레이션이 종료되지 않으므로 나머지 세가지 요소인 시간, 비용, 품질에 변경이 오게 되는데 일반적으로 이 세가지 요소는 동시에 나빠지는 경향이 있다.
즉, 납기를 맞추자면 동일한 시간에 더 많은 일을 해야 하고 이는 개발인원의 증가로 이어져 예산증가로 이어진다. 만약 예산을 맞추자면 이번에는 개발자 부족으로 인한 품질이 문제가 되게 되어 납기가 연장되는 악순환이 반복되게 되는데, 이러한 악순환은 원인에 대한 인식이 잘못된 경우가 많기 때문에 끊어내기가 대단히 어려울 뿐더러 한가지를 막아낸다 해도 나머지 두 요소에 치명적인 손실을 가져오는 경우가 많다.
작업범위의 우선순위가 낮은이유
바로위의 문단에서 작업범위의 우선순위가 낮다고 하였는데 이에대해 조금더 설명해 보겠다.
작업범위에 포함되는 내용은 크게 납품물로 지칭되는 프로젝트 작업범위(Project Scope)와 기능으로 지칭되는 제품 작업범위(Product Scope)를 들 수 있겠다. 이들은 각각 많은 세부 항목들을 지니게 되는데 이들에 대하여 우선순위를 정하고 고객의 승인을 받는 작업을 통해 작업범위의 축소/이관이 가능해진다.
이러한 작업범위 내의 작업들에 대한 우선순위는 프로젝트 진행상황에 따라서 수시로 바뀌는 경향이 있으므로 프로젝트 매니저는 이러한 우선순위 변동에 대하여 지속적으로 체크해 나가고 이를 이터레이션 계획에 반영시켜 나가는 노력 만으로도 나머지 세가지 요소인 시간,비용,품질을 지켜 낼 수 있게 된다.
절대로 박스를 자르거나 찌그러트리지 말라!
타임박싱의 긍정적인 효과중 큰 부분은 반복형 개발의 리듬을 지킬 수 있게 해 준다는 점 이다. 반복형 개발은 몰입과 휴식의 반복이 가장 핵심적인 개념이다. 이터레이션 종료후의 휴식시간은 그냥 토일 쉬게 해주는 것 과는 다른다. 하나의 작업이 완료되고 정신적으로 몰입했던 일에서 완전히 빠져나와 개인적인 시간을 가질 수 있게 해 준다는 의미이다. 맨탈은 공짜가 아니다. 몰입은 심하게 맨탈 에너지를 소모하는 작업인만큼 휴식시간의 양과 질이 보장되지 않으면 다음 이터레이션에 사용될 맨탈의 양 당연히 줄어들게 된다.보통 계획단계에서는 대부분 팀원의 타임라인이 이쁘게 채워질 것이다. 만약 기획단계에서 채위지지 않는 자투리 칸이 발생한다면 그것은 그것대로 놔 두는것이 중요하다.
작업이 진행됨에 따라 숨겨져 있던 요소들이 들어나고 각각의 작업들이 늘어나게 되는것은 개발 현장에서 흔히 볼 수 있는 풍경이다. 이때, 이터레이션에 들어가지 못하게된 작업은 다음 이터레이션으로 넘겨야 한다. 무리하게 이터레이션 안에서 소화하려고 하다 보면 결국 품질이 희생되게 될 학률이 높다. 끝나지 않은 상태로 두개의 이터레이션에 걸쳐 넘기는것도 좋지 않다. 작업의 품질과 이터레이션 이후 휴식에 문제가 되기 때문이다. 과감하게 다음 이터레이션으로 덤기도록 하자.
 |
| 남은 시간에 들어가지지 않는 작업은 다음 이터레이션으로 넘겨야 한다. |
빈 공간은 창의성과 기술적 부채의 해결을 위한 시간이다
이렇게 생긴 자투리공간들은 테스트코드작성, 리팩토링, 문서화와 같이 개발자가 그동안 미뤄 왔던 기술적 부채의 상환에 사용할 수 있도록 한다. 생산성 향상을 위한 새로운 툴의 도입을 검토해 보는것도 좋을것이다. Jira나 Redmine과 같은 티켓 기반 관리툴을 사용할경우 작업자가 스스로 티켓을 끊고 자신의 타임라인에 붙여 넣기만 하면 된다.작업범위 변경에 대한 힌트
작업범위는 고객과의 약속이므로 변경 불가능하다는 고정관념을 가지고 있는 PM들이 많지만 이는 사실과 다르다. 고객이 원하는것은 제대로 작동하는 소프트웨어이지 부차적인 절차나 산출물이 아니기 때문이다. 프로젝트 제안서에 적힌 프로젝트 목표에 비추어 나열된 기능들과 산출물들이 어떠한 의미를 지니는지 되새겨 보자.
 |
| 고객의 요구는 의외로 단순한 경우가 많다. 갑과 을의 관계에만 얽메여서 생각하지 말고 고객의 입장에서 프로젝트를 바라보고 우선순위를 다시 살펴봄으로서 윈윈할 수 있는 타협점을 찾아야 한다. |
작업범위 변경에 대해서 고려해야 하는경우(우선순위 재 배치) 다음과 같은 항목들이 우선적인 고려의 대상이 될 수 있을것이다.
쓸데없는 납품물: 작동하는 소프트웨어와 별개의 부분들. 특히 문서화 작업에 대해 다시한번 생각해 보자. 이미 작업과 상관없게 되어 버린 상세 설계서를 유지해 나가는것은 고객에게 있어서 아무런 도움이 되질 않는다. 무거운 문서화를 피하는 방법에 대해서는 문서화에 대한 이전 포스팅이 도움이 될 것이다.
혹시나 기능: 미래에 이러이러한 일이 있을지도 몰라 추가로 만들어 놓는 기능들이 있다. 이러한 기능들은 프로젝트 중간에 고객과의 재 검토를 갖는것 만으로도 필요 없는것으로 판명되는경우가 많다.
기술적 부채: 기술적 부채도 이관이 가능한 작업범위중 하나이다. 기술적 부채에 대한 자세한 사항은 기술적 부채에 대처하는 자세를 참고해 보기 바란다.
요구사항을 동결시키는 효과
물위를 걷는 것은 쉽다. 만약 물이 얼어 있다고 한다면 말이다.
위의 문구는 인터넷에 떠도는 사양 변경에 대한 어려움을 물위를 걷는것에 비유한 글 이다.
많은 개발자들이 고객의 요구사항 대응이 어렵다고 말을 한다.
하지만 열심히 해서 그러한 대응에 모두 대응 할 수 있는가? 현실적으로 불가능한 경우가 대부분일 것이다. 납기를 지키면 품질에 문제가 생기고 품질을 지키면 납기를 지연 시킬 수 밖에 없다. 이것은 명백한 사실이다.
이것저것 변경을 요구해 오는 고객에 대해서 "예. 알겠습니다. 어떻게든 열심히 해서 일정을 맞춰 보겠습니다" 라고 말 해 놓고 정작 프로젝트 말미에 가서 "열심히 했지만 납기를 지킬 수 없습니다. 정말 죄송합니다."라고 말 하면 좋아할 고객이 있을까?
"이번 프로젝트(또는 이터레이션)에서는 현재 가능한 최선의 일정으로 일 하고 있습니다. 만약 이러한 변경을 이번에 반영하고 싶다면 동등한 비용이 발생하는 다른 기능을 다음 개발로 넘기셔야 합니다" 라고 알리고 현실적인 대응 반안을 제시하는 것이 훨씬 나은 방법일 것이다.
물론 이러한 대화가 이루어지려면 현실적인 스케줄에 대한 추정이 있어야 하며 작업 범위에 대한 정확한 산출과 프로젝트 현황에 대한 파악이 있어야 할 것이고 이것은 어디까지나 고객과의 신뢰관계가 쌓여 있을 경우에만 가능하다는 사실이다. 수치를 제시하지 못하는 설명은 설득력을 지니지 못한다는 사실을 명심하라.
이것저것 변경을 요구해 오는 고객에 대해서 "예. 알겠습니다. 어떻게든 열심히 해서 일정을 맞춰 보겠습니다" 라고 말 해 놓고 정작 프로젝트 말미에 가서 "열심히 했지만 납기를 지킬 수 없습니다. 정말 죄송합니다."라고 말 하면 좋아할 고객이 있을까?
"이번 프로젝트(또는 이터레이션)에서는 현재 가능한 최선의 일정으로 일 하고 있습니다. 만약 이러한 변경을 이번에 반영하고 싶다면 동등한 비용이 발생하는 다른 기능을 다음 개발로 넘기셔야 합니다" 라고 알리고 현실적인 대응 반안을 제시하는 것이 훨씬 나은 방법일 것이다.
물론 이러한 대화가 이루어지려면 현실적인 스케줄에 대한 추정이 있어야 하며 작업 범위에 대한 정확한 산출과 프로젝트 현황에 대한 파악이 있어야 할 것이고 이것은 어디까지나 고객과의 신뢰관계가 쌓여 있을 경우에만 가능하다는 사실이다. 수치를 제시하지 못하는 설명은 설득력을 지니지 못한다는 사실을 명심하라.
타임박싱을 이용하지 않을 이유가 하나도 없다!
반복형 개발을 기반으로 하는 스크럼이나 간반과 같은 애자일 개발은 물론이고 전통적인 폭포수형 개발에 있어서도 타임박싱은 매우 유용하다. 폭포수형 프로젝트에서도 그 나름의 시간 구획이 존재하기 때문이다.
타임박싱은 성공한 많은 프로젝트 들에서 채택되어 그 효용성을 입증 받았으며 DSDM(Dynamic systems development method), RAD(Rapid application development software development), Scrum, Extreme programming과 같은 프로젝트 관리 방법론에서 기본적으로 채택되고 있다. 사실상 SI에 에자일방법론을 적용 시킬 때 필수적인 기법이라 할 수 있겠다.
Trac이나 Redmine과 같은 이슈추적 시스템을 사용해 프로젝트 관리를 하고 있다면 티켓(테스크)의 타겟버전을 변경하는 것 만으로도 손쉽게 작업을 다음 이터레이션으로 이관하는것이 가능해진다.
타임박싱은 성공한 많은 프로젝트 들에서 채택되어 그 효용성을 입증 받았으며 DSDM(Dynamic systems development method), RAD(Rapid application development software development), Scrum, Extreme programming과 같은 프로젝트 관리 방법론에서 기본적으로 채택되고 있다. 사실상 SI에 에자일방법론을 적용 시킬 때 필수적인 기법이라 할 수 있겠다.
Trac이나 Redmine과 같은 이슈추적 시스템을 사용해 프로젝트 관리를 하고 있다면 티켓(테스크)의 타겟버전을 변경하는 것 만으로도 손쉽게 작업을 다음 이터레이션으로 이관하는것이 가능해진다.
좋은 글 감사합니다.
답글삭제