사용자 스토리에 요구 사항이 포함되지 않고 (카드에 기록 될 때) 여전히 구현 가능한 방법

"사용자 스토리는 요구 사항이 아니라 고객이 원하는 것을 상기시키는 것입니다. 스토리 내에 요구 사항을 넣을 수는 없습니다"라고 들었습니다. 그러나 고객이 다른 신용 카드에 대해 다른 처리를 원한다는 예를 들어 봅시다. 테스트 케이스를 작성할 수 있도록 구현하고 알아야하는 엄격한 요구 사항이 있습니다. 사용자 스토리에없는 경우 요구 사항은 어디로 가야합니까?

요구 사항이 더 낮은 경우 개발자는 스토리에서 어떻게 발전 할 수 있습니까? 테스터는 사용자 사례를 기반으로 테스트 사례 (상세 사례)를 작성하는 방법은 무엇입니까? DB 제약 조건, 필드 유효성 검사 등과 같은 요구 사항은 사용자 스토리 외부에 있습니까?

이 답변은 사용자 사례 및 하위 수준 요구 사항을 다루는 방법에 중점을 둘 것입니다. 나는 스크럼이나 애자일의 미덕에 대해 이야기하지 않을 것이다. 나는 전문가에 대해서도 이야기하지 않을 것입니다.

이 답변은 귀하가 Scrum에 탑승했지만 아직 귀하에게 적합한 방법을 찾지 못했다고 가정합니다.

다른 사람들이 언급했듯이, 사용자 사례는 사용자 가 소프트웨어를 원하는 방식을 다루기 위한 것입니다. 사용자는 데이터베이스 테이블, 제약 조건, 아키텍처 패턴 등과 같은 저수준 구현 항목에 신경 쓰지 않기 때문에 사용자 스토리에서 이러한 세부 정보를 찾을 수 없습니다.

그러나 이것이 세부 사항을 어디에도 기록해서는 안된다는 의미는 아닙니다.

개발자가 사용자 사례를 구현할 때는 일반적인 사용자가 알지 못하는 낮은 수준의 세부 정보를 알고 있어야합니다. 이 정보는 SME, BA, 제품 소유자, 설계자 또는 기타 전문가 나 기술 전문가가 제공 할 수 있습니다.

이것이 하위 레벨 세부 사항이 사용자 스토리에 기록되어야 함을 의미합니까? 아니요 (그렇습니다).

이야기가 만들어지고 구현되는 시점 사이의 어느 시점에서 누군가 그것을 구현 하는 방법 을 연구해야 할 것입니다. 이것은 일반적으로 스토리에 관련된 사람들 (사용자, 건축가, 개발자 등)과 대화하는 형태를 취합니다. 이러한 대화는 사용자 사례 구현 범위를 명확하게 나타내는 명확한 수락 기준 을 가져야합니다 . 이러한 세부 사항은 어딘가에 그리고 그것이 어디에 있는지에 대한 기록이 필요합니다. 여기서 핵심 은 사용자 스토리가 생성 된 후 이러한 세부 정보가 도출된다는 것입니다. 나는 이것이 당신의 전문가 가 강조하려고하는 것이라고 생각합니다 .

개발자에게는보다 구체적인 요구 사항을 사용자 사례와 연결할 수있는 방법이 필요합니다. 그렇게 하는 방법 은 전적으로 팀의 책임입니다.

팀원이 이러한 세부 정보를 사용자 사례에 보관하지 않으려면이를 존중해야합니다. 고급 사용자 사례에 구현 세부 정보를 제공하지 않으면 이점이 있습니다. 그것들을 간결하게 유지하고 백 로그를 사용자와 제품 소유자가 원하는 것에 대한 이력으로 읽을 수 있습니다. 개발자로서의 요구 사항도 알려주세요. 사용자 스토리에 연결 하는 것만으로도 모든 사람을 행복하게 하는 절충안을 해결할 수 있어야합니다 .

예, BS. 그리고 스크럼은 민첩하지 않습니다.

나는 민첩하게 행동하는 한 가지 방법이 있으며 그들이 사용하는 '민첩한'방법론의 성서에 제시된 모든 규칙을 따라야한다는 소위 민첩한 실무자의 강성을 싫어합니다. 모든 BS.

민첩한 민첩성입니다.

