1. 개발 일정과 리소스 배분 문서화
1.1.개발 일정 산정 | 일정을 산정하는 순서
- Proposal → User Story → Feature List → Estimation
1.1.1. User Stroy
- 기획서에 표현된 기능을 사용자의 입장으로 “~하면 ~할 수 있다” 형식으로 누가, 무엇을, 왜 하는지를 정의
- 사용자 스토리를 장성하면 제품에 대한 이해가 쉬워져 개발 우선순위를 정하기 수월
- 사용자의 시선을 그대로 따라가면서 각각의 스토리를 작성해야함
- 위에서 아래로, 왼쪽에서 오른쪽으로
- User Stroy가 완성되면 기획서 대신 User Stroy로만 기능 파악 가능
- 이를 위해 기존에 있던 기능이라도 User Stroy에 모두 작성하는 것을 권장
[ 사용자 스토리 예시]
- [US] 결제하기를 누르면 결제페이지를 볼 수 있다. (*US는 User Story의 약자)
- [US] 결제페이지에는 제품이름, 가격, 배송지, 약관 동의하기 체크버튼을 볼 수 있다.1.1.2. Feature List
- 하나의 User Stroy를 충족하기 위해 구현해야할 기능들을 모두 나열
- 작성 형식은 “[담당] 작업내용” 형식으로 작성
- 작성이 완료되면 공통된 기능(재사용 할 수 있는 기능)을 각각의 그룹으로 묶음
- 그룹화는 재사용을 위한 일반화와 추상화 방법 판단에 도움을 줌
- 기존에 개발된 기능도 Feature List에 누락없이 작성을 원칙으로 하고, 모두 작성 후 제품과 비교해 실제 필요한 기능만 남김
[ Feature List 예시]
- [US] 결제하기 버튼을 클릭하면 결제 페이지로 이동할 수 있다.
- [마크업] 결제 페이지 마크업
- [프런트] 결제 페이지 마크업 반영
- [프런트] 페이지 이동 링크 작업
- [US] 결제 페이지 접근 시 제품 이름, 가격, 배송지, 약관 동의하기 체크박스를 볼 수 있다.
- [API] 제품 조회 API
- [프런트] 제품 조회 API 연동[ 공통 Feature List 예시 ]
1. [US] 휴가 신청 메뉴 클릭 시 휴가 신청 페이지로 이동된다.
2. [US] 휴가 신청 페이지에서 달력, 사유 입력 양식을 볼 수 있다.
3. [US] 휴가 신청 페이지에서 달력을 통해 날짜를 선택할 수 있다.
4. [US] 리포트 메뉴 클릭 시 리포트 페이지로 이동된다.
5. [US] 리포트 페이지에서 달력, 차트를 볼 수 있다.
6. [US] 리포트 페이지에서 달력을 통해 날짜를 변경할 수 있다.
---
1. [공통] 달력을 통해 날짜를 선택할 수 있다.1.1.3. Estimation (개발 일정 산정)
- 각 기능 별로 일정을 산정
- 정확할 필요는 없음
- 필요하다면 기능 리스트를 수정
- MD : Man Day의 약자로, 한 사람의 하루 작업량(약 8시간)
- 30MD를 1MM(Man Month의 약자)로 환산해서 사용하기도 함
[ Estimation 예시 ]
- [US] 결제하기를 누르면 결제 페이지를 볼 수 있다.
- [1MD][마크업] 결제 페이지 마크업
- [US] 결제페이지에는 제품이름, 가격, 배송지, 약관 동의하기 체크버튼을 볼 수 있다.
- [2MD][API] 결제 API1.1.4. Buffer
- 코드리뷰, 테스트 작성 등 상황에 따라 2배수 정도의 버퍼를 일정에 추가
- 일정 지연을 예방하는 완충효과 기대
1.2. 리소스 배분
- 리소스 : 장비, 자금, 기술 툴, 직원 업무 가능 여부 등 프로젝트를 완료하는 데에 도움이 되는 것 일체
프로젝트 목표 설정 → 프로젝트 범위 조율 → 필요한 리소스 유형 파악 및 사용 가능한 리소스 확인 → 프로젝트 진행상태 확인
1.2.1. 프로젝트 목표 설정
- 좋은 프로젝트 목표의 기준 (SMART 방법론)
- Specific(구체적인)
- Measurable(측정 가능한)
- Achievable(달성 가능한)
- Realistic(현실적인)
- Time-bound(기한이 정해진)
- 목적과 목표의 차이
- 일반적으로 목적은 목표의 상위 개념
- 목적은 프로젝트 성공 시 어떻게 되는지 나타냄
- 목표는 프로젝트가 완료되면 완성하게될 실질적이고 구체적인 결과물에 초점을 맞춤
목표 예시 : 고객이 제품에 포함된 피드백 양식을 발견할 새로운 방법 다섯 가지를 두 달 내로 추가합니다.
목적 예시 : 엔지니어링 팀이 고객 피드백 접수 및 대응을 더 쉽게 할 수 있는 방법을 찾습니다.1.2.2. 프로젝트 범위 조율
- 프로젝트 범위 : 프로젝트의 요구 사항과 결과물에 대한 개요
- 프로젝트 결과물과 이러한 결과물이 프로젝트 목표와 어떻게 관련되는지 명확하게 설명
- 범위를 정의하지 않을 시 프로젝트 결과물에 무엇을 포함할지 안 할지 명확히 파악할 수 없음
1.2.3. 필요한 리소스 유형 파악 및 사용 가능한 리소스 확인
- 모든 팀원이 담당하는 업무를 명확히 파악해 프로젝트에 적합한 팀원을 선출
- 프로젝트 범위에 따라 팀에 과도한 업무가 배정되지 않도록 리소스 평준화, 우선순위 조정
1.2.4. 프로젝트 진행상태 확인
- 배정된 리소스가 적절히 배분되었는지 지속적으로 확인
1.3. 현 프로젝트 적용
1.3.1. 탬플릿
- 프로젝트 목적 : ${프로젝트 완료 시 기대효과}
- 프로젝트 목표 : ${기간} ${측정 가능한 목표 수치} ${구체적 결과물}
- 프로젝트 범위 : ${결과물을 포함하는 범위}
- 개발 일정 (buffer를 포함)
- [US] ${사용자가 ~을 하면} ${~을 얻을 수 있다}
- [${기능에 소요되는 기간 }] ${스토리에 해당하는 기능} - ${담당자} ${필요시 추가 리소스 기입}
1.3.2. 보고서
참고자료
감동 코딩