Team Rules
프로젝트 진행 시 꼭 지켰으면 하는 것들!
팀 규칙
1. 자신의 상황을 공유하자.
맡은 역할이 생각보다 오래걸릴 것 같거나 어렵다면 혼자 안고가지 말고 공유해서 방법을 찾는 것이 필요할 것 같다.
2. 연락을 잘하자.
바로 답하지 못하는 경우에는 이모지 등 꼭 반응이라도 남겨두면 좋을 것 같다.
3. 불만이 있으면 짧게 고민하고 털어두자.
솔직하게 이야기해도 아무도 뭐라하지 않으니 터놓고 얘기하면 좋을 것 같다.
4. 라고할뻔 금지어.
!important
Meeting
스크럼
🥝 주기
하루에 1-2번 (시간 30분)
하루에 1번도 괜찮을 것 같다
🥝 내용
현재 자신이 맡은 기능 개발이 어느 정도 진행되고, 어떤 문제가 있었는지 공유하기
- 개인의 개발일지를 기반으로
매일 매일 자신이 개발한 내용을 꼼꼼하게 정리하는 것이 필요할 것 같다.
회고
🥝 주기
프로젝트 중간 / 최종 → 총 2번 진행 (30분)
🥝 방식 (추후 논의)
- KPT
- Keep: 지속할 것
- Problem: 문제가 된 것
- Try: 다음에 시도할 것
코드 리뷰
- 모두가 한 사람의 코드를 리뷰할 필요는 없다. 두 명의 approve 받으면 리뷰 x
방식: 뱅크샐러드 pn룰 적용
커뮤니케이션 비용을 줄이기 위한 Pn 룰
우리는 상대방과 대화를 할 때, ‘말’이라는 언어적 표현 외에도 ‘표정’, ‘손짓’ 등의 비언어적 표현도 적극적으로 활용합니다. 온라인으로 코드 리뷰를 진행하는 경우 ‘글’ 로만 생각, 감정을 포함한 의견을 전달하기 때문에 전달력이 상대적으로 부족하고, 이로 인해 가벼운 농담이 상대방에게 진지한 이야기로 전달되는 상황이 연출되어 Blocker 가 될 수도 있습니다.
뱅크샐러드 기술 조직은 코드 리뷰의 코멘트에 Pn 룰을 사용하여 리뷰어가 코멘트를 강조하고 싶은 정도를 표현합니다.
- P1: 꼭 반영해주세요 (Request changes)
리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.
- P2: 적극적으로 고려해주세요 (Request changes)
작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.
- P3: 웬만하면 반영해 주세요 (Comment)
작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.
- P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.
- P5: 그냥 사소한 의견입니다 (Approve)
작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.
FYI) Pn 룰은 뱅크샐러드에서 성장하는 회사에서 커뮤니케이션은 가장 큰 비용이라는 문제의식에서 이를 해결하기 위한 문화를 배경으로 탄생했습니다. Pn 룰은 코드 리뷰 외에도 슬랙 등 텍스트로 커뮤니케이션을 하는 곳에서도 활용하고 있습니다
코드 리뷰 방식과 기간, 시간 등
인원 선정 방식..고민
PR 당 2명
강제성은 없되, 최소 1-2인 이상의 approve가 있어야 머지할 수 있게
자율적으로 리뷰를 하되, 회고 시에 리뷰를 너무 하지 않았을 경우 자진 신고
Git
project, milestone을 사용해보는 것
pr과 slack을 연동하여 알림 가도록
branch strategy
이슈 단위로 브랜치 → dev 브랜치 → main 브랜치feature/#4-add-login-ui (다 소문자로)
라벨/#이슈번호-내용
참고
처음에 default를 dev로 해두고, 이후에 main으로 default를 옮기기
commit convention
message
(헤더) prefix: 커밋 메세지
(바디) #이슈번호
commit message prefix
- feat: 기능 추가, 삭제, 변경
- fix: 버그 수정
- docs: 문서 추가, 삭제, 변경
- chore: 패키지 매니저 설정, yarn 모듈 설치 등
- refactor: 코드 리팩토링 ex) renaming a variable
- rename: 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
- remove: 파일을 삭제하는 작업만 수행한 경우
- style: 코드 형식, 정렬, 주석등의 변경 ex) 세미콜론 추가
- etc: 위에 해당하지 않는 모든 변경 ex) 빌드 스크립트 수정, 패키지 배포 설정 변경
- test: 테스트 코드 추가, 삭제, 변경 등
참고
- lint-staged
- @commitlint/config-conventional
- commitzen
- git을 좀 더 익숙해졌을 때 사용하기
issue
제목:
로그인 UI 생성
로그인 기능 개발
로그인 UI 수정
검색 기능 구현
Issue_템플릿.md
## 📃 작업 내용 (작업할 내용에 대해 간단히 작성)
label 목록
crossBrowsing, html/css는 생략해도 좋을 것 같다.
pull request
제목: 브랜치 명 그대로 (feature/#4-add-login-ui)
PR_템플릿.md
## 📌 이슈 번호 (링크 달기) ## 👩💻 작업 내용 (자세히 쓰기 - 이미지가 필요한 경우 첨부하기, 영상도 ok)
협업 툴
소통
슬랙 팀 채널 (부끄러워하지 않기)
스크럼
디스코드
개발일지, 자료공유
노션(유리팀)
디자인
피그마
회고록
피그잼
