기능 우선순위 정리, 에자일

백엔드 기능 우선순위 정리

• 동네에서 운동친구를 구할 수 있는 플랫폼

Must

• 회원가입
• 닉네임

• 로그인

• 팀 생성 기능
• 팀 이름 설정 (중복 X)
• 사용자 초대
• 사용자 승인
• 팀 대표 설정
• 팀 개설자가 default로 가져가는 걸로

• 대결 신청
• 해당 팀의 전력 조회 기능 (팀 승률, 개인(주전멤버) 승률 등)
• 팀 대결일 경우 어떤 팀원들이 들어갈지 선택
• 그에 따라 팀의 인원수를 맞춰야 된다. (Validation) - policy

• 대결 성사
• 상대 팀에서 대결 신청 시 조회 ()
• 알림이 뜨면 수락 여부
• 댓글이든 쪽지든 뭐 (1대 1) 소통 수단, 실시간x 새로고침식 (웹소켓은 학습 및 적용 오버헤드 우려)
• 댓글 , 대댓글로 해소함

• 대결 이후
• 승패여부 확인 → 우선 게시글 작성자가 판단하는 걸로 MUST
• 여유가 된다면 추후에 도전자와 피도전자의 승패 기입→ 검증→ 둘의 기입한 승 패 데이터가 맞을 시 확정
• 개인이나 팀에대한 후기 작성
• 별점 : 한눈에 파악 용이 (일단 별점으로 선택 이유 - 간단히 평균 별점으로 점수낼 수 있음)
• 전적(승/패) 업데이트
• 경기 종료 후 전적 업데이트
• 개인이나 팀의 후기에 따른 별점 변화

Should

• 프로필 이미지

• 승패여부 확인
• 도전자와 피도전자의 승패 기입→ 검증→ 둘의 기입한 승 패 데이터가 맞을 시 확정

• 후기 작성
• 텍스트 : 별점 + 텍스트 후기

• 알림 기능
• 매치가 끝나고 후기가 날라왔을 때
• 매치 문의가 들어왔을 때
• 매치 문의 메시지가 왔을 때
• 매치 수락 시 → 해당 신청자에게 알림

Could

• 랭킹 변화
• 지도로 하면 랭킹 검색 조건으로 갈 수 있을 것 같음.

• 티어(티어별 마크) → 슈퍼 후순위
• 하수
• 중수
• 고수
• 지존

모호한 부분

• 매치만들 때 팀전, 개인전의 경우 어떻게 플로우가 흘러가는지
• 매치에 맞게 유동적으로 팀원 선택(주전 멤버)

• 삭제 정책
• 매칭 성사 시 게시글 삭제 불가

• 소통수단이 게시글마다 어떻게 ui가 되는건지
• 게시글 종속
• 웹소켓 사용 x

• 다건 조회 UI
• 조회 조건 (위치, 거리 관련 문제) > 내 위치 기준 반경으로
• 동운 : 위치가 자세한게 아니라 동으로 지정된 경우에는 마커로 주변 경기 표시가 불가능
• 형욱 : 위치가 노출되는 부분도 우려되며 어느정도 초기에 생각했던 프로젝트 정체성에 맞게 진행할 필요성도 있어 보입니다. 또한 해당 위치 시점으로 먼 거리까지 조회를 가능하게 해준다면 오히려 그 부분이 사용자에게 더 편의성을 줄 수 있지 않을까 생각했습니다.w
• 진형 : 위치 노출 우려가 있습니다.(개인정보)
• 경기장 위치로 글을작성하는 것은 경기장 예약가능에 대한 명확한 정보가 없기때문에 좋지않을듯
• 본인위치로부터 대결작성시점 위치로 반경 n km가 더 좋을듯합니다.
• 혜빈 : 명확한 기준점이 없습니다. 그리고 수요가 부족하다면 더더욱 리스트 형식이 맞다고 생각합니다. 어디에 수요가 있을지 어떻게 알고 선택할 수 있을까요

멘토님 말씀

• 코어타임 시작 시간을 더 빨리 정하는게 어떨지

