스토리 프로세스에 대한 가장 좋은 설명이 존 레프리즈가 쓴 Extreme Programming Installed에 쓰여 있다.
카드(card) : 만들려고 하는 소프트웨어에 무엇을 기대하는지 인덱스 카드에 쓰기
대화(conversation) : 어떤 소프트웨어를 만들지 함께 모여 많이 이야기하기
대화는 아마 생각하고 있는 것을 묘사하면서 시작할 것이다. 듣는 사람은 들은 내용을 기반으로 머릿속에 아이디어를 형성할 텐데, 무언가를 완벽하게 설명하기란 어렵고, 각자의 과거 경험을 바탕으로 다른 것을 떠올리기 쉽기 때문에 듣는 사람이 상상한 것은 내가 상상한 것과 다를 수 있다. 하지만 바로 그런 이유로 마법이 일어난다.
이건 대화이기 때문에 듣는 사람은 질문할 수 있고, 올바로 이해할 수 있도록 정정해서 알려줄 수 있다. 대화는 이처럼 서로가 주고받으면서 모두가 같은 공유된 이해에 다다를 수 있도록 한다.
전통적인 소프트웨어 개발 프로세스에서 요구사항을 가진 사람의 목표는 요구사항을 정확하게 작성하는 것이다. 그 소프트웨어를 만들 사람에게 정확하게 이해시키기 위해서다. 허나 지금 하려는 일은 스토리 기반 프로세스이기 때문에 여러분 각자는 이전과는 다른 공유된 이해를 갖는다. 여러분의 목표는 소프트웨어를 만들어 해결할 수 있는 문제를 이해하고, 가능한 한 최선을 다해 문제를 해결하는 것이다. 즉, 제품 사용자를 돕는다고 믿는 것을 만들어야 한다는 점에 동의해야 한다.
승인(confirmation) : 모두가 동의하는 소프트웨어가 완료된 것을 승인할 (수 있는) 방법 찾기
실질적으로 이야기해야 할 내용에 대한 점검 목록
'누구'에 관해 이야기하기
제발 '그 사용자'라고 하지 말고 상세하게, 어떤 사용자를 뜻하는지 이야기하자. 특히 소비자용 소프트웨어의 경우 같은 기능을 사용하더라도 사용자 유형은 매우 다를 수 있다. 다른 사용자의 관점에서 그 기능에 대해 이야기하자.
고객에 대해 이야기하자. 소비자용 제품의 경우, 고객(또는 결정자)은 아마 사용자와 같은 사람일 것이다. 하지만 기업용 제품의 경우, 구매 결정을 내리는 사람과 전체 좆기, 그리고 어떤 이점이 있는지에 대해 이야기해야 한다.
다른 이해 관계자에 대해 이야기하자. 해당 소프트웨어를 구매할 수 있도록 지원하는 사람에 대해 이야기하자. 사용자와 협업할 수도 있는 사람에 대해서도 이야기하자.
중요한 사용자가 단 한명인 경우는 매우 드물다.
'무엇'에 대해 이야기하기
내가 선호하는 방식은 소프트웨어로 사람들이 하고 싶어하는 것, 즉 사용자 활동으로 스토리를 시작하는 것이다.
서비스와 그 서비스를 호출하는 여러 시스템에 대해 이야기하는 건 괜찮다. 특정 UI 컴포넌트와 화면이 어떻게 동작하는 지에 대해 이야기하는 것도 괜찮다. 단지 누구를 신경 쓰고 왜 그런지에 관해서만 잊지 않으면 된다.
'왜'에 대해 이야기하기
특정 사용자가 어떤 스토리에 관심을 가지는 이유에 대해 이야기하자. 그리고 '왜'를 깊이 파고들어 보자. 때로 그 '왜'는 한개가 아니기도 하고, 그것들 간에 계층구조가 생기기도 하기 때문이다. 따라서 근본적인 이유를 찾을때까지 오랜 시간을 들여 왜에 대한 답을 찾아보자.
소프트웨어 밖에서 무슨 일이 일어나는지 이야기하기
여러분의 제품이 어디에 쓰이는지 이야기하자. 사용자들이 언제 여러분의 제품을 쓰고, 얼마나 자주 사용할지 이야기하자. 그때 다른 사용자는 누가 있을지도 함께 이야기하자.
잘못되는 경우에 대해 이야기하기
무언가가 잘못되면 어떻게 되는가? 시스템이 다운되면 어떻게 되는가? 사용자가 선택할 수 있는 대안은? 현재 어떻게 하고 있는가?
질문과 가정에 대해 이야기하기
앞서 언급한 이 모든 것에 대해 이야기해보면 몰랐던 점을 발견할 수 있다. 의문점을 찾아내고 소프트웨어를 만들기 전에 답을 얻어야 할만큼 중요한지 토론하라. 답을 얻는데 필요한 사람이 누군지 결정하고 다음 대화때 참여시키자. 어떤 스토리는 검토할 때 아주 많은 대화가 필요할 수도 있다.
여러분의 가정에 의문을 가져보자. 사용자를 진정 이해하고 있는가? 이게 정말 그들이 원하는 해결책인가? 이 문제가 사용자의 진짜 문제인가? 이 해결책을 정말 사용할까?
여러분의 가정에서 기술적인 부분에 대해 질문해보자. 우리가 의존하고 있는 기반 시스템은 무엇인가? 그것들이 정말 우리가 생각하는 방식으로 동작하는가? 고려해야하는 기술적인 위험 요소가 있는가?
더 나은 방안에 대해 이야기하기
정말 큰 이점은 해결책은 이래야 한다는 원래 가정을 버리고 다시 문제로 돌아간 뒤 모두 함께 더 효과적이고 경제적인 해결책을 찾아낼 때 나온다.
'어떻게'에 대해 이야기하기
실제로 좋은 스토리 대화에서는 어떻게, 무엇, 왜 이 세가지 모두를 최적화하려고 노력한다. 스토리 대화가 잘못되는 경우는 대화에 참여한 사람들이 특정 방안이나 그것이 구현된 방식을 '요구사항'이라고 가정할 때다. '어떻게'(물론 여러분이 개발자라면 고려하겠지만)에 대해 명확히 이야기하지 않고는 (소요될) 비용을 생각하기 어렵다.
해결책을 구현하는 데 예상되는 소요 비용이 너무 크다면 그다지 좋은 선택이 아닐 수 있다.
얼마나 걸릴지 이야기하기
궁극적으로 어떤 것을 만들지 혹은 그만둘지 결정해야 한다.
소프트웨어 영역에서는 코드를 작성하는 데 걸리는 시간을 의미한다. 초기 대화에서는 아마 '아주 긴 시간'이나 '며칠'처럼 표현될 수도 있다. '지난 달에 만든 댓글 관련 기능과 비슷하게'처럼 이미 만들어져 있는 스토리와 비교하면 더 좋다.
무언가를 만들어야 할 때가 가까워지면 더 많은 대화를 하고 더 많은 결정을 내려야 하므로 좀 더 정확해질 수 있다. 하지만 우리는 늘 약속이 아닌 추정을 이야기한다는 점을 기억하자.
