Story Mapping, Product Backlog를 시각적으로 구성하는 방법
졸업프로젝트를 시작한지 한달…. 이제 대략적인 컨셉이 잡혔다. 프로젝트 구현에 앞서 구체적인 개발 계획을 짜야한다. 애자일 방법론을 활용한 프로젝트 관리를 알아보자. 애자일 방법론에서 제일 선행되어야 할 일은 Product backlog이다.
Product backlog
Product backlog는 프로젝트에서 구현해야할 모든 List를 말한다. 그렇다면 Product backlog는 어떻게 작성해야 할까?
누가, 무엇을,왜 3가지 항목을 포함하여 작성해보자 (사실상 유저 스토리 작성법)
-
누가(type of user)
여기서 누가는 고객이나 사용자를 말한다. 연령대,취미등을 고려하여 구체화시키면 좋다. 예를 들자면, 30~40대 안전한 거래를 원하는 여성 주부들 -
무엇을(goal)
누가에 해당하는 이해관계자의 goal이다. -
왜
단순하게 왜 해당기능을 사용하는지 이기도 하지만 결과적으로 누가에 해당하는 고객이나 사용자가 얻을 수 있는 이점이 된다.
Product Backlog 작성시 생각해야할 3가지
- Product Backlog는 항상 우선순위에 따라 정리한다.
팀 내부 판단하에 중요한 일들은 올리고 상대적으로 덜 중요하거나 기한의 여유가 있는 일은 백로그의 아래로 위치시킨다. - Detail and Rough
백로그 상단에 위치한 일들은 중요도가 높은 일이기 때문에 Detail한 표기가 필요하다. 반대로 하단에 위치한 일들은 상대적으로 Rough해도 괜찮다. 자세할수록 좋겠지만, 최소한 제품이 지향하는 핵심가치나 차별화 포인트가 드러나야한다. - Product Owner
프로덕트 오너는 백로그를 관리하는 사람이다. 일들의 우선순위를 정하고, 새로운일을 추가하거나 이미 진행중인 일들을 수정하기도 한다. 그래서, 프로덕트 오너는 모든 StakeHolders들과 의사소통하고 이를 백로그에 반영하여 한다.
요구사항의 우선순위 정하기
(MoSCow 방법)[https://wemake.services/meta/rsdp/requirements-analysis/#requirements-prioritization]
총 4가지 카테고리로 요구사항을 나눈다.
must, should, could, and won't
Sprint Backlog
Product Backlog를 작성했으면 Sprint Backlog를 정해야한다.
Sprint는 무엇인가?
Sprint란 작은 기능 하나에 대한 계획부터 개발, 테스트, 기능 구현까지의 주기를 말한다.
대략 1~4주 사이의 기간으로 정해진다.
Sprint Backlog는 해당 Sprint기간에 해야할 백로그다.
하지만 당장 해야할 일들이기 때문에 백로그에 위치할 때보다 더 세분화 되어야 한다. 주로 task형식으로
Burndown Chart
위에서 Sprint를 알아봤다. 번다운 차트는 스프린트동안의 개발 진행정도를 알려주는 차트다.
daily scrum에서 매일 업데이트 된다.
Story Mapping
요구사항 분석하는 top-down 방식 tree형태로 그려진다. Story Map의 최상단은 Vision이다. 이 Vision은 Goal을 통해서 이루어진다. 그리고 이 Goal은 activities에 의해서 이루어진다. 다시 이 activites는 Task로 이루어지고, 이 Task는 User Story가 된다.
Story Map Structure: Goals > Activities > Tasks > Stories 순이다.