배포 주기
- 현재 스프린트 시작 때 배포하고 개발
- 시각적으로 차이를 느낄 수 있도록
- 저희가 생각했을 때 릴리즈 버전으로 쓸 만 하다 ⇒ 배포
- 릴리즈 버전 ⇒ 페이지 단위
- 배포 시 마다 공유하는 형태 ⇒ 독립적 확인할 수 있게
- 변경사항에 대한 문서화
- release ⇒ 할 때마다 버셀에서 자동적으로
- main ⇒ 최종
API 요청 프로세스
- 설계 프로세스 : 기획 처럼 팀별 생각하는 API ⇒ 서로 협의
- 설계는 기획처럼 빠르게 안될거에요 ⇒ 스프린트 단위로 매 번?
- 전제 : API 설계가 서로 끝났을 때 ⇒ 협의가 끝났을 때
주말 활용
- 주말은 안썼으면 좋겠다.
- 주말은 스프린트 기간 제외
- 주말은 트러블슈팅 기간으로 생각 ⇒ 여유시간을 두는게 문제해결에 좋음
- 스프린트 일찍 끝나면 비동기로 스프린트 기간 당길 수 있음
- 정해진 회의시간이 부담스러움
- 주말에 프로젝트 안하는게 아니에요 ⇒ 게더에 있습니다.
- 백로그를 당겨오는 방향으로
시장 조사
기획/개발일정
- 기획 일정
- + API 설계
- 스프린트 회고
- 다음 스프린트 얘기하면서 다음 기획과 API 설계에 대한 협의
- 개발 일정
- 스프린트 따라서 갈 것
지라 작업
- 스프린트 단위: 4일
- 스토리는 형식에 맞게
- 사용자는 ~하기위해 ~ 한다.
- 스토리 포인트는 30분에 1점
- 하위 작업의 경우 형식 자유롭게
- 백로그
- 맡은 부분 분업
- 에픽 먼저 - 프론트, 백 vs 도메인
- 하위에 스토리
- 유저 스토리(사용자는 ~을 위해서 ~을 한다.)
프론트 백 나눌 거냐- 도메인
- 에픽 ⇒ 스토리, 작업(기획, 문서화..) ⇒ 스토리 하위 작업
- 회원관리
- 유저를 기능을 쓰기위해 회원가입을 할수 있다.
- [Front] UI를 구성한다.
- [Front] API를 연동한다.
- [Front] 기능을 구현한다.
- [Back] DB 구성한다.
- [Back] API 구성한다.
- 작업(기획해야돼, 구분하려구 이슈)
- 하위 스토리 ⇒ 하위 작업