Rational Team Concert 2.0 에서의 진척도 막대(Progress Bar)와 부하량 막대(Load Bar), 그리고 작업 예측의 중요성
By Agile Planning Component Team
Last modified June 25, 2009
Build basis: Rational Team Concert 2.0
Last modified June 25, 2009
Build basis: Rational Team Concert 2.0
애자일 플래닝 기능은 우리가 개발 주기를 계획하고 수행하는 것을 보조해주는데, 그 핵심은 바로 진척도(Progress)와 부하량(Load) 막대이다. 이 글에서는 부하량과 진척도를 참조해 개발하는 것의 잇점과 둘 간의 차이점, 그리고 의미를 해석하는 방법을 설명한다.
Load versus Progress
애자일 개발 방봅을 따른다면, 팀은 보통 고정된 시간을 갖는 반복되는 개발 주기를 정하고 각각의 주기에 작업들을 할당한다. 따라서 누군가는 모든 개발자들에게 개발 주기 종료일까지 얼마만큼의 가용 시간이 있고, 또 할 일들은 어느 정도 남아 있는지를 알려줄 필요가 있다. 애자일 플래닝 툴은 남아 있는 작업 항목들의 예측 시간과, 당신이 개발 주기 내에 일할 수 있는 시간을 기반으로 이 정보를 계산해준다.
- 부하량(Load) 은 앞으로 가용한 업무 시간과 남아 있는 작업들의 예상 소요시간에 대한 정보이다. 이렇게 생각하면 간단하다. '남은 시간 동안, 이번 개발 주기에 내게 할당된 일들을 다 끝낼 수 있을까?' 이 부하량 정보는 팀 멤버중 누구에게 부하가 걸려있는지를 빠르고 쉽게 알려주므로 결함 선별 과정에서 반드시 참조되어야 하는 자료 중 하나이다. (역자주: 결함 선별 과정에 대한 정보는 여기를.. (중요) Bug Triage Meeting - Severity & Priority )
- 진척도(Progress) 는 남은 일뿐 아니라, 완료된 일들까지 함께 고려된다. 간단히 완료된 작업과 남은 일들의 비율로, 이렇게 읽으면 될 것 같다. '이번 개발 주기의 모든 일들을 고려해볼 때, 나는 지금 어디쯤 온 걸까?' 지난 일들과 남은 일들의 시간 기록이 잘 되어 있다면 진척도는 앞으로의 진행까지 예측해준다. 기본 가정은 지금까지 완료한 작업 속도와 동일한 속도로 앞으로도 일을 처리한다는 것이다. 그래서 만약 당신이 3시간 예상한 일을 9시간 만에 끝냈다면, 남은 일들도 예상치보다 3배씩 더 오래 걸릴 것이라 가정한다. 이렇게 계산된 값이 당신의 가용 작업 시간보다 작다면 당신은 스케줄을 앞지르고 있는 것이고, 더 크다면 뒤쳐진다는 뜻이다.
아래 그림들은 부하량 막대와 진척도 막대이다. 막대 아래의 레이블(Load vs. Progress)과 그 내용을 보면 어떤 막대인지 쉽게 구분할 수 있다.
| 부하량(Load) 막대 | |
| 총 가용한 104 시간 중 18 시간 만큼의 업무가 할당되어 있다. 레이블과 흰색 부분이 아직 86 시간 치의 가용 시간이 남아 있음을 알려준다. | |
| 남은 작업량이 가용한 업무 시간을 초과하고 있다. 총 137 시간치 작업이 할당되어 있으나, 가용 시간은 104 시간뿐이다. 초과 할당된 33 시간이 레이블과 붉은 막대로 표시된다. | |
| 진척도(Progress) 막대 | |
| 총 219 시간의 작업들 중 48 시간치가 완료되었음을 보여준다. 예상 정보는 나타나지 않고 있다. | |
| 예상 정보를 함께 보여주는 진척도 막대이다. 총 80 시간의 작업량 중 45 시간치를 완료했으며, 이번 개발 주기에서 예상보다 빠른 페이스를 보이고 있다. 밝은 녹색 부분이 목표치보다 앞서 있다는 것을 나타낸다. | |
| 5 시간만큼 뒤쳐져 있다. 21 시간의 업무량 중 4 시간 분량을 완료했다. 하지만 총 9 시간치의 일을 완료했어야 하는 시점이라 남은 부분이 붉은 색으로 칠해져있다. |
Why accumulating Estimates and not counting Work Items?
작업의 기준으로 작업 항목의 숫자 대신 예측 시간을 사용하고 있는데, 다음과 같은 장점 때문이다.
- 예측의 정확성이 높아진다. 복잡한 기능 구현 작업 하나와 간단한 결함 수정 작업이 하나가 계획되어 있다고 가정해보자. 기능 구현에는 2일 정도 예상되고, 결함 해결은 2시간이면 될 것다. 그 중 기능 구현을 완료한 시점이다. 만약 항목 수를 기준으로 한다면 당신은 전체 작업 중 절반밖에 완료하지 못한 것으로 계산된다.
- 예측의 유연성이 높아진다. 한 작업 항목을 처리하던 중 그 일이 원래의 예상보다 더 오래, 혹은 간단히 해결될 수 있음을 알게 되었다. 이럴 때 간단히 그 작업 항목의 예상 소요 시간을 갱신해주면 관련된 전체 부하량/진척도 막대가 자동으로 갱신된다.
이렇게해서, 작업 항목의 수보다는 예상 시간을 사용하는 것이 훨씬 유연하고 현실적인 플래닝을 가능하게 해준다. 하지만 예상 시간을 통한 계산은 얼마나 많은 작업 항목들에 예상 시간을 입력해 놓았느냐에 좌우된다. 그래서 우리는 계획의 품질을 높여야 한다.
What is Quality of Planning?
앞서 살펴봤듯, 일(Work)이란 작업 항목들의 예상 소요시간들을 누적한 값이다. 작업 항목에 예상 시간을 입력하는 것은 필수가 아니기 때문에, 예상치를 입력한 작업 항목들의 비율은 그 누적 예측값이 직접적인 영향을 미친다. 더 많은 작업 항목들에 예측값을 입력할 수록 계산의 정확도는 향상된다. Rational Team Concert 에서는 이를 계획의 품지(Quality of Planning)이라 부른다. 모든 작업 항목들이 예측 시간이 입력되어 있다면 품질은 excellent 로, 대다수가 입력되어 있다면 good 과 같은 형태로 표현된다. 시각적으로는 예측치를 입력한 항목의 비율이 높아질 수록 막대가 높이 채워지도록 만들었다(fill-level). 즉 부하량/진척도 막대의 높이가 높아질 수록 예측치가 입력된 항목이 많음을 의미한다. 예측된 항목이 하나도 없다면, 막대가 전혀 보이지 않는다.
| 예측된 작업 항목의 수가 양호한 상태이다. 막대는 거의 끝까지 차있고, 정확한 수치는 레이블에 적혀있다 (80%). | |
| 20%의 작업 항목들만이 채워져 있어 빨리 개선해야할 상황이다. 나머지 80% 항목들의 예측치를 입력하고나면 일이 초과 할당되어 있을 가능성이 높다. | |
| 50% 정도가 채워진 진척도 막대이다. 역시, 막대의 높이가 한참 부족하다. |
Progress Bars in Release Plans
릴리스 계획의 기본은 상위 레벨의 작업들을 가려내는 것이다. 수행 항목(execution item)에 집중하는 반복 계획(iteration plan)과 달리, 릴리스 계획은 계획 항목(plan item)들에 집중한다. 일반적으로 계획 항목들은 너무 모호하여 정확한 시간을 예측하기 어렵기 때문에 시간 예측을 하지 않는다. 그래서 추상적인 예측 단위가 사용되는데, 그 좋은 예가 스토리 포인트(story point)가 될 수 있다. 이 방법은 계획 항목들의 복잡도를 비교하는데 좋은 척도가 되지만, 얼마만큼의 시간이 걸릴지 고민하지 않아도 된다. 종종 그것은 불가능하기도 하다.
진척도 막대는 계획 항목들의 예상 시간이 아닌 복잡도를 기준으로 그려진다. 기본적으로 복잡도는 스토리 포인트를 기준으로 하지만, 필요하다면 커스터마이징할 수 있다 (자세한 설명은 이곳을 참조 - Planning Customization).
레이블과 툴팁 외의 표현 방식은 동일하다. 유일한 차이는 시간이 아닌 스토리 포인트를 기준으로 진척도를 표현하고 있다는 것. 읽는 방법은 이렇다: 총 11 스토리 포인트 중 7 만큼이 완료되었다.
릴리스 계획의 진척도 막대 역시 계획의 예상 진도를 추산해준다. 예를 들어, 한 개발 주기의 절반이 넘어섰으나 (40 작업 시간 중 30 시간이 지났다 치자), 완료된 스토리 포인트는 1/3 뿐이다 (30 포인트 중 10). 그럼 3/4 의 작업 시간이 지났으나 완료된 스토리 포인트는 이제 1/3 이므로, 스케줄에 뒤쳐진 상태가 된다.
Where is the next Bar?
부하량과 진척도 막대는 곳곳에서 찾아볼 수 있다. Plan 에디터는 윗쪽에 전체 진척도를 보여주고, Planned Items 페이지에는 각 그룹별로 부하량과 진척도를 보여준다. 그리고 Team Central 뷰의 Team Load 섹션은 팀원별 현 개발 주기의 업무 부하량을 표시해준다. 부하량은 My Work 뷰의 Current Work 섹션에서도 찾아볼 수 있다. 이곳은 현재 로그인한 사용자의 부하량 보여준다.
No comments:
Post a Comment