[스토리]User Story Mapping

🤨 갑자기 스토리? 왜?

갑작스레 소프트웨어 설계팀에 들어가게 되었다. 사실 소프트웨어 설계라고는 해도 설계는 거의 끝난 상태였고 유지/보수를 위해 PM과 함께 일할 각 팀 사람들을 뽑아 만든 팀이다.

비전공자에 아직 코드도 버벅대면서 치지만 설계 파트에 들어가게 된 것이 어떻게 보면 부담이고 어떻게 보면 기회라 생각을 하고 설계팀 합류를 위해 책을 읽어보았다.

책은 Jeff Patton의 "User Story Mapping"이라는 책이다. 영어로 읽어서 술술 읽히지는 않았지만, 그래도 읽으면서 정리해두지 않으면 또 까먹을 것 같아서 블로그에 정리해두려 한다. 좋은 책이니 시간이 있다면 읽어보길 추천한다😎

🍳 들어가기 전에

스토리란?

위의 사진이 스토리를 표현하는 가장 대표적인 형태이다. 큰 메모지를 왼쪽에서 오른쪽으로 적으면서 하나의 스토리 즉, 해결해야 하는 고객의 문제들을 적고, 그 아래 세부 스토리들을 적어나가면 된다. 특히 이 과정에서 중요한 점은, 회의실 책상에 앉아서 맥북 모니터를 방패 삼아 본인 화면만 보고 얘기하는 것이 아니라, 모두 자리에서 일어나 큰 메모지부터 작은 메모지까지 그 스토리들을 하나하나 손으로 적어가면서 리액션이나 같이 동의한 부분 등을 기록하며 스토리들을 채워나가는 것이다. 그리고 이러한 스토리들은 애자일 개발 프로젝트를 위해 더 나은 백로그를 만드는데 도움이 된다.

애자일과 스토리에 관한 자세한 포스팅은 여기를 참고 바란다.

⛔ 공유 문서 != 공유 이해 ⛔

우리는 참 많은 문서들을 작성한다. 본인의 이해를 위해, 다른 팀과의 협업을 위해, 나중에 회의시간에 들고갈 나의 증거들을 위해.

하지만, 문서를 공유한다고 해서, 생각이 공유될 것이란 생각을 하면 안 된다. 같은 문서를 보고도 사람들은 다 다른 생각을 하게 된다. 그러니 작은 카드나 메모지에다 같이 이야기 하면서 생각을 정리하는 것이 오히려 효율적이다.

우리에게 중요한 것은 문서를 공유하는 것이 아니라 이해를 공유하는 것이다.

👨‍👩‍👧‍👧 사람 그 보다 중요한 것?

없다. 고객과 사용자가 원하는 것을 얻지 못 하면 회사는 원하는 것을 얻을 수 없다. 그리고 당신을 짤릴 것이다. 사용자에게 집중하라.

하지만, 우리가 구축해야하는 것은 우리의 리소스보다 항상 더 많다. 그 때, 빠르게가 아니라 적게에 집중하라.

Chapter 1. 큰 그림

• 얘기하면서 문서화(Talk and doc)하면서 생각을 가시화하고 구체화해라. 카드나 스티커에 아이디럴 생각한 직후 몇 마디 적고, 다른 사람에게 큰 동작과 함께 얘기하고, 모든 사람이 볼 수 있는 공유 작업 공간에 놓는다.

• 내려놓은 카드를 재구성하면서 대화하지 않고도 무엇이 우선순위인지, 어떤 순서로 진행할 것인지 합의된다.

• 이야기의 깊이에 들어가기 전, 이야기의 폭에 초점을 맞춰라. 전체 Flow를 완성하고 세부사항으로 들어가야 한다. 그러다보면 세부사항에 구멍이 있는 부분이 있을 것이고, 그 구멍을 인지하는 것만으로도 큰 소득이다.

• 스토리 맵을 완성하고 나면, 회사가 가지고 있는 리소스보다 훨씬 방대한 사이즈에 압도당한다. 따라서 이 때는 최소한의 스토리에 집중하고 목표를 줄이는 것이 중요하다.

Chapter 2. 건물을 적게 지을 계획을 세워라

• 사람, 시간 또는 돈보다 건설해야 할 것이 항상 더 많습니다. 언제나.

• 스토리 맵은 척추(Backbone)를 먼저 쓰고 그 아래의 디테일한 Body를 채워나가는 형식으로 채워져나간다. 그리고 이 과정은 각 팀 내에서 진행하고, 모든 팀이 모였을 때 다시 한 번 진행한다.

• 스토리 매핑을 해나가는 과정에서 스토리의 구멍을 찾을 수 있다. "만약?"이라는 단어로 시작하는 온갖 상상과 걱정들로 제품이나 기능에 대해 생각해보고 그를 위한 대응방안을 카드나 메모지에 적어나간다.

