2011년 6월 3일 금요일

User Stories Applied : Chapter 12 왜 사용자 스토리인가?

사용자 스토리의 장점
  • 구두 의사소통

모든 것을 기록하고 기록된 사항에 모두가 동의했다면, 어떠한 의견 차이도 발생하지 않을 것이며, 개발자들은 정확히 무엇을 만들어야 하는지 알고 테스터들은 정확히 무엇을 테스트해야 하는지 알며, 무엇보다 고객들은 정확히 자신들이 원하는 것을 얻게 거라고 생각하는 것이 당연해 보인다. 그러나 그렇지 않다. 고객들은기록된 대해 개발자들이 해석한 내용을 받을 것이며, 그것은 고객이원하는 아닐 수도 있다.

구두 의사소통 역시 언어이기 때문에 기록을 통한 의사소통에서 나타나는 문제점들이 어느 정도 동반된다. 그러나 고객, 개발자, 사용자가 대화를 나눌 때에는 서로 즉각적인 피드백을 주고 받을 있으며, 이는 상호 학습과 이해를 증진시킨다. 그리고 기록된 것에서 느끼는 것과 같은 명확성과 정확성에 대한 잘못된 인상이 대화에서 배제된다.

사용자 스토리를 사용하는 목적은 우리가 바라는 기능들의 모든 세부사항까지 문서로 자세히 기록하자는 것이 아니다. 오히려 나중에 개발자와 고객이 대화를 이어갈 있을 정도의 내용을 담은 짧은 문장들을 기록하자는 것이다.
  • 사용자 스토리는 이해하기 쉽다.

스토리는 유스케이스나 시나리오보다 이해하기 쉽다. 스토리는 간명하고 항상 고객과 사용자의 가치를 표현하도록 작성되기 때문에 비즈니스를 하는 사람이든 개발자든 쉽게 이해할 있다.
스토리의 형태는 언급된 행위의 회상을 촉진할 뿐만 아니라 언급되지 않은 행위의 회상도 촉진한다. 우리가 작성하는 스토리는 전통적인 요구사항 명세서나 심지어 유스케이스 보다 간결하며, 스토리의 형태로 작성되므로 기억하기도 훨씬 쉽다.
  • 사용자 스토리는 계획 수립에 적합한 크기다.

사용자 스토리는 계획 수립에 적합한 크기로 되어 있다. 너무 크지도 않고 그렇다고 너무 작지도 않은 적당한 크기다. 스토리는 관리하기 적합한 크기로 릴리즈를 계획하거나, 개발자 들이 프로그램을 작성하고 테스트를 수행하는 적절히 사용할 있다.
  • 사용자 스토리는 반복적 개발에 효과적이다.

코딩을 시작하기 전에 스토리를 모두 작성할 필요는 없다. 가지 스토리를 작성한 그것들을 코딩하고 테스트한 과정을 필요한 만큼 반복하면 된다. 스토리를 작성할 때는 우리가 원하는 만큼 적절한 수준의 세부사항만 작성하면 된다. 스토리를 작성한 다음에도 상세한 수준으로 반복해서 수정해 나가기가 쉽기 때문에 반복적 개발에 아주 효과 적이다.
  • 스토리는 세부사항을 나주에 고려할 있게 해준다.

초기에는 단지 프로젝트의 목적을 기술하는 수준에서 시작하여 세부사항들이 필요할 내용을 추가해 나가는 것이다. 이러한 특징은 시한부 프로젝트에 아주 도움이 된다. 프로젝트 팀은 재빨리 가지 스토리를 작성하여 시스템의 전반적인 윤곽을 잡을 있다. 중에서 가장 중요한 스토리에서 시작해 세부사항을 추가하여 바로 코딩에 착수할 있다.
  • 스토리는 기회주의적 개발을 지원한다.

- 사용자가 사전에 자신들의 요구사항들을 완전히 알고 있다고 가정하지 않는다.
- 개발자들이 모든 세부사항을 완전히 이해할 있다고 가정하지 않는다.
- 변화를 포용한다.
이러한 점에서 스토리는 소프트웨어가 기회주의적으로 개발되어야 한다는 점을 인정한다. 높은 수준의 요구사항들을 한번에 코드로 바꾸는 마법은 없다. 스토리는 프로젝트 팀이 요구사항에 대해 다양한 수준으로 생각하고 이야기 나눌 있게 해준다.
  • 스토리는 참여적 설계를 유도한다.

스토리와 시나리오는 사용자들이 쉽게 이해할 있으므로 사용자가 소프트웨어 설계에 참여하도록 유도한다. 게다가 사용자가 자신의 오구사항을 스토리로 만드는 익숙해지면 그것으로 이득을 보게 되는 개발자로서는 더욱 사용자의 참여를 독려하게 된다. 이러한 선순환 구조는 소프트웨어를 개발하는 사람이나 사용하는 사람에게 모두 유익하다.
  • 스토리는 암묵적 지식을 구축한다.

스토리는 직접 대화하는 것을 강조하기 때문에 전체에 암묵적 지식을 쌓도록 해준다. 개발자와 고객이 대화를 많이 나눌수록 팀에 많은 지식이 축적된다.

사용자 스토리의 단점
  • 대규모 프로젝트에서 스토리가 많을 스토리 사이의 관계를 이해하기 어렵다.
  • 요구사항 추적성이 요구되는 경우 사용자 스토리 외에 문서를 추가로 작성해야 할지도 모른다.
  • 내의 암묵적 지식을 강화한다는 점에서는 훌륭하지만, 매우 규모의 팀에서는 장점이 그대로 적용되지 않는다.

댓글 없음:

댓글 쓰기

ETL 솔루션 환경

ETL 솔루션 환경 하둡은 대용량 데이터를 값싸고 빠르게 분석할 수 있는 길을 만들어줬다. 통계분석 엔진인 “R”역시 하둡 못지 않게 관심을 받고 있다. 빅데이터 역시 데이터라는 점을 볼때 분산처리와 분석 그 이전에 데이터 품질 등 데이...