사용자 스토리 워크샵에서 해야 할 일

사용자 스토리 워크샵은 최초 스프린트 시작 전에 수행하는 것이 일반적이다. 스프린트에서 수행해야 하는 단위를 사용자 스토리 단위로 수행함으로써 사용자 관점의 개발이 가능하기 때문이다. 사용자 스토리 워크샵을 마친 후 스프린트 계획을 수립하고 개발과 평가를 수행한다. 평가에 따라 스프린트를 반복 수행하게 되는데 기본적인 반복은 사용자 스토리 워크샵을 마치면서 정하는 것이 좋다(그림5).

<그림5> 사용자 스토리 워크샵과 스프린트(개발) 수행

그림5에서 보는 것처럼 사용자 스토리 워크샵은 스프린트 수행을 위해 필요한 것들을 정리해야 한다. 사용자 요구사항을 명확히 해야 하고, 요구사항을 구현할 때 나타날 수 있는 위험 요소(Pain Points), 애자일 기반으로 접근하는 프로세스, 형성된 공감대를 소프트웨어에 담기 위한 방법, 개발을 위한 액티비티 등을 정의한다.

사용자 스토리 워크샵에서는 스프린트에서 역할별로 해야 할 일도 구분해서 정리해야 한다(그림6). 그림5에서 나타난 기능(Feature)들을 대상으로 역할별로 참여해야 하는 범위와 해야 할 일을 자세하게 정의해야 스프린트를 수행할 때 어려움이 없다. 그림7이 QA(Quality Assurance)가 해야 할 일을 정의한 예이다. 해당 항목들은 누가, 언제, 어떻게 할 것인지 세부적으로 정의되어 있다.

더보기

사용자 스토리 워크샵의 티밍 방향

SI에서는 티밍을 개발 프로젝트 시작 전에 해서 종료 할 때까지 유지하는 것이 일반적이다. 중간에 문제가 발생하지 않는다면 바꿀 이유가 없다고 생각하지만 프로젝트 수행 중에 보면 많은 팀원들이 역할을 바꿔가며 업무 수행하고 있는 것을 쉽게 볼 수 있다. 이 것은 잘못된 것이 아니라 상황에 따라 적절한 역할이 필요하다는 것을 보여주는 사례로 봐야 한다.

사용자 스토리 워크샵을 하는 시점은 언제라고 정해지진 않는다. 원하는 시점에, 필요한 시점에 할 수 있다. 일반적으로, 애자일 프로젝트가 수행될 때 스프린트(Sprint) 단위로 진행되는데, 첫 번째 스프린트가 시작되기 전에 하는 경우가 많다. 스프린트의 범위가 정해지면서 필요한 역할자도 함께 구성되어야 하기 때문이다.

사용자 스토리 워크샵에서 정하는 티밍은 스프린트가 시작하면서 각 역할을 수행하게 한다. 그림4는 Thoughtwork사에서 제시하는 티밍 가이드이다. 코어팀(Core team)을 중심으로 티밍이 이루어지는데 경우에 따라 확장팀(Extended team)의 역할도 참여를 시킬 수 있다.

<그림4> Thoughtwork사의 티밍 가이드

출처: Thoughtwork

더보기

사용자 스토리 워크샵의 기본 사상

애자일의 인기가 높아지면서 애자일 개발 방식을 지원하는 개발 도구가 많이 나오고 있다 아틀라시안(Atlassian), 액소소프트(Axosoft) 등이 대표적이다. 이러한 도구는 코드에 나타난 오류나 작업량을 지속적으로 추적할 수 있게 해주고 개발 진행 상황을 체계적이고 자세하게 알 수 있도록 도와준다. 하지만, 개발에 필요한 사항을 공유하는 것이기 때문에 사용자와 개발자 간의 간극은 쉽게 줄어들지 않는다. 사용자 스토리 워크샵은 사용자와 개발자 간 생각의 차이를 없애주는 것에 가장 큰 목적이 있다(그림2).

<그림2> 사용자 스토리 워크샵의 목적

개발 프로젝트에 참여하는 사람들이 소프트웨어를 다르게 생각하면 안되기 때문에 이에 대한 공감대 형성이 사용자 스토리 워크샵에서 가장 먼저 해야 할 일이다. 공감대가 형성한 후 공감대를 실체화 하면서 사용자 스토리(User Story)를 만든다(그림3).

<그림3> 사용자 스토리 워크샵 프로세스의 예

사용자 스토리의 관점은 개발자가 아닌 사용자 관점이다. 따라서, 애자일도 마찬가지지만 사용자 스토리 워크샵에서 가장 중요한 점은 사용자가 반드시 참여해야 한다는 것이다. 사용자가 없는 상태에서 사용자 스토리를 작성하는 것은 기존 SI 개발 방식과 크게 차이가 없다고 봐야 한다. 사용자를 사용자 스토리 워크샵에 참여시키고 사용자가 가지고 있는 생각을 좀더 많이 알아내기 위해서는 효율적이고 체계적인 티밍이 필요하다.

더보기