그라운드 룰 2.0

그라운드 룰 2.0

저희 끼리 정한 그라운드 룰이 생각보다 부족한 점이 많았습니다. 그중 특히 느꼈던 점은 그라운드 룰이 이전과 다르게 계속 바뀌거나 지켜지지 않는 일들이 많았던 것이였습니다. 그래서 저희가 해야할 일들을 다시 업데이트한 그라운드 룰 2.0 버전으로 새롭게 기록을 해두어서 이전과 바뀐 점에 대해서 제대로 명시해야함을 느꼈습니다.

또한, 변경사항을 제대로 명시하여 굳이 변하지 않은 그라운드 룰을 매번 지켜볼 필요가 없도록 하려고 합니다.

추가된 변경사항

• 문서화 계획 추가 : 노션만 사용하기
• PR 룰 수정 : dev 브랜치에만 전원 Approve
• 데일리스크럼, 데일리 회의 관련 룰 명시
• 스프린트 항목 추가 : 스프린트 마스터, 스프린트 할당하는 시간, 마감 계획, 태스크 분배 관련 룰 추가
• ZEP 참여 시 자리비움 등일 때에는 회의 불가능한 상태임을 명시
• Conflict 머지 시 책임자 정하기, 머지 책임자 정하기

2.1 추가 사항

• 앞으로 태스크 분배 시 태스크 번호도 할당 하여 소통할 때 편리하도록 합시다.
• 그리고, 태스크와 관련된 이야기는 깃허브 이슈에 적힌 내용을 1순위로 정합니다.
  • 얘기하다가 나온 정보도 깃허브 이슈 에 없으면, 전달이 제대로 되지 않기 때문입니다.

📖 그라운드 룰

그룹 내 지켜야할 규칙입니다

기록을 먼저 하기

• 노션을 먼저 쓰고, Github wiki 에는 그룹 프로젝트 이후 AI 를 활용해 문서를 정리하는 식으로 문서를 옮기기
• 생각이 나는대로 바로 적어보기
• 각자 찾아본 상황, 문제 해결 과정을 서로 공유하기
• 개발 일지를 각자 적어보기
  • 상대방이 리뷰하기 쉽게
  • 자소서 쓸 때에 참고할 자료로도 사용할 수 있게

GitHub PR 룰

• dev 브랜치로의 병합은 만장일치로 Approve 하기
  • 그 외 브랜치 병합은 자유롭게 리뷰어 설정 하기
• 프론트, 백 분야에 상관없이 코드 리뷰하며, 설령 의견이 없더라도 간단한 Comment 남겨주기
• 서로 분야가 달라도, 해당 코드가 무슨 기능인지는 알기

Conflict 해결 규칙

Merge는 Approve 가 끝나면 아무나!

• 저희 팀에 일단 누가 merge 를 할 지는 정하지 않았습니다.
• 중요 브랜치의 경우, Approve 를 전원이 해야하므로, merge가 가능한 상황이 된다면 상관 없다고 판단하였습니다.
  • merge 할 브랜치가 여러개인 경우 Conflict 나지 않는 선에서 계속 머지해주시면 됩니다.

Conflict 는 당사자끼리

• 다만, merge 작업 중 Conflict 가 발생한다면, 작업 당사자끼리 해결하도록 합니다.
• 작업 당사자들끼리 작업이 완료되었을 경우 merge 를 합니다.

데일리 스크럼

• 시작하기 전에 핀볼로 진행자 뽑기
• 추가로 매일 매일 TMI 공유하기
• 데일리 스크럼은 15분 이하로 하고, 10분 휴식 후 데일리 회의 등을 시작할 수 있도록 합니다.

의견 충돌 조율 방법

1. 토론
   1. 멘토님 의견 : 시간을 정해두고 하는걸 추천
2. 토론으로 결정이 나지 않는다면 다수결
3. 다수결에서 2:2 상황으로 진행된다면 슈퍼패스를 많이 쓰는 쪽

슬랙 허들 이용

• 학습하거나 구현할 때는 슬랙 허들에서 함께하기

팀 회고 방식