• 문서화 이외에 협업 프로세스에 대해서 얘기 나누기

• 기획에는 핵심 인원들만 참여해서 하도록 ex) 모스카우

• 시퀀스 다이어그램

• 유스케이스

• API는 스펙만 맞춰놓는다 Request Response Endpoint

• 결정사항을 무작정 기다릴 필요는 없다. 다른 일을 찾아 압축적으로 시간을 아끼자

• 어떻게 개발해 나갈 것인지 워크플로우를 정해야한다.
• 한 화면이 나와야되고 인터렉티브도 나와야하고 API기능이 나와야한다.
• 병목이 생기지 않게 어떻게 협업을 진행할지 얘기를 해봐야한다.
• 어느 구간에는 어디까지 개발을할 것인지 얘기해야한다.
• 마지막에 컨펌을 받으면 문제가 발생하니 지속적인 검토 필요

• 시나리오가 끝났을 때 회고를 통해서 개선 어떤게 문제였고 왜 못했는지 어떻게 하면 개선 시킬 수 있을지

• 팀 컨벤션, 워크플로우, 로드맵, 업무 프로세스 스크럼 시간, 개발 진행, 누구는 어떤 역할을 한다. 툴은 어떤 걸 사용하면서 비동기적 개발을 한다. 마무리 스크럼, 어느 단위로 개발한다.

• 리퀘스트모델 리스폰스 모델 맞추고 엔드포인트 맞추기

• 기능이 모호하더라도 이런게 필요하다 하면 동시에 개발이 가능할것이다.

• 이번에 할것을 MUST를 뽑아라 우선순위

• 3일이든 4일이든 MosCow를 정하자

• 중간에 리팩토링하는 시간을 가져봅시다 필수 🌟
• 마지막에 리팩토링을 하면 나중에 다 터집니다.

• 저희 슬랙에서 많은 얘기를 하면 좋을 것같아요 비동기 적인 결정도 좋고, 인사도 좋고 수다도 좋습니다.
• 비동기적인 TodoList, 의견들을 슬랙으로 공유하는것도 좋습니다.
• 언제까지 어떤것들을 준비를해야하는가
• Top down 방식을 권장드립니다.

상의 해봐야할 것

• 프론트 분들을 게더에 초대해서 마이크만 키면 대화를 나눌 수 있는 환경을 조성하는건 어떤지
• 게더 사용 ⇒ 대화가 안될 경우 구글 미트로 진행
• 부담가지지 말고!! 선택적 참여 ~

• 애자일 적인 부분을 어떻게 가져갈건지
• 스프린트 초반 3~4일 단위, 안정화 된다면 주기를 좀 길게 가져가는 것
• 변동사항은 항상 있을 수 있기 때문에 3~4일 유지하다가 일주일로 변경
• 스프린트 진행 후 회고를 진행합니다.

• 기획에는 핵심 인원들만 참여해서 하도록 ex) 모스카우
• 기획에 관심이 있는지 없는지도 체크해서 관심 없는 사람들은 다른 곳으로
• 백엔드 : 혜빈, 동운
• 프론트 : 파파, 톰슨 | 로렌스

• 협업프로세스

확정

• 각 팀에서 팀회의 진행하고 공통회의 때는 각팀 당 회의 대표자 2명 참여

• 게더 사용
• 코어타임 이외에 모여서 상주하자~

• 스프린트 3-4일에서 이후에 7일

• 내일까지 프론트엔드 협업프로세스 회의 후 노션에 문서화 슬랙에 남겨두도록 하겠습니다.

• 시장조사 프론트, 백 조사 후 서로 협의
1. 프로젝트의 이름 : 한국어명, 영문명
2. 비슷한 서비스가 무엇이 있을까?
• 해당 서비스에서 배울 점.
• 우리 프로젝트에서 차별을 둘 점
3. 가장 중요한 기능은 무엇일까
4. 어떤 사람들이 사용할지, 타겟 추측하기
5. 우리의 서비스를 문장으로 표현해보기 (1~5문장)

• 낼 몇 시

• 낼 뭐 할 것인지