Epics, 스토리 및 기능을 사용하는 방법은 다음과 같습니다.

프로젝트주기 초반에 Epics 가 나옵니다 . 이것들은 매우 마케팅 수준이 높으며 거의 ​​핵심적인 기능입니다. 다음과 같이 요약에 사용할 수있는 것

새로운 웹 사이트를 통해 고객은 제품을 검색하고 가용성 및 가격을보고 주문을하고 과거 주문 내역을 볼 수 있습니다.

이것은 다음과 같은 에픽으로 이어집니다

• 제품 카탈로그 찾아보기
• 가용성보기
• 가격보기
• 주문하기
• 주문 내역보기

이것들은 사용자 스토리로 작성됩니다 (예 : 고객으로서, 제품 카탈로그를 탐색하여 정보에 근거한 구매 결정을 내릴 수 있기를 원합니다). 실제로 개발 및 출시 될 제품에 대한 10 가지 스타터 역할 만합니다.

그런 다음이 Epics는 사용자 스토리 로 세분화됩니다 . 실제 엔드-투-엔드 사용자 여정은 범위가 매우 제한되어 있으며 독립적 으로 추정 및 계획 하고 한 번의 릴리스 주기로 개발 , 테스트 및 릴리스 할 수있는 방식으로 정의됩니다 .

사용자 스토리는 제공 단위입니다. 완전하거나 완전하지 않거나, 생방송 또는 생방송하지 않는 사용자 스토리입니다.

Epic은 많은 수의 사용자 스토리를 야기 할 수 있지만, 모두 동시에 개발 또는 출시되지는 않습니다.

예를 들어 제품 카탈로그 찾아보기 서사시가

• 범주 계층 구조 탐색
• 키워드로 검색
• 제품 속성별로 필터링 (예 : 가격 범위, 브랜드, 색상, 크기 등)

다시 말하지만, 이들 각각은 다음과 같은 형식으로 작성됩니다. 예를 들어 고객으로서 카테고리 계층 구조를 탐색하여 제품을 찾아보고 내 요구에 가장 적합한 제품으로 드릴 다운하고 싶습니다.

일반적으로 대부분의 프로젝트에는 수십 개의 Epics와 수백 개의 이야기가 있습니다.

이제 스토리 라이프 사이클을 진행하면서 이러한 스토리에 Feature을 태그합니다 . 예를 들어, 모든 찾아보기 및 검색, 재고 및 가격 책정에 ‘product-catalog’라는 태그가 지정됩니다. 신용 카드 결제와 관련된 장소 주문 스토리에는 ‘신용 카드’라벨이 붙어있을 수 있으며 PayPal 결제와 관련된 주문 스토리에는 ‘페이팔’라벨이 붙어 있습니다.

이 레이블은 동일한 활동을 수행하는 여러 유형 (예 : 모든 작업장 주문 스토리)이 아니라 함께 릴리스되어야하기 때문에 함께 속하는 스토리를 그룹화하는 역할을합니다.

예를 들어, “신용 카드로 지불하는 주문”스토리는 “PayPal로 지불하는 주문”스토리와 같은 서사에 속하지만 함께 릴리스 할 필요는 없습니다.

반면, “신용 카드로 결제 주문하기”스토리, “신용 카드로 환불 환불 처리”스토리 및 “고객이 자신의 계정에서 저장된 신용 카드를 관리하도록 허용”스토리는 서로 관련이있는 것으로 보입니다. . 모두 ‘신용 카드’기능 레이블로 태그가 지정되었을 것입니다. 즉, 모두 “신용 카드”기능에 속합니다. PayPal에 대한 환불 환불을 처리 할 수 ​​없거나 계정에서 저장된 신용 카드를 관리 할 수없는 경우 신용 카드로 주문할 수있는 기능을 공개하는 것은 큰 도움이되지 않습니다.

참고 : 일반적으로 그렇습니다. 이것은 결국 비즈니스 결정입니다. 시장 출시 시간이 중요한 경우, 이들 중 하나가 아닌 다른 하나를 사용하는 합법적 인 이유가있을 수 있습니다.

따라서 Epics는 독립적으로 개발할 수있는 스토리로 세분화되는 기능을하는 반면, 피처는 함께 공개되어야하는 스토리를 그룹화하는 기능을합니다.

Epics가 User Stories로 분해되고 User Stories가 기능으로 구성되었다고 말할 수 있습니다. 지형지 물에 속하는 이야기는 일반적으로 Epics 전반에 걸쳐 있습니다. 따라서 Epics와 특징은 엄격한 계층 구조가 아닌 직교입니다.

우리가 일하는 방식에서 에픽 스가 이야기로 나뉘어지면 목적을 잃습니다. Epics를 추정하거나 계획하지 않습니다. Epics의 진행 상황을 추적하지 않습니다. Epics는 공개하지 않습니다. 사용자 사례를 추정, 계획 및 추적합니다. 그리고 우리는 기능을 출시합니다.

답변