사용자 스토리(스크럼) #3(사용자 스토리)

사용자 스토리란?

사용자의 요구사항을 who, what, why의 형태로 간단하게 기술한 것

 

who : 나는 누구로서

why : 이러한 이유로 인해서

what : 이러한 기능이 필요하다

 

 

○ 소프트웨어 사용자가 구매자에게 가치를 줄 수 있는 기능

○ 스토리는 고객이나 개발자 모두 이해할 수 있도록 고객이 작성(제품 책임자 또한 작성 가능)

 

---

사용자 스토리의 세가지 측면 3Cs

1. 카드(card) : 고객의 요구사항을 문서화하기 보다는 포현하기 위한 것

2. 대화(conversation) : 대화를 통해 세부사항을 구체화

3. 테스트(confirmation) : 스토리의 완료 여부를 판단

 

카드 :  위 그림과 같이 사용자의 요구사항을 기술해 놓은 것이다.

대화 :  고객이 원하는 기능 및 디자인 등 세부사항을 대화를 통해 해결

테스트 : 고객이 원하는 기능이 제대로 동작하는지 모든 예외상황 테스트

 

사용자 스토리의 장점 : 고객간의 대화를 원할하게 해준다.

 

---

좋은 사용자 스토리를 만들기 위한 조건 [INVEST]

Independent(독립적)

○ 사용자 스토리는 의존성이 적어야 한다.

○ 의존성이 많은 사용자 스토리는 개발 우선순위를 설정하는 작업을 복잡하게 한다.

○ 의존성이 생길경우는 제품 책임자와 개발팀 협의하에 스토리 분할이나 다른 방법 선택

    의존성이란 한개의 기능이 구현되려면 다른 스토리의 기능이 먼저 구현되어야할 때의 상황이다

 

Negotiable

○ 대화를 통해 고객과 협의점을 찾을 수 있어야 한다.

○ 보안기능으로 얼굴인식을 사용하라의 스토리는 Negotiable하지 않다. 얼굴인식을 쓰라고 명령함.

    대화의 형태로 기능을 어떤 형태로 구현할 것인지 협의할 수 있어야함

 

Valuable

○ why 가 명확해야 한다.

○ why가 가치가 있어야 한다.

 

Estimable

○ 사용자 스토리의 크기가 예상이 가능해야한다.

○ 너무 큰 스토리는 분할해야 한다.

 

Small

○ 스토리의 사이즈를 적절하게 분할해야 한다.

○ 다음 스프린트에서 개발될 사용자 스토리는 최소한 스프린트 내에 개발할 수 있는 크기로 분할해 놓음

○ 우선순위가 낮은 사용자 스토리 들은 인수조건이 기술되지 않을 수 있다.

○ 곧 개발될 것들은 꼭 인수조건이 기술되어 있어야 한다.

 

Testable

○ 사용자 스토리의 기능을 확인해봐야 한다.

○ 기능이 정상적으로 동작하는지 오류는 없는지 확인

○ 오류가 발생했다면 기능의 구현이 완료되지 않은 것이다.