팀 undefined 그라운드 룰

👨‍👩‍👦‍👦 팀 문화

💡 우리 모두가 리더다.

리더가 있더라도, 모두가 참여하며 수평적으로 의사결정함. 리더라는 포지션은 말 그대로 책임과 리딩을 위함.
의사결정의 논리와 근거에 대해 팀 모두가 알아야함.
작업과 학습에 대해 적극적으로 공유.
초기에는 공유하는 시간이 많고, 이후에 서로 익숙해지면 개인 작업 (공유는 필수)
프로젝트 기간의 과정도 결과가 된다. 그러나 완결성이 완성도보다 중요하다.
출근했다고 생각하면서 코어타임에 임하기

🤼 역할과 책임

[팀 undefined 역할 (2022.11.07.)](https://www.notion.so/undefined-2022-11-07-35c26baeac36434cbe2e3cc58454575a)

🚷 최소한의 규칙

이것만큼은 지켜요

코어타임 : 10시 ~ 19시
점심시간 : 12시 ~ 13시 (일정 따라서 변경)
게더타운이 코어타임 중 회사라고 생각하기
상대방을 생각하며 말하기
공지 & 비상 채널 읽으면 체크표시
트러블 슈팅이 있었다면 문서화 & 다른 사람들은 해당 문서 읽어보기
(질문이 있다면 손을 들고 기다려요)

개발 규칙

코드 치기 전에 하려고 하는 것을 적기. 이후 작업이 종결되었을 때, 작업 내용을 공유하기 (로그를 남기는 것에 포커싱)
이후 이 내용을 정리하여 모두가 작업 내용을 이해할 수 있도록 함. (이슈, 학습 사항, 레퍼런스 등)
읽을 사람을 생각하며 코딩하기 & PR 날리기 & 커밋 메세지 쓰기
30분 고민해보고 한 명에게 물어보기, 이후 그 사람도 모르면 전체 소집

⇒ 2명이상이 한 트러블 슈팅과 혼자한 트러블 슈팅은 따로 분류하기
💡 우리 undefined의 트러블 슈팅 분류 기준
🐶 도지 하나 : 혼자 고민한 문제 🐶🐶 도지 둘 : 둘이서 고민한 문제 🐶🐶🐶 도지 셋 : 다같이 고민한 문제

시간대별 할 일 (2022.11.07.)

데일리 스크럼 (30분)

전 날 한 일

데일리 코드리뷰 (1시간)

가볍게 코드리뷰
전체 코드리뷰가 아니라, 팀원들의 코드 가독성 맥락 맞추기에 중점
가독성을 위주로 코드리뷰 한다.

Feature List 갱신 (30분)

전날의 이슈와 스크럼을 토대로 Feature List 갱신

개발

갱신된 Feature List를 반영하여 개발하기

코어타임 마무리 스크럼 (30분)

하루 정리가 아니라, 중간 체크포인트 개념
오늘 개발 사항 간단히 공유 (+ 2명 이상 모였던 내용이 있었음을 나누기)

⏰ 일정 (2022.11.07.)

일정표

[Week 1]
[Week 2-5]
[Week 6]

Day01 ~ Day04 코어타임

오전

10:00 ~ 10:30 : 데일리 스크럼 (커뮤니케이션, 일정 관리 - 코드 제외)

10:30 ~ 11:00 : 데일리 코드리뷰 (가독성에 중점)

11:00 ~ 12:00 : Feature List 갱신

12:00 ~ 13:00 : 점심시간

이슈
- 성현님 : 파편화된 시간 사용이 좋다.
⇒ 관경, 대호 : 파편화된 시간은 루즈해집니다.

⇒ 성현님께서 코어 이전 시간에 사용하시기로 함.

오후

13:00 ~ 17:00 / 19:00 : 개발

16:30 / 18:30 ~ 17:00 / 19:00 : 마무리 스크럼

17:00 ~ 19:00(마스터 클래스) : 마스터 클래스

코어타임 이후

슬랙 비상 채널에 올라오는것에는 대답하기

🗣️ 커뮤니케이션 방법

커뮤니케이션 수단

🌃 접속 : 게더타운

유대감, 연결감을 위해서 접속하기

🗣️ 주요 회의 : Zoom

음질이 가장 깔끔함.

📣 공지 : Slack

알람을 켜놓기

그룹프로젝트_web17 : 공지

undefined : 잡담방

📁 문서 저장소 : Notion

회의록
각종 문서 저장
회고 등등

이슈 관리 도구 : Jira + Github (2022.11.07.)

필요성, 논의의 이유

Github만의 이슈 관리가 불편했다. (데이터 시각화 부족)
새로운 기술에 대한 학습 vs 거기서 나오는 코스트
Jira에 대한 흥미

후보 1. Jira

장점

개인적으로 써보고 싶다.
현업에서 많이 쓰니 사용경험 해보고 싶다.
Jira를 사용하는 프로세스에 대해 배울 수 있을 것 같다.
Github과 연동이 좋다.

단점

배워야한다.
읽을 사람이 알아야할 것.

후보 2. Github

장점

프로젝트 볼륨에 맞다.
연동 필요 없이 편리하다.
보여주기도 편하고, CI / CD로 이어졌을 때도 좋을 것 같다.

단점

시각화가 Jira보다는 덜하다.

결론 (2022.11.07.)

Jira와 Github를 연동해서 쓴다.
~~읽을 사람들을 생각해서 Github으로 결정하되, Issue를 관리하는데에 있어서 필요한 도구들(Project 탭, wiki, Issue 자동 Close 등)을 이전보다 적극활용하기.~~
~~Trello : Jira와 이유가 겹치고, Jira가 더 매력적~~
~~Excel : 더 나은 도구가 많다.~~

문서 양식 & 템플릿 (우선순위 하)

‘괜찮은’ 양식이나 템플릿을 하나로 만들면 읽는 리소스를 획기적으로 줄일 수 있음. 코딩 컨벤션이 있는 코드와 아닌 코드의 차이와 유사함.

협력 트러블 슈팅 템플릿 (2명 이상이 트러블슈팅, 하면서 추가)

문제
카테고리 (프론트엔드, 백엔드, 네트워크 등등)
둘 다 혼란에 빠진 부분
해결 방법 & 의사 결정 (정책을 바꾼 경우)
해결한 뒤 다시 본 문제

PR 템플릿

커밋 템플릿

학습 정리?

회고?

🪣 Github 사용 규칙 (우선순위 중)

Branch 관리 전략 : git flow

git flow (feature list 나오면 세부적으로 정하기)

main : release 되는 브랜치

release : demo 버젼 확인되는 브랜치

dev : Day별로

feature : dev에 merge되는 기능단위

의사결정과정

main 브랜치는 배포버전단위로만 관리되도록

dev는 정해놓은 기능 단위 (여러 feature)

feature는 커밋 단위
~~trunk based~~
gitflow
의사결정과정

⇒ 하나의 브랜치를 안정적으로 쓰기에는, 아직 그 정도로 괜찮은 테스트 코드를 처음부터 쓸 수 있을지 모르겠다.

⇒ git flow로 선정

Issue 규칙

이슈는 feature, bug, refactor
의사결정과정

어떨 때 이슈를 발행해야할까?
- feature list가 나왔을 때 - 다 같이(기획단계)
- feature lsit가 수정될 때 - 다 같이(진행단계)
- bug - 혼자 : 올리고 공유하기
- refactor - 혼자 : 올리고 공유하기

Commit 규칙

커밋 예시

[feat] 채팅 기능 구현 (#1)
[style] 세미콜론 제거

커밋 시 규칙

force push 금지
main 브랜치를 rebase merge 금지
한 문장으로 표현 가능한 단위로 commit

커밋 타입

env (environment) : 환경 설정, 의존성 추가
feat (feature) : 기능 구현
fix (bug fix) : 버그 수정 - 기능의 수정과 함께 코드를 변경하는 것
refactor : 코드 리팩토링 - 기능상의 수정없이 코드를 변경하는 것. 코드 내용이 바뀌는 것.
style (사용 후 변경) : 간단한 코드 스타일링을 포함함. import해놓고 안썼다거나, 줄바꿈 등. 리팩토링과 별도로 코드 스타일만 변경. 넘겨도 된다.
chore (maintain) : 기타 잡다한 일. 폴더, 파일 삭제 등.
test (when adding missing tests) : 테스트 코드 작성
docs (documentation) : 문서

커밋 메세지 내용

한글로 쓰기.
코드 구성 요소는 영어로 쓰기.

참고자료

[좋은 git commit 메시지를 위한 영어 사전](https://blog.ull.im/engineering/2019/03/10/logs-on-git.html)

PR 규칙

PR 발생 규칙

Day별로 dev 브랜치 merge
feature 브랜치 하나가 닫히면 dev에
feature 병합 PR의 최대 길이나 기준을 정하자
- 의사결정과정 (명세서가 나온다음 추후 논의)
  
  PR이 크면 리뷰도 어렵고, conflict 나오는 양이 많아질 것 같으니 PR 기준을 정하자.
  
  feature 단위를 지금 정해야할까? ⇒ 명세서가 나온다음에

PR 병합 규칙

생성되면 다음날 00시 이전에 코멘트 or 리뷰
모든 사람이 확인해야 merge를 원칙

PR 작성 규칙

읽는 사람이 코드의 맥락을 이해할 수 있도록 PR을 작성하기
해당 PR에 담긴 코드에 대한 설명을 작성한다.
작업 배경 (Issue보다 세세하게, 왜 이렇게 접근을 했는지)
코드에 대한 설명 ⇒ 이후 PR 보면서 추가한다.
필요한 경우 작업물이나 결과물 시각 자료 (스크린 샷, ERD, UML 등등…)
트러블 슈팅 링크

## 작업 배경

- 작업 배경입니다.
- 이런 저런 이유로 이런 방식으로 접근하였습니다.

## 작업 내역

- ~~ 파일을 처리하였습니다.
- 작업 내역 1입니다.
	- 이런 저런 플로우로 데이터가 처리됩니다.
- 작동 스크린샷입니다. (optional)

## 코드 설명

- 이런 이런 플로우로 데이터를 처리합니다.

## 트러블 슈팅

- 트러블 슈팅 내역입니다.
	- [트러블 슈팅 노션 링크 1](https://notion.so)
	- [트러블 슈팅 노션 링크 2](https://notion.so)