스토리별로 요구 사항 사양을 작성하는 것이 좋습니다?

현재 프로젝트에서 민첩한 방법을 사용하고 있으며 다음과 같은 많은 이야기가 있습니다.

• 조수로서 고객이 요청할 때 돈을 벌 수 있도록 환불을하고 싶습니다.

• 고객은 상품을받을 수 있도록 구매 비용을 지불하고 싶습니다.

우리가 지금까지 한 방법은 모든 스프린트에서 가장 중요한 이야기를 골라 여러 공식 요구 사항 사양으로 구체화하는 것입니다 (우리는 같은 사양에서 비슷한 이야기를 그룹화합니다). 스토리에 따라 화면의 단추이거나 전체 워크 플로 일 수 있습니다.

문제는 이야기가 너무 많기 때문에 이야기와 관련된 시스템의 어느 부분에 대해서도 명확하지 않다는 것입니다.

개발자 당시에는 작동하며 모든 스프린트는 개발자가 수행해야 할 작업과 변경 사항을 간략하게 설명합니다. 그러나이 스토리 목록을 유지하고 테스트를 위해 화면에서 하나의 기능이 여러 위치에 문서화되어있을 수 있기 때문에 실제로 버그를 추적하고 일반적으로 사양을 유지하기 시작합니다. 이야기로 나습니다.

스토리를 기반으로 스펙을 작성하는 것이 좋은 생각입니까? 이야기를 잘못 작성 했습니까?

이것은 논쟁의 여지가 있지만 여기에 있습니다!

우리는 과거의 보스 중 한 명이 AGILE을 해보자고 제안한 실시간 시스템에서 작업했습니다! 실제로 경영진을이기는 것은 쉬웠습니다. 그러나 말보다 쉬웠다.

이야기의 개념은 좋지만 매우 선행 적이라는 것은 매우 모호합니다. 실제로 이야기는 무엇입니까? 실제 문제는 스토리를 사용하는 것 alone(그리고 유스 케이스도 마찬가지입니다)에는 다음과 같은 몇 가지 문제가 있다는 것입니다.

1. 심한 반복을 여러 번하지 않는 한 , 요구 사항이 문맥을 벗어나지 않아야합니다. 주어진 요구 사항과 연관된 가정, 배경 지식 및 기타 요구 사항이 있습니다. 상황과 특정 순서에 따라서 만 의미가 있습니다. 가장 중요한 것을 먼저 구현하는 것은 사업 적으로 이해가되지만 적어도 제출할 때는 처음부터 완벽하게 참조하십시오. 요구 단어 자체는 복잡하며 실제로 사용 사례 / 스토리로 제한되지 않습니다. 실제로 이야기는 실행 가능하지만 성능, 충족해야 할 제약 조건, 비즈니스 규칙 등과 같이 실행 불가능한 요구 사항이 있습니다.

2. 요구 사항은 크기와 양을 정할 수있는 방식으로 적절 해야합니다. 정확히 1 이야기는 무엇입니까?

   • 하나의 자세한 시나리오입니까? (예 : ATM이 거래를 거부했을 때의 한 가지 이야기)
   • 사용자가 수행하는 일련의 작업입니까? (예 : 출금에 관한 전체 기사)
   • 아니면 사용자 인터페이스에서 하나의 화면입니까? (예 : 철회 화면 전체 기사).
   • 스토리를 통해 매우 선명한 비즈니스 규칙을 실제로 수량화하는 방법은 무엇입니까? 솔직히, 그것은 위의 어느 것도 될 수 있습니다. 요점은 당신이 얼마나 제한적이고 세밀한가는 개인 스타일입니다. 작동하면 괜찮습니다.

3. 도메인 지식 은 정말 필수입니다! Glass, Steel 및 Wood의 다양한 속성 을 알고 있는 건축가의 간단한 예입니다. 이 지식은 건물 당 요구 사항 문서의 일부가 아닙니다! 같은 방법으로 뱅킹 소프트웨어를 작성하는 경우 뱅킹에 대한 개념이 많이 있습니다. 로, 그 진술 요구 사항 자체가 비 다루기 쉬운 당신을 말하지 않기 때문에 만드는 소프트웨어가 무엇을해야하는지 에 반대 하는 방법을 세계 작품 . 이야기에 그러한 영역의 복잡성이 포함되어 있습니까? 아니면 이것을 배제합니까?

