"사용자 스토리(User Stories Applied)" 발췌

• • 사용자는 채용 정보를 검색할 수 있다
  • 기업은 채용정보를 게시할 수 있다

  확실히 이 두 스토리는 이것만으로 일을 진행하기에 너무 크다

  ... 이러한 모든 세부사항들까지 스토리로 작성하는 것보다, 개발팀과 고객이 이런 세부사항에 대해 논의하는 것이 더 낫다. 즉 세부사항이 정말 중요한 시점이 되었을 때 그에 관해 대화를 나누는 것이다.
  ...스토리는 계약과 같은 구속이 아니다. 앞으로 살펴보겠지만, 합의된 내용은 스토리가 정확하게 개발되었는지를 증명하는 테스트 형태로 문서화된다.
  

  프로젝트에서도 사용자들이 기대하는 바를 이해하는 것은 중요하다. 그러한 기대는 인수 테스트(acceptance test)의 형태로 표현하는 것이 가장 효과적이다. 종이로 인덱스 카드를 이용한다면, 카드의 뒷면을 이용하여 이러한 기대사항을 표현할 수 있다.
  

  테스트 서술은 간결해야 한다. ... 개발자들이 고객의 기대를 아는 것은 일의 완료 여부를 아는데 유용하다.
  

  고객 팀에는 소프트웨어가 사용자의 요구를 만족하는지 보증해 줄 사람들이 포함된다. 여기에는 테스터, 제품 관리자(product manager), 실제 사용자, 상호작용 설계자(interaction designer)등이 포함될 것이다.
  

  "왜 고객이 스토리를 작성하는가?"
  각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성해야 한다. 그래야 고객 팀에서 스토리를 어느 이터레이션이나 릴리즈에 포함시킬지 우선순위를 결정할 수 있다. 제품의 주된 기획 주체로서 고객팀은 제품의 동작을 가장 잘 설명할 수 있다.
  

  고객 팀에는 현실적으로 가능한 많은 사용자 유형을 대표할 수 있느 사람들이 포함되어야 한다.
  

  고객팀과 개발자가 협력하여 이터레이션 길이를 1~4 주 정도 범위에서 선택한다. 선택한 이터레이션 길이를 프로젝트가 끝날 때까지 변경하지 않고 사용한다. 개발자들은 이터레이션마다 소프트웨어의 일부 기능만이라도 그 자체로 쓸모 있는 코드를 인도해야 하는 책임이 있다. 고객 팀은 이터레이션 동안 긴밀하게 참여하고 개발자와 해당 이터레이션에서 개발하는 스토리에 대해 대화를 나누어야 한다. 또한 고객 팀은 테스트할 것을 지정하고 개발자와 함께 테스트를 자동화하고 실행하도록 한다.
  

  
  책에서 발췌한 내용임.  괜찮은 내용만 다 추려볼까 하다가.. 일부만 올림.

저작권 문제도 있고..
자세한 것은 "사용자 스토리(User stories applied) - 마이크지음. [인사이트]" 를 볼 것.