일정산정
기능을 개발하기 앞서 선작업이 필요한 것은 개발에 소요되는 일정을 산정하는 것이다. 서비스에 필요로하는 기능은 많지만 현실적으로 모두 구현한다는 것은 힘들기 때문에 우선순위 조정이 필요했다. 그래서 일정산정에 대한 정확한 과정을 알아보기로 하였다.
- Feature : 요구 사항, 스펙과 같은 기능 하나를 의미합니다.
- MD : Man Day 약자로 한사람이 하루를 작업한 것을 의미합니다. 즉, 8시간입니다.
User Story => Feature List => Estimation
일정산정의 과정은 기획서를 참고하여 사용자 스토리를 작성하고, 사용자 스토리를 기반으로 기능 리스트를 작성한다. 그리고 마지막으로 기능 리스트를 통해 일정산정하게 된다.
사용자 입장에서 사용 스토리를 표현한다. 각각의 스토리는 하나의 기능만을 표현한다. ~하면 ~할수있다 와 같은 형식으로 누가, 무엇을, 왜 하는지를 정의한다. User Story를 작성하게 되면 제품에 대한 이해가 더 쉬워진다. 비즈니스 가치에 집중하게 되며 개발 우선 순위 선정을 하게 된다.
그리고 명확하지 않은 부분이 보이게되어 확인해야 할 사항목록이 만들어진다.
기획서를 사용자 스토리를 작성하는 데 주의할 점이 있다. 정말 사용자 입장에서 왼쪽에서 오른쪽으로 위에서 아래로 보면서 각각의 사용자 스토리를 작성해야 한다. 그리고 기존에 있던 기능이라도 일단 작성하는 것이 좋다. 그렇게 되면 기획서 대신 사용자 스토리로 기능을 파악할 수 있다.
- [US] 결제하기를 누르면 결제페이지를 볼 수 있다.
- [US] 결제페이지에는 제품이름, 가격, 배송지, 약관 동의하기 체크버튼을 볼 수 있다.
User Story를 기반으로 하나의 User Story를 충족하기 위해 구현해야 할 Feature를 나열한다. 다수가 검토를 할 수록 좋은 Feature를 추출할 수 있다.
기존에 개발된 개발로 보여도 기능 리스트를 작성할 때는 계속 작성하여 누락이 없게 하는 것이 좋다. 모두 작성이 되었다면 제품과 비교하여 실제 필요한 기능만 구분한다.
마지막으로는 재사용할 수 있는 기능들을 그루핑한다. 그루핑을 하게되면 개발시간단축과 재사용을 위한 일반화가 쉬워진다.
- [US] 결제하기를 누르면 결제 페이지를 볼 수 있다.
- [마크업] 결제 페이지 마크업
- [US] 결제페이지에는 제품이름, 가격, 배송지, 약관 동의하기 체크버튼을 볼 수 있다.
- [API] 결제 API
각 Feature 별로 일정을 산정한다. Feature 별로 1~2MD가 되면 좋으나 개개인의 경험과 역량에 따라 다르다. 추정은 추청일 뿐 정확할 필요는 없다. 필요하다면 Feature List를 수정한다.
- [US] 결제하기를 누르면 결제 페이지를 볼 수 있다.
- [1MD][마크업] 결제 페이지 마크업
- [US] 결제페이지에는 제품이름, 가격, 배송지, 약관 동의하기 체크버튼을 볼 수 있다.
- [2MD][API] 결제 API
코드리뷰, 테스트 작성 등 프로젝트 사항에 따라 2배수 정도 버퍼를 추가한다. 일정 지연을 예방하는 완충기간의 효과를 볼 수 있다.
일정산정에 근거를 통해 협업 관계자와 일정 조정에 관한 원활한 의사소통이 가능하다. 기간이나 Feature를 조정하는 일정 조율의 유연성이 생긴다. 진척도를 가시화 할 수 있다. 작업에 소요되는 시간을 측정가능하게 되고, 주어진 시간에 얼만큼 생산 가능한지 알게 된다.