4. 세계 모델링은 전제 조건이 아닙니다.
   세계가 어떻게 작동하는지 이해하는 데 중점을 둔 모델링에 관한 많은 문헌이 배경 지식입니다. 모델링은 요구 사항이 명확한 의미를 얻는 확고한 토대를 형성합니다. 그러나 그러한 것은 선행되어야합니다. 불행히도, 민첩한 관행의 대부분은 더 빠르고 더 적은 배송을 위해 초기 모델링의 가치를 거부합니다. 그러나 나는 여전히 규모가 커야 할 때 주요 쇼 스토퍼라고 생각합니다. 모델링이 관련이 없기 때문에 많은 프로젝트가 성공하지 못합니다. 그러나 노련한 엔지니어는이를 이해하고 많은 명시 적 지침이 필요하지 않습니다.

그래서 당신의 질문에 와서 :

스토리를 기반으로 스펙을 작성하는 것이 좋은 생각입니까? 이야기를 잘못 작성 했습니까?

사용자 스토리는 고객이 제공 한 명백한 평결로 가치가 있다고 생각합니다. 그러나 그들이 체계적으로 구성되어 있지 않고 상세하지 않거나 모호한 경우 문제가 있습니다. 광범위한 이해 (도메인 지식) 및 범위 (총 사양)를 축적 할 수있는 더 큰 구조가없는 한. 이러한 시스템에서 더 큰 세그먼트 또는 요소에 대한 사용자 스토리.

추신 : 나는 유스 케이스 (타원형 다이어그램에 묘사되어 있음)에 대해 적절한 견해와 적절한 세분성을 두지 않으면 좋은 일을하지 않는다는 정확한 의견을 가지고 있습니다. (나는 그들을 쓸모없는 사건 이라고 부른다 ). 내가 사용 사례 작성이 진정으로 확장 가능하고 의미있게 찾을 수있는 유일한 신뢰할 수있는 소스는 쓰기 효과적인 사용 사례 로 콕번

> Writing specs by stories? a good idea?

이야기의 상호 의존성과 우선 순위를 관리 할 수 ​​있다면 그렇습니다 .

다음은 많은 사용자 스토리 를 주문하고 관리하는 데 도움이되는 스토리 맵 에 대한 기사 입니다.

이 답변을 쓰는 ​​시점에서 나는 그것이 테스트가 아니라 문서에 관한 것임을 깨달았습니다. 먼저 애자일 선언문을 읽어야합니다 .

[우리는] 종합 문서보다 작동 소프트웨어 를 소중하게 생각 합니다

따라서 사양을 실행 가능하게 만들어야합니다 (예 : 완전 자동화 된 테스트 세트로 작성).

스토리를 기반으로 스펙을 작성하는 것이 좋은 생각입니까?

네, 임호입니다. 이를 "행동 주도 개발"또는 "예제 별 사양"이라고합니다. 루비에는 큰 도움이되는 도구 오이 가 있습니다.

문제는 이야기가 너무 많기 때문에 이야기와 관련된 시스템의 어느 부분에 대해서도 명확하지 않다는 것입니다.

왜 명확하게하고 싶습니까? 정말로 "테스트 / 코드"추적 매트릭스가 필요합니까? 테스트를 스펙으로 작성하면 테스트가 요구 사항이되기 때문에 별도의 "요구 사항 / 테스트"추적 성이 필요하지 않다는 장점이 있습니다. 통합 테스트를 위해 소프트웨어를 별도의 부분이 아닌 전체로 취급해야합니다.

사양 테스트에 포함되지 않은 시스템의 일부인 "데드 (dead)"모듈이 있는지 확인하려면 적용 범위 도구가 필요할 수 있습니다. 그러나이 특정 코드가 어떤 사양에 해당하는지는 신경 쓰지 않아야합니다. 특정 사양에서 시스템의 어느 부분이 이에 해당하는지 알아야합니다. 사양의 중복에 대해 걱정하지 않아도됩니다. 그리고 코드에 DRY 원칙을 적용 하면 동일한 코드를 실행하는 수십 가지 사양이 있습니다.

