80.사용자 스토리
성공적인 소프트웨어 신상품 개발가이드
사용자 스토리는 상품 요구사항이 고객에게 제공하는 가치를 고객관점에서 간결하게 설명한 것이다. 사용자 스토리는 작은 카드 한 장에 정리하여 토론할 때 사용하기도 한다. 이번 섹션에서는 사용자 스토리의 특성과 사용자 스토리 작성을 위한 가이드를 설명한다.
1) 사용자 스토리의 특성
사용자 스토리는 상품관리자와 개발팀간의 의사소통을 촉진하는 도구이기 때문에 반복적 개발에 효과적으로 사용된다. 사용자 스토리는 상품개발 착수 전에 작성한 후 릴리즈 계획 또는 스프린트 계획 수립 시 변경되거나 구체화된다.
사용자 스토리는 As, I want, So that의 형태로 작성한다. 예를 들어 상품관리자가 상품 릴리즈 준비현황을 파악하기 위해 상품 요구사항의 개발현황을 파악하고 싶다면 사용자 스토리를 다음과 같이 정리할 수 있다.
As (상품관리자로서),
I want (상품 요구사항 개발현황을 파악하고 싶다),
So that (상품 릴리즈 준비가 제대로 되고 있는지 파악하기 위하여)
좋은 스토리 작성을 위한 가이드는 다음과 같다. (<사용자 스토리, 2006>에서 요약 인용)
- 케이크 자르듯이 나누어라
큰 사용자 스토리는 작은 스토리로 나누어야 한다. 이때 사용자 스토리를 개발자 관점에서 기술적으로 나누어서는 안 된다. 예를 들어 ‘구직자는 이력서를 등록할 수 있다’는 스토리를 다음과 같이 나누어서는 안 된다.
. 구직자는 입력 양식에 값을 채워 넣는다. (I)
. 이력서 양식의 정보는 데이터베이스에 기록한다.(II)
위와 같은 스토리분할은 사용자 관점에서 어느 하나도 완전하기 않다. (I)은 등록한 값이 저장되지 않고, (II)는 (1)을 전제로 한다. 스토리를 케이크처럼 나눈 예는 다음과 같다.
. 구직자는 기본정보(이름, 주소, 학력)을 포함한 이력서를 제출할 수 있다.
. 구직자는 기업측에서 요구하는 모든 정보를 포함한 이력서를 제출할 수 있다.
케이크처럼 분할하는 것의 장점은 어플리케이션 아키텍처의 모든 계층을 포함하여 문제점을 사전에 검증할 수 있고, 일부 기능만 구현해도 고객에게 릴리즈 할 수 있다는 것이다.
- 닫힌 스토리를 작성한다.
닫힌 스토리는 끝이 명확하다. 끝이 명확하지 않으면 어디까지 코딩 할지 불명확해진다. 예를 들어 ‘인사담당자는 자신이 게시한 채용공고를 관리할 수 있다’와 같이 작성하면 관리가 무엇인지 명확하지 않다. 관리의 내용을 수정, 삭제와 같이 명확하게 표현해야 한다.
- 제약사항을 기록한다.
비 기능 요구사항의 경우 제약조건을 포함할 수 있다. 예를 들어 연계해야 할 데이터베이스, 지원하는 스마트 폰과 윈도우 버전, 응답속도 등이 예가 된다.
- 스토리는 개발 순서에 따라 상세화한다.
가까운 미래의 스토리는 상세하게 정의하고 먼 미래의 스토리는 간략히 정의한다. 예를 들어 초기에는 아래와 같이 네 개의 사용자 스토리를 도출한 후 첫 번째 스토리만 다시 상세화 하는 방식이다.
. 구직자는 이력서를 등록할 수 있다.
. 구직자는 채용정보를 검색할 수 있다.
. 인사 담당자는 채용공고를 게시할 수 있다.
. 인사 담당자는 이력서를 검색할 수 있다.
.. 구직자는 웹 사이트에 새 이력서를 추가할 수 있다.
.. 구직자는 게시한 이력서를 수정할 수 있다.
.. 구직자는 게시한 이력서를 삭제할 수 있다.
.. 구직자는 이력서를 임시 저장할 수 있다.
- 요구사항 구현방법은 가능한 포함하지 않는다.
요구사항에 구현의 세부사항을 포함하는 것은 요구사항 정의시 범하기 쉬운 오류이다. 개발자 관점의 요구사항 구현방법은 포함하지 않는다.
https://brunch.co.kr/@kbhpmp/160
