풀스택 서버리스 프로젝트 with React - 2. 프로젝트 관리

사이드 프로젝트：10개 기술스택으로 구현하는 풀스택 서버리스 프로젝트 with React
Part 1. 프로젝트 시작하기
Ch02. 프로젝트 관리

 

# 프로젝트 관리, 개발자가 왜 알아야 하죠

## 프로젝트를 관리하는 목적

- 팀이 업무를 체계적으로 계획/관리/수행하여 프로젝트 요구 사항을 충족 시킬 수 있다.
- 모든 이해 관계자와 프로젝트의 상태를 원활하게 공유한다.
- 프로젝트 계획, 세부 사항, 파일, 피드백을 한 곳에서 관리할 수 있다.
- 팀 효율성 및 협업 개선

- 보통 실무에서 프로젝트 관리는 PM (Project Manager) 혹은 PO (Project Owner) 가 담당

## 저는 개발자인데 왜 알아야 하나요?

- 사이드 프로젝트에서 여러분의 역할은 개발자 이면서 Project leader
- 프로젝트의 원활한 진행과 효율적인 협업을 위해

## 실무에서는 왜 알아야 하나요?

- 소프트웨어를 개발/유지보수 하는 데에는 프로젝트가 연속적으로 발생하는데, 프로젝트의 흐름을 알고, 관심을 가져야 큰 그림을 볼 수 있다
- 지금 프로젝트에서 중요한 것이 무엇인지 알고 관심을 가져야 본인의 개발 일정도 잘 관리할 수 있다
- PM, PO 중에는 비 개발자 출신이 많다. 우선 순위와 일정을 논의하면서 개발자의 의견을 구하는 경우도 빈번하게 일어납니다. 그들에게 대안을 제시하거나 적극적으로 의견을 피력해야 할 경우가 많다

- 기술적인 챌린지가 주인 프로젝트일 경우, 개발자가 PO의 역할을 대신 하기도 한다
- 점점 시니어가 되어가면서 팀 내에서 해야 할 프로젝트를 리딩하게 될 것이고, 프로젝트 관리에도 자연스럽게 주축 멤버가 될 것이다

## 개발자로서 잘 해야 할 것

- 프로젝트의 목표와 목적의 이해
- 우선 순위 정하기
- 개발 일정 산출과 스케줄링

- 타 조직/직군과의 커뮤니케이션

- 위험 관리

- 문서화

# 프로젝트를 잘 관리하기 위한 방법 (1)

## 팀 관리 측면

- ✅ 프로젝트의 목표가 명확해야 한다
    - 팀원들이 같은 곳을 바라보고 있는가?
    - 목표가 같아야 최고의 결과물이 나옵니다!
- ✅ 팀원들과 자주 소통 한다
    - 나와 다른 의견도 존중할 줄 알아야 한다. 감정적으로 받아들이지 말 것.
    - 플래닝 및 의사결정에 다같이 참여하도록 한다.
        - 동기 부여도 되고, 팀원들이 더 적극적으로 임한다.
    - 실수 했을 때는 "왜 이런식으로 하는거야 대체?" 보다는 "우리 모두 이런 일을 겪을 수 있어. 어떻게 해야 다음 번에 같은 일을 방지할 수 있을까?"를 논의하기. Blameless
- ✅ "왜 (Why)" 생각하기
    - ‘안될 것 같은데요?’ ❌  → '왜' 할 수 없는지 생각 해보고 공격적이지 않게 소통 하기
    - ‘어 일단 해볼까요?’ ❌ → '왜' 해야 하는지 생각 해보고 소통하기
    - 팀이 프로세스에 문제를 제기 했을 때, 이게 왜 문제인지 생각하기. 표면의 이유만 덮고 지나가는 것이 아니라 근본적인 문제를 찾으려고 노력하고 대화하는 것이 필요

## 문서화 측면

목표: 팀에 새로 조인한 사람이 봐도 파악하기 쉽도록 작성 해야 한다. 뉴비의 관점에서 보려고 노력하기!!

✅ 충분한 정보를 담고 있는가?

- 프로젝트 주제와 목표
- 서비스 요구사항/기능 리스트
- 시스템 설계 및 스펙
- 일정
- 대시보드

✅ 필요한 정보를 잘 찾을 수 있는가?

