개발 일정산정
들어가며
서비스 운영 중에 기능 추가 및 개선이 필요한 백로그는 많지만 현실적으로 모두 구현하기에는 어렵다. 그래서 일련의 스프린트 중에서 "스프린트에 어떤 기능을 넣어 배포할지" 그리고 "큰 볼륨의 기능 담당자와 배포 시점을 어떻게 할지" 등과 같은 업무 조정이 필요했다.
이런 업무 조정에 앞서 선작업이 필요한 것은 개발에 소요되는 일정을 산정하는 것이다. 일정 산정은 애자일 방법론 기반으로 하며 스토리 포인트나 플래닝 포커 등 다양한 방법이 있지만 경험적으로 도입이 가장 쉬운 방법을 소개하고자 한다.
용어정의
- MD : Man Day 약자로 한 사람이 하루를 작업한 것을 의미합니다. 즉, 8시간입니다.
일정산정 전반적인 과정
User Story => Feature List => Estimation => Buffer
일정 산정의 과정에서 시작은 기획서를 참고하여 User Story를 작성하고, User Story를 기반으로 Feature List를 작성하는 것이다. 그리고 Feature List를 통해 경험을 기반으로 MD를 산정하고 상황에 따라 Buffer를 추가하여 일정 산정을 마무리하게 된다.
User Story
User Story는 기획서를 보고 사용자 입장에서 하나의 기능을 "~하면 ~할 수 있다" 와 같은 형식으로 누가, 무엇을, 왜 하는지를 리스트로 정의한다.
User Story 예시
[US] 결제하기를 누르면 결제페이지를 볼 수 있다.
[US] 결제페이지에는 제품이름, 가격, 배송지, 약관 동의하기 체크버튼을 볼 수 있다.
User Story를 작성하게 되면 제품에 대한 이해가 더 쉬워져 비즈니스 가치에 집중하게 되며 개발 우선순위 선정에 도움 된다. 그리고 명확하지 않은 부분이 보이게 되어 확인해야 할 목록이 만들어진다.
User Story를 작성할 때 개발자 입장이 아닌 서비스 사용자 입장에서 기획서를 꼼꼼히 보면서 각각의 User Story를 작성하는 것에 주의해야 한다. 그리고 기존에 있던 기능이라도 일단 작성하는 것이 좋다. 그렇게 되면 기획서 대신 User Story만으로도 서비스 기능을 파악할 수 있다.
Feature List
Feature List는 하나의 User Story를 충족하기 위해 구현해야 할 Feature를 나열한다. 보통 퍼블리셔와 백엔드 개발자와 협업했기 때문에 Feature의 카테고리는 "마크업", "FE", "API"로 표현했다. Feature List는 다수가 검토를 할수록 좋은 Feature를 추출할 수 있다.
Feature List 예시
[US] 결제하기를 누르면 결제 페이지를 볼 수 있다.
- [마크업] 결제 페이지 마크업
- [FE] 결제하기 버튼 연동
[US] 결제페이지에는 제품이름, 가격, 배송지, 약관 동의하기 체크버튼을 볼 수 있다.
- [API] 결제 API
- [FE] 폼 유효성 작업
기존에 개발된 기능으로 보여도 기능 리스트를 작성할 때는 계속 작성하여 누락이 없게 하는 것이 좋다. 모두 작성이 되었다면 제품과 비교하여 실제 필요한 기능만 구분한다.
Feature List 작성 중 마지막으로는 재사용할 수 있는 기능들을 그루핑한다. 그루핑을 하게 되면 개발 시간 단축과 재사용을 위한 일반화가 쉬워진다.
Estimation
Estimation에서는 각 Feature 별로 일정을 산정한다. Feature 별로 0.25~2MD가 되면 좋으나 개개인의 경험과 역량에 따라 다르다. 추정은 추정일 뿐 정확할 필요는 없으며 필요하다면 Feature List를 수정해서 조정한다.
Estimation 예시
[US] 결제하기를 누르면 결제 페이지를 볼 수 있다.
- [0.25MD][마크업] 결제 페이지 마크업
- [0.25MD][FE] 결제하기 버튼 연동
[US] 결제페이지에는 제품이름, 가격, 배송지, 약관 동의하기 체크버튼을 볼 수 있다.
- [0.5MD][API] 결제 API
- [1MD][FE] 폼 유효성 작업
Buffer
코드 리뷰, 테스트 작성 등 프로젝트 사항에 따라 2배수 정도 버퍼를 추가한다. 일정 지연을 예방하는 완충 기간의 효과를 볼 수 있다.
Note: 일정 산정을 통해 얻어지는 기대효과
- 일정 산정에 근거를 통해 협업 관계자와 일정 조정에 관한 원활한 의사소통이 가능하다.
- 기간이나 Feature를 조정하는 일정 조율의 유연성이 생긴다.
- 개발 진척도를 가시화할 수 있다.
- 작업에 소요되는 시간을 측정 가능하게 되고, 주어진 시간에 얼마나 생산 가능한지 생산성을 알게 된다.
마치며
이 방법을 카카오에서 선배 개발자에게 전수받을 때는 효과적인 방법일지 몰랐다. 하지만 여러 번의 일정 산정과 시행착오를 겪고 나서 나와 팀에 어울리는 방법을 찾을 수 있게 되었다. 만약에 단순히 때려 맞추는 일정 산정이 아닌 이론을 기반한 체계적인 일정 산정을 도입하고 싶다면 애자일 방법론이나 이 글을 참고하면 도움 되리라 생각한다.