사용자 스토리 워크샵 사례 연구 - 사용자스토리 정의 편

SI 프로젝트에서도 사용자(고객)가 수행하는 비즈니스를 흐름도로 정의하는 프로세스가 있다. 비즈니스 흐름도, 업무 흐름도 등 다양한 이름으로 정의되지만 사용자가 해야 하는 일을 순서대로 보여준다. 비즈니스 흐름은 사용자가 어떤 비즈니스를 가지는지를 보여주기 때문에 매우 중요한 프로세스이지만 개발 프로젝트에서는 많은 시간을 할애하지 않는 것이 일반적이다. 이번 회에서는 사용자 스토리 워크샵의 사용자 스토리 정의에 대해 살펴보기로 한다. 명확한 사용자 스토리 정의를 통해 애자일 기반 프로젝트의 성공률이 높아지기를 기대한다.


사례 연구 전 확인 사항

사용자 스토리의 필요성

사용자 스토리는 사용자 스토리 워크샵의 핵심 작업 중의 하나다. 사용자가 어떠한 흐름으로 비즈니스를 진행하는지 보여주기 때문이다. SI 프로젝트에도 이와 유사한 비즈니스 흐름도나 업무 흐름도에서 사용자의 업무 흐름을 보여준다. 요구사항을 적용하기 전에는 (As-Is)업무 흐름도, 요구사항을 적용한 후에는 (To-Be)업무 흐름도로 표현된다. 그런데, 이 문서들은 사용자들이 알아볼 수 있는 문서는 아니었다. As-Is는 현재 하고 있는 업무를 나타내는 것이고, To-Be는 개발팀에서 작성하다 보니 시스템 중심으로 작성이 되어 있다. 시스템이 만들어지기 한참 전이기 때문에 사용자가 알아보기 어려운 것이 당연하였다.

사용자 스토리 워크샵의 주요 목적은 사용자와 개발팀 간의 커뮤니케이션이다. 서로 대화가 되기 위해서는 사용자의 업무 흐름이 사용자가 알아보기 쉽게 작성되어야 한다. 사용자 스토리를 만들기 위해 다양한 프로세스가 선행된다.

더보기