User Stories Applied : Chapter 1 Intro - 1

1. 사용자 스토리 개요

Is User Story : 프로젝트를 착수하는 시점에 모든 것을 포괄하는 결정을 하기보다, 프로젝트 전 기간에 걸쳐 의사를 결정해야 한다. 사용자 스토리(User Story)는 이를 위한 기법이다.

기법	서술	대화	테스트
설명	스토리는 서술 형태로 기록되며, 계획하거나 기억하기 위한 단서로 사용된다.	스토리는 대화를 통해 세부사항을 구체화한다.	스토리는 테스트를 통해 세부사항을 문서화하고 전달하며, 스토리의 완료 여부를 판단한다.
대상	카드(Card)	대화(Conversation)	확인(Confirmation)
기능	고객의 요구사항을 문서화 하기 보다는 표현하는 수단	카드가 본문을 담고 있는 반면 세부사항은 대화를 통해 결정된다.	확인에는 대화 통해 결정된 세부사항의 테스트가 포함된다..

• 사용자 스토리는 사용자에게 가치를 평가 받을 수 있도록 기능을 표현

예)

“사용자는 채용 정보를 검색할 수 있다.”

“기업은 채용 정보를 게시할 수 있다.”

“사용자는 자신의 이력서를 열람할 사람을 제한할 수 있다.”

• 스토리가 너무 큰 것 보다는 스토리가 많은 것이 더 낫다.

• 스토리는 한두 명의 개발자가 반나절에서 길어야 2주일 안에 구현하고 테스트할 수 있는 정도의 크기가 적당하다.

• 스토리가 너무 큰 경우에 ‘에픽(epic)’ 이라고 말하며 에픽은 더 작은 스토리로 나눌 수 있다.

예)

“사용자는 채용 정보를 검색할 수 있다.” (에픽)

“사용자는 위치, 급여 수준, 직업 명, 회사 명, 게시 날짜 등의 속성값으로 채용 정보를 검색할 수 있다.”

“사용자는 검색 조건과 일치하는 채용 정보를 볼 수 있다.”

“사용자는 채용 정보를 게시한 기업에 대한 세부 정보를 볼 수 있다.”

• 모든 세부사항들까지 스토리로 작성하는 것보다, 개발팀과 고객이 이런 세부사항에 대해 논의하는 것이 더 낫다. 합의된 내용은 스토리가 정확하게 개발되었는지를 증명하는 테스트 형태로 문서화 한다.

• 테스트 서술은 간결해야 하며, 테스트는 어느 때라도 추가하거나 제거할 수 있다. 이 과정의 목적은 스토리에 대한 부가 정보를 통해 개발자가 자기 일을 끝냈다는 것을 알 수 있도록 하는 것이다.

예)

“채용정보를 입력하지 않고 시도해 본다.”

“채용정보를 아주 길게 넣어 본다.”

“급여정보가 빠진 경우를 확인해 본다.”

“여섯 자리 급여도 시도해 본다.”

• 스토리는 고객팀(테스터, 제품 관리자, 실제 사용자, 상호작용 설계자 등…)이 작성을 한다. 개발자 대신 고객팀이 사용자 스토리를 작성하는 이유는 각 스토리는 전문용어가 아닌 비즈니스 언어로 작성되어야 고객팀에서 스토리를 어느 이터레이션이나 릴리즈에 포함시킬지 우선순위를 결정하기 쉽고 또 제품의 주된 기획 주체로서 고객팀은 제품의 동작을 가장 잘 설명할 수 있다.