《사용자 스토리 맵 만들기》를 작년 5월 11일에 사서 분명히 다 읽었는데(북마크, 밑줄도 있다), 막상 써먹을 때가 되니까 전혀 기억이 나질 않아. 이래서 꼭 노트 정리를 해야 하는 건데, 대충 빠르게 읽어서 그런 것 같네.😩
애자일 방법론에서 쓰는 ‘스토리’는 제품, 서비스를 만들 때 무엇을 만들지 사용자 관점에서 제작/개발에 참여한 사람들이 함께 정의하는 단위야. 보통 ‘누가’, ‘무엇을’, ‘왜’의 세 가지 요소와 해당 스토리가 완성됐다고 판단하는, 합의된 '인수 기준'(acceptance criteria)을 포함하지.
“사용자 스토리의 진정한 목표는 이해한 내용을 공유하는 것”이라고 이 책은 못 박고 있어. 그리고 다음 세 가지만은 꼭 기억해 달라고 하는데,
- 스토리는 요구사항 형태로 쓰지 않는다: 스토리 이야기하기는 단어와 그림을 이용한 협업을 통해 공유된 이해를 이끌어 내기 위한 장치다.
- 스토리는 요구사항이 아니다: 무엇을 만들어야 할지를 놓고 그 기준이 되는 우리 조직, 고객 그리고 사용자들의 문제 해결에 대한 토론이다.
- 여러분의 일은 더 많은 소프트웨어를 더 빠르게 만들어 내는 것이 아니다. 만들기로 한 것에서 얻을 수 있는 구체적인 성과와 영향력을 최대화하는 것이다.제프 패튼, 《사용자 스토리 맵 만들기》, p. xlix.
스토리 맵을 만드는 스토리 매핑 활동의 '표면적인' 절차는 이래.
여러 사람이 함께 모여 제품 스토리에 대해 이야기 한다.
사용자가 그 스토리에서 실행하는 각각의 큰 단계를 포스트잇에 적고 왼쪽에서 오른쪽으로 붙여 나간다.
그런 다음 맨 처음(왼쪽)으로 돌아가 각 단계별로 자세하게 이야기한다.
이때 나온 세부사항을 포스트잇에 적고 해당 단계의 아래에 세로로 붙인다.
결과적으로 이야기는 왼쪽에서 오른쪽으로 흘러가고 각 단계의 상세 정보는 위에서 아래로 기술된, 간단한 격자 모양의 구조를 이룬다.위의 책, p. xxiv.
이후 내용은 이 절차를 효과적으로 수행해서 성공적인 결과물을 만들어 내는 방법에 대한 설명이야(말은 쉽지). 아무튼 나는 나의 퇴락한 기억력을 곱씹으며 이 책을 다시 읽을 거야. 이제 믿을 것은 노트와 카드에 남은 기록뿐.
댓글
의견을 남겨주세요