• 스토리가 너무 많아진다면, 팀 내에서는 무력감이 들 수 있다. 따라서 그 때는 시스템 내부가 아니라 시스템 외부에 집중하고 그에 포커스를 맞춰라. 그 때, 릴리즈를 나눠서, 개발 속도와 최소한의 기한에 따른 릴리즈 버전을 따로 설정하라. 즉, 릴리즈 로드맵으로 발전시켜라.

• 기능을 우선순위에 두지말고, 결과를 우선순위에 두어라. 하나의 결과를 얻고 나면 그 뒤에 보여지는 유저들의 행동에 변화가 있을 것이다. 그것에 또 하나의 스토리가 생겨날 수 있다.

• MVP는 출시할 수 있는 가장 형편없는 제품이 아니다. 원하는 결과를 성공적으로 달성하는 가장 작은 제품 릴리스이다. 당신이 만들 수 있는 제품이 사용자의 기대의 최소한보다 낮다면 당신은 실패한 것이고, 사용자 기대의 최대한 보다 높다면 당신은 너무 많은 리소스를 써버린 것이다.

Chapter 3. 더 빨리 배울 계획을 세워라

• 해결하려는 문제가 실제로 존재하는지 확인하라. 그리고 솔루션이 가치 있고 사용 가능한지 알아보기 위해 프로토타입을 만들고 사용자와 함께 테스트하라. 솔루션을 여러번 반복해서 고객에게 보여주고 피드백 받은 후 백로그를 구축하고 개발팀이 작업할 수 있도록 하라.

• 베타 고객에게 피드백을 받을 때마다, 현재 진행중인 스토리들을 위로 올리고 아래에 있던 중요순위가 낮은 스토리들을 한 칸 위로 올린다. 그리고 다음 스크럼 때 아래에서 올라온 것들에 대해 자세히 토론한다.

• 하나씩 기능을 추가하는 것이 아니라, 완성된 기능으로 유저가 원하는 것을 좀 더 스무스하게 전달하는 방식으로 개발 프로세스를 구축하라.

출처

• 루프를 만들어라. 빌드 -> 측정/검증 -> 학습 -> 또 다시 빌드

Chapter 4. 제 시간에 끝낼 계획

• 때때로 사람들은 약간의 변경을 위해 제품을 매핑해야 한다고 생각하고, 이를 매핑하지 않는 이유로 사용한다. 틀렸다. 대화를 하기위해 필요한 것만 매핑하라.

• 전체를 매핑하지 말고 1. 기능 전체를 슬라이스 하라. 2. 릴리즈 버전에 가까워지기 위해 계층화된 기능을 구축하라. 3. 모든 기능을 레이어링하여 기능을 다듬고 가능한 한 세련되게 만든다. 다만 이렇게 슬라이스 한 것은 사용자에게 릴리즈 되는 것이 아니라, 팀 구성원이 자신의 현재 위치를 확인하고 조사하는 데 사용하는 이정표이다.

• 그리고 이러한 프로세스의 좋은 점은 예산 대비 결과를 측정하는 데 용이하다는 것이다. 예산의 반이나 썼지만, 기능적으로는 1/3 밖에 구현하지 못 했다라던가 이런 것을 확인 할 수 있다.

• 소프트웨어를 만들 때는

  • Opening : 제품 전체에 걸쳐 있는 필수 기능 또는 자용자 단계에 초점을 맞춘다. 기술적으로 어렵거나 위험한 일에 집중한다. 제품이 엔드 투 엔드로 작동하는 것을 확인할 수 있을 정도로만 구축하라.
  • Mid : 기능을 채워라. 유저가 사용할 수 있는 선택적 단계를 지원하는 내용을 추가하라. 엄격한 비지니스 규칙을 구현하라.
  • End : 릴리즈를 다듬어라. 실제 데이터와 함께 프로토타입에서 보기 힘들었던 개선 기회를 찾고 적용할 수 있는 사용자의 피드백을 받아라.

의 순서로 진행하라. 그리고 이 과정을 MVP마다 반복하라.

Chapter 5~

책은 챕터 5까지 유저 스토리 매핑에 대한 대략적인 개념을 소개하고, 그 이후 어떻게 진행을 해야 실패 없이 유저 스토리 매핑을 진행할 수 있을지에 대해 이야기 한다.

하지만, 우리 회사 특성상 이러한 스토리 매핑을 실질적으로 진행할 가능성이 적어 개념적으로만 이해하고 회사에 맞춰 다시 팀내에서 회의를 하기로 했다.

그래도 책은 생각보다 재밌었고, 그 유명한 "애자일"한 개발 프로세스에 대해 조금이라도 더 알게되어 흥미로웠다.