사용자 스토리, 기능 및 서사시의 관계?

아직 민첩한 사람은 사용자 스토리, 기능 및 서사시의 관계 또는 차이점을 완전히 이해하고 있는지 잘 모르겠습니다.

이 질문 에 따르면 기능은 스토리 모음입니다. 답변 중 하나는 기능이 실제로 서사시라는 것을 암시합니다. 기능과 서사시가 같은 것으로 간주됩니까? 기본적으로 관련 사용자 사례 모음입니까?

우리의 프로젝트 관리자는 계층 구조가 있다고 주장합니다.

에픽-> 기능-> 사용자 스토리

기본적으로 모든 사용자 스토리는이 구조에 속해야합니다. 따라서 모든 사용자 스토리는 엄브렐러 기능에 속하고 모든 기능은 서사시 적이어야합니다.

나에게는 그것은 어색하다. 사용자 스토리, 기능 및 서사시가 어떻게 관련되어 있는지 명확히 할 수 있습니까? 아니면 차이점을 명확하게 설명하는 기사가 있습니까?

그들은 실제로 매우 일반적인 용어입니다. 그것들을 해석하는 방법은 여러 가지가 있으며, 문헌에 따라 다르며 사람들이 어떻게 보는가. 내가 말한 모든 것을 큰 소금 알갱이로 가져 가라.

일반적으로 Epic은 소프트웨어에서 매우 전역적이고 잘 정의되지 않은 기능으로 구성됩니다. 매우 넓습니다. 일반적으로 이해하기 쉽고 민첩한 반복에 적합하게 만들 때 더 작은 사용자 스토리 또는 기능으로 분류됩니다. 예 :

Epic-
고객이 웹을 통해 자신의 계정을 관리하도록 허용

기능 및 사용자 사례는보다 구체적인 기능으로 승인 테스트를 통해 쉽게 테스트 할 수 있습니다. 단일 반복에 맞출 수있을만큼 세분화 된 것이 좋습니다.

기능은 일반적으로 소프트웨어의 기능을 설명하는 경향이 있습니다.

기능
-웹 포털을 통해 고객 정보 편집

사용자 스토리는 사용자가 원하는 것을 표현하는 경향이 있습니다.

사용자 스토리
은행 직원으로서
고객 정보
를 최신 상태로 유지할 수 있도록 수정할 수 있기를 원합니다 .

나는 둘 사이에 실제로 계층 구조가 있다고 생각하지 않지만 원하는 경우 또는 작업 방식에 맞는 경우 계층 구조를 가질 수 있습니다. 사용자 스토리는 기능에 대한 특정 정당성 또는 기능 수행 방법 일 수 있습니다. 아니면 다른 방법 일 수도 있습니다. 기능은 사용자 스토리를 실현하는 방법이 될 수 있습니다. 또는 그들은 같은 것을 나타낼 수 있습니다. 사용자 스토리를 사용하여 소프트웨어의 제약 조건을 설명하는 비즈니스 가치와 기능을 제공하는 요소를 정의 할 수 있습니다.

사용자 이야기 : 고객으로, 나는 카드가 가장 인기있는 크레딧으로 지불하고자하는
기능 정부의 GOV-TAX-02 XML API를 지원합니다.

시나리오의 문제도 있습니다. 일반적으로 지형지 물 / 사용자 스토리가 실행되는 방식입니다. 그들은 일반적으로 특정 합격 시험에 깔끔하게 매핑됩니다. 예를 들어

시나리오 : 자금 인출
은행 계좌에 2000 $가 있다고 가정
하면 100 $를 인출 할 때
현금으로 100 $를 받고
잔액은 1900 $입니다.

그것이 내가 일하는 용어를 정의하는 방법 입니다. 이러한 정의는 수학적 정의 나 표준화 된 용어와는 거리가 멀다. 우익 정치인과 좌익 정치인의 차이와 같습니다. 당신이 사는 곳에 따라 다릅니다. 캐나다에서는 미국에서 우익으로 간주되는 것이 좌익으로 간주 될 수 있습니다. 매우 가변적입니다.

