목차
1. 기본 워크 플로우
1 - 1. 1주일 단위 스프린트 진행
•
월: 팀 별 프로젝트 issue 발급 및 담당자 선정
◦
•
월 ~ 목: 발급된 issue에 따른 작업 진행
◦
작업 진행은 "작업 가이드"를 참고
•
금: issue 회고 및 결산, 결산 통합 보고
◦
2. 회의 규정
2 - 1. 회의 시간
•
월 오전 10시: 프론트엔드 팀 issue 발급 회의
•
월 오전 11시: 백엔드 팀 issue 발급 회의
•
금 오전 11시: 결산 보고 통합 회의
2 - 2. 회의 목적 및 절차 가이드
3. issue 규정
3 - 1. issue 규격
3 - 2. issue 작성 가이드
4. 프로젝트 진행 규정
4 - 1. 비 코딩 issue 진행 가이드
•
코딩을 하지 않아 branch를 생성하지 않는 issue에 대한 가이드
•
branch가 없는 issue는 PR이 존재하지 않으므로 보고를 따로 해야함
4 - 2. 코딩 issue 진행 가이드
•
branch를 생성해 coding을 직접 진행하는 issue에 대한 가이드
•
PR을 생성할 수 있으므로 PR단위로 자동화
4 - 3. 완료되지 못한 issue
•
해당 주기에 완료되지 못한 issue는 다음 주기로 넘어갑니다(milestone 다음 주기로 이동)
5. commuication 가이드
•
기본적으로 앞으로 모든 communicating은 issue와 PR로 이루어집니다
◦
즉 완료 보고 / 결제 완료에 대한 chatting이 없습니다
•
따라서 issue와 PR에 대한 notification을 설정해 둘것을 권장합니다
6. 기타
6 - 1. commit convention
6 - 2. 원론
•
이 과정으로 쉽게 파악할 수 있는것
◦
작업의 일련의 흐름(milestone을 통해 해당 주기에 마무리된 issue를 일괄적으로 파악 가능)
◦
작업의 진행 상황(in_progress)에 등록된 모든 issue가 진행상황임을 알 수 있음
◦
커뮤니케이션 툴 최소화(git만으로 보고 / 결제 가 가능함)
◦
통일된 규격으로 인한 장기적 작업 효율화
6 - 3. 자료 아카이빙
•
프로젝트를 하면서 수집한 자료는 reference(mention)에 저장합니다.
◦
제목과 링크만 달아도 됩니다
•
프로젝트의 결과문서는 PM(seolim) dev log에 따로 종합하거나, 직접 dev log(mention)에 작성합니다
◦
예를 들어 특정 문서(프로젝트 환경 가이드)를 요구한 경우 해당 문서를 직접 dev log에 작성 후 issue에 작성 완료 및 링크를 남겨두어도 되고 issue에 작성하고 차후 PM이 dev log로 이전할 수 있습니다