Skip to content

그라운드 룰

Jump to bottom
ez edited this page Jan 6, 2025 · 1 revision

코어타임

  1. 코어타임(13:00~18:00)에는 게더타운 접속, 게더타운으로 소통 가능할 것

  2. 코어타임 외에는 슬랙으로

  3. 불참 시, 팀원에게 알리고 일정 캘린더 업데이트

    전날 데일리스크럼에서 팀원에게 리마인드 시켜주기

데일리스크럼

  • 매일 오후 1시 데일리 스크럼

    <aside>

    1. 어제 한 일, 학습
    2. 오늘 할 일
    3. 논의할 일 </aside>

  • 진행자

    월 화 수 목 금
    조배경 민경준 박경희 유성민 민서진

    • 상세 작성

      • 팀 빌딩 결과는 프로젝트 저장소 wiki에 문서화합니다.

        • 이후 대표 1명이 Slack에 3줄 요약 하여 링크와 함께 전체 공유합니다.
        • 추후 지속 업데이트 가능합니다.

        <aside>

        • 팀의 성장 목표를 세웁니다.
          • 각자 어떤 목표를 가지고 CS 리팩토링을 진행하는지 공유합니다.
          • 우리 팀의 프로젝트를 고려했을 때 무엇을 시도해보고 싶은지 이야기 나눠봐도 좋습니다.
        • 그라운드 룰을 세웁니다.
          • 원활한 협업을 위해 다함께 지켜야 하는 최소한의 기준입니다.
          • 팀마다의 개성있고 재미있는 그라운드 룰이 나오기를 기대합니다.
        • 프로젝트 선택을 확정합니다.
          • 어떤 이유로 해당 프로젝트를 리팩토링 하려고 하는지 충분히 논의하고 합의합니다.
          • 명확한 이유가 있을수록 남은 기간을 보내기 좋을 것 같습니다. </aside>

      전체 리팩토링 계획을 수립해 프로젝트 저장소 wiki에 작성합니다. (~1/7, 화) ⇒ 박경희

      • 1주차 계획은 1/7(화)까지 업데이트합니다.
      • 2, 3주차에는 월요일에 주간 계획을 수립하고 업데이트 합니다.
      • wiki 작성 이후 대표 1명이 Slack에 요약 하여 링크와 함께 전체 공유합니다.

      팀 회고(금) ⇒ 조배경

      • 회의록으로 작성하여 프로젝트 저장소 wiki에 업로드합니다.
        • 주어진 1시간이 부족하다면 추가적인 시간을 내어 내용을 보충합니다.
        • 마스터 클래스 및 멘토링에서 받은 질문이나 피드백을 추가해도 좋습니다.

      릴리즈 노트(비동기)

      • 한 단위의 개선 및 리팩토링 작업이 끝날 때마다 프로젝트 저장소 wiki에 작성합니다.
        • wiki 작성 이후 대표 1명이 Slack에 요약 하여 링크와 함께 전체 공유합니다.

      학습정리와 회고(개인)

      • 구글 스프레드 시트에 업로드하고, Slack으로 공유합니다. (바로가기)

    코드리뷰

    1. 분야 가리지 않고 적극적으로 하기(최소 1명)

    2. 리뷰 할 때 Pn 룰을 사용하여 리뷰어가 코멘트를 강조하고 싶은 정도를 표현하기

      • P1: 꼭 반영해주세요 (Request changes)

      리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

      • P2: 적극적으로 고려해주세요 (Request changes)

      작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

      • P3: 웬만하면 반영해 주세요 (Comment)

      작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

      • P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)

      작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

      • P5: 그냥 사소한 의견입니다 (Approve)

      작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

      출처: https://blog.banksalad.com/tech/banksalad-code-review-culture/

    휴식

    1. 회의

      50분 회의, 10분 휴식

    2. 개인 작업

      자율

    ## 코어타임

    1. 코어타임(13:00~18:00)에는 게더타운 접속, 게더타운으로 소통 가능할 것

    2. 코어타임 외에는 슬랙으로

    3. 불참 시, 팀원에게 알리고 일정 캘린더 업데이트

      전날 데일리스크럼에서 팀원에게 리마인드 시켜주기

    데일리스크럼

    • 매일 오후 1시 데일리 스크럼

      1. 어제 한 일, 학습
      2. 오늘 할 일
      3. 논의할 일

    • 진행자

      월 화 수 목 금
      조배경 민경준 박경희 유성민 민서진

    문서화 담당

    팀 빌딩 (~1/6, 월) 유성민
    전체 리팩토링 계획(매주 월 업테이트) 박경희
    팀 회고(매주 금 업테이트) 조배경
    릴리즈 노트(비동기) 작업 별 참여 인원
    학습정리와 회고 개인

    • 상세 작성

      • 팀 빌딩 결과는 프로젝트 저장소 wiki에 문서화합니다.

        • 이후 대표 1명이 Slack에 3줄 요약 하여 링크와 함께 전체 공유합니다.
        • 추후 지속 업데이트 가능합니다.
        • 팀의 성장 목표를 세웁니다.
          • 각자 어떤 목표를 가지고 CS 리팩토링을 진행하는지 공유합니다.
          • 우리 팀의 프로젝트를 고려했을 때 무엇을 시도해보고 싶은지 이야기 나눠봐도 좋습니다.
        • 그라운드 룰을 세웁니다.
          • 원활한 협업을 위해 다함께 지켜야 하는 최소한의 기준입니다.
          • 팀마다의 개성있고 재미있는 그라운드 룰이 나오기를 기대합니다.
        • 프로젝트 선택을 확정합니다.
          • 어떤 이유로 해당 프로젝트를 리팩토링 하려고 하는지 충분히 논의하고 합의합니다.
          • 명확한 이유가 있을수록 남은 기간을 보내기 좋을 것 같습니다.

      전체 리팩토링 계획을 수립해 프로젝트 저장소 wiki에 작성합니다. (~1/7, 화) ⇒ 박경희

      • 1주차 계획은 1/7(화)까지 업데이트합니다.
      • 2, 3주차에는 월요일에 주간 계획을 수립하고 업데이트 합니다.
      • wiki 작성 이후 대표 1명이 Slack에 요약 하여 링크와 함께 전체 공유합니다.

      팀 회고(금) ⇒ 조배경

      • 회의록으로 작성하여 프로젝트 저장소 wiki에 업로드합니다.
        • 주어진 1시간이 부족하다면 추가적인 시간을 내어 내용을 보충합니다.
        • 마스터 클래스 및 멘토링에서 받은 질문이나 피드백을 추가해도 좋습니다.

      릴리즈 노트(비동기)

      • 한 단위의 개선 및 리팩토링 작업이 끝날 때마다 프로젝트 저장소 wiki에 작성합니다.
        • wiki 작성 이후 대표 1명이 Slack에 요약 하여 링크와 함께 전체 공유합니다.

      학습정리와 회고(개인)

    코드리뷰

    1. 분야 가리지 않고 적극적으로 하기(최소 1명)

    2. 리뷰 할 때 Pn 룰을 사용하여 리뷰어가 코멘트를 강조하고 싶은 정도를 표현하기

      • P1: 꼭 반영해주세요 (Request changes)

      리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

      • P2: 적극적으로 고려해주세요 (Request changes)

      작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

      • P3: 웬만하면 반영해 주세요 (Comment)

      작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

      • P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)

      작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

      • P5: 그냥 사소한 의견입니다 (Approve)

      작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

      출처: https://blog.banksalad.com/tech/banksalad-code-review-culture/

    휴식

    1. 회의

      50분 회의, 10분 휴식

    2. 개인 작업

      자율

    git 컨벤션

    1. 프로젝트 관리
      1. 이슈/pr로만 관리
        1. pr을 남긴 후 작업 완료전까진 draft 모드로 merge를 못하게 설정
        2. 작업이 끝난 후 draft 모드 해제
    2. issue/pr 템플릿
      1. 기존 octodocs 템플릿 유지
    3. commit 컨벤션
      1. feat : 기능 구현
      2. fix : 버그 수정
      3. refactor: 리팩토링
      4. chore : 환경 변경
    4. branch 전략
      1. develop 브랜치에서 브랜치 나누어서 기능 개발 후 릴리즈 배포할 때 main 브랜치로 병합
      2. feat-be-#139, fix-fe-#123

리팩토링

docker 이미지 최적화
docker 배포 환경 최적화
docker 자동 배포 파이프라인 시간 단축
redis 낙관적 락 도입기
불필요한 리렌더링 개선

💡lighthouse 개선

팀 문화

🧸 팀원 소개
⛺️ 그라운드 룰
🍞 성장 목표
📅 프로젝트 계획

회고

1️⃣ 1주차 회고
2️⃣ 2주차 회고
3️⃣ 3주차 회고
4️⃣ 4주차 회고
5️⃣ 5주차 회고
6️⃣ 6주차 회고

Clone this wiki locally