2011년 6월 3일 금요일

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

좋은 스토리의 6가지 특징
독립적이다.
  • 스토리 사이에 의존성이 있으면 우선순위 결정과 계획 수립에 문제를 야기한다. 때문에 가능하면 스토리 간에 의존성을 배제하도록 신경 써야 한다.
  • 상호 의존성이 높은 스토리들에 대해서 스토리별 추정이 어려운 경우 의존성이 있는 스토리들을 합쳐 좀더 하나의 독립적인 스토리를 만들거나 스토리들을 다른 방식으로 분리한다.


협상가능하다.
  • 스토리는 기능에 대한 짧은 설명일 , 세부사항은 고객과 개발 팀이 대화를 통해 협상해야 한다.
  • 스토리카드는 대화를 이끌기 위한 단서지, 자체로 완성된 상세한 요구사항이 아니기 대문에, 필요한 모든 세부사항까지 포함할 필요가 없다.


사용자와 고객 혹은 구매자에게 가치가 있다.
  • 모든 스토리는 사용자에게 가치가 평가되어야 한다.
  • 스토리가 고객이나 사용자에게 가치 있도록 하는 가장 좋은 방법은 고객이 직접 스토리를 작성하게 하는 것이다.


추정 가능하다.
  • 개발자는 스토리의 크기 혹은 작업 소요시간을 추정할 있어야 한다.
  • 개발자가 해당 분야의 지식이 부족하여 스토리를 이해하지 못한다면, 그것을 작성한 고객과 직접 의논해야 한다.
  • 스토리와 관련된 기술적인 내용을 개발자가 모른다면, 한두 명의 개발자가 스파이크(Spike) 수행하여 개발자들이 작업을 추정가능 하도록 해야 한다. 이를 위해 스토리를 개로 스파이크 진행 스토리와 실제 작업 스토리로 나눈다.
  • 스토리가 너무 크기 때문에 추정하기 어려운 경우는 좀더 작은 단위로 나누어서 추정 가능하도록 한다.


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

스토리 나누기
복합적인 스토리 : 작은 스토리를 여러 포함하는 애픽
- 일련의 작업 단위에 따라 나눈다.(입력, 수정, 삭제)
- 데이터의 경계에 따라 나눈다.(학력정보, 가족정보, 기본정보)

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

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

테스트 가능해야 한다.
스토리는 테스트 가능하도록 작성해야 한다. 테스트를 성공적으로 통과해야 스토리가 성공적으로 개발되었다고 말할 있다.
어떤 화면도 사용자를 오래 기다리게 해서는 안된다. X

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

댓글 없음:

댓글 쓰기

블록체인 개요 및 오픈소스 동향

블록체인(block chain) 블록체인은 공공 거래장부이며 가상 화폐로 거래할때 발생할때 발생할 수 있는 해킹을 막는 기술. 분산 데이터베이스의 한 형태로, 지속적으로 성장하는 데이터 기록 리스트로서 분산 노드의 운영자에 의한 임의 조작이 불가...