개발자 당시에는 작동하며 모든 스프린트는 개발자가 수행해야 할 작업과 변경 사항을 간략하게 설명합니다. 그러나이 스토리 목록을 유지하고 테스트를 위해 화면에서 하나의 기능이 여러 위치에 문서화되어있을 수 있기 때문에 실제로 버그를 추적하고 일반적으로 사양을 유지하기 시작합니다. 이야기로 나습니다.

중요한 모듈을 한 번만 변경하면 수백 건의 통합 테스트가 중단되는 것은 드문 일이 아닙니다. 그것이 단위 테스트가 시작되는 곳입니다.

특정 테스트가 높은 수준의 요구 사항을 충족하는지 또는 미묘한 세부 사항을 다루는 지 알 수 있도록 테스트를 구성해야합니다. 후자의 경우이 테스트를 통합 테스트 스위트와 분리해야합니다. 단위 테스트의 목적은 버그를 지역화하는 것입니다. 따라서 버그를 도입하면 한 번의 테스트 실패 만 발생합니다.

이야기를 잘못 작성 했습니까?

"고객", "어시스턴트"또는 기능 / 화면 / 워크 플로 ( "구매", "환불") 등 사용자별로 스토리를 에픽으로 구성하면된다고 생각합니다.

또한 사양 테스트는 단위 테스트를 대체하지 않습니다. 더 읽어보기

문제점과 문제점 해결 방법을 언급했지만 스펙 및 그룹화의 예와 제품 개발 방식과의 관계를 언급하는 것을 잊었습니다.

스토리별로 스펙을 작성 하시겠습니까? 좋은 아이디어?

애자일은 그것을 금지하지 않습니다. 민첩하게 지속 가능한 속도로 최대 비즈니스 가치를 제공하는 데 필요한 모든 것을 할 수 있습니다. 따라서 사양을 작성하는 것이 더 많은 비즈니스 가치를 제공해야하는 경우에는 그렇게해도됩니다.

귀하의 예는 두 가지 사용자 스토리를 보여줍니다. 아마도 비즈니스 로직과 관련이있을 수 있지만 매우 일반적인 시나리오입니다.

사용자 스토리에 기능을 배킹해야하는 경우 문서, 일부 다이어그램 또는 "사양"을 포함하여 가장 적합한 것을 다시 사용할 수 있지만 이러한 아티팩트를 유지 관리하면 개발 된 애플리케이션의 복잡성이 증가함에 따라 비용이 더 많이 들도록 준비해야합니다. 따라서이 경우 대답해야 할 유일한 질문은 다음과 같습니다. 사양을 사용하지 않으면 더 많은 비용이 듭니까? 대답이 예이면 더 나은 옵션을 선택한 것입니다.

애자일은 소규모 팀이있는 중소 규모 프로젝트에 가장 효과적이며 전체 아키텍처가 팀에서 공유되는 암묵적 지식으로 유지되었습니다. 반복 계획 중에 선택한 스토리를 살펴보고 현재 구현에 미치는 영향에 대해 토론하고 스토리를 완료하는 데 필요한 몇 가지 작업을 작성합니다. 이 경우 실제 문서는 자동 승인 및 통합 / 단위 테스트를 보유한 테스트 스위트입니다. SW 또는 팀이 성장하면 암묵적 지식은 부분적으로 일부 문서로 이동해야합니다.

이제 추상화가 중요한 역할을합니다. 관련 관점과 관련된 이야기를 살펴 봐야합니다. 문장에서 명사 와 동사 를 모아서 확인하십시오. 개인적인 가정을 바탕으로 모델을 만들 수 없으며 세부 사항에도주의를 기울이십시오.

사용자 스토리를 기반으로 사양을 작성하는 것은 정확할 수 없습니다. 여분의 디테일을 파고 때로는 관련이없는 디테일을 무시해야합니다. 분석가의 확인에 따라 모델이 완전하고 정확할 때 사양을 작성해야합니다.