[태그:] 타임로그

이번에는 예전에 작성한 하루에 얼마나 일하고 있나요? 에 이어서 2번째 시리즈입니다. 본래는 타임로그관련 3번째 포스트네요.
첫번째 포스트는 여기에 실었습니다.

이전 포스트에서는 타임로그를 작성법과 더불어, 타임로그 통계 정보들을 공유 드렸는데요..
이번에는 개발속도에 대해서 이야기 하려 합니다.

개발 속도와 추정

개발 속도를 이야기 하기 앞서, 지난 Sprint 5 에 대한 번다운 차트부터 봅시다!
[[ 이 글의 이미지도 역시 날려먹었네요. ㅜㅜ ]]

이전 포스트에서도 밝혔지만, 전 위와같은 챠트를 이용해, 현재 내가 얼마나 일하고 있는지..
그리고 앞으로 또, 얼마나 일해야 맡은 일을 완료 할수있는지 추정하고 있습니다.

그래프를 보시면, 이번 스프린트5 에서는 지난 스프린트와는 다르게 기간을 3주로 잡았습니다.
물론 3주로 잡은 나름의 이유는 있었죠. 여하튼, 빨간 가이드 라인과 녹색 그래프가 거의 비슷하게
일치하는 매우 준수한 그래프입니다. 평균 개발속도는 4~5를 왔다갔다 하는군요.
( 실제 속도는 78/15 = 5.2 시간입니다. 그래프와 약간의 오차가 있군요. )

지난 스프린트4 와 비교했을때, 역시 비슷한 속도를 내고 있습니다. ( 이전 속도는 5.6 이었습니다. )
이제 어느정도 일정한 속도를 내고 있다고 얘기할수 있겠군요.

하지만, 최종 그래프가 찍은 시간을 보면, 초기 추정 68시간보다 10시간 많은 78시간을 일했다고 얘기하는군요. 그래프를 보아하니, 마지막 3주차에 아하… 뭔가가 이슈가 있었나 봅니다.
그래서 무엇이 문제 였는지 로그를 디벼봤습니다.

추정의 실패한 원인 찾기

이슈가 있었던것이라기 보다는 다른 개발자가 사전에 해주어야할 일정이 예상보다 늦어지면서,
전 다음 스프린트에 해야할일을 땡겨서 해버렸습니다. 왜냐면 놀수는 없는 거잖아요. ㅎㅎ
분위기상 띵가띵가 놀수도 없고.. ㅋㅋㅋ

그러다 보니, 받듯하게 가야할 노랑색 추정시간이 마지막 차수에 10시간이나 올라가 버렸습니다.
일단 그래프만 보아서는 추정에 실패한 문제가 있는 그래프 이지만, 로그를 확인해보니,
사연이 있었군요.. 리즈너블합니다. ( 뭐 저 혼자만의 생각일수도 있어요.. ㅋㅋㅋ)

그래도 그나마 다행인것은, 노랑색 추정그래프가 왔다갔다 하지 않고, 일정 하게 수평을 긋고 있다는 사실입니다. 노랑색 그래프가 한쪽 방향으로 올라가거나 내려간다면, 분명 초기 추정에 실패한것입니다.
따라서, 우리는 매순간순간 철저하게 일정을 추정해야하고, 성실하게 로그를 기록해야
아~~~ 내가 이쯤 달리고 있꾸나 를 넘어서,
아~~~ 우리가 이쯤 달리고 있구나 하는것을 알수가 있는 것이죠. ^^

정답은 역시 타임로그!

그렇다면, 역시 답은 하나밖에 없습니다.
앞서 언급했던 개개인의 타임로그를 부지런히 남기는 수밖에 없습니다.

“수신제가치국평천하” 라고, 개인의 타임로그를 부지런히 남겨야,
전체 프로젝트 관리도 잘 될수 있다는 사실 다시 한번 곱씹어 봅니다.

우리는 보통 하루 8시간을 회사에서 일하며 보내게 됩니다. 회사가 집에서 멀다면 출퇴근 시간포함하여 대략 24시간의 절반을 회사에서 보내게되며
잠자는 시간 8시간을 빼면 4시간을 집에서 혹은 가족과 보내게 되죠. 정말 이런가요?.. 이론적으로 그렇겠죠? 아마 이론이 아니라, 이상론이겠죠..ㅎㅎ

개인적으로 하루 8시간 이상 자는 날은 주말 말고는 없습니다.
각설하고, 오늘 하려고 하는 얘기는 시간관리에 대해서 입니다.

회사에서 일하는 시간은 8시간

하지만, 집중해서 일하는 시간은 얼마나 될까요? 개발자라는 직업을 가진 저에겐 일하는 시간이란 프로그래밍 다른말로 코딩을 하는 시간을 의미합니다.
물론, 회사 일에는 코딩 말고도, 여러가지가 있습니다. 회의도 있고 메일도 확인해야하고 문서도 가끔 쓰고 팀원들과 이런저런 얘기도 해야하고.. 그래서 전 궁금했습니다.

과연 내가 하루에 얼마나 일하는것인지.. 아래 차트는 지난 2주간 일한 시간입니다. (지금 제가 하고 있는 프로젝트는 Sprint 라는 이름으로 2주간 일정을 나눠서 진행하고 있습니다.)

