개발 일정 관리에 대한 조언 부탁드립니다.

개발일정이라는 것이 정해진 작업을 반복하는 것이 아니기 때문에 시간을 정하는데 늘 어려움이 따릅니다.
전 개발일을 한지 몇 년이 지났는데도 어렵습니다.
조엘 온 소프트웨어라는 책에서는 정확한 일정을 잡기 위해 일을 최대한 나누라고 합니다. 최대한이라는 기준은 측정 가능한 단위까지 나누라는 것입니다.
어떤 책에서는 대략적인 기준을 잡고, 진행되는 정도에 따라 계속 수정하라고도 합니다.
위와 같은 방법을 제대로 수행하기 위해서는 경험이 중요하다고 생각됩니다.
아직 개발 경험이 없다면 매우 어려운 일일 수 있습니다.
조급해 하지 마시고, 실패하더라도 계속 시도를 해보세요.
특히 일이 잘 안된다 싶으면 과감하게 늦어진다는 걸 미리 상사에게 이야기하세요.
혼자 고민하지 마시고, 직장 동료들과도 많은 대화를 나누시길 바랍니다.
또한 책임은 혼자 지는 것이 아니라 상사도 같이 책임을 지게 됩니다.
때문에 일정을 상의할 때 위에 나온 기준대로 개인적인 생각을 표현하고, 상사가 결론을 내도록 하세요. 당연 억지 일정은 개인적인 생각을 강하게 표현하세요.

일정을 잡는 것도 중요하지만, 관리도 중요합니다.
툴을 쓰는 것도 방법입니다. 저희 회사는 DotProject라는 툴을 씁니다.
조엘은 엑셀도 좋은 툴이라고 권합니다. 종이나 달력도 좋은 방법입니다.

이런 호기심을 가지신다는 것에 높은 점수를 드리고 싶군요.
호기심을 가장 잘 해결하는 방법은 책을 읽는 것입니다. 질문 내용 이외에 방대한 내용이 들어있긴 하지만 소프트웨어 공학이나, 개발 방법론, 프로젝트 관리에 대한 책들을 몇 권 읽으시면 나름 생각이 잡힙니다.

아래 책들을 한 번 읽어 보세요. 책 내용을 고집할 필요는 없지만 생각을 많이 하게 하는 책들입니다.
좋은 책들을 모두 기억할 수 없어 대략 생각나는 걸 적어봅니다. 개인 적인 생각으로 적은 책목록입니다. 다른 사람은 안 좋게 생각할 수도 있죠.

조엘 온 소프트웨어
피플웨어
소프트웨어 컨플릭트 2.0
소프트웨어 크리에이티비티 2.0
스티브 맥코넬이 지은 책
등등...

이건 제 의견이라기 보다는 agile 관련 서적들의 권고사항 정도인데요.

원론적으로 말씀드리자면 4시간 이하 정도의 task 단위로 나누는 것이 좋습니다.
처음에는 잘 안되지만 하다보면 오차범위가 (일정 수준까지) 계속 줄어듭니다.

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

요구사항을 잘 이해하고 해당 요구사항을 구현 하고 추정 할수 있는 단위로 나누는 것이 핵심입니다.
그런데 여기서 수많은 변수가 작용합니다.
요구사항의 변경, 시스템의 제약 사항, 구현 이슈, 테스트 의 어려움, 문서화 작업, 등등
어떻게 하던 100% 정확한 일정 추정은 불가능 한 상태에 놓여 집니다.
하지만 현실에서는 한번 추정한 일정을 뒤업기는 힘들죠, 특히 신입 같으면 죄짓는 기분이 들지도 모르겠습니다.

나름 8년 정도 개발하면 일정 추정에 대한 노하우라면
첫번째 추정 할수 있는 단위로 잘게 나눈다. 만약 요구사항을 보고 5일 이상 일정이 소요 될것 같으면 해당 요구사항을 다시 나눈다.

두번째 가산 기간을 포함한다. UML 기법이나 나사의 소프트웨어 공학 기법을 살펴 보면 소프트웨어의 설계전 추정치는 추정된 결과에 과중치 100%~400% 정도를 더한 값이다라고 되어있습니다.
물론 위의 경우는 메우 크리티컬한 프로젝트의 경우이고 또한 국내 현실에서 무시당하기 십상인 경우가 많습니다.
하지만 개발자라면 어떤 변수가 생길지 모르는 일정에 항상 과중치를 가져가 일정 지연으로 발생되는 심각한 손실을 미연에 방지 해야 합니다.
가령 3일 정도 예상 되는 작업이 있다면 1.5~ 2일 정도 과중치를 주어 추정하는게 좋습니다.

세번째 계속 자주 재 추정 한다.
일반적으로 가장 실수를 많이 하는 부분이 시작 시 추정후 해당 추정치를 재 추정 하지 않는 문제 입니다.
물론 한번 추정된 일정을 변경할 수 없는 경우가 많이 발생해서 그렇겠지만, 추정 일정을 조절하지 못한다면, 다른 방법으로 해당 추정일정을 이룰수 있는 방안을 고안해내야 합니다.
범위의 축소, 업무의 분담 등 모든 방법을 동원해야 합니다.
하지만 추정일정이 왜 잘못 되었고 얼마나 잘못되었는지 는 재 추정을 해봐야 알수 있는 부분입니다.
또한 추정이라는 것은 구현이 되어 감에 따라 상대적으로 정확도가 항상 되어 갑니다.
그래서 프로젝트 전반에 걸쳐 추정된 일정을 현 사항에 맞게 다시 추정해야 하며, 과거 추정의 실수나 실패가 있더라도 재추정으로 나온 문제를 객관적 사실로 프로젝트 이해 관계자들이 알수 있게 해야 추정의 실패로 야기 된느 손실을 최소화 할수 있습니다.

결론 적으로 정확한 추정일은 존재 할수 없습니다. 하지만 우리는 최대한 정확한 추정을 도출 해야 합니다.
방법은 작은 단위를 추정하고 추정된 값을 계속 확인 조정 하며, 객관적 사실을 바탕으로 추정을 바라 보는 수 밖에 없습니다.

* 실제 이번 서울 지하철 9호선 개통 연기가 교통카드 시스템의 소프트웨어적 문제라고 하더군요.
하루에 발생 하는 손실액만 수억원에 이런다고 하니 프로젝트에서 소프트웨어 개발에 관련된 추정의 실패가 빛는 손실은 엄청나다고 할수 있습니다.