답변:
솔직히 말해서 민첩한 개발에 2 년 가까이 투자 한 후에도 "사용자 사례"는 "기능적 요구 사항"이라는 멋진 용어라고 생각합니다.
피상적 인 수준에서는 다릅니다 . 예를 들어 항상 특정 형태 ( "X, Y는 Z를 원합니다 ..." )를 취하지 만, 이해 관계자와 이론적 근거를 식별하는 핵심 요소도 고유하게 내재되어 있습니다. 서면 기능 요구 사항. 나쁜 요구 사항을 작성하는 것만 큼 나쁜 사용자 스토리를 작성하는 것만 큼 쉽습니다 ( "[회사 이름], [모호한 기능]을 원합니다. '고객에게 더 많이 판매하십시오'] " ).
내 경험상 사용자가 거의 포착 하지 못하는 것은 성능 및 보안과 같은 비 기능적 요구 사항입니다. 이러한 종류의 요구 사항은 제대로 작성하기가 매우 어렵고 사용자 스토리의 형식은 특정 사용자의 요구를 충족시키기보다는 일반적인 제품 품질과 위험을 완화 (그러나 제거하지는 않음)에 관한 것이기 때문에 단순히 캡처하기에 좋지 않습니다. 필요한 것.
따라서 저는 사용자 사례를 특정 공식을 사용하여 요구 사항 의 하위 집합 으로 생각 하며 용어를 거의 상호 교환 적으로 사용합니다.
사용자 요구 사항이 요구 사항을 능가하는 주요 이점 중 하나는 "요구 사항"이라는 단어 가 종종 원하는 곳에 기능이 필요 하다는 것을 나타냅니다 . 이론적으로 사용자 스토리는 모든 릴리스에 대해 우선 순위를 매기고 슬롯에 넣을 수 있지만 요구 사항은 모든 릴리스 의 전제 조건 인 것으로 보입니다 .
물론, 위에서 언급 한 차이가 중요하기 위해서는 고객 및 / 또는 고위 경영진이이를 수용해야합니다. 30 개의 사용자 스토리가 모두 동시에 완료되어야하는 "프로젝트"로 그룹화되어 있다면 아무 소용이 없습니다. 이 경우에는 실제로 필요하기 때문에 "요구 사항"이라고도합니다.
Ron Jeffries는 카드에 중점을 둔 사용자 설명 ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) 에 대해 오래 전에 글을 썼습니다. 대화가 끝난 후 실행 가능한 스토리가 확인되었습니다.
본질적으로 대화하기 전에 사용자 스토리는 계획된 범위입니다. 대화가 끝나면 이야기가 완료되었음을 확인할 수있는 방법이 있어야합니다. 따라서이 타임 라인에서 스토리를 볼 때 시간에 따라 스토리는 범위 또는 자세한 요구 사항에 대한 광범위한 아이디어 일 수 있습니다.
요즘 "사용자 이야기"의 의미는 Jeffries 3C의 "카드"부분으로 좁혀진 것 같습니다. 이 경우 사용자 스토리는 요구 사항이 아니라 요구 사항에 대한 대화를 약속합니다.
C2 Wiki ( http://xp.c2.com/UserStory.html ) 에서 사용자 스토리에 대한 수많은 지식을 얻을 수 있습니다.
사용자 스토리와 요구 사항은 매우 다릅니다.
요구 사항은 응용 프로그램의 디자인이 미리 수행되고 개발이 해당 디자인의 구현임을 전제로합니다. 따라서 요구 사항 은 기능을 구현하는 방법 에 중점을 둡니다 .
요구 사항의 예 :
사용자 스토리는 무엇 을 달성 해야하는지 에 초점을 맞추고 제품 설계는 마지막 순간에 수행되며 제품 담당자와 개발자 간의 공동 작업이라고 주장합니다. 세부 사항은 기회를 기반으로 구현 중에 결정됩니다.
이야기의 예 :
보시다시피, 제공된 세부 사항의 양에는 분명히 차이가 있지만 이야기에서만 사용할 수있는 많은 정보, 즉 우리 가이 기능으로 달성하려고 하는 목적 이 있습니다.
목적이 상대적으로 중요하지 않은 것으로 보이지만 민첩한 개발에서는 잘못된 가정입니다. 일반적으로 목적을 아는 것이 중요하다는 두 가지 경우가 있습니다. 기회 비용을 줄이고 민첩성을 가능하게합니다.
요구 사항에 숨겨진 가정이있는 경우 달성하기가 매우 어려울 수 있습니다. 예를 들면 다음과 같습니다. 사용 가능한 메일 서버가 있습니까? 그렇지 않은 경우 요구 사항을 개발하는 데 시간이 훨씬 오래 걸릴 수 있습니다. 다른 경우에는 설계로 인해 동일한 목표를 달성하는 간단한 방법을 놓칠 수 있습니다.
반대로 사용자 스토리는 지원 부서에 문의하는 사용자에 관한 것입니다. 메일을 발송할 수 없거나 너무 비싸다면 다른 해결책을 찾아 낼 수 있습니다. 예를 들어, 데이터베이스에 쓰거나 Google 문서를 통해 양식을 사용하거나 양식 대신 이메일 주소를 입력하십시오. 요구 사항으로는 쉽게 수행 할 수 없지만 스토리와 제품 담당자가 쉽게 수행 할 수 있습니다.
이러한 이유로 요구 사항이있는 경우 일반적으로 이러한 숨겨진 가정을 미리 생각하고 장애가 없는지 확인합니다. 따라서이 경우 미리 예약 된 다른 요구 사항이있을 수 있으므로 메일 서버가 있어야합니다.
인 이야기와 요구 사항 사이의 또 다른 큰 차이점이 리드 우리를 계층 구조 . 위에서 예시 한 바와 같이, 요구 사항은 그 자체의 특성상 의존성이 충족되도록 일부 자연 계층 구조로 정렬되어야합니다. 반면에 이야기는 목적에 중점을 두며 그러한 제약은 없습니다.
민첩하게 설계되었으므로 프로젝트 실행 중에 필요에 따라 스토리를 추가, 제거, 일정 변경 및 수정하는 것이 기본적으로 중요합니다. 일반적으로 요구 사항을 추가하거나 수정하거나 제거 할 수 있지만 모든 종속성으로 인해 요구 사항을 옮기는 것은 일반적으로 매우 고통스러운 일입니다. 단순히 자주 수행되지는 않습니다. 요구 사항을 다루는 경우 변화를 수용 할 수 있다는 의미에서 민첩한 구현에 어려움이 있거나 전혀 민첩하지 않을 수 있습니다.
나에게 사용자 스토리의 중요한 요소는 사용자가 시스템을 사용하는 이유와 방법을 캡처한다는 것입니다. 시스템이 필요한 기능을 제공하는 방식을 많이 지정하지 않기 때문에 특히 유용합니다. UI 및 사용성 테스트가 필요한 경우 사용자 스토리가 가장 중요한 문서 일 수 있습니다.
물론 셀레늄이 특정 노드가 HTML에 있는지 확인하거나 스크린 샷을 찍거나 특정 픽셀이 원하는 위치에 있는지 확인할 수 있습니다. 그러나 오해의 소지가있는 텍스트가 있거나 사용자가 시스템을 어떻게 사용해야하는지 명확하지 않거나 목표를 달성하는 방법을 이해하기 어려운 경우 갑자기 더 이상 완전한 시스템이 없습니다. 이제 시스템을 사용하려면 교육이 필요합니다. 사용자 시나리오에 대해 완성 된 시스템을 검토하는 것은 수동 테스트의 중요한 구성 요소입니다.
사용자 스토리 / 시나리오에는 캡처에 대한 많은 세부 설계 결정에 영향을 미치는 사고 방식이 있습니다. 개발자가 사용자와 직접 대화하거나 시스템을 사용하는 것을 관찰하지 않는 한 사용자 시나리오는 사용자 요구를 이해할 수있는 유일한 링크 일 수 있습니다.
마지막으로, 비즈니스 사람들은이를 달성하는 방법을 제안하지 않고도 필요한 것을 지정할 수 있습니다. 요구보다 솔루션을 설명하는 것이 훨씬 쉽고 사용자 시나리오는 특정 솔루션을 제안하지 않고 요구를 설명하기위한 프레임 워크를 제공합니다. 내가 들었던 가장 일반적인 비즈니스 요구 사항은 "실제로는 실제로는 필요하지 않은 Excel과 같지만 웹에 있기를 원합니다."입니다.
따라서 좋은 이야기에는 시스템 구현 방법에 대한 특정 세부 정보가 포함되어서는 안된다고 말하고 싶습니다. "한 달에 한 번 시스템 A는 시스템 B의 새 데이터로 업데이트해야합니다. 해당 데이터를 수정해야 할 수 있습니다. 클라이언트에 잘못된 데이터를 입력 한 기록이 있지만 몇 주 동안 문제를 실현하지 못했습니다." "시스템은 적어도 한 달에 한 번은 latin1 CSV 파일을 수락하고 열 3이 숫자가 아닌 경우 NumberFormatException을 발생시켜야합니다." 차이점이 보입니까? 시나리오는 특정 솔루션이 아니라 필요를 설명합니다. 그런 다음 테스트에서 시나리오로 돌아가 솔루션이 필요에 맞는지 확인하십시오. 요구 사항은 일부 요구 사항을 일부 솔루션과 혼합하거나 솔루션에 전적으로 집중할 수도 있습니다.
Google 검색 중이 문제에 걸려서 내 의견을 던질 것이라고 생각했습니다.
요구 사항과 사용자 스토리 사이에는 실제로 차이가 없습니다. 둘 다 사용자 관점에서 원하는 결과 또는 목표를 나타냅니다.
유일한 차이점은 비즈니스 분석가가이 목표 또는 결과를 포착하는 방식입니다. 이 경우 그것은 표현에있다.
예:
팀장으로서, 저의 팀 중 어느 팀이 모기지 사건을 다루고 있는지보고 그들의 성과를 모니터 할 수 있기를 원합니다.
이 솔루션은 모기지 사건에 대해 작업하는 팀원을 표시해야합니다.
위의 두 가지 모두 같은 방식으로 해석 될 수 있지만 두 가지 모두 모호합니다. 여기서 중요한 점은 스타일의 차이입니다. 우리가 주로 보는 문제는 요구 세계에서 기능 설계 세계로 이동하기 전에 솔루션을 정의하는 데 얼마나 먼가입니다. 비즈니스 분석가가 "기본 응용 프로그램 메뉴에 이름으로 로그인 한 사용자를 나열"하거나 너무 많은 정보를 표시 하는가? 우리가 이해 관계자들과 대화를 나눌 때 우리 모두가 해결책을 알고 그것이 어떻게 보일지, 가능한 코드 언어와 전개 방법을 해석 할 수있을 때, " 솔루션이 아닌 목표를 정의 해 봅시다. " 이것이 내가 혼란을 느끼는 곳입니다.
요구 사항은 종종 솔루션에 대해 원하는 결과 만 알지 못한다고 가정합니다. 예, 이것이 모든 솔루션을 불가피하게 만들지 만 개발주기에서 실제로 우리에게 도움이됩니까? 무언가를 정확하게 정의 할 수 있다면 왜 그렇게하지 않습니까?
사용자 스토리와 요구 사항의 차이점에 대해 걱정하지 않아도됩니다. 궁극적으로 솔루션을 개발하기 위해 충분한 정보를 정의하려고합니다. 너무 높은 수준의 사용자 스토리는 단순히 취소되고 더 작은 사용자 스토리로 분류되도록 요청됩니다. "시스템은"스타일과 동일합니다. 세부 사항이 충분하지 않으면 요구 사항이 너무 모호한 것으로 간주 될 수 있습니다.
결국 개발자와 이해 당사자가보고 싶어하는 일과 함께 진행하십시오.
고전 교과서에서도 단어 요구 사항의 의미에 대해 많은 불일치가 있다고 생각합니다. 사용자 사례에도 동일한 불일치가 적용됩니다. 여러 조직과 교과서에서 이러한 용어를 다르게 취급합니다. 예를 들어 Roger Pressman의 고전적인 소프트웨어 엔지니어링 교과서에서 요구 사항에 대해 말하는 방식은 Dean Leffingwell의 Agile Software Requirements 책과는 상당히 다릅니다. 나는 둘 다 존중하고 둘 다 유효 할 수 있습니다.
요구 사항은 상상력에 거의 남지 않고 특별한 특이성을 갖는 코딩 대상이 될 수 있습니다. 반면에 요구 사항은 비즈니스 문제점을 지정하고 솔루션을 지정하지 않아야한다고 주장 할 수 있습니다. 나는 그것이 더 뉘앙스가 있다고 생각하며 대답은 각 회사와 산업에 고유 한 스펙트럼에 있습니다 (모든 소프트웨어 개발이 IT에서 발생하는 것은 아닙니다).
요구 사항 추출 은 분석으로 이어지고, 디자인으로 이어지며, 요구 사항을 구체화 하는 아키텍처로 이어집니다. 하거나 사양화하여 코딩 할 수있는 무언가로 이어지는 . 나는 이것이 민첩하게 사라진다고 생각하지 않습니다. 이런 일이 발생하는시기는 변하기 때문에 가장 중요한 차이점입니다. 폭포수 모델에서는 추출과 정교화가 일찍 발생합니다. 린 (lean)과 스크럼 (scrum)에서는 스프린트에서 구현에 가까워 질수록 정교함과 정교함이 다양한 단계에서 발생합니다. 새로운 디자인 작업과 마찬가지로.
우리 조직에서는 Leffingwell의 Epics, 기능 및 스토리 모델을 요구 사항이 아니라 작업 분류 및 우선 순위 지정으로 기울이고 있습니다. 요구 사항은 다릅니다. 규제 기관에 대한 요구 사항이 있기 때문에 요구 사항은 별도로 관리됩니다. 그러나 일부 팀은 프로그램 증분 및 스프린트 계획 중에 사용자 스토리 내에서 요구 사항을 확실히 개발하고 있습니다.
기능 요구 사항은 일반적으로 소프트웨어가 작동하는지 여부를 정확하게 알 수있는 공식 사양입니다. 사용자 스토리는 일반적으로 사용자 스토리의 필요성을 설명하는 훨씬 비공식적 인 방법입니다. 소프트웨어가 "유효한지"또는 "유효하지 않은지"확인하기 위해 엄격한 사양을 지정하지 않습니다. 당신은 그것의 일부를 테스트 할 수 있지만, 사용자 스토리 (실제로 올바르게 수행하는 경우)의 실제 완성은 사용자가 "그래, 내 문제를 해결한다!"라고 말할 때입니다. 민첩한 선언문을 기억하십시오.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Mike Cohn은 자신의 저서 인 "User Story Applied"에서 일부 내용은 사용자 사례에 매핑되지 않으므로 그저 사용할 필요는 없다고 구체적으로 말합니다.
우리 팀에서는 다음을 사용합니다.
기능적 요구 사항으로 인해 오이 테스트를 통과하고 모든 서면 단어를 구현하더라도 구현 한 기능으로 사용자의 요구를 해결할 수는 없습니다. 이야기는 토론이며 비공식적입니다. 요점은 구현 담당자가 문제가 무엇인지 이해하는 것입니다. 계약 도구가 아닙니다. "스크럼 하지만 ... "을하고 당신의 이야기가 단순히 소프트웨어의 요구 사항을 작성하는 재미있는 방법이라면, 그렇습니다 . 차이 는 없습니다 .
요점은 사용자 이야기가 아니라 요점은 수행하려는 작업에 접근하는 방식에서 패러다임의 큰 변화입니다. 계약을 체결하지 않고 일부 사용자가 문제를 해결하도록 돕고 있습니다. 사용자 스토리가 실제 사용자 와의 토론 도구로 표시 되지 않으면 사용자 스토리를 사용하지 않고 펑키 한 요구 사항 구문을 사용하는 것 입니다.
나머지는 제 의견입니다. 사용자 이야기는 결코 일방적으로 성공할 수 없습니다. 고객과 함께 일해야합니다. 워터 스크럼 폴은 이상한 요구 사항이지만 요구 사항은 아닙니다. 당신이 반복하고 사용자 스토리를 사용하지 않는 특정 요구 사항에 고정 입찰 계약을하는 경우가 없다 어떤 점 . 자동화 된 장치 / 기능 테스트, 코드 검토, 지속적인 통합, 리팩토링 등의 민첩한 툴킷의 나머지 부분을 사용하십시오. 소프트웨어가 지속적으로 작동하고 즉시 통지 할 수 있는지 확인하십시오. 고객에게 가능한 한 많은 피드백을 제공 할 수 있도록 완성되지 않은 형태로 제공하십시오. 만약 당신이 내 친구라면 "User story"와 "Scrum"을하지 않더라도 소위 "Agile"상점보다 더 민첩했을 것입니다.
나는 모든 사람들이 과거 경험에 따라 다르게 모든 것을 구현하고 레이블을 붙일 것이라고 믿고, 그 회사에서 어떤 언어를 사용하든 그 일을 끝내는 것은 가치가 없다고 생각합니다.
그러나 IMO, 사용자 스토리는 Agile의 "건물에있는 고객 또는 고객이 즉시 이용 가능"접근 방식을 따르며, 세부 사항은 고객의 머리에 있고 쉽게 이용할 수 있으므로 문서가 필요하지 않은 공식 SRS 필요하지 않습니다. 이제 "사용자 스토리"의 "작업"은 개발자가 소화 가능한 사용자 스토리를 구축하는 방법입니다.
사용자 스토리의 예는 다음과 같습니다.
관리자로 그리드에 나열된 고객 데이터를보고 싶습니다
"작업"은 다음과 같습니다.
표시 할 데이터를 나열하는 그리드 만들기
선택한 열을 정렬하는 그리드에서 정렬 사용
이제 각 작업은 각각의 스프린트로 추정되고 완료됩니다.
"고객"이 파악하기 어려운 "전통적인"관점에서, 우리는 계획 / 코딩을 시작하기 바로 전에 고객이 보유하고 있음을 확인할 수 있도록이를 기록해야합니다. 고객의 머리 속에 떠오른 아이디어가 될 것입니다.
이 경우 "기능 요구 사항"은 해당 SRS의 핵심 세부 사항이며 더 큰 아이디어의 일부입니다. 제 생각에 사용자 스토리는 공식적인 "요구 사항"의 일부로 볼 수 있으며 해당 사용자 스토리의 작업은 기능적 요구 사항 중 하나입니다.
예제 사용자 사례에서 공식 "요구 사항"은 플로우 차트가 포함 된 긴 문서이며 일반적으로 고객 중심의 "애자일"접근 방식과 달리 문서 중심적입니다.
차이점은 공식적인 "요구 사항"은 일부 목록이 필요함을 나타내는 앱의 관리 섹션과 역할 기반 보안 등을 나타내는 약 10 페이지 문서의 행을 따라가는 것입니다. 요구 사항은 "목록 그리드 정렬 가능", "사용자 정보가 그리드에 나열되어야 함"등입니다.
그리고 요즘에는 용어가 모두 섞여 섞여 있다고 믿습니다.