Winter Season Plan
언제볼까? 프로젝트는 이전의 Hearus 프로젝트가 완료된 이후 기말고사가 끝나고 겨울에 진행하고자 위와 같이 팀원들과 의견을 취합한 상태였다.
또한 스스로 인프라 구축에 더 많은 Load를 할당하기 위해 BE 개발자를 추가적으로 모집하여 2월부터 Auth-based 버전을 개발할 계획을 가지고 있다.
Jira Workspace Migration
우선 기존 Notion + Slack을 통해 진행했던 업무를 더 Agile한 방식으로 진행하기 위해 Jira로 Workspace를 Migration 하였다.
JIRA
- Planning : user story 및 issue(일감)를 생성하고 sprint를 계획
- Tracking : 팀 업무의 우선순위를 정하고, 수행 상태 등 가시성 제공
- Release : 일감의 개발완료 등 최신 정보를 가지고 제품 출시 관리
- Report : 실시간 시각적 데이터를 기반으로 팀 효율을 향상
Issue의 종류
Epic: 큰 단위의 업무(여러 User Story, Task 등을 묶은 단위)Story: 최종 고객에게 가치를 제공하는 기능
- 작성 방법 : “I as WHO want to do WHAT, so that WHY”
- Tip) User story의 크기는 sprint내에 완료 가능한 단위로 분할 필요
- 예) 사용자 관리 개발Task: User Story외의 기술적, 관리적 업무
- 예) 설계, 서버 설치, 클라우드 도입 등Sub-Task
- Story, Task를 더 작은 단위로 나눈 업무
- 즉, 모든 Sub-Task가 끝나야 해당 업무 종료
- 예) 사용자 관리(UI) 개발, 사용자관리(Service) 개발
참고로, JIRA에서는 Story와 Task를 같은 레벨로 구분하지만, 일반적으로 Story를 더 작게 나눈것을 Task라고 정의하기도 함
에픽이 가장 큰 단위, 그안에 스토리들과 스토리보다는 작은 단위인 작업 이 존재
스토리와 작업 안에 가장 작은 하위 작업들이 존재하고 버그 트래킹을 위해 버그 이슈도 존재
Reporter(보고자)
Issue 업무 내용을 작성하고, 진행상황을 보고 받는자
(원래는 일을 시키는 사람이 작성하므로, 일감 작성자로 기본 할당됨)
Assignee(담당자)
해당 Issue를 수행하고, 일감상태를 현행화할 담당자
Watcher(지켜보기)
JIRA는 기본적으로 보고자, 담당자에게만 Issue 변경, comment 발생시 알림이 가며, 담당자를 1명만 선택가능
따라서, 다른 사람에게도 알리는 기능 필요
1. 숫자(Watch하고 있는 사람수)를 클릭해서 다른 사람 추가
2. 본인이 관심있는 Issue를 클릭하여 추가
Jira Project Setting
이전에는 위와 같이 Notion에서 Board를 생성하여 진행하였는데
이와 유사한 형태로 우선 Jira에 Board를 생성하였다
고맙게도 FE 팀원분이 적극적으로 프로젝트에 Jira를 도입할 수 있도록 노력해주셨다.
Slack 연결
우선 기존에 활용하고 있던 Slack에 Jira Cloud 플러그인을 추가하면
위와 같이 메세지를 받을 수 있고
Slack 개인 프로필에서 현재 Jira에서 진행되고 있는 프로세스를 한눈에 볼 수 있다.
이후 Jira 프로젝트 내에서 Slack을 Integration 해주면 Slack과 연결을 완료할 수 있다.
이후 위와 같이 현재 존재하는 파트들에 대한 Issue Type을 새롭게 생성해주고
Slack의 각 Channel에 각 Issue Type에 대한 알림을 설정한다.
이후 Notion에 존재하던 기존의 Issue들을 Jira에 설정하면
성공적으로 Slack을 통해 메세지가 오는 것을 볼 수 있다.
Github 연결
이후 Github Issue와 Branch를 더 쉽게 생성할 수 있도록 하기 위해 위와 같이 Jira와 Github를 연동한다
성공적으로 연결되었는지 판단하기 위해 임의로 branch를 Jira에서 생성하고
Github Repository에서 확인할 수 있었다.
Scrum Board Management
Backlog
한 팀이 일정 기간 또는 일정 시간 안에 해야 할 모든 업무를 작성한 문서
이를테면 업무 개선 아이디어부터 제품 개발 관련 업무, 회고, 학습 리뷰, 사후 분석까지 모두 백로그에 포함됨
Scrum 보드
- Timebox(Sprint)단위로 Issue 관리를 하는 프로젝트
예) 2주 단위로 sprint planning을 수립후 수행하는 프로젝트 - JIRA Scrum 보드에는 전체 Issue가 아닌, Sprint내에 할당된 Issue만 보임
Kanban 보드
- Timebox없이 Issue 관리를 하는 프로젝트
예) 요청(Ticket)이 발생되면 최단시간(Lead time)에 처리해야하는 프로젝트 - JIRA Kanban보드에는 등록된 전체 Issue가 보임
우선 위와 같이 약 2주의 Sprint를 생성해주었다.
이후 각 Backlog에 있는 Issue들을 Sprint에 할당해주었고
전체 Sprint Board에서 한눈에 확인할 수 있었으며
이러한 내용을 Slack을 통해 팀원들에게 공유하였다.
https://velog.io/@juyeon/JIRA-%EA%B8%B0%EB%B3%B8-%EC%82%AC%EC%9A%A9%EB%B2%95-yjj2ykrk
https://medium.com/hgmin/devops-jira%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%9C-%ED%98%91%EC%97%85-ii-fe28e7ab829c
이후 팀원들과 이전보다 훨씬 원활하게 협업을 진행하며 프로젝트를 이어갈 수 있었다.
Git Team Convention
브랜치 명, 커밋 구조 등의 규칙을 정하는 것을 팀 컨벤션(관례)이라고 함
좋은 Github Convention의 조건
- 각자가 맡은 Task가 구체적으로 정리되어있어야 함
- 개발을 하다 겪은 문제들이 Github Issue로 잘 정리되어있어야 함
- Convention을 제대로 이해한 개발자는 원하는 정보가 어디에 존재할 지 알 수 있음
- 읽는 환경에 따라 정보가 달라지면 안됨 (OS에 따라 가독성이 변경되는 gitmogi 사용x)
Git Flow
git+flow는 'git에서 제공하는 브랜칭 기능을 활용한 변경 이력 관리 전략'
이 외에도 다음과 같은 전략이 존재하며, 팀 사이즈에 따라서 이를 선정하여 사용
github flow: git flow보다 훨씬 단순한 전략
gitlab flow: git보다는 단순하고 github flow보다는 복잡한 전략
`main`: 제품 출시 브랜치
`develop`: 출시를 위해 개발하는 브랜치
`feat/{기능명}`: 새로운 기능 개발하는 브랜치
`refactor/{기능명}`: 개발된 기능을 리팩터링하는 브랜치
`hotfix`: 출시 버전에서 발생한 버그를 수정하는 브랜치Branch 분류의 이유
협업 중 수정된 코드의 충돌을 방지하기 위함
위와 같은 상황을 서로 다른 두가지 작업이 다른 수정 사항이 존재하여 충돌이 발생하는 git merge conflict이 발생한다고 함
에러 발생 가능성 뿐만 아니라 불필요한 작업이 추가로 발생하고 개발자가 코드에만 집중하기 힘들어지기 때문에 이러한 병합 충돌을 피해야 함
따라서 각자 담당하는 작업 단위로 브랜치를 분할하여 중복되는 변경사항을 줄이는 전략인 git flow를 사용
위와 같이 develop, main의 공유되는 부분을 개발자가 직접 수정하지 않기 때문에 수정된 코드에서 충돌이 일어나지 않음
그렇기 때문에 하위 브랜치에 코드를 작성하고 상위 브랜치로 merge하며
이러한 특징을 'A successful Git branching model'에서는 분리되어 있지만 중앙에 집중되어 있다고 표현
Commit Convention
Commit 메시지 형식 :
[TYPE]: subject
body (선택사항)
// TYPE은 항상 대문자로 작성
// [TYPE]을 제외한 모든 커밋 내용에 한글 사용 가능Type:
// TYPE은 항상 대문자로 작성
[INIT]: 프로젝트 초기화
[FEAT]: 새로운 기능 추가
[UPDATE] : 기타 변경사항 (빌드 스크립트 수정, 기초적 로직 수정 등)
[FIX]: 버그 수정
[REFACTOR]: 리팩토링
[DOCS]: 문서 작업
[DESIGN]: 디자인 (UI 컴포넌트 생성 및 변경 등)예시:
[FEAT]: 회원가입 및 로그인 기능 추가
회원가입 기능, 로그인 기능 추가breakchange :
브레이크 체인지가 존재하는 커밋의 경우에는 제목 뒤에 '!' 추가
[FEAT!] 랭킹 점수 계산 공식 변경
// 변경(change)되었으니 잠깐 멈춰서(break) 이 커밋을 읽어주세요기존 개발하는 방식에 비해 많이 변경된 경우를 알리기 위한 표시
또한, 브레이크 체인지가 존재하는 경우 변경내용에 대한 설명을 body에 작성해야 함
footer :
[FEAT]: 회원가입 및 로그인 기능 추가
SMS, 이메일 중복확인 API 개발
// fotter
Resolves: #123
Ref: #456
Related to: #48, #45- optional하게 사용하고 이슈 트래커 ID를 작성
"Issue Tracker Type: #Issue 번호"형식으로 사용- 여러 개의 이슈 번호를 적을 때는
,로 구분
Issue Tracker Type :
Fixes: Issue 수정중 (아직 해결되지 않은 경우)
Resolves: Issue를 해결했을 때 사용
Ref: 참고할 Issue가 있을 때 사용
Related to: 해당 커밋에 관련된 Issue 번호 (아직 해결되지 않은 경우)PR Convention
## 요약(Summary)
// 작업한 부분에 대한 간단한 요약
## 변경 사항(Changes)
// 기존과 비교했을 때 해당 PR에서 변경된 내용
// 어떤 부분을 왜 수정했는지 작성
## 리뷰 요구사항
// 해당 PR에서 중점적으로 혹은 꼭 리뷰가 필요한 사항들
// 체크리스트 등 자유 형식으로 작성
## 확인 방법 (선택)
// 화면 스크린샷, 기능 구동 gif 등 작업 결과를 한 눈에 볼 수 있는 자료Issue Template
"[TYPE] 이슈 제목"
## 요약(Summary)
// 간단하게 현재 해결하고자 하는 문제나 추가 기능 요약
// 예) 새로운 회원가입 API 명세 정리 및 구현 준비
## 상세설명(Description)
// 이슈 상세 설명, 필요 시 요구사항, 고려사항, 디자인 목업 등 추가
// 예) 현재 회원가입 API의 중복 확인 로직이 누락되어 있어 개선이 필요
## 추가사항(Additional Context)
// 추가하고 싶은 내용이나 참고가 필요한 정보를 작성
// 외부 API(구글, 페이스북 등) 인증 연동 관련 참고
---
// Commit Convention의 footer 양식에 따라 작성
Fixes: #
Resolves: #
Ref: #
Related to: #Issue Type
[INIT]: 프로젝트 초기 세팅, 기본 구조 구축 등에 관한 이슈
[FEAT]: 새로운 기능 구현이나 추가 사항에 관한 이슈
[UPDATE]: 빌드 스크립트 수정, 기초적인 로직 또는 의존성 업데이트 등에 관한 이슈
[FIX]: 버그 수정에 관한 이슈
[REFACTOR]: 기존 코드 구조나 로직을 개선하는 리팩토링 이슈
[DOCS]: 문서 작업에 관한 이슈
[DESIGN]: UI/UX 디자인 및 컴포넌트 수정, 생성 등에 관한 이슈 Contributing.md
또한 위와 같이 전체 언제볼까? 프로젝트에 대한 Github Convention을 생성하였으며, 이를 Contributing.md에 기록해두었다.