진심으로, 나는 그것에 대해 너무 걱정하지 않을 것입니다. 중요한 것은 팀의 모든 사람이 정의에 동의하므로 서로를 이해할 수 있다는 것입니다. 스크럼과 같은 일부 방법은 더 공식적으로 정의하는 경향이 있지만 나에게 적합한 것을 선택하고 나머지는 남겨 둡니다. 결국, 포괄적 인 문서 보다는 프로세스와 툴 에 대한 개인과 상호 작용 및 작업 소프트웨어 에 대해 민첩하지 않습니까?

Epic : 매우 큰 사용자 스토리는 결국 작은 스토리로 나뉩니다.

사용자 스토리 : 개발자가이를 구현하기위한 노력을 합리적으로 추정 할 수 있도록 충분한 정보를 포함하는 요구 사항에 대한 매우 높은 수준의 정의.

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

기능 : 소프트웨어 응용 프로그램 또는 라이브러리의 특징 또는 성능 (예 : 성능, 이식성 또는 기능성).

http://en.wikipedia.org/wiki/Software_feature

이 용어에 너무 엄격한 계층 구조를 적용하지 않도록주의하십시오. 우리는 이전 일에서 그렇게하려고했습니다. 두번. 두 시도는 달랐으며 두 번이나 불필요하게 자신을 제한했다는 것을 알았습니다. 유일한 상수는 사용자 스토리 의 정의였습니다 . 계획 관점에서 이야기는 프로젝트의 기본 구성 요소입니다. 더 큰 용어 (에픽, 피처 등)는 사실상 태그 일뿐 입니다. 태그는 스토리를 여러 Epics 및 여러 기능의 일부로 동시에 존재하게하는 쉬운 방법입니다. 그보다 더 엄격한 정신적 노력은 가치가 없습니다.

태그는 스택 교환에서 작동하며 작동 할 수도 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

본인은 현재 어떤 애자일 캠프에 따라 달라질 수있는 용어 일 뿐이며 외부 이해 관계자를 포함하여 팀의 모든 사람들이 자신의 캠프 를 확실히 구성 할 수 있기 때문에 실제로 정답이 없다는 많은 답변에 동의합니다. 그들이 무엇을 의미하는지 이해하십시오. 요구 사항을 구성하는 방법 일뿐입니다.

내가 좋아하는 대답은 Mike Cohn의 캠프에서 왔으며 매우 간단합니다.

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

• 에픽은 단지 큰 이야기입니다 (계층 적)
• 테마는 이야기의 그룹 일뿐입니다 (태그와 매우 유사).

그는 실제로 "기능"이라는 용어를 피합니다. 나는 그것이 전통적인 폭포 세계에서 일반적인 용어이기 때문에 주로 가정합니다. 많은 애자일 캠프는 차이점을 강조하기 위해 다른 용어를 사용하는 경향이 있습니다.

따라서 PM의 정의에서 Feature는 Epic-Story 계층의 중간에 있습니다.

내 InfoQ 기사 http://www.infoq.com/articles/visualize-big-picture-agile ;-) 에서이 정의에 대한 내 정보 그래픽입니다.

기능과 에픽은 동일하지 않습니다.

• 기능은 사용자 스토리가 아닙니다.
• 에픽은 사용자 스토리입니다.
• 사용자 스토리는 에픽 일 수 있습니다.
• 사용자 스토리에는 많은 기능이 포함될 수 있습니다.
• 기능은 1에서 많은 사용자 스토리를 수행 할 수 있습니다.

계획 단계에서는 토론 을 통해 솔루션을 구현하려는 노력이 며칠 내에 달성하기에는 너무 커서 사용자 스토리 가 일반적으로 Epics로 식별됩니다 . 이 단계에서 제품 기능 이 식별됩니다. 그러나 그것은 토론의 부산물 일뿐입니다. 그런 다음 기능 을 사용하여 제품 로드맵을 계획합니다. 이는 별도의 토론입니다.