애자일은 최소한의 오버 헤드로 작업을 처리하는 것입니다. 일반적으로 민첩한 역할로 더 많은 문서를 작성하기 때문에 "문서화 없음"을 의미하지는 않으며 문서화를위한 프로세스를 계획 할 필요없이 문서화를 시작하면됩니다. 코딩, 테스트 및 요구 사항 캡처와 유사합니다. 민첩한 프로세스에서 중요한 것은 BS없이 빠르고 효율적으로 업무를 수행하는 데 도움이되는 것입니다.

따라서이 경우 카드에 사용자 요구 사항을 넣으면 필요한 코드를 작성, 테스트, 문서화 및 설명하는 데 도움이됩니다 ... 요구 사항을 카드에 넣고 전문가에게 팀이 항상 옳다고 말하십시오.

나머지 개발자 팀은 어떻게 생각하십니까? 진정한 민첩한 방법론에서 요구 사항을 '사용자 대화'없이 미리 작성해야한다고 생각하면 팀이 업무를 수행하기 위해 최선을 다한다고 생각하는 것을 수행합니다. 팀이 사용자 대화가 좋은 것이라고 생각하면, 대화를 듣고 왜 이것을 생각하는지 이해하고 자신의 업무 방식을 이끌어냅니다.

이것을 사용자 스토리라고 부르지 마십시오. 모든 사람이 행복 할 것입니다.

대답은 당신이 원하는 곳에 적을 수 있다고 생각합니다.

일반적으로 특정 구현은 몇 가지 이유로 사용자 스토리에 포함되지 않습니다.

1. 고객이 원하는 것을 알고 있지만 어떻게 구현 될지는 모릅니다.
2. 고객은보다 구체적인 요구 사항이 관련되어 있음을 알고 있지만 실제로는이를 관리 및 / 또는 이해하지 않습니다.
3. 모든 사람들은이 시점에서 특정 구현을 완전히 알고 있다고 생각하지만, 경험상 모두 변경 될 것이기 때문에 아무도 다시 작성하기를 원치 않기 때문에 아무도이를 작성하고 싶지 않습니다.

필요한 경우 추가 문서를 생략하는 규칙은 없습니다. 클라이언트가 액세스해야 할 수도 있고 아닐 수도 있습니다. 특정 구현에 대해 귀하와 고객 사이에 일종의 계약을 맺고 싶을 때 그것을 따르고 작동하지 않을 때 고객이 그에 동의한다고 비난하는 것은 잘못입니다. 고객이 신용 카드 처리에 대한 기술적 세부 사항을 이해하면 이러한 문서를 해당 문서와 공유하고 대화의 일부로 만들어야합니다.

Scrum 컨설턴트가 귀하에게 요구하는 바가 Scrum에 요구 사항이 필요하지 않다면 컨설턴트가 매우 부족하다는 것입니다. 사용자 스토리가 실제로 요구 사항이 아니라는 한 가지 요구 사항이 있다고 말하는 것은 잘못된 것입니다.

다른 유형의 소프트웨어 요구 사항은 무엇입니까?

비즈니스 요구 사항

이들은 일반적으로 시스템에 대한 일종의 경영진 진술에 해당하는 높은 수준의 비즈니스 요구입니다. 그것은 의도적으로 높은 수준이고 광범위하며 그 자체만으로 훨씬 더 자세하게 구현할 수는 없습니다.

사용자 요구 사항

다음은 익숙한 사용자 사례 요구 사항입니다. 그들은 일반적으로 스티커 메모에 맞을 수 있습니다.

• 액터- 일반적으로 사용자 또는 이해 관계자.
• 필요- 사용자에게 필요한 일부 항목 또는 일반 기능
• 이유- 이 필요성이 존재하는 이유 또는 배경
• 수락 기준- 이것은 사용자 승인 테스트를위한 프레임 워크이며 Sprint Demo 동안 제품 소유자가 사용자 스토리의 수락 여부를 결정하는 방법입니다.

기능 또는 시스템 요구 사항

퍼즐에서 빠진 조각 인 것 같습니다. 사용자 수준 요구 사항에 따라 기능 요구 사항은 시스템 수준의 행위자와 시스템 속성 및 시스템의 동작 및 기능을 정의합니다. 이것은 스토리 형식으로 이루어질 수 있으며 백 로그에 포함될 수 있습니다. 이러한 항목은 독립적이어야하며 하나의 사용자 요구 사항과 독립적으로 구현할 수 있습니다.