- 검색 기능 활용
- 비슷한 내용을 여러 문서에 적기 ❌ → 한 곳에 정리
- Table 잘 사용하기
- Tag 사용하기

# 프로젝트를 잘 관리하기 위한 방법 (2)

- 노션 템플릿을 사용할 수 있다.

# Notion으로 프로젝트 관리 템플릿 생성하기

- 노션으로 

# 소프트웨어 개발 주기

## 왜 알아야 하죠?

- 소프트웨어를 개발하고 관리하는 데에 있어 가장 근간이 되는 프로세스이자 프레임워크
- 실무에서도 소프트웨어 개발 주기를 기반으로 프로젝트를 진행
- 사이드 프로젝트도 이 개발 주기를 기반으로 진행해야 체계적으로 진행하고 더 좋은 품질의 제품을 개발할 수 있다

## SDLC (Software Development Life Cycle)

### 1. 기획

- 요구사항을 수집하고 프로젝트를 기획하는 단계
    - 사용자 설문, 마케팅 요구사항 등 다양한 채널을 통해 데이터를 모으는 과정으로 가장 중요하면서도 기초가 되는 단계
- QA (Quality Assurance)를 위한 요구사항과 프로젝트가 가질 수 있는 리스크 판단

### 2. 분석

- 제품의 요구사항을 정의하는 단계
- SRS (Software Requirement Specification)에 기록
    - SRS : 디자인/구현해야 할 소프트웨어의 모든 요구사항을 기록해 둔 명세서
    - IEEE 에서 제공하는 SRS 템플릿: https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc

### 3. 디자인

- 시스템을 디자인하고 설계하는 단계

### 4. 구현

- 디자인을 기반으로 개발자가 코드로 기능을 구현하는 단계

### 5. 테스팅 및 배포

- 구현 내용이 요구 사항을 충족 하는지 검증하는 단계
- 프로젝트/비지니스 성격에 따라 베타 오픈, 특정 시간에 오픈 하기도 함

### 6. 유지 보수

- 제품을 마켓에 배포하고 서비스를 모니터링 하면서 유지보수 하는 단계

## 소프트웨어 개발 방법론

### Waterfall

- 전통적인 개발 모델로 프로젝트 기간 동안 SDLC의 주기를 한 사이클만 돈다. 즉, 모든 단계를 완벽하게 준비하고 진행해서 모든 기능의 배포를 한 번에 한다는 것
- 개발 하기 앞서 완벽에 가까운 플래닝이 되어야 하기 때문에 요구사항이 변동됐을 때 유동적으로 대처하기가 힘듦
- 요즘 이 모델을 사용하는 회사는 거의 없음

### Agile

- 소프트웨어의 요구사항은 개발 도중 자주 변경 된다. 그리고 변경된 요구사항의 따른 작엽량을 예측하기 힘들다. 따라서, 계획과 형식에 지나치게 의존할 경우에는, 전체적인 개발의 흐름이 느려진다
- 아무 계획이 없이 개발하는 것과 지나치게 많은 계획을 세우고 개발하는 방법들 사이에서 타협점을 찾고자 고안됨
- 제한된 시간과 비용 안에서 정보는 불완전하고 예측은 불가능하다는 전제를 가진다. 그 전제 안에서 합리적인 답을 내는 것이 애자일 개발 프로세스

# 사이드 프로젝트에서 적용할 것들

## 계획/기획~분석 - Part 2

- 아이디어 구체화
- 서비스 요구사항을 도출하는 방법
- 서비스 요구사항 정의하기
- 프로젝트 플래닝 하기

## 디자인 - Part 2

- UI 디자인을 할 수 있는 툴 소개
- Figma로 디자인 된 시안 살펴보기

## 설계 - Part 2

- 시스템 설계하기
- 최적의 기술셋 찾기
- 리액트 컴포넌트 설계하기

## 구현 - Part 3~4

- 선택한 기술셋으로 초기 환경 셋업하기
- 설계를 바탕으로 React component 구현하기

## 테스트 - Part 5

- Unit test로 functionality 기능 검증
- Cross-browser 테스팅
- End-to-end 테스팅

## 배포 - Part 5

- 배포 프로세스 수립하기
- 서비스 배포하고 모니터링 하기

## 유지보수 - Part 6. 새로운 요구 사항에 대처하기

- 기존 설계 문서 업데이트, 디자인 업데이트 등 Part 2~Part5를 반복