<aside> 📌

목적

프로젝트 진행을 위한 초기 회의

</aside>

<aside> 💡

요약

| 회의 | • 매일 10시 / 18시 데일리 스크럼을 통해 진행 • 회의록은 이름순으로 번갈아가면서 작성 | | --- | --- | | R&R | • 비슷한 기능 + API 엔드포인트 개수 기준으로 4개로 분리하여 분배 완료 • 세부 사항 바로 가기 | | 깃 이슈 및 PR 규칙 | • Github에 깃 이슈 및 PR 템플릿을 적용하여 사용 • 세부 사항 바로 가기 | | 프로젝트 컨벤션 | • 클래스 / 변수 / 메서드에 대한 컨벤션 지정 • 프로젝트 전반에 적용될 코드 스타일 지정 (Naver) • 세부 사항 바로 가기 | </aside>

회의 안건

1. 회의 방식 및 시간

• 회의 시간

  매일 오전 9시 / 오후 18시

• 회의 방식

  • 데일리 스크럼

    | 오전 | • 오늘의 컨디션 • 전 날 개발했던 내용 • 오늘 개발 목표 • 논의 사항 | | --- | --- | | 오후 | • 금일 개발 진행 상황 공유 • 개인 트러블 이슈 정리 • 논의 사항 |

  • 주간 회의

    : 데일리 스크럼 대신 진행

    | 월요일 오전 | • 주간 목표 • 논의 사항 | | --- | --- | | 금요일 오후 | • 금주 진행 상황 공유 • 남은 작업 목록 공유 • 논의 사항 |

• 회의록 작성

  : 회의록은 이름순으로 돌아가면서 작성

  ⇒ [이다솔 → 전승주 → 박나경 → 박정현]

2. 팀 규칙

• 서로 존중하고 화내지 않기
• 적극적으로 소통하기
• 불참 해야할 경우 최소한 전 날 이야기 하기
• 메시지 보내면 체크 표시하기
• 혼자서 해결하기 어려운 문제가 생기면 팀원들한테 공유하기

3. 프로젝트 구조

• 도메인 형식 구조로 결정

  Member
      ⎿ controller
      ⎿ service
      ⎿ dto
  Order
  	⎿ controller
  		⎿ OrderContrlloer.java
    ⎿ service
    ⎿ dto
  

4. 브랜치 전략

• Git Flow 전략을 벤치마킹한 브랜치 전략 사용

  • main 브랜치에 직접 push 불가능
  • 모든 작업은 feature 브랜치에서 시작해 dev로 merge

  브랜치	용도
  main	• 최종 완성된 프로젝트 코드

  • 직접 push 금지 |
  

  | dev | • 구현 및 테스트가 끝난 기능의 통합본 • feature 브랜치에 구현된 기능 병합 | | feat/#이슈번호-간단한설명 | • 개별 도메인 기능 개발 • 기능 당 하나의 브랜치 정의 • dev 브랜치에 병합된 브랜치는 삭제 | | release | • 배포 환경에 업데이트 되는 코드 • dev 브랜치에 병합된 기능 대상 |