• 액터- 어떤 종류의 시스템 또는 구성 요소.
• 요구- 존재해야하는 시스템의 요구, 속성 또는 행동 설명.
• 이유- 시스템에서 이것이 필요한 이유의 배경
• 수락 기준- 시스템 및 통합 테스트 수행 방법을 전달하는 데 필요한 시나리오, 동작, 기능 및 흐름. 요구 사항에 대해 이러한 유형의 테스트를 통과하면이 기능 요구 사항이 완료된 것입니다. 이것들은 사용자 스토리의 외부 문서에 존재할 수 있지만 스프린트에서 스토리를 할당하기 전에 완료해야합니다.

기능적 요구 사항은 프로세스의 격차로 설명하는 것처럼 들리는 솔루션을 정의합니다.

언급하지 않아도되지만 질문에 중요하지 않은 주목할만한 요구 사항 유형 : 비 기능 요구 사항, 기술 요구 사항 등

사용자 스토리는 사용자가 시스템에서 기대하는 인터페이스를 설명하는 것을 목표로 한 특정 종류의 인공물입니다. 이것이 저수준 세부 정보가 단순히 거기에 속하지 않는 이유입니다. 그것들을 거기에 넣으면, 당신은 인공물의 의도를 바꾸고 더 이상 미국의 정의에 맞지 않습니다.

더 낮은 수준의 요구 사항과 설계 결정을 캡처하려면 다른 형식의 사양을 사용하십시오. 이러한 다른 형태는 정확히 조직에서 해결하고 특정 환경에 맞게 사용자 정의해야하는 것입니다.

귀하의 질문은 다음과 매우 유사하게 들립니다

나는이 CarFactory 를 가지고 있으며 자전거를 만들어야하지만 OOD "Guru"는 그렇게 할 수 없다고 말합니다. 이 BS는 무엇입니까?!

코드와 프로세스에서 모두 아티팩트에 대한 우려와 응집력의 분리를 존중하십시오.

이 방법의 목적은 사용자 스토리를 제한하는 것이 아니라 나쁜 요구 사항을 방지하는 것입니다.

내 경험상 사용자는 일반적으로 글쓰기 요구 사항이 없습니다. 개발자는 일반적으로 쓰기 요구 사항이 없습니다. 도대체 그냥 인정하자 : 요구 사항을 작성하기 어렵다!

사용자가 사용 사례의 일부로 요구 사항 용어로 무언가를 작성하는 것이 유효하다고 생각합니다. 그러나 그렇게하면 자동으로 요구 사항이되지는 않습니다. 두 가지 상충되는 사용 사례를 갖는 것은 사소한 문제입니다. 두 가지 상충되는 요구 사항이있는 것은 주요 계약 위반 문제입니다. 시대 이전에 서로 홍보하는 것은 의미가 없습니다.

나는 드라코 니안의 관점은 인간 본성의 인정에서 비롯된 것이라고 생각합니다. 사람들이 사용자 스토리를 요구 사항을 놓을 장소로 생각하기 시작하면 그렇게 할 것입니다. 정보와 같은 요구 사항을 수집하는 다른 방법에 비해 사용 사례의 실제 이점은 사용자의 자연어와 표기법으로 표현되어 있다는 것입니다. 이를 통해 개발자는 고객의 관점에서 생각할 가능성이 높아집니다. 완벽한 세상에서는 냉담한 요구 사항도 거기에 갈 수 있습니다. 실제로 이러한 단어는 개발자가 이해하기 쉬운 요구 사항을 파악하고 민첩한 개발에서 사용 사례를 사용하여 발굴하려는 미묘한 문구와 뉘앙스를 놓치는 경향이 있습니다.

자신의 결정을

'더 낮은 요구 사항이 없다면 개발자가 실제로 스토리를 개발할 수있는 방법은 무엇입니까?' 최종 사용자의 요구에 직교하는 세부적인 요구 사항 (예 : DB 제약 조건, 필드 유효성 검사 등)은 실제로 사용자에게 중요하지 않습니다. 매우 다양한 필드 유효성 검사, 매우 다른 DB 구조 또는 기존의 DB가 전혀 없어도 사용자의 요구를 충족시킬 수 있다면 사용자가 특정 구현을 염두에두고 이러한 정보를 구성하는 것이 비생산적 일 수 있습니다. 시스템이 결국 구현되는 방식과 다릅니다.

