상사에게 일을 받으면 상사분은 '언제까지 할 수 있어?' 부터 물어본다.
단순 작업이라면 기간이 얼마나 걸릴 지 어렵지 않게 이야기 할 수 있을 것이다.
그만큼 많이 해 왔을 작업일 것이니...
그 추정의 기준이 되는 것은 보통은 '이전에 걸린 시간'이다.
환경 차이, 스케쥴 차이, 기타 차이 등을 고려하면서 이전에 걸린 시간을 기준으로 더하거나 빼는 것이다.
근데, 프로그래머로 살다 보면 기간 추정이 상당히 어려울 때가 많다.
예를 들어, 기존에 한 번도 못해본 것이라던지, 설계단계부터 새로 시작하는 경우라던지, 해야 할 일이 방대해서 기간 추정을 길게 해야 할 때이다.
어렵다고 안할 수도 없는 노릇이고... 너무 짧게 잡으면 스스로 무덤을 파는 것이고, 너무 길게 잡으면 긴장이 풀려서 일하기가 어려울 뿐더러, 상사에게 좋게는 핀잔, 나쁘게는 잔소리를 들어야 한다.
Software Estimation 이라는 책이 있긴 한데, 얼마나 도움이 될까는 미지수이고...
(보신 분께서는 소중한 리뷰 부탁드립니다.)
필요한 것은 시간일까?(경험을 더 쌓는다는 의미로...)
아니면 문제를 분석하고 쪼개고 단순화시켜 단순 작업처럼 추정 가능한 정도로 만들 수 있는 능력일까?
아님, 후자를 가능하게 하는 것이 전자일까?
어떻게 하면 더 효율적이고, 더 정확하게 추정할 수 있을까?
단순 작업이라면 기간이 얼마나 걸릴 지 어렵지 않게 이야기 할 수 있을 것이다.
그만큼 많이 해 왔을 작업일 것이니...
그 추정의 기준이 되는 것은 보통은 '이전에 걸린 시간'이다.
환경 차이, 스케쥴 차이, 기타 차이 등을 고려하면서 이전에 걸린 시간을 기준으로 더하거나 빼는 것이다.
근데, 프로그래머로 살다 보면 기간 추정이 상당히 어려울 때가 많다.
예를 들어, 기존에 한 번도 못해본 것이라던지, 설계단계부터 새로 시작하는 경우라던지, 해야 할 일이 방대해서 기간 추정을 길게 해야 할 때이다.
어렵다고 안할 수도 없는 노릇이고... 너무 짧게 잡으면 스스로 무덤을 파는 것이고, 너무 길게 잡으면 긴장이 풀려서 일하기가 어려울 뿐더러, 상사에게 좋게는 핀잔, 나쁘게는 잔소리를 들어야 한다.
Software Estimation 이라는 책이 있긴 한데, 얼마나 도움이 될까는 미지수이고...
(보신 분께서는 소중한 리뷰 부탁드립니다.)
필요한 것은 시간일까?(경험을 더 쌓는다는 의미로...)
아니면 문제를 분석하고 쪼개고 단순화시켜 단순 작업처럼 추정 가능한 정도로 만들 수 있는 능력일까?
아님, 후자를 가능하게 하는 것이 전자일까?
어떻게 하면 더 효율적이고, 더 정확하게 추정할 수 있을까?
'Dev.Think' 카테고리의 다른 글
| IT 전공자에게만 산업기능요원 자격 - 듣던 중 반가운 소식 (0) | 2007/06/04 |
|---|---|
| 엔지니어 발을 묶겠다는 어이없는 칼럼에 대한 생각 (0) | 2007/05/31 |
| 기간 추정... (0) | 2007/05/31 |
| 오픈소스 개발에 관한 시도, 그리고 돌아섰던 경험담 (0) | 2007/05/19 |
| (산업기능요원 종사자가 바라본)산업기능요원 IT 분야 보충역 배정 중단 (0) | 2007/05/02 |
| 블로그 전문 검색엔진 '나루' 에 대한 생각 (0) | 2007/04/09 |
