why not

프로젝트 플래닝3 (10일차) 본문

Today I Learn/환급 챌린지

프로젝트 플래닝3 (10일차)

novem 2023. 3. 1. 10:12

<릴리즈 날짜 계산하기>

 

1. 릴리즈 날짜를 계산하기 위해 필요한 것들

1-1. 이상편

  • UI 디자인 -> 프론트엔드 로직이 바뀔 수 있기에 꼭 필요
  • 시스템 설계도 -> 설계 기반으로 태스크를 세분화 할 수 있음
  • 투입될 인원과 프로젝트에 쏟을 수 있는 시간 -> 본업이 있는 상태이기 때문에 쓸 수 있는 시간이 다양함

1-2. 현실편

  • 아직 완벽하지 않아도 1차적으로 무엇을 해야 할지 파악이 끝난 프로젝트만 있으면 가능
  • 직감이나 예측(전략적인 배포라면 날짜가 박혀 있는 경우도 있음)

ex) 릴리즈 날짜를 정하기엔 시간이 오래걸리기 때문에, 아마존의 경우, 프로젝트를 관리해주는 매니저나 경험이 많은 개발자들이 모여 프로젝트의 규모와 해야 할 일을 파악 및 예측을 한 후 목표 날짜를 1차로 러프하게 정한 후 설계를 진행 -> 매니저의 성향이나 프로젝트의 성격 등을 토대로 릴리즈 날짜를 유동적으로 변경이 가능함

 

2. 릴리즈 날짜는 유동적으로 대처하는 것이 핵심!

2-1. 주어진 정보 만으로 1차 목표 날짜 정하기

-> 태스크 3가지 중, A태스크는 3일, B태스크는 2일, C태스크는 1일이 소요될 때, 병렬적으로 진행되는 태스크들도 있기 때문에 총 6일이 소요된다고는 할 수 없다.

 

2-1.1) 일정 관련 체크리스트

  • 병렬적으로 진행할 수 있는 task가 있는지 확인하기
  • 개발 테스팅 단계에서 QA대한 일정을 포함하고 있는가? -> 회사에 따라 QA조직이 따로 있는 경우에는 QA조직과 논의하기
  • 프로젝트의 시스템 설계가 끝나지 않은 상태에서 릴리즈 날짜를 잡기때문에 리스크를 고려한 충분한 버퍼를 넣었는지 생각하기

2-1.2)병렬적으로 수행할 수 있는 태스크 진행 시에 타임라인 예시

  • 요구사항 정리 -> 요구사항의 정의와 우선순위를 정하는 step
  • UI 디자인 -> 요구사항을 정리하는 동안 디자인 시작 가능
  • 아키텍처 설계 -> UI 디자인의 초안과 큰그림만 나왔을 때도 아키텍처의 설계가 가능
  • 플래닝 업데이트 -> 아키텍처 설계 끝나고 릴리즈 날짜 등이 대강 나오게 됨
  • 리소스가 충분하고 이용할 기술이 확정 되었을 때 프론트엔드와 백엔드 세팅 시작(상황따라 유동적으로 가능)
  • 플래닝 업데이트 -> 있을 수도, 없을 수도 있음(해결할 크고 작은 이슈들을 있으면 일정 변경이 가능 -> 큰 이슈에서는 꼭 필요함)
  • QA진행 -> 모든 기능들이 정상적으로 동작하는지 확인하면서 배포 준비 가능
  • 배포준비가 다 되면 릴리즈 발사!

-> 정리) 1차 목표 날짜 / 디자인 + 프론트 엔드 구현 + { 백엔드 미지의 넘버이기에 직감을 이용!! } / QA 계산 / 버퍼는 30% 정도를 잡도록 하자 / 각 팀원들이 얼마나 dedicate 하게 프로젝트에 참여할 수 있는지도 파악 필요

 

3. 노션에 업데이트하기 (Product-level task board)

  • 타임라인 뷰 생성하기
  • 릴리즈 날짜 정하기

 

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

* 필수 삽입 링크 : http://bit.ly/3Y34pE0

 

패스트캠퍼스 [직장인 실무교육]

프로그래밍, 영상편집, UX/UI, 마케팅, 데이터 분석, 엑셀강의, The RED, 국비지원, 기업교육, 서비스 제공.

fastcampus.co.kr