오늘 할 일: 스프린트 플래닝
1. 프로덕트 백로그에 대한 설명: PO[15분]
- 백로그 변동 사항에 대해 설명해주시면 됩니다.
2. 플래닝 포커[60분]
- 각 유저스토리 모두에 대해 진행합니다.
- 각 유저스토리에 대한 소요 시간을 예상합니다.
- 단위(일)
- 0: 반나절도 안 걸림
- 1/2: 반나절이면 충분
- 1일, 2일, 3일, 5일, 8일 등: 피보나치 수열 형태
- 주의
- MoSCoW의
Must
우선순위의 경우 3 이하로 맞춘다! - 5일 이상일 경우, 해당 유저스토리를 쪼개면 될 것 같음
3. 플래닝 포커의 변동사항을 백로그에 반영한다: PO[15분]
- 제안사항
- 스프린트 미션 상으로는 15분 동안 PO가 혼자서 진행하게 되어 있는데,
- 업무 부담을 덜기 위해서 협력하는 것은 어떨지
4. Must레벨 유저스토리에 대한 세부 테스크 작성[45분]
- Must레벨 유저스토리 = 이번 스프린트 백로그
- 각 유저스토리 모두에 대해서 구체적인 해결 방안을 작성
- “개발자들” 포지션 멤버들이 준비해온 사항 같이 살펴보기
- YR2-96: 일단 카테고리별 검색으로만 한정
5. 세부 테스크를 할당[45분]
- 4에서 도출된 세부 테스크 각각을 모두가 할당받음
- 작업 완료일은 스스로 결정함
6. 이번 스프린트의 목표 설정: PO[15분]
- 이번 스프린트의 목표를 설정합니다.
논의 기록
프로덕트 백로그 살펴보기
- 서비스를 파악한다 = 메인 페이지
- 유저 입장의 기획 포인트: 붉은 포인트들에 대해서 고려
- 중복 기능은 제공함
- 좋아요 기능
- 좋아요 한 글을 모아보기가 필요한지?
- 스크랩이 있으니 중요도 낮음, 제거
- 댓글에 좋아요가 필요한지?
- 커뮤니티 기능에서는 중요하기는 하지만, 바로 만들 필요는 없을듯
- 메인 페이지에 노출되는 상품은 좋아요 기반으로 보이는데, 좋아요 필요성은?
- 이건 스크랩 수를 기반으로 조정하거나 할 수도 있겠음
- 팔로잉 기능이 소속해야 하는 부분? 회원인지, 커뮤니티인지?
- 피드 기능의 위치?
- 구현의 측면에서는
- 회원 서비스를 커뮤니티, 스토어 양 쪽에서 사용하니까 회원에 두자?
- 기획의 측면에서는, 커뮤니티의 핵심 기능이니까
- 상품 등록이 사용자 여정에서 누락되어 있음
- 이 기능을 어떻게 처리할지
- 판매자가 상품 등록, 배송 처리 등 추가 사항이 많음
- 다른 여정을 하나 만들어야 할 규모임
- 저번 기수의 오늘의 집 프로젝트와 비교했을 때 Must 규모가 너무 큼
- 조율 필요할 듯
플래닝 포커
- 현재 댓글 유저스토리는 대댓글을 포함하지 않음
- 대댓글은 별도의 유저스토리로 추가해야
- YR2-26 전문가 답변 관련하여 댓글 형식인지, 누가 답변하는지?
- 사실 누구나 답변 가능
- 회원, 멘토로 구별됨
- YR2-38 로그인 기능
- OAuth 종류 별로 완전히 다른 회원으로 구별, 자체 가입이랑도 구별
- OAuth + 자체 로그인 포함
- 배송 조회 중요도 낮추기: 3단계로
- 커뮤니티 33.5
- 민성
- 한빈
- 회원 18.5
- 현정
- 커머스 26.5
- 훈기
- 민재
- 시간 분배 방법론
- 티켓
- 실무에서도 하는 방식
- 유동적 분배
- 파트
- 머지 충돌 확률 높음
- 파트 분배, 티켓을 찾아가는 식으로
- 밀리는 파트의 경우 먼저 끝난 파트가 지원
추가 논의사항
- repository
- 리포지터리 이름?
- joseph-home
- artifact
- org.programmers
- 버저닝
- 0.0.0부터 시작
- 사진 조회, 공유는
- 의견이 분분
- 질문 글의 경우 사진
- 커뮤니티의 경우 사진이 대부분
- 사진 기능에 대한 글로벌 관리가 필요
- 결제의 경우
- 프론트 업무가 많을듯
- 설계 방법론
- ERD
- UML, 유스케이스
내일까지 할 일
- 모임 시간에 대해 정하기: 14시
- repo 연동
- 프론트가 필요할지?
- 컨벤션 생각해보기
- 파트별 ERD 작성해보기