1	비공개 손님 … 2015-01-02 15:49:12
	그런게 있을리가요.... 일단 원활히 진행했을 때에 대한 일정을 짜는것 보단 각각 개발진행에 대해서 문제점 발생할 건들을 미리 리스트업하는게 중요하지 않나 생각합니다. 디버그, test에 대한 일정도 따로 잡아야 하구요. 이 일정 중 이런 문제가 발생해서 길어질 수 있다 등등을 미리 보고해서 문제 발생시 대처합니다. 솔직히 일정을 말도 안되게 타이트하게 주는 경우가 대부분인데... 암튼 저의 경우는 일정을 주면 경험에 따른 문제들하고 처음할 경우 이를 파악이 안되서 어떠한 문제가 발생할지 모르기 때문에 일정대로 흘러가지 않음을 팀장에게 미리 주지하는 편입니다. 개인적인 일 빨리 하는건 크게 중요하지는 않다고 생각하거든요.

2	비공개 손님 … 2015-01-02 16:10:00
	/1 저도 그렇게는 하고 있는데 문제가 발생해서 일정에 변화가 생겨도 사실상 그게 일정을 변경한다는게 쉽지가 않아서요. 조금이라도 오차를 줄이고 싶어서 뭔가 객관적인 산정 기준이 있나 해서요. 예전에는 1본 기준으로 업무난이도 테이블 수 화면에 붙일 입력항목 수 등등을 정의해서 한적이 있기는 한데..다른 분들은 어떻게 하시는지 궁금하네요. 어떤곳은 시간단위로도 일정을 산정한다던데..

3	비공개 손님 … 2015-01-02 18:49:21
	그게 되면 개발하면 안되죠. 돗자리 깔아야죠. 저는 일반적으로 추정치의 1.25 정도를 곱하면 거의 맞아떨어지더군요. 추정은 100% 감이고요, 감 안잃을려고 이제껏 작업한 모든 내용들 이슈트래커에 기록해 두면서 일하고 있습니다. 추정단위는 1h 단위고요. 저도 처음엔 많이 틀렸었는데(최대오차 2.5) 5년차쯤 되니 거의 1.25에 수렴하더군요. 꾸준히 기록해 두는것 말고는 답없습니다. 엑셀 같은 문서로 꾸준히 기록해 두세요 그게 쌓이면 결국 자기 재산이 되더라구요 (물론 이직하면 무용지물이 된다는 것은 함정)

4	비공개 손님 … 2015-01-03 07:37:28
	해본적이 있는건 경험에 맞추고, 해본적 없는건 구글에 때려봐서 많이 나오면 규모에 맞춰서 하고, 거의 안나오면 '이건 좀 너무 많은게 아닌가?'싶을 정도로 잡아준 후에 1.2~1.3정도 곱해주는 편입니다. 실상 일정을 맞추는건 처음에 일정 잡는것도 중요하지만 중간에 트러블이 생겼을때 어떻게 처리하느냐가 중요해서, 경력이 쌓여야 세운 일정에 맞아가는 듯요.

5	비공개 손님 … 2015-01-03 11:02:47
	아 힘드네요...

6	비공개 손님 … 2015-01-03 15:02:43
	저도 1.25-1.5 정도로 잡고 하는 데 처음 산정도 중요하지만 일이 틀어 졌을 때 빨리 다시 일정을 잡는 것이 더 중요하다고 봅니다...

7	비공개 손님 … 2015-01-04 11:58:10
	일정은 계약이 아니라 추정입니다...하지만 대한민국 IT에서는 일정을 계약으로 치는 노답들이 너무 많더라

8	비공개 손님 … 2015-01-04 12:01:12
	물론 일정은 추정이기때문에 관리자에게 불안감을 심어주지 않으려면 현재 프로젝트 상태를 매일마다 업데이트 하는 것이 중요한데.. 사실 개발자들은 이런거는 잘 신경쓰지 않는 문제도 있긴합니다. 또 기회가없으니 배울기회도없다눈것도 문제고..