1. 스프린트 정의
•
스프린트는 최대 4주로 한정한다.
•
메인 스프린트와 QA 스프린트를 분리한다.
◦
메인 스프린트: 기능 및 플로우 위주로 구성
◦
QA 스프린트: 테스트 및 기능/번역/디자인 고도화 진행
스프린트와 연관성이 적은 업무는 최대한 추가하지 않도록 한다.
예외 케이스: 핫픽스가 필요한 이슈
2. 킥오프 미팅
•
스프린트 시작 전 얼라인을 위해 전사 킥오프 미팅을 진행한다.
◦
스프린트의 목표와 목적의 명시화
▪
필요 서류: 기획서 (노션 문서) & 화면 정의서 (피그마 파일)
◦
스프린트 스펙 조정
▪
번역을 메인에서 진행할지 QA에서 진행할지
▪
QA 수준을 풀로 할지, 파트로 할지 정한다.
◦
타겟 일정 조정
◦
업데이트 노트 작성
◦
팀별 목표
◦
해당 내용을 작성해서, 노션 & 슬랙(pinned)에 모아둔다.
3. Jira 사용 및 작성법
•
프로덕트와 관련된 모든 이슈는 jira에 등록한다.
•
등록할때는 우선순위도 함께 표시한다.
◦
번역 이슈 또한 task로 만들어서 관리한다.
•
일반 이슈란?
◦
QA 스프린트 버전에서 일어나는 버그성 제외 모든 이슈
•
버그 이슈란?
◦
기획 의도와 다르게 동작하는 경우
◦
앱이 터지는(크래시) 경우
◦
디자인이 원하는 형상이 아닌 경우
버그의 경우, 경향성 파악을 위해 Jira 템플릿에 따라 상세하게 작성하도록 한다.
4. 번역 이슈
•
기본적인 내용은 Figma로 관리한다.
•
메인 스프린트에서 번역을 진행한다.
•
번역 관련 세부 정책을 정한다.
◦
꼭 한줄로 정리되어야 하는 부분은 정책서에 별도 표시한다.
▪
제목 → 폰트, 볼드 조건에 따라 글자수를 제한한다.
▪
CTA
◦
줄수 제한이 있는 부분도 별도 표시한다.
◦
닉네임의 경우 한줄을 모두 할당한다.
◦
개발팀은 한줄로 처리되어야 하는 부분을 인지한다.
5. QA
•
핵심이 되는 QA 시나리오를 사전 작성하여 공유한다.
•
테스트 시점
◦
QA 시작 전, 프로덕션 전에 1회씩 진행
•
QA 테스트를 진행할때, 테스트 버전에 따라 릴리즈 노트와 지라 이슈번호를 함께 명시한다.
◦
이때, 특정 부분을 테스트할 담당자를 설정한다.
6. 마케팅
•
마케팅 플랜을 거시적으로 잡고, 스프린트 일정에 맞춰 이벤트 타이밍을 맞춘다.
•
스프린트 기간에 맞는 목표와 목적을 함께 설정한다.
7. 기타
•
광고 설정은 금요일에 등록하는 방향으로 한다. (광고 설정할때 리소스를 줄이는 방법을 고민한다.)
•
시스템화 할 수 있는 부분을 정리해서 업무 효율을 높인다.
기획 프로세스는 다음과 같다.
1.
one pager를 통해 해당 기능이 필요한 이유(Why)에 대해 정의한다.
2.
스토리 보드를 통해 유저들이 어떻게(How) 기능을 활용할지, 어떤 기대 효과가 있을지 작성한다.
3.
기획 회의를 통해 1번과 2번 내용을 공유하고, 업무 R&R과 일정을 정의한다. (아웃풋 = 컨플루언스 문서)
a.
기획 컨셉에 대한 아이디어 미팅을 진행한다. → 핵심 가설을 정의한다.
4.
3번의 문서를 기반으로 wireframe을 작업한다.
5.
wireframe을 기반으로 UI/UX를 논의한다.
a.
해당 과정에서 공유가 필요할 경우, 다수의 팀원에게 공유하여 의견을 받아본다.
6.
(스프린트 진행 확정 이후) 담당 개발자 + Jay와 함께 figma를 보면서 상세 기능을 확정한다.
7.
sprint용 figma 버전을 만든다. 그리고 번역용 figma 버전도 만든다.
8.
스프린트 킥오프 미팅을 진행한다.
9.
메인 스프린트가 종료되면 개발자가 개발된 부분을 시연한다.
10.
해당 기능에 대해 UI/UX를 아카이브 한다. → 피그마 저장
11.
QA일정과 함께, 프로덕션 일정을 협의한다.
전체 미팅은 다음과 같이 진행한다.
1.
데일리 스크럼은 오전 12시에 진행한다.
2.
주간 회의는 매주 첫번째 요일 오전 11시에 진행한다. 또한 이때 1주간의 업무 계획을 간단하게 공유한다.
3.
팀원 전체의 의견을 받아보고 싶은 안건(아이디어 수집, 유저 반응 상정)에 대해서, 주간 회의에 공유한다.
a.
해당 안건에 대해 사전에 공유한다.