⛳ 그라운드 룰 결정 회의 - boostcampwm-2022/web33-Mildo GitHub Wiki

개요

  1. 일시 및 장소 : 11.08.(화) 10:30 ~ 11:40 및 13:00~16:00, zoom 회의실
  2. 참여자 : 전원
  3. 목적 : 업무 방식과 생활 방식에 대한 그라운드 룰 결정
  4. 회의 중요도 : 중

주요 고려 사항

  • 본인의 프로젝트 경험이나 부스트캠프 경험을 토대로 아이디어 도출
  • 이전 기수에서 결정한 내용 참고
  • 확실하게 정할 수 있는 것만 명시하고, 향후에 새롭게 필요한 규칙은 업데이트의 방식으로 추가

개별 멤버 의견

상준

  1. 업무 방식
    • 코어 시간을 정하고 게더타운에서 함께 페어프로그래밍 진행
      • 일정 시간이 지나면 각 페어가 진행했던 작업과 파트너를 변경
      • 상대 페어의 코드에 대한 명확한 이해를 위한 과정 필요
    • 업무의 중요도를 상·중·하로 나누고 중요도에 따라 다른 권한 부여
      • 업무는 쪼개거나 합칠 수 있으며, 변경 사항은 회의를 통해 결정
    • 중요도 상은 무조건 코어 시간에 함께 수행하고, 중·하는 이외의 시간에 개인이 할 수 있음
      • 다만, 미리 팀원들에게 작업 수행 여부를 알리고 다음날 데일리스크럼에서 내용 설명
  2. 생활 방식
    • 코어 시간에는 모두가 같은 공간에 상주
    • 코어 시간 이외에는 팀원들에게 통보 후 원하는 기능 개발
    • 모두가 동의하는 경우에 PR merge 작업
    • 코어 시간 참여가 불가능한 경우 팀원들에게 통보

한빈

  1. 업무 방식
    • 회의 및 기능 개발을 중요도 별로 나누기
      • 상 : 하루를 투자하더라도 정확한 의사 결정 및 기능 구현
      • 중 : 제한된 시간을 정하고 의사 결정 및 기능 구현
      • 하 : 선택적으로 필요한 의사 결정 및 기능 구현
  2. 생활 방식
    • 공식 문서에 멤버 호칭은 그냥 이름만 적기
    • 회의 시간 중간에 휴식 시간 꼭 가지기
      • 50분 회의, 10분 휴식

현정

  1. 함께 논의하고 싶은 것
    • 개발 시간 정하기
    • 온라인, 오프라인 미팅 규칙 정하기
      • 미팅 장소 및 시간
      • 지각 관리
    • Github 이슈를 사용할 경우 템플릿
    • Github Branch 전략
      • 개인적으로 dev-feature Branch 선호
  2. 같이 했으면 좋은 것
    • 15분 이상 고민하지 말고 생각 공유하기
    • 개발을 끝내고 짧은 시간이라도 회고 시간 가지기
    • 모든 결정에 대해 이유를 생각하고, 문서로 작성하기
    • 하루 업무를 구체적으로 정하기
    • 학습할 내용을 생각하며 계획
    • 주말에는 휴식 시간 가지기

윤우

  1. 개발 방식
    • 테스트 코드 작성 방식 학습 및 적용
    • 7시까지 코어 시간을 정하여 개발 집중하기
  2. 생활 방식
    • 낮잠을 잘 경우 팀원들에게 알려주기
    • 주말에는 휴식 시간 가지기

향후 논의가 필요한 내용

  1. 협업의 개념과 방식에 대해 멤버들 사이에 의견을 정해야 함
  2. 페어 프로그래밍을 통해 각자의 의사 결정이나 코드 내용에 대해 더 자세하게 이해할 수 있음
  3. 페어 프로그래밍만이 협업의 전부라고 볼 수 없으며, 의사 결정 과정을 함께 하거나 코드리뷰를 통해 충분히 협업을 할 수 있음
  4. 실제 코딩을 하는 단계에서 조금 더 논의해보고 정하기로 결정

그라운드 룰

업무 방식

작업 시간

  • 코어 작업 시간
    • 오전 : 10:30 ~ 12:00, 오후 : 13:00 ~ 19:00
    • 중요도가 높아 함께 작업해야 하는 기능을 우선적으로 구현
    • 오전은 데일리스크럼에 따라 변동, 오후는 마스터클래스에 따라 변동
  • 선택 작업 시간
    • 오후 : 19:00 ~ 24:00
    • 코어 작업 시간에 수행하지 못한 기능 구현 및 문서 작업
    • 중요도가 상대적으로 낮아 각자 처리할 수 있는 기능 구현이나 리팩토링 등 수행
      • 각자 기능을 구현할 시 팀원들의 동의 필요
      • 각자 구현한 기능은 데일리 스크럼에서 팀원들과 코드리뷰 진행
    • 개인의 스케줄에 맞춰 유동적으로 시간 사용
      • (선택) 원활한 의사소통을 위해 선택적으로 모각코 진행
  • 기타 사항
    • 시간이 정말로 모자란 경우에만 평일 오전 2시까지 작업 수행
      • 배포, 필수 기능 구현 등
    • 선택 기능을 수행하지 못한 경우에는 기능을 줄이는 것 고려

Github 활용

  • 이슈는 템플릿을 만들어 사용
  • 프로젝트 및 마일스톤은 주 단위로 생성
  • Branch 전략
    • main - (hotfix) - (release) - dev - feature
    • main : 가장 위에 위치하는 마스터 branch
    • release : 배포 시 사용하는 branch, 테스트 작업을 통해 에러 확인 및 디버깅
    • hotfix : 배포 후 발생한 에러 해결을 위한 branch
    • dev : 개발을 위한 branch
    • feature : dev branch에서 파생되며, 특정 기능을 개발하기 위한 branch
  • PR, merge 방식
    • 반드시 PR을 리포지터리에 보내고 merge 수행
    • 팀원들과 코드리뷰 후 merge 수행
  • 위키
    • 데일리스크럼은 위키에 작성
    • 위키 템플릿을 만들어 사용

생활 방식

온/오프라인 미팅 진행 방식

  • 온라인 미팅
    • Discord 활용
    • 50분 미팅, 10분 휴식으로 순환
  • 오프라인 미팅
    • 작업에 부담이 되지 않도록 필요 시에만 진행
    • 진행 시 판교역 주변 카페 이용

출결 관리

  • 코어 작업 시간에 부재중(낮잠, 개인 업무 처리 등)일 경우 멤버들에게 통보
  • 지각 횟수 1위는 프로젝트 마무리 후 커피 사기
    • 1분이라도 늦을 경우 지각으로 처리
    • 사전에 통보 했으면 면제
    • 정규 시간 및 휴식 시간 모임 모두 포함

기타 팀 규칙

  • 그라운드 룰 변경 및 추가 사항이 생기면 다음 날 데일리스크럼에서 바로 논의
  • 공식 문서에서 멤버의 호칭은 이름만 적기
  • 개발 후 팀 회고 시간 가지기
  • 15분 이상 고민하는 경우 팀원들과 생각 나누기
  • 모든 결정에 이유를 고민해보고, 이를 문서화
  • 기능을 나눠서 코딩하게 될 경우 같이 논의하기