기능을 공유하는 스토리를 다루는 방법

두 가지 이야기가 있습니다 (혜택 부분이 없다는 것을 알고 있습니다)

1. 여신 관리 사용자로서 저는 현재 및 이전 급여 급여 차이를 볼 수 있습니다.
2. 신용 관리 사용자 인 저는 현재 및 이전 급여 급여 차이에 대한 PDF가 포함 된 전자 메일을받을 수 있습니다.

둘은 동일한 쿼리 / 필터 기준을 갖기 때문에 관련됩니다. 유일한 차이점은 "보기"스토리에서 결과가 사용자에게 표시되고 "이메일"스토리에서 결과가 사용자에게 이메일로 전송되는 PDF로 작성된다는 것입니다.

나는이 두 이야기의 공통된 측면을 분리하거나 심지어 그렇게해야하는지 고민하고 있습니다.

예를 들어 둘 다 동일한 쿼리를 가지며 결과로 수행하는 작업이 다릅니다.

검색어를 기술적 인 다른 스토리로 분리해야합니까?

PDF 작성 및 이메일 전송은 오프라인에서 수행해야합니다. 이것이 기술적 인 이야기가되어야합니까?

그 두 이야기를 2 개의 기능적인 이야기와 2 개의 기술적 인 이야기로 나누는 것을 볼 수있었습니다.

1. 시스템으로서, 나는 현재 및 이전 급여의 차이를 계산할 수 있습니다.

2. 신용 관리 사용자는 현재 및 이전 급여 급여의 차이점을 볼 수 있습니다.

3. 시스템으로서, 저는 현재 및 이전 급여의 차이에 대한 PDF 문서를 작성할 수 있습니다.

4. 신용 관리 사용자는 현재 및 이전 급여에 대한 PDF 차이가 포함 된 전자 메일을 받도록 요청할 수 있습니다.

내가 다시 계속 문제는 4 층 이야기가 독립적이 아니며 "케이크를 썰지"않는다는 것입니다.

그래서 나는이 두 가지를 어떻게 다루어야할지 잘 모르겠습니다.

사용자 사례는 시스템 사양이나 기능 요구 사항이 아닙니다. 오히려 이러한 사양이나 요구 사항으로 이어질 수있는 대화의 시작입니다.

따라서 시스템 구현에 중복이있을 것으로 기대합니다. 사용자 스토리는 이러한 기능적 중복을 설명하거나 제거하기위한 것이 아닙니다. 사용자 스토리의 목적은 구현 세부 사항을 설명하지 않고 사용자 관점에서 기능적 기대를 포착하는 것입니다.

하지 말아야 할 것 : 이야기를 나누고 나누십시오. 한 이야기를하고 다른 이야기를하십시오.

해야 할 일 : 개발자 팀이 두 번째 이야기를 알고 있는지 확인하십시오.

세부적인 작업을 계획하고 우아한 방법으로 둘 다 처리 할 수있는 일반 모델을 만드는 데 따르는 문제는 어렵다는 것입니다.

사용자 스토리의 목적은 작업을 완료하는 것입니다. 우아함은 이차적 인 목표이며 리팩토링에 맡겨야합니다.

분명히 이것을 최대로 가져 가면 수행 해야하는 10 가지 다른 유사한 작업에 대해 아무에게도 말하지 말고 첫 번째 작업이 완료 될 때까지 두 번째 또는 세 번째 작업을 생각하지 않아도됩니다. 당신이 그것을 계획하고 싶다면 폭포와 함께 가십시오.

Robert Harvey와의 폭력적인 합의에서 사용자 스토리의 목적은 사용자가 수행 할 수있는 작업을 이해하는 것입니다. 정리를 할 때 고객은 사용자 스토리를 이해하고 관심을 갖지만 개발자는 조금 더 관심을 갖습니다. 작업을 이해하고 추정하기 위해 충분한 질문을 한 후에는이를 지원하기위한 작업을 만들 수 있습니다.

이 특정한 경우, 먼저 다루는 것과 함께 수행 될 두 사용자 스토리의 핵심을 가능하게하는 태스크를 작성할 수 있습니다.