귀하는 전문 개발자이므로 구현 세부 사항에 대해 최대한 최선을 다해 전문적인 결정을 내립니다. 테이블을 원하는 사용자는 목수에게 원하는 나무 종류를 말할 수 있지만, 목수는 테이블 다리가 적당한 하중을 처리하기 위해 얼마나 두껍게해야하는지 결정해야합니다. 의미있는 결정을 내릴 정보가 부족한 경우 사용자와 논의해야하지만 자세한 요구 사항 문서에 대한 콘텐츠의 약 90 %는 실제로 모호한 사용자 스토리 상식 및 업계 모범 사례를 제외하고는 정보가 필요하지 않습니다. .

이러한 모든 세부 사항은 임의적이지 않습니다. 잘못된 선택과 더 나은 선택이 있으며 구현의 다른 부분에 영향을 미치기 때문에 문서화해야하지만 결국 구현 팀이 결정해야 할 구현 세부 사항입니다. 사용자 요구와 모범 사례에.

표준 자동차 유추-고객이 자동차를 빨간색으로 칠하기를 원한다면 사용자 스토리에 대한 적절한 설명은 어떤 빨간색 음영이 더 좋을지 물어야하지만 페인트의 화학적 조성은 아닙니다. 그럼에도 불구하고 비가 오지 않는 수채화로 차를 페인트하지 않는 것이 좋습니다. 그렇게하지 않는 것이 가장 좋습니다.

TL; DR

사용자 스토리는 제품에 어떤 가치를 추가해야하며 그 이유를 문서화하기위한 것입니다. 구현 세부 사항 (예 : 어떻게 값이 추가 테스트, 측정, 또는 검증되어야한다) 이야기에 의해 제한되어 있지만, 그 안에 포함되어 있지 않습니다. 프레임 워크 내에서 유연성과 민첩성을 유지하기 위해 의도적으로 별도의 아티팩트로 남겨집니다.

스펙 및 구현 세부 사항은 ATDD (Acceptance-Test Driven Development), TDD (Test-Driven Development) 및 BDD (Behavior-Driven Development) 스크립트 및 시나리오와 같은 다른 아티팩트에서 가장 자주 캡처됩니다. 이러한 특정 아티팩트는 Scrum 프레임 워크에 의해 의무화되지 않지만, 다른 효과적인 프로세스 제어가없는 경우에는 확실히 좋은 출발점이 될 것입니다.

사용자 사례가 사양이 아님

오리지널 포스터 (OP) 는 다음과 같은 질문을했다 :

[A] 고객은 다른 신용 카드에 대해 서로 다른 처리를 원하며, 테스트 케이스를 작성할 수 있도록 구현하고 알아야하는 엄격한 요구 사항이 있습니다.

사용자 스토리는 가치 를 제공 하고, 구현에 대한 대화를 안내 하는 컨텍스트 를 제공 하며 기능 이 제공하는 가치 를 활용할 가치 소비자 와 관련된 관점을 제공합니다.

전체 포인트 사용자 이야기는 구현 세부 사항은 규정하지 않은 것입니다. 팀은 적절한 맥락에서 식별 된 가치를 가치 소비자에게 전달하는 방식으로 기능을 자유롭게 구현할 수 있습니다.

작동하는 예

샘플 사용자 스토리

덜 모호한 사용자 스토리로 시작하면 설명하기가 더 쉽습니다. OP는 다음을 따르는 실행 가능한 사용자 스토리를 제공하지 않았기 때문에 INVEST 니모닉 예제를 위해 하나를 발명하겠습니다. 다음 이야기를 고려하십시오.

Discover 카드 결제를 선호하는 사용자는

Visa, Mastercard 또는 American Express로 제한되지 않도록 Discover 카드로 구매할 수있는 옵션을 원합니다 .

이는 구체적인 기능을 제공하고, 팀이 결정해야하는 구현 결정을 안내 할 수있는 컨텍스트를 제공하며, 가치 소비자를 Discover-card 소유 고객으로 식별합니다. 그것은 일련의 사양이 아니지만 개발 반복 중에 스토리를 구현하는 가장 좋은 방법에 대해 고객 및 팀과 올바른 대화를 나누기 위해 필요한 것입니다.

분석 및 구현

실제 구현은 팀의 책임입니다. 팀은 다음을 결정하기 위해 몇 가지 분석을 수행해야합니다.

• 새로운 기능을 구현하는 가장 쉬운 방법입니다.
• 기술 부채를 발생시키지 않으면 서 앞으로 진행하기에 가장 쉬운 다양한 구현 옵션은 무엇입니까?
• 개방형 및 YAGNI 원칙을 적용하여 과도하게 엔지니어링하지 않고도 새로운 기능을 강력하게 유지하는 방법

