피처리스트는 간단히 말해서 "할 일 목록"을 정하는 일이다. 보통은 기획자가 1차로 작성을 하고 개발팀에서 구조설계나 테스트 등 기획자가 정하기 어려운 항목을 추가할 수 있다. 예를들어 어떤 다이얼로그 창이 있다면 버튼의 기능 별로 피처가 나올 수 있고, 드래깅과 같은 행위들도 별도의 피처가 될 수 있다. 보통 엑셀파일로 작성한다. 기획자는 피처에 우선순위를 지정할 수 있다. 추정된 일정이 너무 길 경우 우선순위에 따라서 피처를 들어낼 수 있다.
각 피처에 대해서 개발자를 배정하고 공수를 산정한다. 피처를 완료하는데 걸리는 시간을 3점 추정(최소공수, 보통공수, 최대공수를 산정하고 비중을 두고 곱한 후 나눠서 가중치를 두어 평균을 내는 방법)하는 것이 원칙이기는 하나 규모가 큰 경우에나 의미가 있는 것 같다. 프로젝트라는게 추정 자체에 오차가 심하고 3점 추정의 평균을 하면 보통공수와 크게 다르지 않은 경우가 많았다. 하지만 공수산정은 반드시 해야 하는 것이 해당 피처를 완료했을 때 실제로 투입된 시간으로 추정의 정확도 파악할 수 있기 때문이다. 그것을 바탕으로 추정능력도 나아지게 된다.
일정추정이 중요한 이유중 하나는 유관부서의 협업 일정 때문이다. 마케팅이나 광고 제작 등을 프로젝트 완료시점에 맞추어 준비시키는 것이 대부분이라 완료시점을 잘 추정하는 것이 여러모로 자원의 낭비를 막을 수 있다.
프로젝트 일정 산정하는 법:
* 개발자가 하루 일 하는 공수는 1MD(man day) 이다
* 1MD는 6H (6시간) 이다. 이유는 프로젝트를 하다보면 여러가지 개발 외 업무가 있다. 개발자는 이것을 간과하기 쉬운데 대표적인 것이 회의, 교육, 이동시간, 고객응대, 메일대응, 긴급대응, 기타 조직업무 등으로 실제로 8시간을 다 개발하는데 쓸 수가 없다. 특히나 큰 회사에서는 2개 이상의 프로젝트를 동시에 진행하는 경우가 종종있는데 프로젝트 업무를 전환하는 비용이 상당히 커서 많은 시간을 산만하게 흘려보내는 경우가 많다. 야근과 주말근무는 당연히 완전히 배제한다.
* 5MD 이상 걸리는 피처는 쪼개서 여러 피처로 분할한다.
* 공수는 설계 + 구현만 산정한다. TDD나 유닛테스트, 문서작성이 필요하다면 포함시킨다.
* 안정화 공수는 개발 공수 * 0.5 이다. 개발 공수의 0.5는 개발자 테스트 및 모듈 통합시 발생할 수 있는 버그의 수정 등 안정화에 사용된다. 안정화 공수는 필수다.
* 설계 + 구현 + 안정화 + 릴리스 + 출시관련작업 = 개발공수
* 프로젝트 전체 일정 = 개발공수 + 개발공수 * 0.3 로 산정하는데 개발공수의 30%는 프로젝트 버퍼에 해당한다. 버퍼는 메이저 스펙변경, 팀원의 건강악화, 교통사고, 유관부서의 일정지연 등 예상할 수 없는 일을 대비하기 위함이다.
* 매 주 추정공수와 투입공수를 확인하여 추정의 정확도를 기록으로 남긴다.
* 최종 릴리스전에 팀내 중간 릴리스나 유관부서 테스트 단계를 두는 경우가 있는데 이 때 일정 재추정을 할 수 있다. 일정 재추정 단계는 개인적으로 매우 중요하다고 생각한다. 프로젝트의 스펙변경은 일상다반사이다. 이전 스펙으로 추정된 일정은 의미가 없으므로 재추정이 필요하다. 일정 재추정이 없다면 정확한 개발완료 시점을 알 수 없다는 것과 같다. 일정 재추정이라는 과정을 통해서 프로젝트가 진행될수록 프로젝트의 남은 일정을 점점 정확히 추정할 수 있게 된다.
프로젝트를 몇 건 진행해 보니 이렇게 추정된 일정을 더 썼으면 더 썼지 덜 쓰지는 않았다. 딱 맞게 떨어진 경우도 있었다. 2달 이내로 추정된 경우는 추정의 정확도가 높았다.
같은 피처라고 해도 개발자 별로 추정공수의 오차가 심할 수 있는데, 역량의 차이가 큰 이유이겠지만 개인별 성향의 차이 때문일 수도 있다. 이 경우 개발리더는 과거 데이타를 바탕으로 해당 개발자의 산정된 개발공수를 보정해 줘야 한다.(보통은 정성적으로)
오차를 줄이는 또 다른 방법은 카드를 이용하는 방법이다. 개발팀의 모든 팀원이 각 피처에 대해서 공수가 적힌 카드를 동시에 꺼내놓는다. 최소로 추정된 공수와 최대로 추정된 공수에 대해서 그 이유를 들어보면 구현 과정에서 중대한 누락이 발견될 수 도 있다. 역량이 높은 개발자는 더 깊게 보기 때문에 주니어개발자가 미처 찾아내지 못하는 구현대상을 찾아낼 수 있다.
개발자별로 추정된 개발공수가 다른데 가장 길게 추정된 공수가 크리티컬패스가 된다. 일정이 적게 추정된 개발자에게서 지연이 생기더라도 프로젝트 전체 일정에는 영향이 덜한데 크리티컬패스가 되는 개발자에게 지연이 생기면 프로젝트 전체 일정에 영향이 있게 된다. 역량에 따라서 피처를 잘 배분하는 것이 중요하다.
일정추정시 성능적인 관점에서도 충분히 검토가 있어야 한다.
타 부서의 대략적인 일정을 얘기할 때는 주의가 필요하다. 예를 들어 대략적으로 5MD 걸릴 것 같은 경우 5MD라고 얘기하는 것 보다는 1주일 걸린다고 얘기하는 것이 좋다. MD는 주 단위보다 오차범위가 좁은데 때문에 꽤 정확한 일정으로 오해하고, 확정되어 커뮤니케이션 되는 경우가 있다.
위 기술된 기법중에 일정재추정과 카드로 하는 공수회의는 해 보지 못했다.
