• 피드백 원문

<aside> 📌 - **멘토님 피드백 → 검정색 글씨

• 멘티의 피드백 반영 → 파란색 글씨
• 프론트엔드와 상의 필요한 내용 → 주황색 글씨**

</aside>

공통사항

1. 기능이 너무 많다.
   • MVP 이외의 기능에 대해 우선순위를 더 세분화 해서 이번 프로젝트 기간 동안 할 수 있는 부분에 대해 구체적으로 정하겠습니다.
2. 스크럼을 더 자세히 작성했으면 좋겠다.
   • 무엇을 했는지, 무엇을 할 것인지
   • 이슈는 무엇이었는지, 어떻게 해결했는지
   • 각 구성원 별로, “지난 스크럼 이후 진행한 태스크”, “오늘 예정 태스크”, “이슈 내역”으로 나누어 관리하도록 변경했습니다.
     • 팀 스크럼 템플릿
3. 스프린트 단위의 회의가 있으면 좋겠다.
   • 기존에도 스프린트 페이지에서 프론트엔드, 백엔드 함께 회의 및 일정 산정 하고 있었습니다.
   • 하지만 한눈에 태스크 진행도를 파악하기 어려워서, 전면적으로 구조를 개편해봤습니다.
   • 표, 타임라인, 칸반보드, 캘린더 네 개의 view를 통해 하나의 스프린트에서 각 태스크가 어떻게 진행되고 있고, 어떤 하위 태스크 들로 이루어져 있는지 파악할 수 있도록 개선했습니다.
     • 백엔드

일정

1. 달력보다는 간트차트로 각 기능에 대한 일정 정리가 필요하다.
   • 누가
   • 어느 기간동안
   • 현재 각 기능에 대한 우선순위가 나눠져 있지 않아서 막연하게 일정을 정해놓은 상황입니다.
   • 월요일에 프론트엔드 분들과 상의해서 모든 기능에 대한 우선순위를 정하고, 데모데이 이후 ~ 수료식 전 까지 각 주 단위로 어떤 기능들을 완성할 예정인지 간트차트와 캘린더로 제작해보겠습니다.
2. 기술과 구조보다는 기능 완성이 우선이다. 기한 안에 기능을 빠르게 완성하는게 중요하다.
   • 일정이 정리되면 각 일정에 맞게 반드시 기능을 완성할 수 있도록, 코드 리뷰를 너무 꼼꼼히 하는 방향보다는 완성에 초점을 맞춰 진행하겠습니다.

개발

1. 노션 문서화는 변화에 유연하게 대처하기 어려우니, 수동이든 자동이든 프론트엔드에게 알림을 줘야한다.
   • 공통 사항이 변경되면 아래 페이지에 변경된 내역을 적어 기록하고 알려주는 방식으로 진행할 예정입니다.
   • 나중에 swagger를 통해 API의 변경 내역의 경우 자동 반영 예정입니다. 일단 그 전까지 위의 방식으로 진행하겠습니다.
2. 브랜치 전략은 무엇인지?
   • main → prod 환경입니다. (직접 push 불가능)
   • dev → dev 환경입니다. (직접 push 불가능)
   • feature → 각 기능 구현에 대한 개인 브랜치입니다.
     • feature/#{이슈번호}
   • hotfix → 버그 수정을 위한 개인 브랜치입니다.
     • hotfix/#{이슈번호}

ERD

1. 테이블이 너무 많다. 일정 내에 가능한지 파악하고 가능하다면 진행하고, 아니면 줄여야한다.

   • 일단 아래와 같이 ERD를 MVP 버전과, 이후 버전으로 나누었습니다. 데모데이 전까지는 MVP 버전의 ERD 기준으로 기능을 완성할 예정입니다.
   • 이 역시 팀원 전체와 기능의 우선순위를 합의 하에 어떤 테이블을 추가적으로 생성할 건지 논의 해보겠습니다.

2. ERD에 버저닝이 필요하다.

   • MVP 버전의 ERD

     

   • MVP 이후 추가 기능 도입한 ERD

     

3. 크루원 가입 신청목록을 크루원 테이블 하나로 합칠 것인가?

   • 테이블 하나로 합쳐서 관리하는 방식으로 변경했습니다. (대기, 확정 → ENUM으로 관리 / 취소, 거절 → 레코드 삭제(hard delete))