스크럼-사용자 스토리
아시다시피 사용자 스토리는 일반적으로 제품 기능을 설명하는 데 사용되며 스크럼 아티팩트의 일부를 구성합니다. Product Backlog 과 Sprint Backlog.
사용자 스토리
소프트웨어 개발에서 제품 기능은 중요한 역할을합니다. 사용자가 궁극적으로 최종 제품에서 사용하기를 좋아하는 기능입니다. 일반 용어로는 요구 사항이라고합니다. 소프트웨어 개발 프로젝트의 성공은 사용자 요구 사항을 정확하고 적절하게 이해 한 다음이를 최종 제품에 구현하는 데 있습니다. 따라서 요구 사항이나 제품 기능은 개발 프로젝트 팀에 완전히 알려야합니다.
1999 년 Kent Beck은 제품 기능에 대한 사용자 스토리라는 용어를 만들었습니다. 그는 사용자 스토리가 시스템이 자신을 위해 무엇을 할 수 있는지가 아니라 자신이 원하는 것에 대해 사용자 관점에서 설명한다고 설명했습니다. 따라서 뷰는 제품에서 사용자로 완전히 바뀌었고 사용자 스토리는 모든 애자일 프레임 워크의 요구 사항에 대한 사실상의 표준이되었습니다.
Scrum 프로젝트에서 제품 백로 그는 사용자 스토리 목록입니다. 이러한 사용자 스토리는 우선 순위가 지정되고 Sprint 계획 회의의 Sprint 백 로그에 포함됩니다.
추정치는 또한 사용자 스토리를 기반으로하며 제품의 크기는 사용자 스토리 포인트로 추정됩니다.
사용자 스토리 구조
사용자 스토리 구조는 다음과 같습니다.
A와 <사용자의 유형> ,
<작업 수행>을 원합니다 .
그래서 <나는 약간의 목표 / 이익 / 가치를 달성 할 수있다> .
ATM에서 현금을 인출하는 은행 고객의 시나리오에 대해 사용자 스토리가 어떻게 구성되는지 살펴 보겠습니다.
사용자 스토리 : 고객의 현금 인출
로 Customer,
나는 원한다 withdraw cash from an ATM,
그래서 I don't have to wait in line at the Bank
사용자 스토리 수락 기준
또한 각 사용자 스토리에는 수락 기준이 정의되어 있으므로 사용자 스토리 구현의 정확성은 수락 기준에 기반한 수락 테스트를 통과하여 확인됩니다.
다음은 사용자 스토리 고객의 현금 인출 예시에 대한 샘플 수락 기준입니다.
Acceptance Criterion 1:
Given 계정이 신용 할 수 있는지
- 그리고 카드는 유효합니다
- 그리고 디스펜서에는 현금이 들어 있습니다.
When 고객이 현금을 요구하다
Then 계좌가 인출되었는지 확인
- 그리고 현금이 지급되었는지 확인하십시오.
- 그리고 카드가 반환되었는지 확인하십시오.
Acceptance Criterion 2:
Given 계정이 초과 인출되었음을
- 그리고 카드는 유효합니다
When 고객이 현금을 요구하다
Then 거부 메시지가 표시되는지 확인
- 그리고 현금이 지급되지 않도록하십시오
- 그리고 카드가 반환되었는지 확인하십시오.
사용자 스토리 작성
제품 소유자는 제품 백 로그 및 사용자 스토리에 대한 책임이 있습니다. 그러나 제품 소유자 만 사용자 스토리를 작성한다는 의미는 아닙니다. 스크럼 팀의 누구나 사용자 스토리를 작성할 수 있으며 요구 사항이 개선되고 새로운 기능이 추가됨에 따라 활동이 프로젝트 전체에 분산 될 수 있습니다.
사용자 스토리의 비 기능적 요구 사항
비 기능적 요구 사항을 사용자 스토리에도 통합 할 수 있습니다. 주어진 ATM 예제에서 사용자가 365 일 24 시간 365 일 사용할 수있는 ATM은 사용 사례로 설명 할 수있는 비 기능적 요구 사항입니다.
사용자 스토리 관리
사용자 스토리는 제품 백 로그에서 관리됩니다. 사용자 스토리는 우선 순위에 따라 정렬됩니다. 가장 우선 순위가 높은 사용자 스토리는 세분화 된 수준으로 세분화되고 가장 낮은 우선 순위 사용자 스토리는 더 낮은 세부 수준으로 유지됩니다. 모든 스프린트에 대해 가장 우선 순위가 높고 더 세분화 된 사용자 스토리가 스프린트 백 로그에 포함됩니다. 사용자 스토리가 제품 백 로그에 추가 될 경우 우선 순위가 먼저 결정되고 우선 순위에 따라 위치에 따라 배치됩니다. 사용자 스토리는 언제든지 우선 순위를 다시 지정할 수 있습니다. 필요한 경우 사용자 스토리를 제거 할 수도 있습니다.
사용자 스토리의 이점
사용자 스토리의 주요 이점은 사용자 중심 정의 자체에 있습니다. 이는 궁극적으로 관련 사용자 시나리오에서 제품을 사용할 사용자이기 때문입니다. 최종 사용자와 팀 구성원을 연결합니다.
사용자 스토리 자체의 구문은 사용자가 달성하고자하는 목표 나 이익 또는 가치를 포착하도록 보장합니다.
수락 기준은 사용자 스토리 자체의 일부를 구성하므로 스크럼 팀에 추가 이점이 될 것입니다.
프로젝트 실행 과정에서 사용자 스토리를 변경할 수 있습니다. 사용자 스토리의 범위가 커지면 더 작은 사용자 스토리로 분할해야합니다. 수락 기준의 조건도 변경할 수 있습니다.
각 스프린트가 끝날 때 작업 제품 증분이 사용자에게 전달되면 스크럼 팀은 스프린트 검토 회의에서 사용자로부터 피드백을받을 수 있습니다. 이를 통해 지속적으로 제품에 피드백을 통합 할 수 있습니다.
결론
Scrum의 사용자 스토리는 사용자를 Scrum 팀에 더 가깝게 만들고 마지막 순간의 놀라움을 방지합니다.