어디 한번 밀리의 서재 스크럼 팀을 만들어볼까?
[코드스테이츠 PMB 10기] 애자일과 스크럼 프레임워크
어쩌면 이렇게 하지 않을까?
밀리의 서재 스크럼팀
1. 스프린트 계획하기
(*위의 과제와 이어집니다.)
드디어 위클리의 마지막, 8주차가 되었다. 이번 주차에는 애자일 프로세스와 스크럼에 대해서 학습하였으므로, 이전에 구체화해두었던 [도서 제안하기]의 가상 스크럼 팀을 만들어보고자 한다.
User Story & Backlog
이전 포스팅에서 기록한 유저스토리와 백로그는 다음과 같다.
밀리의 서재에서 도서를 제안하고 싶다면, [관리] - [고객센터] - [1:1문의] -[도서관련문의]에서 보고 싶은 책과는 관련이 없는 여러 정보를 기입해야 한다. 이는 도서 제안을 하고 싶은 고객들로 하여금 불편함을 일으키고, 쉽지 않은 UX로 인하여 읽고 싶은 책을 제안하지 못한 고객은 이탈할 가능성도 높다.
그래서 고객들이 도서 제안을 쉽게 할 수 있도록 서비스를 기획했었다.
1. 도서를 검색하였을 때, 도서가 없다면 바로 '도서 제안하기'를 클릭하여 서비스를 이용할 수 있다.
2. 기존의 서비스와 달리, 도서명, 저자명, 출판사명 3개의 정보만 입력하여 도서를 제안할 수 있다.
3. 희망도서 내역 확인 탭을 누르면 이제껏 제안했던 도서와 그 처리상태를 확인할 수 있다.
4. 관리탭을 누르면 '나의 도서제안'탭이 존재하고 바로 도서를 신청하거나 내역을 확인할 수 있다.
이 서비스를 만들기 위한 백로그는 다음과 같이 정리를 해보았다.
이때, 알림서비스의 경우 우선순위를 2로 두었는데 그 이유로는 고객들이 도서를 제안할 수 있도록 하는 서비스를 구현하는 것이 더 우선시되어야 하기 때문이다. 먼저 도서제안 서비스를 구축하고, 그 이후에 제안된 도서의 등록 처리 알림을 보내도 늦지 않다.
또한 백로그를 *Bare minimum, Advanced, Nightmare 세가지로 구분을 할 수도 있는데 도서 제안하기를 구성하는 [도서제안하기], [도서 제안 내역 확인하기], [제안된 도서 데이터베이스]는 무조건 필요한 기능이므로 Bare minimum에 속한다.
푸쉬 알림 서비스의 경우, 앞서 말한 것처럼 우선순위는 밀려나지만 있으면 UX적으로 유용한 기능이므로 Advanced이며 작성된 모든 백로그는 반드시 개발되어야 하는 것이므로 Nightmare에 속하는 리스트는 없다.
*Bare minimum : 꼭 필요한 최소 기능 (for MVP)
Advanced : 우선순위는 밀려나지만 있으면 확실히 유용한 기능
Nightmare : 없어도 상관없지만 있으면 좋을 것 같거나, 역량 개발/학습 목적으로 해보고 싶은 것들
2. 가상의 스크럼팀 만들기
스프린트 목표 설정 (ft. KPI)
스프린트를 시작하기 전에는 먼저 스프린트 목표를 설정해야 한다. 스프린트 목표란 애자일 스프린트 과정에서 달성하고자 하는 계획에 대한 간략한 설명을 의미한다. 팀과 프로덕트 매니저가 함께 작성하는 명백한(tangible) 목표로 스프린트 기간에 따라 제한된다.
스프린트 목표를 효과적으로 설정하기 위해서는 다음의 질문에 대한 답이 포함되어야 한다.
팀이 무엇을 위해 노력하고 있는가?
팀이 스프린트 백로그를 완료하기 위해 노력하는 이유는 무엇인가?
이해관계자가 팀의 노력에 관심을 갖고 지원해야 하는 이유는 무엇인가?
또한 SMART 방식을 따랐을 때 효과적인 목표라 할 수 있다. SMART란, 목표를 설정하는 방법 중 하나로 Specific, Measurable, Achievable, Relevant, Time-bound의 앞글자를 딴 단어이다. 즉, 목표는 구체적이지만 측정 및 달성이 가능해야 하고 비즈니스의 목표와 관련이 있으면서 정확한 시간 제한이 있어야 함을 의미한다.
효과적인 스프린트 목표는 스크럼 팀에게 하는 일에 대한 명확성을 제공하고 일일 스크럼에 집중할 수 있게 한다. 또한 진행 상황, 가치 및 결과를 평가하기 위한 벤치마크를 설정할 수 있으며 스프린트 내에서 구현된 기능에 대한 유연성을 허용할 수 있다.
위의 설명을 염두에 두었을 때, 이번 가상의 스크럼 팀의 스프린트 목표는 다음과 같이 작성될 수 있다.
도서 제안 서비스 시스템을 구현하여 고객들의 많은 도서 제안을 장려하고, 고객들의 욕구를 충족시킴으로써 고객 유지율을 10% 향상한다.
고객 유지율을 10% 향상한다는 것이 도서 제안 서비스의 구현과 연관이 있을 지는 현재로서는 알 수 없다. 왜냐하면 내부적으로 이탈에 대한 고객들의 불만사항을 살펴보아야 하기 때문이다.
하지만 고객들의 제안을 밀리의 서재가 받아들이고 있다는 형식을 통해 고객들이 밀리의 서재에 현재로서는 읽고 싶은 책이 없다 하더라도 제안을 함으로써 조금은 서비스를 더 이용할 수 있도록 붙들 수 있을 거라 예상한다.
스프린트 백로그 작성
스프린트의 목표도, 그리고 그 목표를 달성하기 위한 KPI도 설정을 해보았다. 그래서 이번에는 Jira를 활용하여 스프린트 백로그를 작성해보고자 한다.
앞서 백로그를 위와 같이 기록을 해두었기 때문에, 우선순위가 1인 것만을 Jira에 기록하고자 한다. 이때, 데이터베이스를 구축하는데 시간이 많이 들 것으로 예측되므로 2주로 설정하였다. 그리고 백로그에는 알림에 관한 것도 작성을 해야 하지만, 이번 2주 스프린트만을 계획하고자 그 기간동안 할 백로그만 작성을 하였다.
Backlog list & Description
제안된 도서 데이터베이스 구축
- ${bookName}[도서명], ${authorName} [저자명], ${publisher}[출판사명], ${nickName}[제안된 사람 닉네임], ${frequency}[제안된 횟수], ${ip}[전자책 IP유무] 에 대한 데이터베이스가 구축되어야 함
도서 제안하기 기입 페이지 구현
- 찾는 도서가 없었을 때, 바로 도서 제안하기 페이지로 갈 수 있는 url shortcut 제공
- ${bookName}[도서명], ${authorName} [저자명], ${publisher}[출판사명] 기입 받음
- 도서 제안 이용 동의 checkbox 구현
- 필수 값들이 모두 기입이 되었을 때에만 [도서 제안하기] 버튼 활성화
- 맨 위 내비게이션에 두 개의 버튼을 구현하여 도서 제안하기, 도서 제안 내역 확인 페이지 이동 가능
도서 제안 내역 확인 페이지 구현
- ${bookName}[도서명], ${bookCover}[책표지], ${date}[신청일], ${authorName}[저자명], ${publisher}[출판사명], ${status}[처리상태], ${reason}[불가사유] 확인 가능
- [상세] 버튼을 클릭하였을 때 불가사유를 상세히 확인 가능 (모달로 창을 띄움)
- 맨 위 내비게이션에 두 개의 버튼을 구현하여 도서 제안하기, 도서 제안 내역 확인 페이지 이동 가능
[마이페이지] 도서제안/도서제안 내역 확인 페이지 구현
- [마이페이지]에서 [나의 도서제안] 아이콘을 클릭하면 바로 도서제안하기 기입 페이지로 이동
도서 제안 확인 페이지 구현
- 도서 제안을 하였을 시, 이동되는 페이지
- 아이콘과 함께 카피문구 등장
- 맨 밑의 버튼을 클릭하여 [도서 제안 확인] 페이지로 이동
도세제안의 모든 아이콘 구현
- 확인 페이지 카피 문구
- [나의 도서제안], [상세] 버튼 아이콘
기술적인 부분이 맞을 지는 알 수 없으나, 만일 내가 프론트엔드 개발자라면 저런 식으로 페이지를 구성하지 않을까 추측하며 작성을 해보았다. Jira의 경우 하나의 백로그를 클릭하였을 때, 그 안에 설명을 적을 수 있기 때문에 위의 description을 기입하였다.
역할 분담
역할 분담의 경우, 페이지를 구현하는 것은 프론트엔드 개발자가 하고 데이터베이스를 구축하는 것은 백엔드 개발자가 한다고 할 수 있다. 또한 도서 제안 아이콘을 구성하는 것은 밀리의 서재 디자인팀에서 맡으면 된다.
Jira의 경우, 사람 아이콘을 클릭하면 각자에게 역할을 분담할 수 있다.
그래서 지인의 이메일을 빌려 각자 SB프론트엔드, JH 백엔드, BJ 디자이너로 나누어 할당해보았다. (이메일 공유 감사합니다 ㅋㅋ) 그러자 담당자가 할당된 것을 확인할 수 있다.
그리고 위의 모든 백로그를 스프린트 계획하기 란으로 옮기고 [스프린트 시작]을 누르면 스프린트 title과 기간을 설정할 수 있는 화면이 나온다.
앞서 이야기한 것처럼 스프린트 이름을 [도서 제안 서비스 기획] 으로 두고 기간을 2주로 설정한 후 시작을 누르면, 다음과 같이 스프린트가 시작된 것을 확인할 수 있다.
실제 프로덕트를 개발할 때는 위보다 더 복잡한 형식으로 Jira를 사용해보겠지만, 그에 대한 지식은 없어 여기까지 하는 것으로 이번 포스팅을 마치고자 한다. 실무에서는 어떻게 사용할 지, 얼른 PM으로서 확인해보고 싶다.
참고자료.