서사시는 촬영 및 결과 더 설명 사용자 스토리 각 에픽합니다. 특징 및 서사시는 토론 구동하는 데 사용되는 백 로그 정제 및 스프린트 계획 세션을. 이 때 토론에서 나온 사용자 스토리 는 개선 되고 우선 순위가 정해 지고 스프린트 계획 에서는 스프린트로 구현됩니다.

그것은 단지 문제 분해입니다. 그들은 다른 크기를 제외하고는 단지 이야기입니다.

나는 개인적으로 크기를 표시하지 않는 것을 선호하지만 그렇게하면 괜찮습니다. 작업 공간에 정의가 무엇인지 PM에게 물어보십시오.

우리 조직에는 2,000 명 이상의 개발자가 있으므로이 질문에 대한 답변은 공통 제품을 위해 함께 작업하는 수백 명의 애자일 팀 간의 유창하고 명확한 의사 소통에 중요합니다. 매우 작은 조직의 경우 계층 구조가 필요하지 않은 매우 간단한 구조를 가질 수 있습니다 (다른 사람들이 대답했듯이). 그러나 대규모 조직의 경우 체계적이고 확장 성 있고 일관된 계층 구조가 필요합니다. 엄격하게 계층 적이 지 않은 계층 구조에서 계층 구조를 만드는 데 어려움이 있습니다.

또한, 우리는 이러한 각기 다른 수준을 "작업 항목"이라고합니다. 위의 응답자 중 일부를 포함하여 일부 조직은 이기종 레벨을 스토리 또는 사용자 스토리 (및 과거에도 있음)로 지칭하지만이 모호한 점을 발견하여이를 일반적으로 작업 항목이라고합니다.

우리가 지금까지 "공식적으로"수행 한 최선의 방법은 Dean Leffingwell의 투자 테마 및 비즈니스 에픽 (Business Epics)의 SAFe 구조를 따라 계층 구조의 최상위 (위에서 두 번째), 그 아래의 피쳐, 그리고 피쳐 아래의 스토리를 따르는 것입니다. 애자일에 따르면 작업은 항상 스토리 아래에 있으므로 해당 용어를 더 이상 재사용하지 않도록주의해야합니다. 우리는 적어도 모든 팀에서 일관성을 유지하기 위해 SAFe를 따르기로 결정했습니다.

그러나 이것은 여전히 ​​우리의 필요에 충분하지 않습니다. 당사는 기능을 소프트웨어 제품 소비자에게 명확하게 제공 할 수있는 것으로 정의합니다 (즉, 출시 예정 발표에 이러한 기능을 나열합니다). 그리고 우리는 스토리를 하나의 애자일 개발 팀이 단일 스프린트로 제공 할 수있는 더 적은 양의 범위와 작업으로 정의합니다. 우리는 이제 포트폴리오 수준 (이 수준 이하가 아님)에서 투자 테마 및 비즈니스 에픽의 SAFe 정의를 따르기 시작했습니다. 그리고 우리는 "테마"와 "에픽"이라는 오래된 정의를 사용하지 않기 시작했습니다.

우리는 이제이 방향으로 천천히 진화하고 있지만, 진보의 바퀴는 천천히 갈고 있습니다. 우리는 작업을 한 입 크기의 덩어리로 나누는 방법으로 여전히 어려움을 겪고 있으므로 여러 팀이 작업을 정의하고 원활하게 수행 할 수 있습니다. 이를 위해서는 피처보다 작지만 스토리보다 큰 "하위 기능"이 필요합니다. 하위 기능은 각 개별 팀이 기능에 대해 수행 한 작업 덩어리 또는 다른 시간에 (다른 스프린트 또는 다른 릴리스에서) 단일 팀이 수행 한 작업 덩어리에 사용할 수 있습니다.

