스크럼 방법론에 대한 요구 사항을 문서화하기위한 템플릿

Question

유스 케이스로 애플리케이션 요구 사항을 문서화하고 Rational Unified Process를 사용하여 시스템을 모델링하는 것에 대해 잘 알고 있습니다.

하지만 지금은 스크럼과 같은 민첩한 방법론을 사용할 때 시스템 요구 사항을 문서화하기위한 템플릿 또는 모델이 있는지 알고 싶습니다.

당신에게

Answer 1

확인이 아웃 : http://www.scrumbasics.com/scrum-documentation/

(PS가 : 스크럼이 프레임 워크는)

Answer 2

감사하지만 지금은 스크럼 같은 애자일 방법론을 사용하는 경우 시스템 요구 사항을 문서화하기위한 템플릿 모델이 있는지 알고 싶습니다.

스크럼은 요구 사항을 캡처하는 방법에 대한 규범이 아니기 때문에 스크럼을위한 템플릿이 없으며 사용자의 컨텍스트에서 적절한 것을 사용할 수 있습니다. 많은 (웹) 팀이 User Stories을 사용하고 있지만 잘 작동하지만 일반적인 합의가 없습니다. 이런 경우에, 사용자 스토리에 권장되는 템플릿은 다음과 같습니다

"사용자의 < 유형>으로, 나는> 어떤 목표를 < 원하는 그래서 < 몇 가지 이유가>."

하지만 아무것도 세력이 이야기를 사용하고 그들이 모든 프로젝트에 적합하지 않은 (예를 들어, 제프 서덜랜드는 그가 PDA 프로젝트, UI 및 탐색 규칙은 이야기가 너무 복잡 다시 이야기를 사용하지 않을 것이라고 말했다).

스크럼을 사용하면 일반적으로 (그리고 정시에 맞춰야 함) 사양을 (이는 RUP와 유사한 방식의 철저한 유스 케이스 모델과는 다릅니다.)으로 생산하는 것이 일반적이라고 할 수 있습니다. 자신의 상황에 맞는 형식이 무엇인지 찾아내는 것은 당신에게 달려 있습니다.

Answer 3

당신은 사용 사례로 요구 사항을 기술에 유지할 수 있습니다. 또는 사용자 스토리로서. 또는 시로. 당신 (제품 소유자, 팀 및 ScrumMaster 및 잠재적으로 심지어 이해 관계자들까지 포함하여)이 무엇이든지 알고 있고 이해합니다. Scrum에서 오는 두 가지 암묵적인 요구 사항이 있습니다.

요구 사항

가 할 수있는 방법으로 설명해야합니다 가) 스프린트 선택하면이 요구 한 요구 사항은 하나의 질주, B에서 행할 뭔가 지점)과 그들을 분할하는 것이 될 수있다 완전하고 명백하게 구현되었습니다 ("완료").

사용자 스토리가 인기가있는 이유입니다. 이해하기 쉽고 간단하게 시연 할 수 있습니다. 실제로 수행 할 것인지 확인하기 위해 스프린트 동안 생성 된 증가분을 시도해보십시오.