request response 에러 등 비동기로 의견 받기로했음
문서화 위주의 스프린트가 될 것 같습니다.
팀 생성시 팀원 조회 기능이 필요하다.
백엔드 알림사항
- 유스케이스는 프론트가 하기로함
- 형욱님이 HTTPS 까지 해놓으셨음
- 병연님이 매일 프로젝트에 대한 질문 리스트 써주실검다
- Project Q&A [Eli]
- 저희도 병연님께 여기다가 전달할 사항들 적어드리면 될 것 같아요
- ERD는 병연님이 해주실 예정
- 다같이 함께 보는 시간을 따로 가지는 것이 필요할 듯?
- 병연님 혼자서해보려했는데 기획자도아니고 해서 좀 어려움이 있었슴다.
- 스프린트에 스토리를 추가 해야될것 같습니다.
이유 - 현재 스프린트에 올라온 작업들이 백엔드 측에서는 이미 미리 완료된 부분도 있고 비교적 간단한 작업입니다.
스토리 단위로 프론트엔드와 백엔드가 항상 같은 작업을 할 순 없다고 생각을 합니다. 일(스토리)의 순서는 정할 수 있겠지만 스토리마다 속도가 다를 수 있다고 생각을 해요(백엔드가 빠를수도있고 프론트엔드가 빠를 수도 있음)
원하는 방향 -
- 아래 스토리를 스프린트에 추가하려고합니다.
- 사용자는 팀에 들어가기 위해 요청된 초대를 받을 수 있다.
- 사용자는 자신의 팀에 팀원을 추가하기 위해 다른 사용자를 초대할 수 있다.
- 사용자는 자신의 팀에 팀원을 초대하기위해 다른 사용자를 조회할 수 있다.
- 와이어 프레임, API 스펙을 먼저 받을 수 있는지? (Request, Response)
- 화면 구현이 아니더라도 화면 설계가 먼저 전달이 된다면 병목을 줄이며 백엔드에서 구현을 빠르게 이어나갈 수 있을 것 같습니다.
- 2시 공통회의 때 이 스토리들 뿐만아니라 전체적인 스토리에 대해서 설계를 먼저 전달할지에 대해서 얘기를 해봐야될 것 같습니다.
백엔드 TODO
- 문서 채울것들 목록
- ERD - 병연님
- 시퀀스다이어그램 + API 설계
- 하위 작업 만들기 스토리 포인트 산정하기
- 회원 가입 로그인 페이지
- 팀 생성 페이지
- 개인 팀 프로필 페이지
- 스웨거도 기본베이스로 무적권 해야함
- 테스트 코드도 물론
⇒ 각자 컨트롤러 만들고 설정만 하면 됩니덩 -혜빈
- 프로젝트 구조
- 예외
백엔드 논의 사항
- DTO 구조 ⇒ service , controller 서로서로 다 dto , record, nested
- 동운님 : stay
- 진형님: stay
- 병연님: stay
- 혜빈님: stay
- 형욱님: stay
- 백엔드 기술스택 저렇게 다 쓰는게 맞는건가요 ? 너무 과한것 같아요 ⇒ 좀 정리함
- 기능리스트 페이지 없어도 될 것 같아요 유저스토리랑 중복인 것 같아요 ⇒ 지움
- 트러블 슈팅 공통 문서에 하나만 만들고 테이블로 따로 관리하면 좋을 것 같아요 ⇒ 프론트한테도 여쭤보는걸
- erd
- 혜빈
- 리뷰는 content가 아니라 다른걸로 수정해야할 것 같습니다.
- 전적 부분에 승 패만있는데 몇전 몇승 몇패 로 갈건지 무승부는 어떻게할건지 이런 부분에 대한 정책을 명확하게 정해야할 것 같습니다.
- 팀에 종목 카테고리가 들어가는 이유가 궁금합니다.
- 매칭 게시글 자체에 카테고리가 들어가는게 맞다고 생각이 들어요. 조회 조건에 종목이 있으니까요 대결 날짜도 조회 조건에 포함될텐데 이것도 없어도 되는건지 궁금합니다
프론트와 상의 해볼 것
- 프로젝트 이름 투표
- 로드맵
- 기획서 어떻게 할지 얘기 해봐야함
- 스프린트 스토리 추가 내용
- 하위 이슈의 스토리포인트가 변경될 경우 상위 스토리까지 다 수정해주세요
- 스토리의 레이블이 필요없다고 생각하는데 어떻게 생각하시는지?
- 왜냐하면 에픽이 다 구분을 가능하게 해주기때문에
- 유스케이스를 스프린트 마다 가져가는지?