[코드스테이츠 PMB 16기 W8] 데일리샷 가상의 스프린트 플래닝

이번 주 몰입학습에서는 한 주 내내 애자일에 대해 배웠다. 그동안 '애자일하다'라는 것에 대해 막연하게 이미지 정도만 갖고 있었는데, 이번 주에 학습을 하며 프로세스에 대해 조금은 이해하게 되었다. 위클리 과제도 어느덧 마지막인데, 그동안 했던 데일리샷의 분석・기획들을 통해 스프린트 플래닝을 해보기로 했다.

현재 프로덕트의 시점에서 개선해야 할 문제는 무엇인지 정리합니다.

개선해야 할 문제 정의

이번 글은 W3 ~ W4 위클리 과제를 바탕으로 쓰여졌다.
본문 중 필요한 부분들은 다시 소개할 예정이다.

[코드스테이츠 PMB 16기 W3] 데일리샷의 MVP를 만들어보자

[코드스테이츠 PMB 16기 W4] 데일리샷 리뷰 시스템의 MVP 기획 문서 작성

W3 과제에서는 데일리샷의 여러 개선점들을 정의했다.
W4 과제에서는 그들 중 리뷰의 유용성이 떨어진다는 점을 골라 리뷰 시스템을 리뉴얼하는 MVP를 기획했다.
이번 W8 과제에서는 리뷰 시스템 리뉴얼을 진행한다면 첫번째로 하게 될 스프린트를 계획해보았다.

 

정의된 문제를 기반으로 사용자 스토리를 작성하고, 이를 바탕으로 개선/개발/구현해야할 기능을 작성합니다.

유저 스토리

리뷰 시스템 리뉴얼에 대한 유저 스토리는 다음과 같다.

사용자들은 리뷰에서 더 유용한 정보를 쉽게 얻기 위해 리뷰 경험의 변화를 원한다.

리뉴얼의 전체 작업에는 기존의 리뷰를 새롭게 개선하는 것 뿐만 아니라 실시간/베스트 리뷰, 리뷰요청 알림 기능까지 포함되기 때문에 포괄적인 유저 스토리로 작성했다. 이는 스프린트 단위로 다시 구체화될 것이다.

 

구현해야할 기능

리뷰 시스템 리뉴얼에 필요한 전체 기능은 아래의 구글 시트에 정리되어 있다.
W4에서 정의했던 요구사항과 거의 동일하며, 실제 서비스에 있었던 픽업 매장 및 경험 리뷰가 추가되었다.

PMB16-데일리샷-요구사항정의서

 

작성된 사용자 스토리와 기능을 카노 모델을 활용하여 평가하고 우선순위를 설정해보세요.

카노 모델로 기능 우선순위 정하기

카노 모델은 기능의 충족에 따른 만족도로 기능을 평가하는 분석 방법이다.
평가 분류는 다음과 같다.

당연한 품질 Must-be Quality
충족된다고 만족을 주지는 않지만 충족되지 않으면 불만스러움

매력적 품질 Attractive Quality
충족되지 않아도 고객이 불만스러워하지 않지만 충족되면 고객에게 만족을 줌
이전에는 매력적 품질이었다고 해도 시간이 지나면 당연한 품질로 간주될 수 있음

일원적 품질 One-dimensional Quality
충족에 따라 고객 만족도가 오르내림
경쟁 제품보다 훨씬 높은 품질이면 매력적 품질에 필적하는 정도의 만족

무관심 품질 Indifferent Quality
충족이든 부족이든 고객 만족도에 영향을 주지 않는 요소입니다.

역 품질 Reverse Quality
충족되면 (의도치 않게) 불만족이 일어나고 불충족되면 만족됨

리뷰 시스템 리뉴얼에서 기획한 5가지의 기능을 카노 모델로 평가한 결과이다. 매력적 품질은 '있으면 좋지만 없어도 되는 것들'로 판단했고, 우선순위를 낮게 잡았다. 무관심 품질인 '리뷰 요청' 역시 사용자가 원하기보다는 더 많은 리뷰를 쓰게 하기 위한 방법이므로 우선순위가 밀렸다.

일원적 품질이라고 적은 것들은 조금 의아하게 느껴질 수 있을 것 같다. 리뷰 기능 자체는 상품 페이지에서 꼭 있어야 할 '당연한 품질'이다. 하지만 리뷰를 리뉴얼한다는 것은 사용경험 차원에서 평가해야 한다. 어떤 서비스는 리뷰가 말 그대로 '조회'만 가능해서 불편한 반면, 어떤 서비스는 옵션 별로 필터링하거나, 원하는 값으로 정렬할 수 있게 하여 손쉽게 원하는 정보를 얻을 수 있게 해놓았다.

나는 현재 데일리샷의 리뷰 조회 기능이 -5점부터 +5점까지 있을 때 -2 정도에 해당한다고 판단했고, 이를 +2로 돌리는 것이 매력적/무관심 품질에 해당하는 기능을 개발하는 것보다 우선순위가 높다고 생각했다.

 

정리한 내용을 바탕으로 가상의 프로덕트 팀을 대상으로 스프린트 플래닝을 진행하기 위한 문서를 정리해주세요.

