사용자 스토리 : 고객 중심의 요구사항 기법

프로젝트가 만족스럽게 수행될 수 있도록 하는 첫걸음이자 가장 중요한 부분이라 할 수 있는 사용자 요구사항 찾아내기.. 모두가 항상 중요하다고 이야기 하지만, 과연 어떻게 라는 질문은 쉽게 떨쳐버릴 수 없는 짐이다.. 상당히 빡빡한(?) 스타일로 관리하는 방법이 있는가 하면 (Software Requirements 참조), 뭔가 엉성한 것 같으면서도 기민하게 대처하는 방법이 있다.. 애자일 스타일의 사용자 요구사항 기법은 목적하는 바는 같다.. 사용자가 원하는 바를 정확히 이해하는 것.. 그 접근법이 뭔가 전문성을 강조하기 보다는 보통 사람들이 비교적 쉽게 따라할 수 있는 습관을 알려주시고 있다..

소프트웨어 요구사항은 의사소통의 문제다.
기술팀과 다양한 집단의 이해당사자들, 양쪽중 어느 한쪽이 우위를 차지하면 프로젝트는 실패하게 된다. 우리에게 필요한 것은 함께 일하는 방법이다. 그리하여 어느 한쪽이 우위를 점하지 않으며, 감정적으로 흐르거나 혹은 정치적일 수 있는 자원 할당 문제를 공동의 문제로 공유하는 것이다.

스토리 카드는 고객이 작성한다. 그 이유는 요구하는 기능에 대해 고객팀이 가장 잘 설명할 수 있으며, 나중에 개발자와 함께 세부사항에 대해 논의하고 스토리의 우선순위를 결정할 수 있어야 하기 때문이다.

스토리는 조직에 가져올 가치를 토대로 우선순위를 매긴다.

좋은 사용자 스토리의 여섯가지 특성
1. 독립적이다
2. 협상 가능하다
3. 사용자 및 고객에게 가치가 있다
4. 추정 가능하다
5. 작다
6. 테스트 가능하다

사용자 스토리는 협상 가능해야 한다. 스토리는 계약서나 요구사항 명세서처럼 꼭 구현한다고 기록된 것이 아니다. 스토리는 기능에 대한 짧은 설명일 뿐 세부사항은 고객과 개발팀이 대화를 통해 협상해야 한다. 따라서 필요한 모든 세부사항까지 포함할 필요는 없다. 뒷면에는 테스트할 항목을 기록해두는 것도 좋다.
1. 대화를 재개할 단서 역할을 하는 한두 문장
2. 대화 중에 해결된 쟁점에 대한 주석

모든 스토리는 사용자에게 가치가 평가되어야 한다고 말할 수 있지만, 소프트웨어를 직접 사용하는 사용자와 소프트웨어를 구매하는 구매자가 다를 수 있다는 사실도 염두에 두어야 한다

여러분이 정말 피해야 하는 사용자 스토리는 개발자에게만 가치가 있는 스토리다.
1. 모든 데이터베이스 연결은 커넥션 풀을 통해 이루어져야 한다
2. 모든 에러처리 및 로그생성은 공통 클래스들을 통해 이루어져야 한다

사용자 스토리는 고객이나 사용자에게 제공하는 이점이 드러나도록 작성해야 한다
1. 사용자 라이선스 5개로 50명까지 데이터베이스 연결하여 사용할 수 있어야 한다
2. 모든 에러는 사용자에게 보여야 하며, 일관된 형태의 로그로 기록되어야 한다

사용자 스토리가 일정 추정이 쉽지 않은 경우
1. 해당분야의 지식 (도메인 지식)이 부족하다
2. 기술적인 지식이 부족하다
3. 스토리가 너무 크다
스토리가 너무 크면 작은 여러개의 스토리로 분리해야 한다

어떤 방법이던 나에게 맞으니 너에게도 맞을 것이다 강요할 수는 없다.. 하지만, 이 기민한 대처법은 습관화 시키면 효과를 볼 수 있는 사례들을 적절히 제공해 주고 있으며, 나도 쉽게 습관화 시킬 수 있다는 느낌을 준다..

사용자도 자신이 원하는 것이 뭔지 정확히 모를 수 있다.. 더 좋은 방법이 있는데 못찾을 수도 있다.. 중요한 것은 그러한 상황을 슬기롭고 현실적으로 대처할 수 있는, 그리고 우리에게 가장 적합한, 가장 효율적으로 수행할 수 있는 방법이 무엇인가 고민하는 것이다.. 이 책이 그 고민에 도움을 줄 수 있을 것이다..

아래의 그림과 같은 현실에서 다른 사람의 생각과 우리의 생각의 차이를 줄이기 위해 노력하는 많은 사람들이 읽어볼만한 책이라 추천한다..
그림을 제대로 보고 싶다면 프로젝트의 진행 과정 - 기획에서 완료까지를 참조