일정산정, 정확성 높이기.

오늘은 타임로그 관련 공식 3탄, 비공식 4탄입니다.

본래 계획했던 글쓰기 일정보다는 약간 늦었습니다. 글쓰기 앞서, 안타깝게도 이번에는 번다운차트가 없습니다. 지난 Sprint6 가 너무나 정신없이 흘러가버려서 스크릿샷 뜨는걸 잊어버렸습니다.ㅜㅜ 정말 슬픕니다. 왜냐면, 이번 Sprint6 번다운 챠트는 그동안 제가 그렸던 그래프중에서,.. 가장 자랑할만한 그래프였꺼든요.. 일정산정도 거의 정확했고, 일정한 개발속도를 유지했으며, 특별한 이슈도 없어서,.. 보통 마지막에 위로 올라가곤했던 예상시간 그래프(노란색그래프)도 초기 예상한 일정대로 한치의 흐트럼 없이 진했됐던 Sprint 였습니다. (오히려 릴리즈 마지막날 역으로 일정이 감소됐습니다.)

백문이 불여일견이라고, 번다운차트를 보여줘야 이해가 빠를텐데.. 아깝네요..ㅜㅜ.. 어떻게든 그래프를 살려서 보여드리도록 하겠습니다. 이상 각설하고, 이번 포스트의 주제는 정확한 일정산정하기 입니다.!!

정확한 일정 산정하기

정확한 일정을 산정하는데 있어서 제가 생각하는 중요한 변수는 2가지가 있습니다.

• 첫째, 가장 중요한것은 일정한 개발속도 유지입니다.
• 둘째, 그다음 중요한것은 경험입니다.

앞의 2가지가 충족되면, 제 경험상 Sprint 단위로 나누었을때, 3번째 Sprint가 지나면서 대체적으로 초기 추정한 일정과 실제 소비한 일정이 맞아 떨어지게 되더군요. 일정한 개발속도와 경험 이라는 변수를 놓고보면 프로젝트는 매우 단순해 집니다. 즉, 개발자 개개인이 일정한 속도를 내고, 경험이 쌓이면 프로젝트는 항상 예상가능해집니다. 제 이론은 그렇습니다.

하지만 일정한 속도를 유지해내는것 자체가 문제겠죠? 무엇보다 중요한것은

• 이 일정한 개발속도를 어떻게 유지하느냐? 그리고
• 도대체 일정한 속도를 어떻게 측정하냐? 일 것입니다.

여기서 제가 말씀 드리는 일정한 개발속도란?

하루동안 본인이 처리할수있는 작업의 양이라고 생각하시면 됩니다. 즉, 하루에 난 어떤 작업이 주어지든지 5시간을 일할수 있다. 라는 의미입니다. 그리고 그 어떤 작업은 항상 예상 추정시간이 있겠죠. 난이도가 있는것은 5시간 이상이 될수도 있겠고, 난이도가 낮은것은 5 이하일수도 있습니다. 이 난이도 측정과 예상시간은 결국 경험입니다. 이것은 나중에 다시 얘기하겠습니다.