[ 안타깝게 이미지링크가 깨졌습니다.. ㅜㅜ ]

[여기서 잠깜!] 그래프 보는 방법

• 녹색선 : 처리 해야 할 일의 남은 시간 총합
• 파란석 : 지금까지 내가 처리한 일의 누적 총합
• 노란선 : 처리해야할 추정 시간 총합
• 빨간 대각선(/) : 기준이 되는 가이드 라인으로 녹색선이 빨간색 기울기와 비슷한 방향으로 이어지면 프로젝트가 제대로 굴러가고(?) 있다는 것을 얘기함.
• 주황색선 : 처리해야할 시간대비, 남은 일정으로 하루평균 얼마나 처리해야하는지 알려주는 가이드 시간

하루 평균 일한 시간은 5시간?

그래프를 보면, 분명 전 5월3일부터~ 5월 15일까지 주말빼고 10일간 총 51시간의 일을 처리했습니다. 즉, 하루 평균 5시간을 일한거죠.

정말 그런가요? 그렇치 않습니다. 5월 5일은 어린이날.. 그날은 놀았꺼든요~ 😀 그래프에도 나오죠.. 5월 5일은 파란선이 옆으로 쭉—– 그어져있죠.. 일을 안했다는거죠.. 그러니까, 결론은 9일간 총 51시간을 일한거니, 5.6 시간을 일한 거에요 🙂 이것을 애자일 진영에서는 보통 속도라고 얘기합니다. 저의 평균 처리 속도는 5.6 입니다.

추정과 일정 계획

그래프를 보면, 초기 추정은 40시간이 었지만 실제 이번 Sprint에 처리한 시간은 총 51시간 이었습니다. 11시간의 오차가 발생한것이죠. 말이 11시간이지, 하루 평균 속도 5.6시간을 놓고 보면, 일정이 이틀 밀린겁니다. 저만 그런가요? 그렇치 않습니다. 프로젝트를 진행하다보면, 초기 추정시간이 끝까지 가는 경우는 없다고 해도 과언이 아닙니다. 만약 초기 추정시간이 프로젝트 끝까지 갔다면, 분명 문제가 있는 프로젝트입니다. 아니라고 부정하실분 계신가요? 없겠죠? ㅎㅎㅎ 11시간의 오차 발생은 로그를 확인해보면, 예상치 못한 부분에서 발생했습니다. 이렇게 예상치 못한 이슈를 만나게 되면, 언제나 야근이 답이죠.ㅎㅎㅎ 이런 이슈때문에 버퍼시간을 두기도 하는데, 일정에 버퍼를 두는 것을 전 그닥 좋아하지 않습니다. 버퍼를 두게 되면, 사실 기록이 왜곡될 가능성이 있기 때문이죠. 이슈가 있으면, 있는대로, 없으면, 없는대로 기록되는 것이 프로젝트를 건강하게 유지하고, 개인적으로도 할 얘기(?)가 많아집니다. 할 얘기가 많아지면, 재밌죠.. ㅋㅋ

로그 남기는 방법

앞에서 보여드린 그래프는 JIRA라는 이슈관리 시스템을 이용한 것입니다. 회사에선 그냥 BTS(Bug Tracking System) 라고 부릅니다. 그리고 이 BTS상에 작업로그를 꼼꼼히 남겨야만, 내가 지금 어디위치에 있는지 한눈에 확인할수있습니다. 그렇치 않고서는 위와 같은 그래프를 확인하긴 어렵죠. 사실 작업로그를 꼼꼼히 남기는 것 또한 일입니다. 쉽지 않다는 거죠. 노력이 필요한 부분입니다. 그래서 전 액셀을 이용합니다. (올레~~ 액셀 참 편하죠~ ) 액셀에 사실 그닥 중요한 내용은 없습니다. 그냥 자리를 비우거나, 뭔가를 하다가 다른 타입의 일을 하게 될때 마다.. 단축키를 이용해 시간을 입력하고, 이전에 무엇을 했는지 기록을 하는 것이 전부입니다. 이렇게 작성한 개인 타임로그는 BTS 상에 작업로그를 입력하는 기반데이터가 됩니다. 😀 매우 중요한 기초자료가 되는 셈이죠. 또한 주간보고를 작성할때도 유용하다죠?

타임로그를 기록하세요!

메모지를 이용하든지, 그냥 노트패드를 이용하든지, 스마트폰을 사용하든지.. 수단 방법을 가리지 마시고, 오늘한 일을 시간과 함께 기록하세요. 특히 이제 막 직장생활을 하시는 분이라면 강추드립니다. 자신의 기억력을 맹신하지 마세요. 우리의 기억력은 아다시피 정확하지 않습니다. 메모하는 습관을 길러보세요. 그럼 기억력도 좋아집니다. 전, 타임로그를 작성하면서부터, 컴퓨터도 빨라진거같아요. ㅋㅋㅋ 뻘소리가 길었습니다. 지금까지 제가 사용하는 시간관리 방법을 적어봤습니다. 여러분들은 어떻게 하나요?

궁금합니다.!!

오늘은 뭔가 그럴듯한 글을 써보고 싶어서, 평소와 다르게 뻘소리 짓꺼린다..ㅋㅋ 아우 어렵다 글쓰기..