• 회고는 KPT 방식으로 개선해나가기

🏃 스프린트 조정하기

팀의 스프린트 타임

• 팀의 스프린트 타임은 월 - 목요일 입니다.
  • 스프린트를 기간 내 완료하지 못했을 경우, 금 - 일 요일을 활용합니다.
• 스프린트 타임 내에 주어진 스프린트 업무를 수행하며, 날짜 배치를 유동적으로 개인 일정에 맞게 설정합니다!
• 스프린트 타임은 멤버 모두가 강제로 참여하는 시간대가 아닙니다.

스프린트 분배 날짜

• 에픽 을 정하는 스프린트 날짜는 목요일 오후 5시 로 정합니다.
• 태스크 분배 는 월요일 오전 10:30 ~ 오후 12:00 때 하며, 그 전 동안은 각자 공부, 휴식을 합니다.

태스크 마감 계획 작성

• 태스크는 이슈가 너무 많아 관리가 어렵습니다. 자유롭게 작성합니다.
• 일단은 스토리 기준으로 마감 날짜를 정합니다.
• 먼저 시작하는 사람이 시작 시간으로 하고 마지막에 끝내는 사람이 끝나는 시간으로 정하기
• 앞으로 태스크 분배 시 태스크 번호도 할당 하여 소통할 때 편리하도록 합시다.
• 그리고, 태스크와 관련된 이야기는 깃허브 이슈에 적힌 내용을 1순위로 정합니다.
  • 얘기하다가 나온 정보도 깃허브 이슈 에 없으면, 전달이 제대로 되지 않기 때문입니다.

👥 회의 방식

🔥 팀의 회의 진행에 있어서 체력적으로 낭비가 되지 않도록 회의 문화를 정하려고 합니다!

데일리 회의 규칙

• 스크럼 이후 다같이 회의를 할 수 있는 시간이 있습니다.
• 아무나 제안 가능하며, 회의록 을 반드시 작성해야합니다!
• 데일리 프로젝트 회의는 12시 까지 진행합니다.
  • 그 이후로 진행되는 회의는 쉬는 시간을 갖고 자유롭게 진행합니다.

기본 회의 플랫폼 : ZEP

Note

ZEP 링크

https://zep.us/play/lpp9Qd

비밀번호 = ******

팀의 코어 타임

• 팀의 코어타임은 반드시 회의나 협업을 할 수 있는 시간대 로, 스프린트 기간과는 다릅니다!
• 팀의 코어타임은 기본적으로 목요일 오후 로, 코드 리뷰 를 통해 모두가 스프린트 기간 동안 작업한 작업물들을 확인할 수 있어야합니다!

🏉 팀원 상태 공유(중요)

• 각자 최소한의 상태를 공유하면서, 회의 가능한 상태인지 공유하는게 중요하다고 생각했습니다.
• 상태 공유를 하지 않는다면 쉬운 협업이 되지 못할 것이라고 생각합니다.

1. ZEP 에 참여한 상태 : 회의 가능

• 기본적으로 프로젝트와 관련된 작업 을 수행중일 때에는 ZEP 에서
• ZEP 에 미참여 상태는 기본적으로 최소한의 소통도 불가능한 상태 라고 간주합니다.
• ZEP에 있더라도 자리비움, 식사, 외근상태일 때는 회의 불가능인 상태입니다!
• 회의라고 해도 단순 의견 공유(채팅)도 회의가 될 수 있으므로 적극적으로 참여 부탁합니다…!

2. ZEP 에 참여하지 않는 상태 : 회의 불가능

• 휴식, 수면, 외부 일정 등으로 인해 프로젝트 작업에 참여하지 않는 상태를 뜻합니다.
• 개인적인 휴식 중일 때에도 자유롭게 나가셔도 좋습니다..!
• 최소한의 소통(채팅) 이 가능하면 되도록 ZEP 에 접속해주세요…!

3. 스프린트를 수행하지 못할 경우

• 스프린트 기간 동안 주어진 업무를 다 하지 못할 경우, 미리 팀원에게 슬랙으로 공유할 수 있도록 합니다.