개발 일정 예상... 어떻게 하시나요?

안녕하세요! 오, 좋은 고민을 하고 계시네요. 저도 문득 다른 분들은 어떻게 하고 계신지 궁금하네요. 저 같은 경우는 이렇게 하고 있어요: 1. 작업을 할당 받으면, 작은 단위로 나눔. ex) xx 기능 개발이 아니라 xx 기능 프론트, xx 기능 백엔드 등으로 정리 (프론트, 백엔드에서 끝나는게 아니라 더 나눌수 있으면 나눕니다) 2. 작은 단위로 나눈 거를 구글 캘린더에 기입 3. 미지수가 있으면 최소 써야할 시간을 미리 정해놓고 이것도 캘린더에 같이 기입 4. 이렇게 쭉 기입하면 마지막 완료일이 나오는데, 이걸 과거 기록과 비교할 수 있으면 비교합니다. 그리고 역산을 해서 조정할 부분 (시간을 더하거나 빼는 거)을 조정합니다. 추가적으로 실제 작업이 끝나면, 제가 적어놓은 일정을 제대로 다시 수정해놓습니다. 캘린더에 10시간으로 기입 되어있어도 실제로 8시간만에 끝났으면 8시간으로 수정해요. 이렇게 계속 하다보면 데이터가 어느정도 쌓여서 보다 정확하게 예측을 할 수 있는 것 같아요. 물론, 완벽하게 예측하는건 불가능이라서 작업 완료 예측일을 미루기도하고 땡기기도하고 있습니다 :)

실제 작업에 걸리는 시간을 기록하고 그걸 참고하시는 것만 해도 대부분 개발자가 쉽게 하지 못하는 것을 하는 거로 생각해요. 처음 하는 작업은 아무래도 예측이 어려울 수 있어요. 예측을 100%에 가깝게 정확히 해서 처음 전달한 일정을 맞추도록 해야겠다는 목표보다는 단계별 일정을 예측해서 단계별로 공유하고 진행하는 것도 방법이에요. 예를 들어 1. 요구사항 분석 2. 설계 3. 구현 4. 테스트 5. 배포 이와 같은 순서로 개발을 진행한다고 했을 때 1~5번까지의 전체 일정 예측이 힘들 수 있어요. 이때에는 단계별로 일정을 예측하는 방법을 써보는 거예요. 1번을 언제까지 하겠다고 일정을 정하고 팀 내에 공유해요. 요구사항 분석을 진행하면서 문제정의를 제대로 하게 되면 꼭 해야 할 일과하지 않아도 되는 일이 드러나게 돼요. 이 꼭 해야 할 일들을 Tasks로 정리하면 실제 진행해야 할 업무 리스트가 만들어져요. 각 Task에 대한 일정을 스스로 예측해보고 전체 일정을 도출하여 팀 내에 공유해요. 그리고 이후 2~5번을 진행하면서 매일 자신의 진행 상황을 점검해요. 그리고 주 단위 정도의 기간으로 팀 내에 진행 상황을 간단히 공유해요. 이때 일정에 변경이 필요한 이슈가 있다면 같이 공유해요. 이렇게 단계별로 일정을 예측하고, 공유하고, 진행하고, 또 공유하고(daily, weekly) 하는 사이클을 지속해서 반복하면서 업무를 진행하는 것을 습관화하면 좋아요. 결과적으로 이렇게 하는 이유는 협업하는 팀원들이 변경된 일정에 맞춰서 유연하게 업무를 진행할 수 있도록 하기 위해서예요. 일정을 정확히 예측하는 사람은 많이 없을 거라고 생각해요. 저 또한 개발을 계속해오면서도 아직도 일정 예측은 정확히 100% 되지는 않아요. 결국 100% 일정 예측을 하는 것은 불가능하다고 생각하고 위와 같은 방법으로 프로젝트를 진행하고 있어요. 오랜 시간 이렇게 해보니 이 방법이 오히려 협업하는 데 있어서 가장 좋은 방법이라고 저는 생각하고 있어요. --- TMI --- https://github.com/pistis/developers-today 이건 스스로 시간 관리를 잘해보기 위해서 만든 개인 프로젝트에요. 혼자서는 2년 넘게 쓰고 있어요. 특별한 기능이 있는 것은 아니에요. 매일 진행하는 업무를 시작할 때와 끝날 때 시간을 기록해요. 기록된 업무 내용을 토대로 어떤 프로젝트에, 어떤 종류의, 어떤 특정 이슈에 시간을 얼마만큼 썼는지 보고 특정 기간에 내가 어떤 일들을 했는지를 요약해서 볼 수 있는 정도의 기능이 있어요. 일정 예측뿐 아니라 스스로 업무를 진행하는 데에 있어서 자신을 관리하기 위해 만든 도구예요. 관심 있으시면 mac 용(.dmg 파일)으로 만들었으니 링크 README.md의 0.0.7다운로드 링크로 이동해서 설치해서 한번 사용해보세요.

조직에 따라 다를것 같은데요, 말씀하신대로 기존에 비슷한 작업 이력이 있으면 최대한 참고하여 산정 하기도 하구요, 이력이 없을경우, 조직내 일정산정 가이드가 있다면 그에 따르면 되지만, 없다면 "경험치"에 많이 의존하게 되는것 같습니다. 무턱대고 일정을 길게 잡자니 일정 산정근거에 대해서 빡빡하게 묻기도 하고 그렇죠~ 제가 있던 조직에서는 제가 일정 산정 계산 가이드를 만들어 팀내 공유 하기도 해서 근거에 대해 물을때도 요긴하게 사용 했었던 기억이 나네요. 허나, 어차피 개발중에는 예측하지 못한 변수가 자주 생기기 마련이기에 정확한 일정 산정은 어렵습니다. 다만, 일정산정시 순수개발시간만 넣는 실수를 하는 경우가 있는데 반드시 코드 리뷰 활동이나 테스트활동, 개발산출물(개발후 문서) 작성에 드는 시간까지 포함하는 것이 좋습니다.