프로젝트 추정 기술을 향상시켜라

실천 사항

일을 쪼개서 하라는 말은 많이 들었지만 얼마나 쪼개야할지 기준을 정하진 못했다.

앞으로 이틀 이상 걸리는 작업은 더 쪼개려고 한다. 기준은 이틀로 정했다.

업무별 목표를 정해서 진행하는데, 목표를 구체적으로 정해야한다.

왜냐하면 불필요한 작업을 덜어주기 때문이다. 개발자로서 욕심이 생겨서 ‘X 작업할 때 평소 신경쓰였던 Y도 같이 고쳐야 겠다.’라고 생각하는 경우가 많다.

일을 시작할 때 아래 세가지를 정해야겠다.

작게 쪼개기
구체적인 목표 정하기
측정 가능한 마일스톤 정의하기

책 내용

정확한 추정치를 활용하여 프로젝트 계획을 추진하라.

“이 프로젝트를 마치는 데 시간이 얼마나 걸릴까요?” 소프트웨어 프로젝트를 진행할 때 자주 듣는 질문이다. 우리가 한 추정이 설사 부정확하더라도 다른 사업적 결정에 반영된다. 추정이 형편없으면 큰 대가를 치러야 할 수도 있다.

유연성을 보장하는 정확한 추정치를 도출하는데 도움되는 전략 몇가지

프로젝트를 더 작은 작업으로 분해하라.
자신 또는 다른 누군가가 원하는 작업 시간 말고, 작업에 실제로 드는 시간을 기준으로 추정하라.
추정을 최상의 시나리오가 아닌 확률 분포로 생각하라.
실제 업무 담당자가 추정하게 하라.
기준점 편향에 주의하라.
하나의 업무를 여러 방법을 사용해 추정하라.
이상적인 인월(person-month)을 조심하라.
기존 데이터로 추정치를 검증하라.
범위가 커질 수 있는 작업을 타임 박스로 제한하라.
다른 이들이 추정에 이의를 제기하도록 허용하라.

추정을 반복해서 수정하면 프로젝트 결과물이 나아질 수 있다. 프로젝트 초반에는 추정에 불확실한 부분이 많지만, 세부사항이 구체화될수록 변화의 여지가 줄어든다.

미지의 변수를 고려하라.

일정을 크게 어긋나게 한 원인은 아예 추정하거나 계산할 수 없었던 온갖 미지의 프로젝트와 문제에 있다.

새로운 코드베이스를 위한 단위 테스트 장치를 개발하고 테스트용 자체 모의 라이브러리, 단언문 라이브러리 작성하기
일련의 스타일 가이드라인이 장기적으로 코드 품질을 개선하는 데 도움이 된다는 것, 그리고 그렇게 많은 코드를 작성하기 전에 이런 가이드라인을 개발해야 한다는 것을 깨닫기
우선순위가 높은 일부 고객에 대응하느라 작업 중단하기
사용자가 재현하기 어려운 특정한 방법을 통해 발생하는 버그 수정하기
고객 데이터가 많아지면서 발생하는 제품의 확장성 문제 해결하기
프로젝트 중간에 초창기 개발자를 다른 회사에 빼앗기기: 많은 지식을 이어받고 작업을 재분배해야 했다.

‘이 프로젝트 엔지니어링 작업을 완료하기까지 1개월이 걸릴 것이다.’라는 말은 달력상 1개월 이상이 소요된다는 말이다.

평소 개발자는 눈에 띄는 버그 수정, 면접 진행, 팀 회의 참석, 관리자와 1:1 대화 진행, 비상 당번 근무, 신입 개발자 교육, 이메일 회신 등 많은 엔지니어링 외적 업무를 반복해서 처리해야 한다. 이런 사항을 고려하면 하루 8시간을 근무한다고 해서 프로젝트에 8시간을 쓴다고 볼 수는 없다.

일회성 방해 요소도 발생한다.