또한 Feature와 Business Epic 사이에 여러 계층 레벨이 필요하지만 SAFE Investment Themes와 쉽게 혼동되기 때문에 "테마"라고 부르는 것 외에는 아직이 문제를 해결하지 못했습니다. 일부 큰 프로젝트 (릴리스)의 경우 5 ~ 8 개의 서로 다른 계층 레벨이 있으며 각각은 작업을 더 작은 단위와 작은 단위로 나눕니다. 이러한 테마를 "기능 그룹"으로 생각할 수 있지만, 반드시 올바른 용어는 아닙니다.

모호성이 아닌 명확성을 제공하는 용어를 사용하는 것이 중요하다고 생각합니다. 따라서 스토리를 언급하는 사람은 단일 스프린트에서 수행 할 수있는 가장 작은 작업 단위 (스토리 아래의 작업 제외)를 의미하며 하위 기능은 단일 기능으로 수행 할 수있는 기능에 대한 가장 작은 작업 단위를 의미합니다. 팀. 마찬가지로 피처 그룹은 피처 위의 계층 수준입니다. 그보다 약간 애매 모호하기 때문에 보통 테마라고 부르며 다른 테마의 부모와 자식으로 테마를 허용합니다. 피처, 하위 피처 및 스토리 레벨을 각각 단일 레벨로 제한하려고하지만 (피처는 다른 피처의 자식이 아니어야 함) 아직 100 % 제한하지는 않았습니다.

"태그"를 사용하여이 중 일부를 구성 할 수 있지만 태그는 모든 팀간에 작업을 분류하는 데 필요한 조직 작업 분류 구조를 제공하지 않습니다. 정의에 따르면 태그는 모호하지만 (다 대다 관계), 계층 구조는 일대 다입니다.

결론은 이것이 여전히 진행중인 작업이며 우리는 여전히 어려움을 겪고 있습니다. 그러나 Theme, Epic, Feature 및 Story의 SAFe 정의를 준수하면 올바른 방향으로 움직일 수 있습니다!

제품 백 로그 계층은 제품 크기와 모듈성 (정의 된 제품 영역 수)에 따라 크게 달라집니다.

소규모 프로젝트의 경우 : Epic> 스토리는 충분합니다. "기능"이라고 부릅니다.
대규모 프로젝트는 소설> 테마> 에픽> 기능> 스토리와 비슷해질 수 있습니다.

가장 좋은 예는 다음과 같습니다.
소설 = MS Office
테마 = MS Word / MS Excel ...
Epic = 표 / 글꼴 디렉토리 ...
기능 = 기본 표 / 표 색 구성표 / 셀 작업 ...
이야기 ( ' '테이블'에픽의 기본 테이블 기능) = 테이블 추가 / 테이블 그리기 / 원본 삽입 / 열 삽입 ...

백 로그에 대한 자체 스케일링을 정의 할 때 명심해야 할 점은 다음과 같습니다.
1. 스토리 : a) 한 번의 스프린트 내에서 항상 가능합니다. b)는 최종 사용자 항상 검증하지
2. 에픽 / 기능 : A) 한 스프린트 기간에 맞게 분해 될 필요가 없습니다; b) 항상 최종 사용자에 대해 테스트 할 수 있어야한다. C)는 항상로 선적, 수익이 창출 될 수있다 - ROI가 계산 얻을
3. 추가 여부 에픽> 고려할 때 기능 스토리> 섹션 또는 에픽에 충실 : 나는 에픽 스토리만을 사이에 기능을 삽입하는 것이 좋습니다 것 : 에픽은 '아무튼 1 릴리스에도 맞지 않으므로 1 릴리스 기간에 맞는 선적 가능 요소를 정의해야합니다 .

이것이 도움이 되길 바랍니다.

우리 조직에는 다음이 있습니다.

주제 = 스토리 모음을 그룹화하는 데 사용

Epic = 사용자 스토리로 세분화해야하는 대규모 사용자 스토리 (실제로 요구 사항)를 설명합니다.

특징 = 주석에 표시된 내용을 수행하고 필요한 제품의 기능을 설명합니다.

사용자 스토리 = 작업이 파생되는 가장 낮은 수준의 세부 정보입니다.