사용자 스토리에 추가해야 할 중요한 사항은 다음과 같습니다.

• 허용 기준
• 가정

엄밀히 말하면, 사용자 스토리는 필요한 결과를 이해하기위한 대화의 약속입니다.

예를 들어, 두 번째 사용자 이야기

신용 관리 사용자 인 저는 현재 및 이전 급여 급여 차이에 대한 PDF가 포함 된 전자 메일을받을 수 있습니다.

다음에 대해 생각하십시오.

• 이 요구 사항을 추진하는 "필요"사용자는 무엇입니까? (솔루션에서 PDF를 전자 메일로 보냈습니까? 이것이 필요를 해결하지 못할 수 있으며 팀이 더 나은 솔루션을 만들 수 있습니다)
• 이 사용자에게 "필요"하고 솔루션을 검증 할 수있는 최소 슬라이스는 무엇입니까? 짧은 피드백 루프가 중요합니다.

스토리 분할에 접근 할 때는 가능한 한 INVEST 기준을 기억하십시오.

1. 나는 의존적이다
2. N의 egotiable
3. V 가능
4. E의 stimatable
5. S 몰
6. T의 estable

자연스런 질서가있는 이야기 는 괜찮 습니다. 이것을 고려하십시오-일반적으로 첫 번째 이야기는 필요한 기능을 제공하고 두 번째 이야기는 그 위에 쌓입니다.

"기술적 인"스토리에 도전 할 것입니다. 일반적으로 사용자 결과 중심 스토리의 구현을 지원하는 데 도움이되는 작업 일 가능성이 높습니다.

TL; DR

두 사용자 스토리가 동일한 반복 내에서 범위 내로 가져 오면 스토리를 구현 계획 및 수행자 태스크로 분해하는 것이 팀의 임무입니다. 사용자 스토리는 컨텍스트와 범위를 제공합니다. 그것들은 구현, 사양 또는 펀치리스트 항목이 아닙니다.

반복 작업으로 스토리를 분해해야 함

Scrum을 따르 든 다른 민첩한 방법론을 따르 든 반복의 계획 단계를 건너 뛰는 것은 일반적인 오류입니다. 스크럼에서 제품 백 로그 항목 (사용자 스토리 일 필요는 없음)을 현재 Sprint로 가져 오면 팀은 Sprint Planning의 일부를 사용하여 작업 항목 간의 공통성을 제거하고 종속성을 식별 하며 그런 다음 Sprint Backlog를 개발하여 작업 수준의 작업을 캡처하십시오.

게시물에서 지적했듯이 민첩한 반복이 밀접하게 관련된 사용자 스토리를 포함하는 것은 드문 일이 아니며 실제로 바람직하지도 않습니다. 스크럼에서는 스프린트 목표를 사용하여 표시됩니다. 스크럼 프레임 워크 외부에서는 종종 공유 된 목표 또는 공유 된 종속성으로 인해 관련 기사를 가져 오는 것이 합리적 입니다. 단일 반복 내에서 공유 종속성을 추출한 후 작업함으로써 팀은 종종 유사하지만 동일하지 않은 기능을 위해 코드를 리팩터링하거나 반복 할 필요가 없습니다.

과제 구현 사례

사용자 스토리의 종속성 계획에 대해 생각할 수있는 또 다른 방법이 있습니다. 일반적으로 :

1. 서사시 / 테마는 백 로그에서 장기 계획 또는 그룹화에 사용됩니다.
2. 사용자 스토리는 목표, 컨텍스트 및 범위를 전달하는 데 사용됩니다.
3. JIT (Just-In-Time) 계획은 단일 반복 내에 적합한 구현을 개발하는 데 사용됩니다.
4. 작업은 하나 이상의 사용자 스토리에 대한 정의 정의를 충족하는 적시 계획을 구현합니다.

사용자 사례를 구현 계획 또는 작업 목록으로 취급하는 것은 대부분의 실무자에게 민첩한 반 패턴으로 간주됩니다. 무엇을 선택하든, 민첩한 프레임 워크의 적시 계획 단계를 건너 뛰지 말고 팀 프로세스 내 어딘가 에서 종속성 및 공유 구현 세부 정보를 추적하십시오 .