스프린트 목표

상품별 리뷰 화면과 리뷰 작성 과정을 리뉴얼한다.

이번 스프린트는 전체 작업 중 첫번째 스프린트이다. 따라서 어떤 작업을 가장 먼저해야 하는지 정할 필요가 있었다.

실시간/베스트 리뷰와 리뷰 알림 요청은 새롭게 만드는 기능인 반면, 상품별 리뷰와 리뷰 작성은 기존 시스템을 변경해야 하는 기능이다. 전체적인 리뷰의 레이아웃을 변경하는 작업을 한 이후에 실시간/베스트 리뷰를 도입하는 것이 순서상 맞다고 판단되어 첫번째 스프린트의 목표를 위와 같이 정했다. 

 

목표달성 평가 핵심지표 설정

1. 리뉴얼 이후 1개월 간 ASTMO 리뷰 사용률 50% 이상
2. 리뉴얼 이후 3개월 간 작성된 리뷰당 '도움이 돼요' 수의 평균 기존 대비 30% 이상 증가

이번 스프린트에서 달성해야 하는 것은 ASTMO의 실제 사용률과 리뷰의 유용성 증가이다. 

 

스프린트 백로그

백로그는 다음과 같이 작성했다.
에픽으로는 리뷰 작성 / 상품별 리뷰 두 가지 기능이 해당되며,
각각의 요구사항을 유저 스토리 형식으로 등록했다.
요구사항을 구현하기 위한 개발 작업은 태스크로 등록했다.
각 이슈마다 어떤 에픽에 해당하는지 식별할 수 있게 하였다.

백로그를 작성하면서 느낀 것은,

첫번째로 이슈 단위당 설정해야 하는 업무의 규모를 결정하는 것이 어려웠다. 예를 들어, '에픽으로 설정해야 하는 일들은 어떤 것인가?', '스프린트 하나에는 얼마나 많은 이슈를 넣어야 하는가?' 등이 있다.

두번째로는 이슈의 네이밍 컨벤션(규칙)을 정하는 것이 어려웠다. 예전에 기업에서 지라를 잠깐 써본 적이 있는데, 그때는 iOS와 안드로이드를 나누어 명시했던 걸로 기억한다. 따라서 나 역시 그렇게 했는데, 그렇다면 서버는 [서버]라고 명시해야 할지 아니면 굳이 쓰지 않아도 괜찮을지 고민됐다. 일단 서버의 업무는 프론트처럼 같은 작업을 다른 환경에서 할 일이 없을 것이라고 판단되어 넣지 않았다.

예전에 내 컴퓨터에 있던 폴더들을 효율적으로 관리할 수 있도록 네이밍 컨벤션을 적용했던 경험이 있다. 각 폴더마다 용도와 뎁스가 달라 완벽하게 정리하지는 못 했고, 이름 앞에 덕지덕지 기호들이 붙게 되었지만 이전보다는 구별하기 쉬워졌다. 지라 같은 경우에 식별자가 자동적으로 생성되기에 굉장히 편리할 것 같다. 하지만 추가적인 식별이 필요하다면 이슈명에 그 정보를 넣게 될 것이다. 그때 어떤 방식으로 표기할지 잘 결정하고 모두가 그 룰을 지켜야 체계적인 관리가 가능할 것 같다. 

 

역할 분담 및 태스크 작성

모든 태스크의 목록은 다음과 같다.
역할은 데일리샷의 개발팀 구성대로 서버 개발자 / iOS 개발자 / AOS 개발자 / 디자이너로 구분하여 태스크를 배정했다.
이 역시 이전 과제를 바탕으로 재구성하였다.

 

실제 지라의 이슈 화면

전체 이슈 파일

스프린트 이슈.html

1.56MB

지라에 실제로 메일을 여러 개 등록해서 개발자와 디자이너 계정을 만들었다. 각 이슈마다 담당자를 등록했는데, 대부분 프론트 개발자가 해야 하는 일이었다. 백엔드에서 해야할 일은 추가될 ASTMO 형식에 맞게 데이터베이스를 수정하는 정도로 생각해보았다. 백엔드에 대해 잘 알지 못 해서 많은 태스크를 만들지는 못 했지만, 현업에서라면 실제 개발자와의 소통을 통해 만들어가면 될 것 같다.

실제 지라 링크를 걸어서 누구나 볼 수 있게 하기 위해 서치해서 설정도 이리저리 바꿔봤는데 계속 로그인을 요구해서 대신 HTML 파일을 등록했다. 대부분의 정보가 있고, 식별 가능하게 구조화되어 있어 참고가 될 것 같다.

---

실제로 백로그와 스프린트를 만드는 과정은 혼자 하기에 매우 어려웠다. 어떤 기능이 완성되기 위해 정확히 어떤 태스크들이 필요한지 내가 모두 파악할 수 없기 때문이며, 그 태스크들에 얼마 만큼의 자원이 소요될지도 예측할 수 없기 때문이다. 따라서 실제로 작업을 할 개발자와 디자이너들의 의견을 최대한 수렴하되, 비즈니스 일정도 맞출 수 있도록 조율하는 과정이 가장 중요한 포인트일 것 같다.