User Stories Applied : Chapter 2 스토리 작성하기

좋은 스토리의 6가지 특징

독립적이다.

• 스토리 사이에 의존성이 있으면 우선순위 결정과 계획 수립에 문제를 야기한다. 때문에 가능하면 스토리 간에 의존성을 배제하도록 신경 써야 한다.

• 상호 의존성이 높은 스토리들에 대해서 스토리별 추정이 어려운 경우 의존성이 있는 스토리들을 합쳐 좀더 큰 하나의 독립적인 스토리를 만들거나 스토리들을 다른 방식으로 분리한다.

협상가능하다.

• 스토리는 기능에 대한 짧은 설명일 뿐, 세부사항은 고객과 개발 팀이 대화를 통해 협상해야 한다.

• 스토리카드는 대화를 이끌기 위한 단서지, 그 자체로 완성된 상세한 요구사항이 아니기 대문에, 필요한 모든 세부사항까지 포함할 필요가 없다.

사용자와 고객 혹은 구매자에게 가치가 있다.

• 모든 스토리는 사용자에게 가치가 평가되어야 한다.

• 스토리가 고객이나 사용자에게 가치 있도록 하는 가장 좋은 방법은 고객이 직접 스토리를 작성하게 하는 것이다.

추정 가능하다.

• 개발자는 각 스토리의 크기 혹은 작업 소요시간을 추정할 수 있어야 한다.

• 개발자가 해당 분야의 지식이 부족하여 스토리를 잘 이해하지 못한다면, 그것을 작성한 고객과 직접 의논해야 한다.

• 스토리와 관련된 기술적인 내용을 개발자가 모른다면, 한두 명의 개발자가 스파이크(Spike)을 수행하여 개발자들이 작업을 추정가능 하도록 해야 한다. 이를 위해 스토리를 두 개로 스파이크 진행 스토리와 실제 작업 스토리로 나눈다.

• 스토리가 너무 크기 때문에 추정하기 어려운 경우는 좀더 작은 단위로 나누어서 추정 가능하도록 한다.

작다

스토리가 나누거나 합쳐서 적당한 크기의 스토리가 되도록한다.

스토리 나누기

복합적인 스토리 : 작은 스토리를 여러 개 포함하는 애픽

- 일련의 작업 단위에 따라 나눈다.(입력, 수정, 삭제)

- 데이터의 경계에 따라 나눈다.(학력정보, 가족정보, 기본정보)

복잡한 스토리 : 크기가 크면서 작은 스토리로 나누기가 어렵다. 대부분 스토리 자체에 대한 불확실성 때문에 복잡해 지는 경우가 많으며, 알고리즘을 새로 개발하거나 기존의 알고리즘을 확정해야 하는 경우에 자주 발생한다.

- 문제를 조사하는 스토리와 기능을 개발하는 스토리로 나눈다.

스토리 합치기

스토리를 작성하고 작업량을 추정하는 것이 내용을 변경하는 것보다 더 오래 걸릴 것 같은 스토리들은 하나로 합친다.

테스트 가능해야 한다.

스토리는 테스트 가능하도록 작성해야 한다. 테스트를 성공적으로 통과해야 그 스토리가 성공적으로 개발되었다고 말할 수 있다.

어떤 화면도 사용자를 오래 기다리게 해서는 안된다. X

어떤 화면도 2초안에 출력되어야 한다. O