1. Ground Rule

• Rule 1) 데일리 스크럼

  • 시간: 19:00 ~ 19:30
  • 작업 상황 공유 및 진행 상황을 점검합니다.
  • 진행 방식:
    • 어제의 진행 사항: 완료한 작업 간략히 공유(10분 내외)
    • 오늘의 목표: 진행할 작업 설명 (10분 내외)
    • 문제 발생 여부: 막힌 부분 및 해결이 필요한 이슈 공유(10분 내외 + 추가 회의 진행)
    • 회의록 기록: 작업 상황 공유

• Rule 2) 코어 타임

  • 시간: 9:00 ~ 22:00
  • 이 시간 동안은 최대한 집중하여 작업에 임합니다.
  • 이슈 대응, PR리뷰, 커뮤니케이션 요청 등은 코어 타임 내에 우선 처리합니다.

• Rule 3) 기록

  • 작업 중 발생한 오류나 트러블 슈팅을 기록합니다.
    • 1주일에 1개 이상 기록 후 공유
      • 기록 예시 :
        • 문제 상황: 로그인 페이지에서 API 요청 실패
        • 원인 분석: 인증 헤더 누락
        • 해결 방법: Axios 요청 시 Authorization 헤더 추가

• Rule 4) 추가 논의

  슬랙으로 논의 요청 후 진행합니다.

  **논의 요청 ✋🏻**
  - **의논 주제** : 로그인 시 인증 처리 방식 변경
  - **긴급 정도** : [낮음, 중간, 높음]
  - **회의 요청 시간** : 오후 2시 00분
  - **의논 내용** : 인증 실패 시 UX 개선 방향 논의
  

  • 논의 시간 관리:
    • 30분 초과시 잠시 중단하고, 일정을 미리 정해 재정리 후 다시 논의합니다.
    • 효율적인 시간관리를 위해 핵심 논의에 집중합니다.
    • 예외 상황: 배포 직전 긴급 이슈

• Rule 5) 방어적인 태도를 취하지 않습니다.

  • 의견 교환 시 원활한 커뮤니케이션을 최우선으로 합니다.
  • 예시
    • ❌: “내가 만든 코드가 문제없는데 왜 안 된다고 하는 거지?”
    • ✅: “혹시 어떤 부분이 문제일까요? 다시 한 번 같이 확인해볼까요?”
  • 문제에 집중합니다.
    • 사람에 대한 지적이 아닌, 코드나 문제 상황에 대한 논의에 초점을 맞춥니다.
    • 개인의 잘못이 아닌 프로젝트의 개선을 목표로 커뮤니케이션합니다.

2. Code Review

• Rule 1) 슬랙 알림 수신 후 ‘리뷰 가능 시간’을 회신

  <aside>

  예시 응답:

  • “오늘 오후 3시까지 확인할게요 🙆”
  • “내일 오전 중 확인 가능합니다 ⏱️” </aside>

• Rule 2) : 코드 리뷰 작성 잊지 않도록 체크리스트 작성

• Rule 3) 리뷰 반영 필수

  • 리뷰어가 제시한 피드백을 반영합니다.
    • 만약 반영이 어려운 어려운 경우, 명확한 이유와 대안책을 설명합니다.
      • 예시: “이 로직은 API 응답 형식에 의존하기 때문에 변경이 어렵습니다. 대안으로 에러 핸들링을 추가했습니다.”

• Rule 4) 2명의 리뷰가 완료되면 Merge 가능

• Rule 5) : 리뷰를 위한 리뷰는 지양하며 사소한 부분까지 살펴봅니다.

  • 예시
    • ❌ : “괜찮은 것 같습니다.”
    • ✅ : “해당 메서드의 네이밍이 모호한 것 같습니다. 좀 더 명확하게 바꿔볼 수 있을까요?”