[Challenge / day-15] 릴리즈 날짜 계산하기

오늘의 공부범위 : 강의 21강 내용(Part2. ch3. 4강)

 

목차

1. 릴리즈날짜 계산하기

 

 

릴리즈 날짜를 계산하기 위해 필요한 것은?

이상적으로는 UI 디자인, 시스템 설계도, 투입될 인원과 프로젝트에 쏟을 수 있는 시간이 확정되어야 릴리즈 날짜를 제대로 계산할 수 있다.

 

하지만, 현실적인 입장에서 그리고 솔로 프로젝트를 현재 진행하는 입장에서 이런 것들을 제대로 알기 어렵고 확정하기 어려워서 전략적으로 특정 날짜를 정해두고 배포를 조금 급하더라도 한 뒤에 작은 버그들을 수습하거나 직감을 활용하여 이쯤이면 프로젝트가 완성될 것이라고 예상해 볼 수 있다.

 

강사님의 강의와 웹서핑을 통해 또 개념을 한 층 보완해서 정리해보았다. 다음은 릴리즈 날짜 계산의 단계이다.

 

1단계: 프로젝트 범위 및 목표 정의
웹 응용 프로그램의 릴리스 날짜를 계산하는 첫 번째 단계는 프로젝트의 범위와 목표를 정의하는 것이다. 여기에는 응용프로그램의 목적, 사용자 및 응용프로그램이 갖추어야 할 기능을 이해하는 것이 포함된다. 이 정보는 프로젝트의 복잡성과 프로젝트를 완료하는 데 필요한 리소스를 결정하는 데 도움이 된다.

2단계: 프로젝트를 더 작은 작업으로 나누기
프로젝트의 범위와 목표가 정의되면 개발 팀은 프로젝트를 더 작은 작업으로 분류해야 한다. 이 작업은 Trello 또는 Asana와 같은 프로젝트 관리 도구를 사용하여 수행할 수 있다. 이 도구를 사용하면 공동 작업을 쉽게 수행하고 진행 상황을 추적할 수 있습니다. 각 과제는 팀원에게 할당되고 마감일이 주어져야 한다.

3단계: 작업 기간 및 종속성 추정
개발 팀은 프로젝트를 더 작은 작업으로 나눈 후 각 작업을 완료하는 데 걸리는 시간을 추정해야 한다. 이 추정은 다른 작업을 시작하기 전에 완료해야 하는 작업과 같이 작업 간의 종속성을 고려해야 한다.

4단계: 프로젝트 타임라인 생성
예상 작업 기간 및 종속성을 사용하여 개발 팀은 프로젝트 일정을 작성할 수 있다. 이 타임라인에는 각 작업의 시작 날짜와 종료 날짜가 포함되어야 하며 작업이 연결된 방법을 보여주어야 한다. 이렇게 하면 병목 현상이나 지연이 발생할 수 있는 영역을 식별하는 데 도움이 된다.

5단계: 테스트 및 품질 보증 고려
개발 작업 외에도 웹 애플리케이션의 출시 날짜를 계산할 때 테스트 및 품질 보증 작업을 고려하는 것이 중요하다. 여기에는 사용자 승인 테스트, 버그 수정 및 코드 검토와 같은 작업이 포함된다. 이러한 작업은 프로젝트 일정에 추가되어야 하며 적절한 마감일이 주어져야 한다.

6단계: 예상치 못한 지연에 대한 설명
세심한 계획을 세워도 개발 과정에서 예상치 못한 지연이 발생할 수 있다. 이러한 지연은 기술적 문제, 팀 구성원의 가용성 또는 외부 요인 때문일 수 있다. 이러한 지연을 설명하기 위해 개발 팀은 프로젝트 일정에 버퍼 시간을 할애해야 한다.

7단계: 릴리스 날짜 계산
모든 프로젝트 작업과 일정이 준비되어 있으므로 개발 팀은 이제 웹 응용 프로그램의 출시 날짜를 계산할 수 있다. 이는 각 작업이 완료되는 데 걸리는 시간과 프로젝트 시간 표시줄에서 연결되는 방법에 따라 달라진다. 출시 날짜를 이해 관계자에게 전달하고 지연이 발생할 경우 필요에 따라 조정하는 것이 중요하다.

결론적으로, 웹 애플리케이션의 출시일을 계산하는 것은 프로젝트를 더 작은 작업으로 세분화하고, 작업 기간과 종속성을 추정하며, 프로젝트 일정표를 작성하고, 테스트 및 품질 보증 작업을 고려하고, 예상치 못한 지연을 고려하고, 최종 출시일을 계산하는 것을 포함한다. 개발 팀은 이러한 단계를 따름으로써 웹 애플리케이션이 제 시간에 완료되고 프로젝트의 목표와 목표를 달성할 수 있도록 보장할 수 있다.

 

실습이 빠질 수 없다. 직접 실습을 해보자.

강사님의 일정은 실무와 근접하게 잡으신 것 같은데, 사이드 프로젝트임을 고려한 일정일 것이고 강의를 따라가면서 만드는게 아니라 길게 잡으셨는데 나는 강의수강계획과 거의 맞추면 될 것 같아서 다 짧게 줄였다.

 

그리고, 백엔드 설계와 관련된 부분까지 다 다루기에는 너무 강의도 길어질 것이고 (지금 기획,디자인,시스템 설계도 간략하게 배우는데도 강의 양이 엄청 많다..!!) 프론트엔드 강의이기 때문에 백엔드 API는 필요하다라고 가정하고 그에 대한 설계 같은 부분은 사실 AWS에 맡긴 것으로 봐도 무방해서 내용을 수정하게 되었다.

 

수정 전 내용은 다음과 같고,

수정 후에는 다음과 같이 바뀌었다.

 priority도 low로 바꿔서 나중에 진행할 일로 만들어서 프론트엔드 작업을 수월하게 진행할 수 있도록 하였다. 다음시간에는 이번 파트 복습 및 예습할 내용에 대한 과제가 있을 예정이다.

 

 

 

 

관련링크

패스트캠퍼스 : http://bit.ly/3Y34pE0

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

 

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

 

#패스트캠퍼스 #패캠챌린지 #수강료0원챌린지 #환급챌린지 #직장인인강 #직장인자기계발 #패캠인강후기 #패스트캠퍼스후기 #오공완 #사이드프로젝트10개기술스택으로구현하는풀스택서버리스프로젝트withReact