애자일 선언문 의 핵심 원칙 중 하나 는 고객 협업입니다. 기능 간자가 조직 팀이 예상됩니다. 사용자 스토리가 제공하는 가이드 라인 내에서 구현 세부 사항을 해결하기 위해 고객과의 공동 작업을 할 수 있도록.

사용자 스토리가 잘 작성되지 않았거나 팀에 민첩한 프레임 워크에서 요구하는 충분한 분석을 수행 할 기술이나 프로세스 성숙도가없는 경우에는 필요한 것보다 훨씬 어려울 것입니다. 적절한 수준의 세분성으로 좋은 사용자 스토리를 만드는 방법에 대한 주제에 대한 전체 책이 작성되었습니다. 불행히도은 총알은 없지만 민첩한 팀에게는 배울 수있는 기술입니다.

테스트 주도 및 행동 주도 설계

분석이 적절하고 구현이 제정신이며 지원 가능한지 확인하는 가장 좋은 방법은 TDD 및 BDD 사례를 사용하는 것입니다. 예를 들어, 위 이야기를 감안할 때 팀은 다음과 같은 아티팩트를 통해 계획된 구현을 캡처해야합니다.

• 테스트 가능한 시나리오가있는 오이 기능.

  이는 승인 테스트 개발을 주도하고 응용 프로그램 동작에 대한 사용자의 기대치 를 문서화하는 데 가장 유용합니다 . 예를 들어, 사용자 스토리에는 사용자가 Discover 카드로 체크 아웃하는 방법과 프로세스가 사용자에게 어떻게 보이는지 설명하는 하나 이상의 관련 Cucumber 기능이 있어야합니다.

• 새로운 코드 기능 의 동작 (내부 구현 세부 정보가 아님) 을 검증하는 RSpec 테스트 .

  응용 프로그램 내에서 기능의 의도 된 동작을 문서화하고 유효성을 검사하는 데 가장 유용합니다. 예를 들어, 사용자 스토리는 발견 카드를 사용하여 애플리케이션이 지불 게이트웨이를 통해 판매를 승인하는 데 필요한 모든 카드 특정 동작을 호출하는지 확인하는 단위 및 통합 테스트 작성을 주도합니다.

특정 도구는 중요하지 않습니다. Cucumber 또는 RSpec이 마음에 들지 않으면 팀에 가장 적합한 도구 또는 방법을 사용하십시오. 그러나 요점은 구현 세부 사항이 사용자 스토리를 기반으로 하지만 이에 의해 규정되지 않는다는 것 입니다. 대신 구현 (또는 원하는 경우 사양)은 협업 방식으로 기능을 개발하는 동안 해결해야 할 세부 사항입니다.

여기에 좋은 답변이 많이 있습니다. 바라건대 다른 값으로 가치를 더할 수 있기를 바랍니다 ...

팀이 끊어 버릴 수있는 하나는 민첩하지 않은 방법론에서 마이그레이션하는 것입니다.

그것은 일반적으로 어떤 형식의 폭포수 방법론이며 실제로는 일반적으로 코드 줄을 작성하기 전에 모든 기술 요구 사항을 문서화하려고합니다.

그러나 그것이 항상 효과가있는 것은 아닙니다. 종종 작동하지 않습니다. 이유? 요구 사항이 현실과 거의 일치하지 않기 때문입니다. 모든것은 변한다. 따라서 민첩한쪽으로 이동합니다.

애자일을 통해 사용자 스토리는 사용자가 관심을 갖는 모든 것입니다. 그들은 점 B로 폼 점 A를 얻으려면 어떻게 구현의 관점에서 거기에 도착하는 것은 당신의 손에 있습니다. 누군가가 기술 요구 사항을 알려줄 때까지 기다리는 것은 실제로 민첩하지 않습니다. 궁금한 점이 있으면 물어보십시오. 문서, 문서가 필요하지만 고객이 이러한 모든 결정을 내리기를 원하지 않는 경우. 의견이있을 수도 있지만 애자일 환경에서는 이러한 의견이 (구루가 제안한대로) 대화에서 논의해야합니다.

이것이 팀에게는 부담이라고 생각할 수도 있지만, 사치를 고려하십시오. 귀하의 팀은 이제 솔루션에 대해 많은 의견을 가지고 있으며 이는 폭포 모델의 경우는 아닙니다.