[북리뷰] 사용자 스토리

개발자들은 크든 작든 고객에 대한 피해의식을 갖고 있다. 그것은 한 두 번의 경험으로 형성된 것이 아니다. 그 경험이란 것은 바로 고객의 요구사항이 이랬다 저랬다 하며 바뀌는 것인데, 이것을 경계하기 위해 다양한 장치로 고객의 변심을 방어하려고 시도해 본다. 그러나 이마저도 마땅치 않다. 그리하여 개발자들은 고객에 휘둘리는 상황을 항상 경계하며, 요구사항을 끌어내고 가두려 노력한다. 그런 결과물이 요구사항 정의서나 요구사항 추적매트릭스가 되는 셈이다. (좀.. 오버했나? ㅡㅡ;)

 

 

 

이 책은 그런 요구사항 정의서로 고객을 가두려 하지 말라고 충고한다. 저자가 제안하는 방법은 "사용자 스토리를 작성하라"는 것이다. 사용자 스토리는 간단한 말 한 마디로, 고객이 원하는 것을 짦막하게 전하고 있지만, 고객이 가치있다고 판단하는 진정한 요구사항에 부합하도록 하는 진술문이다. 예를 들면 다음과 같다.

 

사용자는 자신의 이력서를 웹사이트에 게시할 수 있다.

 

 

고객의 원하는 가치가 명확하게 전달된 문장이다. 그러나 어찌보면, 조금 단위가 클지도 모른다. 이력서에 포함될 내용이 빠져 있으니, 그런 부분들로 서서히 나뉘어질 수 있겠다. 이렇게 단위가 큰 스토리를 에픽이라고 일컫는데, 이는 고객과 대화하면서 점점 구체화 되어가며, 자리를 잡아 간다. 따라서 사용자 스토리는 어떤 면에서는 고객과 대화를 하기 위한 단초가 되기도 한다. 그렇다고 너무 세분화 할 필요는 없다. 다만, 해당 스토리들을 적은 카드 뒷면에는 가치가 어떻게 테스트 될 것인지 적어 두어야, 테스트 시에 위력을 발휘할 수 있을 것이다.

 

사용자 스토리의 주어는 되도록이면 "사용자는"으로 하는 것이 좋다. 다음과 같은 사용자 스토리는 적절치 못하다.  

소프트웨어는 C++로 작성한다.   프로그램은 커넥션풀을 통해 데이터베이스에 연결한다.

 

이런 스토리는 고객에게 아무런 가치가 없다. 사용자 스토리는 고객에게 어떤 가치가 있는지 명확하게 드러나도록 작성해야 한다. 그리고 되도록이면 고객 스스로 작성하게끔 해야 한다. 한국 실정에서는 조금 현실감이 떨어지지만.

 

성공적인 사용자 스토리를 위해서는 사용자 역할 모델링을 통해 가상의 사용자를 추려볼 수 있겠다. 우선은 브레인스토밍을 통해 사용자 목록을 만든 후, 그룹화 한다. 그리고 등장인물군을 다듬는데, 이름을 부여한다든가, 구체화시키고 심지어는 사진도 오려 붙인다. 그렇게 할 수록 사용자 스토리에 도움이 될 수 있을 거라는 저자의 제안은 상당히 설득력이 있다고 생각한다.

 

사용자 스토리는 워크샵을 통해 이루어질 수 있고, 인터뷰를 동반할 수 있으며, 최대한 피해야 하지만, 어쩔 수 없는 경우엔 설문을 하는 수도 있다. 설문은 추가적인 질문이 사실상 불가능하기 때문이다.

 

모아진 사용자 스토리는 개발자들에 의해 추정된 시간으로 환산이 될 수 있는데, 이때는 고객이 함께 참여하더라도 발언 할 수 있는 기회는 없다. "개발자들이 추정하는 동안 고객도 참가하게 되지만, 고객은 자신이 수긍할 수 없는 경우라도 개인적인 추정치를 제시하거나 사견을 주장하는 것이 허락되지 않는다." (p.135) 개발자들 중 최고 추정시간과 최저 추정시간을 감안하여, 합리적인 추정 근거에 의해 예상 개발 시간이 최종 결정되어지고, 이를 토대로 우선순위를 부여하여 잘게 쪼갠 이터레이션 단위로 릴리즈 계획이 세워진다.

 

보통 한 달여 기간동안을 이터레이션으로 잡는데, 이 기간 동안 개발될 내용들은 사용자 스토리의 많은 추정계획 중 한 달 분량만 추려내어 계획하게 되는 것이다. 이는 애자일 기법인 스크럼에서 말하는 스프린트와 유사한데, 실제로 사용자 스토리는 XP(익스트림 프로그래밍) 방법에서 시작되었으나, 스크럼 쪽에서도 응용이 가능한 부분이라고 저자는 말한다. 내가 생각하기에도 스크럼의 앞부분에 해당하는 요구사항 분석, 즉 백로그 수집 행위에 추가될 수 있는 좋은 방법이다.

 

