일정 예측

기획서가 나오고 개발에 들어가기 전에 얼마나 시간이 걸릴 것인지 예측을 해야된다.
기획서를 토대로 예측을 진행한 후 정해진 개발 기간에 개발할 수 있는 것과 없는 것을 나눌 수 가 있고,
경우에 따라서는 추가 구현을 위한 추가 기획이 필요할 때도 생긴다.

개발 경력이 얼마 되지 않아서 인지, 예측한 일정과 실제 소요된 시간은 항상 차이가 있었고
일정을 어떻게 예측하는 것이 좋을지에 대해서 고민이 있다.

애자일을 도입한 팀에서는 플래닝 포커 카드를 사용해서 일정을 예측하기도 하지만
말로만 들어봤을뿐 한번도 해본적이 없어서 잘 모르겠다.
(사실 플래닝 포커 카드를 사용하는 일정예측을 해보고 싶어서 두 세트의 포커카드를 구했지만
팀에 동의가 없어서 시도해 보지 못하고 책상위에 올려져 있는 상태이다. )

CodeCraft에서 일정 예측과 관련된 챕터가 있기에 정리~

전에 해본적이 없는 일이라면 시간이 얼마나 걸릴지 생각해 내기 더 어려울 것이다.
추정에 기초로 사용할 사전 경험이 없기 때문이다.

그렇다. 일정예측, 시간 추정을 했는데 제대로 못했다고 지쳐있을 필요는 없다.
경험이 쌓여가면 예측을 조금더 잘 할 수 있을것이다.

시간 추정 방법

• 일을 가능한 한 가장 작은 덩어리로 나누어라.
• 이것은 시스템 설계의 실질적인 첫번째 단계이다.
• 이해하기 쉬운 적당한 크기의 구성요소들로 잘게 나누었으면, 각각의 덩어리에 대해 맨아워(man-hour)또는 맨데이(man-day) 단위로 소요 시간을 추정하라
• 각각의 소요시간을 모두 추정하고 난 다음에는 그것을 연속해서 늘어놓고, 기간을 합산하라.
• 합산된 시간이 바로 소요시간이다.

처음에 일정을 예측할때는 코드를 작성하는 시간만을 고려했는데 작업을 하다보니 그것이 아니었다.
코드의 작성이 끝났다고 해도, 테스트를 해야지 되고, 테스트를 하다보면 버그가 나오고
다시 그 버그를 수정하고, 테스트를 해야 작업이 끝나서 저장소에 커밋을 하고 작업 완료를 보고 할 수 있었다.

코드를 잘 작성했다면 버그도 안나와서 한번의 테스트로 모든게 끝났겠지만
미숙하기 때문에 미숙할 것이란것도 예상해서 일정을 예측해야 하는것 아닌가 하는 생각도 했었다.

추정 시간은 소프트웨어 납품에 필요한 모든 활동을 고려해야 한다

• 충분한 생각을 거친 설계 수행
• 필요한 탐구 작업 또는 프로토타이핑 모두
• 실질적인 코드 구현 작업
• 디버깅
• 단위 테스트 코드 작성
• 통합 테스트
• 문서 작성
• 프로젝트 수행 기간 동안 착수할 모든 연구와 훈련
  

프로젝트는 혼자서 하는게 아니기 때문에 팀원은 일정의 진행 상황을 팀장에게 보고 해야만 한다.
처음 예측한 그대로 작업이 진행된다면 좋겠지만, 그렇지 않은 경우에는 일정을 조절 해야하고
최초 기획내용을 수정해서 제한 시간내에 구현하도록 변경한다던지, 아니면 프로젝트의 전체 일정을
수정해야 하는 경우도 생긴다. 이때 가장 중요한 것이 바로 보 고라고 생각한다.

일정이 지연되고 있는데도 보고하지 않고 한동안 지연상태를 알 수 있는 방법이 없다.
일정에 영향을 미칠것 같은 일이 발생하면 빠르게 보고를 해야 프로젝트를 제한된 기간안에 성공적으로 마무리할 수 있을 것이다.

스케쥴 치킨(schedule chicken) 게임
중요한 프로젝트가 5명의 프로그래머로 구성되어 있고,
그 프로그래머들이 각자 자기가 한 일의 진행상황을 반드시 보고해야 한다면,
그 중 어느 누구도 자기가 스케쥴에 뒤처진 첫 번째 사람이 되는 것을 인정하고 싶지 않을 것입니다.
그 결과 모든일이 잘 되고 있는 것처럼 보이다가, 갑자기 프로젝트가 엄청나게 늦어집니다.
한 번에 하루씩 늦어지고 있었찌만 아무도 인정하고 싶지 않았던 것입니다.
이런 악순환을 깨고 가능한 한 빨리 경고 사인을 널리 알리십시오

인용문 출처 : CodeCraft 뛰어난 코드 작성을 위한 설계 지침, 2007, 피트 구들리프, 한빛미디어