사용자 스토리 의 빠르고 더러운 정의 :
"As a <role>, I want <goal/desire> so that <benefit>"
이 일반적으로 허용되는 정의에는 비즈니스 규칙, 제약 조건 또는 사용자 입력을 정의 할 공간이 거의 없습니다.
간단한 예는 다음과 같습니다.
"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"
이 어리석은 예에서, 책을 등록 할 때 필요한 필드를 어디에 정의 할 것인가? 어디서나 작성해야합니까? 또는 제품 소유자가 필수 비즈니스 규칙을 입소문으로 전달해야합니까?
답변:
필드는 대화의 일부입니다 . 유용하지만 판결 요청 인 경우에는 기록 될 수 있습니다. 문서를 최신 상태로 유지하는 것은 어려울 수 있지만 작동중인 소프트웨어는 어느 정도 문서로 볼 수 있습니다.
사용자 스토리-대화 약속 은 이에 대한 블로그 항목입니다.
당신의 사소한 예에는 당신이 이것을 잘 알 수있는 몇 가지 요점이 있습니다. "신규 도서 등록"이란 무엇입니까? "온라인 사용 가능 여부 찾기"란 무엇입니까? 대화가 시작되는 곳이며 스토리가 완료되면 등록이 파일에 보관되거나 보고서가 주기적으로 생성되어야하기 때문에 새로운 스토리가있을 수 있습니다.
이전 답변은 특별히에 대해 유효한 포인트를 제공하는 사용자 스토리 있는 Being 대화를하는 알림 . 고려해야 할 다른 것들 :
테스트 케이스를 암시하는 세부 사항은 스토리 자체와 분리됩니다. [ 마이크 콘 ]
스토리 카드 뒷면에 추가하거나, 실제로 중요하다면 작은 메모를하거나 수락 테스트 문서에 넣을 수 있습니다.
사용자 사례가 좋은지 평가하기위한 지침으로 Bill Wake의 제안을 따를 수 있습니다 .
Mike Cohn의 "User Stories Applied " 책의 2 장 "쓰기 스토리" 를 읽어보십시오 .
일반적으로 다양한 측면을 가진 광범위한 사용자 스토리에서 스토리의 가장 일반적인 예를 얻으려고 노력합니다. 그런 다음 구체적으로 스토리에서 상속하는 하위 사용자 스토리를 작성합니다. RallyDev와 같은 많은 Agile 프로젝트 관리 도구를 사용하면이 작업을 쉽게 수행 할 수 있습니다.
새로운 책을 등록하는 것은 광범위하므로, <role>책을 어떻게 등록하고 싶은지 에 대한 10 가지 다른 어린이 사용자 사례가 있을 수 있습니다.
이러한 것들에 대한 극단적 인 세부 사항이나 기괴한 프린지 세부 사항은 일반적으로 해당 사용자 스토리에서 하나 이상의 작업에서 정의합니다. 이 작업은 해당 사용자 스토리를 충족시키기 위해 수행해야하는 개발 및 설계 작업을 정의하는 데 도움이됩니다 (예 : 설명 필드에 입력이 50 자 미만인지 확인하는 유효성 검사기 작성 ...) 편집 : 추가하고 싶었습니다. 사용자가 실제로 관심을 가질만한 내용이 아니기 때문에 사용자 스토리에서 극단의 세부 사항을 유지하는 것이 좋습니다. 사용자는 소프트웨어를 일반적인 용어로 설명하기를 원하며 소프트웨어 개발자가 세부 사항을 파악하고 숨길 수 있습니다.
이것은 내가 문제에 접근하는 방법이지만 여러 가지 다른 방법이 있다고 확신합니다.
User Stories를 사용하여 복잡한 비즈니스 규칙을 정의하는 방법은 무엇입니까?
그것은 사용자 이야기가 아닙니다. 구현을 작성하는 데 필요한 모든 세부 사항 또는 비즈니스 규칙을 캡처하는 소프트웨어 요구 사항은 아닙니다. 응용 프로그램이 사용자의 관점에서 수행해야 할 작업에 대한 설명 일뿐입니다.
중요한 것을 기억하십시오 : 적절한 소프트웨어를 구축하십시오. 필요한 모든 것을 사용하고 사용자 스토리는 응용 프로그램에 필요한 기능을 수집했는지 확인한 다음 해당 기능에 대해 이야기하고 우선 순위를 정하고 평가할 수 있습니다. 클래식 사용자의 누락 된 부분 이야기 (a .. 내가 원하는 ... 그렇게)는 소프트웨어 제작에 관련된 사람들 사이의 커뮤니케이션에 관한 것입니다.
세부 사항을 수락 문서, 하위 스토리, 사용자 스토리에 첨부 된 기술 작업, 사양 문서 등으로 사용하면 사용자 스토리가 도움이되는 것 이상의 것입니다. stoy는 소프트웨어 구축 방법을 결정할 때 대화의 "주체"입니다.
주어진 예에서, Dewey 또는 기타 분류 시스템, ISBN, 취득 번호, 사본 / 제목 / 저자, 기타 판 등 개발자가 거의 모르는 책 등록에 대한 많은 세부 사항이 있습니다. 새로운 시스템의 경우, 그러한 세부 사항 은 고객이 제공 해야합니다 (그리고 모든 사람의 사서가 확실히 관심을 가질 것입니다).
스티브 오코넬 (Steve O'Connell)은 "사양에 필요한 세부 사항이 부족한 개발자들이 비즈니스 정책을 얼마나 많이 만들 었는지 생각하는 것은 무섭다."