다음은 이 책을 읽으며, 생각을 확장시키거나 새롭게 깨닫게 해준 몇몇 문장들을 정리한 것이다.

 

해답은 한두명의 개발자를 ‘스파이크(spike)를 수행하도록 하는 것이다. 스파이크를 하는 동안 개발자들은 작업을 추정할 수 있을 정도로 내용을 습득할 수 있다. 스파이크 자체는 최대 허용 시간(타임박스)을 정하고 항상 그 시간만큼 부여하는 방식으로 추정할 수 있다. (p.54)

 

스파이크라는 행위가 있는 줄도 몰랐는데, 새로운 분야에 대한 사전 추정작업 정도로 이해하게 해준 문장이다.

 

가끔은 나서기 좋아하는 관리자가 사용자 역할을 하겠다고 자처하는 경우도 있다. 그런 유형의 관리자는 자신이 사용자가 아님을 인정하면서도 무엇이 필요한지 실제 사용자보다 더 잘 안다고 주장한다. 이런 상황에서는 관리자의 기분을 상하게 만들지 않도록 조심해야 할 것이다. 즉, 관리자의 의견을 부분적으로 수용하기는 하되, 프로젝트의 성공을 위해 최종 사용자들에게 다가갈 수 있는 길을 찾아야만 한다. (p.94)

이런 관리자 분들 꼭 있다. 그럼에도 기분상하게 하지 말라는 키 포인트는 좋은 고언이라고 생각한다. 너무 곧으면 부러지는 법.

 

과거에 놓쳤던 판매 기회의 중요성에 따라 관련 스토리를 한두 개 추가하는 것도 괜찮지만, 그것에 지나치게 매달리는 개발 회사라면 제품에 대한 기업의 전략적, 장기적 비전을 놓치기 쉽다. (p.96)

제품의 발전에 영업사원의 의견이 소중하게 작용할 수도 있지만, 이는 어느정도 실제적인 검토가 필요한 부분이다. 영업사원에 상처에서 기원한 요구사항은 보다 중요한 그 무엇을 놓치게 만드는 원인이 될 수 있으니 말이다.

 

해당 분야 전문가를 대리 사용자로 이용할 때의 또 다른 잠재적 문제점은, 최종 소프트웨어가 전문가 정도의 지식 수준에 맞추어질지도 모른다는 것이다. 해당 분야 전문가들은 프로젝트의 개발 방향을 자신들의 수준에 맞게 개발하도록 유도할 수 있는데, 이는 너무 복잡하거나 대상 사용자 층을 잘못 선택하는 결과를 가져올 수 있다. (p.98)

그런 전문가와 일을 하다보면, 위에서 저자가 말하는 바를 알 수 있다. 특히 교수들...

 

스토리 카드의 주 목적은 구현할 기능을 논의하기 위한 단서 역할이라는 점을 잊지 말아야 한다. 단서는 간결해야 한다. 카드에는 나중에 대화를 재개하기 위해 기억하면 될 정도의 세부사항만을 써넣도록 하며, 너무 많은 세부사항을 써넣어 카드의 대화를 대신하지 않게 한다. (p.128)

사용자스토리를 요구사항정의서 대용으로 쓰면 어떨가 하던 찰라에 만난 주의를 환기시키는, 본질로 되돌려 보내는 중요한 문장이라 여겼다.

 

PM들이 간과하기 쉬운 부분을 지적한 다음의 짧은 조언을 기억하고 싶다.

 

소비 작업시간이 아닌 남은 작업시간을 추적한다.일일 소멸 차트는 스토리나 작업에 대한 소비 작업량이 아닌 남은 작업량을 반영한다는 점을 주목하라. 소비 작업량을 추적하는 것도 나름대로 합당한 이유가 있다 (계획 작업량과 실제 작업량의 비교를 통한 추정 능력 향상, 주별 실제 작업 시간 모니터링 등). 하지만 그렇게 하면 안 되는 더 중요한 이유가 있다(대부분의 개발자가 지나치다고 느낄 만큼의 관리, 부정확한 추정치 등). 게다가, 정말 중요한 것은 지금까지 작업량이 얼마나 투입되었는지가 아니라 앞으로 작업량이 얼마나 남았는가다. (p.179)

 

 

마지막으로 사용자 스토리와 관련된 구글링 결과들이다. 하나 같이 도움이 되는 글들이라 생각한다.

 

애자일 – 사용자 스토리 요약 사용자 스토리 왜 사용자 스토리인가 사용자스토리 실무적용 사례 사용자 스토리 : 고객 중심의 요구사항 기법