커뮤니케이션 및 협업 관리
커뮤니케이션 가이드라인
- 온라인 커뮤니케이션
- 줌 회의: 발언 시 오디오 겹침 방지를 위해 손들기 기능을 사용해요.
- 코어 타임: 모두 게더타운에 접속해서 작업해요.
- 연장 활동 시간: 코어 타임 이후에도 작업을 더 할 사람은 게더타운에 남아서 작업해요.
- 긴급 소집: 메인 소통 채널은 슬랙입니다. 필요 시 카카오톡, 정말 급하면 전화로 연락해요.
- 자유롭게 소통: 눈치 보지 말고 자유롭게 의견을 나눠요! 🙏
- 일정 지연 시: 일정이 밀릴 것 같으면 최대한 빨리 알려 주세요. (걱정하지 말고 편하게 알려주세요😳)
백로그 및 일정 관리
- 진행 상황 점검
- 매일 스크럼을 통해 진행 상황을 점검해요.
- 진행 상황 업데이트: 작업을 시작하면
In Progress로, 작업 완료 후 머지 시Complete로 GitHub Project에 상태를 업데이트합니다. - 일정 지연 시: 빠르게 도움을 요청하고 필요한 지원을 받아요.
- 해당 사안에 대해 적합한 사람을 지정하여 도움을 요청해요. 페어프로그래밍을 적극 활용할 수 있습니다 !
- 도움 요청 시, 요청하는 사람은 작업 맥락과 현재 고민 사항을 충분히 설명해요.
- 진행 상황을 슬랙에 간단히 남겨 기록하고, 해결 이후 반드시 문서화 해요.
- 전체적으로 진행이 더딜 경우
- 진행이 느리다고 느껴지면 자유롭게, 솔직하게 얘기해요 (고민이나 어려운 부분 포함)
- 다함께 리프레쉬 하는 시간을 가질 것을 요청하는 것도 권장합니다 !
- 리마인드: 일정을 상기시켜 주는 연락을 자유롭게 보낼 수 있어요.
코드 품질 관리
- 코드 리뷰: 간단한
LGTM(Looks Good To Me)만 달기 지양 🚫 - 진지한 리뷰: 코드 리뷰는 정성껏 🙆♂️
- 팀 성장 지향: 리뷰는 평가가 아닌,
우리의코드 품질 향상을 위한 하나의 소통 방식으료 여겨요. 함께 성장합시다! 🌱
Git 전략
- main 브랜치
- 하나의 배포 버전을 의미해요.
- 충분히 dev에서 디버깅을 거친 뒤, main으로 머지돼요
- dev 브랜치
- story 단위의 task들이 모두 완성되어 하나의 기능이 완성되면 충분히 디버깅을 거치고 main branch로 Pull Request를 보내요
- dev 머지됐을 때 클라이언트, 서버 모두 테스트를 자동화하여 실행해요
- feature 브랜치
- 노션에 있는 백로그에 설정한 feature-[story번호]-[task번호]-[fe/be]로 브랜치를 생성해요
- task 단위로 되어있는 작업들 단위로 브랜치를 생성해요
- task 기능 완료 후에 PR 날려 dev 브랜치에 머지해요
- 백로그에 없는 다른 기능을 추가하기 전에는 팀원과 상의 후 백로그에 task 번호를 추가하고 이슈를 생성한 뒤에 PR을 날려요
- 특정 기능에 대해 오류 수정의 경우 feature-[story번호]-[task번호]-[fe/be]-fix로 브랜치를 만들어요
- 이외의 필요한 브랜치는 팀원과 협의 후 결정해요
커밋 컨벤션
디폴트 포맷 : feat : 기능 완성
prefix : 커밋 메세지 + 본문 간략하게(선택)
| 타입 | 설명 |
|---|---|
test | 🧪 테스트 코드 작성 |
feat | ✨ 기능 추가, 타입 추가 |
fix | 🐛 버그 픽스 |
chore | 🧹 줄 삭제, 패키지 설치 등 서비스 기능에 영향을 미치지 않는 작업 (애매할 때 추천) |
docs | 📝 README 같은 문서 수정 |
refactor | ♻️ 리팩토링 |
style | 💅 스타일 속성 |
ci | ⚙️ CI 관련 변경 사항 |
perf | 🚀 성능 개선 |
remove | 🗑️ 파일 삭제 |
rename | 🔄 파일 이름 변경 |