사용자 스토리 정의에서 '그래서'절의 목적은 무엇입니까?


10

사용자 스토리는 다음과 같은 문장으로 정의 할 수 있습니다.

As a <type of user> I want <some goal> so that <some reason>

'사용자 스토리 공식'을위한 Google과 첫 번째 링크는 모두이 공식을 제안합니다.

내 질문은, 절의 목적은 무엇 입니까? 관리자가 있습니까? 프로젝트 관리자와 이해 관계자가 아이템의 우선 순위를 더 잘 이해할 수 있도록 있습니까? 왜 거기에 있습니까?

참고 : as a <type of user> I want <some goal>수식으로 작업했으며 잘 작동합니다. 더 간단한이 형식을 구현하여 작업에 아무런 문제도 발견하지 못했습니다.


6
SE 사용자로서 나는 유니콘을 원합니다.
Piskvor 건물 왼쪽

답변:


19

이 기능의 존재 이유는 사용자 / 고객이 확실한 유형의 비즈니스 이점을 제공하도록하여 불필요한 작업을 피하는 것입니다.

누군가가 자신이 멋지게 들렸다 고 생각하거나 다른 소프트웨어가 가지고 있다고 생각해서 그 기능이 추가되는 것을 들어 본 적이 없습니다. 종종 유해하지는 않지만 적어도 불필요합니다.

그러나 이러한 기능을 제안하는 사람들은 일반적으로 설득력있는 비즈니스 이유를 제공하는 데 어려움이 있기 때문에 이러한 기능을 쉽게 발견 할 수 있습니다.

Popping The Why Stack 이라는 기술이 있는데 , "그렇게"부분을 취하여 "Why?"라고 묻고 그 대답을 취한 다음 "Why?" 다시, 재귀 적으로. "그것은 우리에게 돈을 절약 할 수 있기 때문에" "왜"의, 당신은 바람직 정확하게의 정확한 설명과 함께 (중 "그것은 우리에게 돈을 벌 것이기 때문에"에 도착하지 않았거나 3 ~ 5 후 (하자 말), 경우 어떻게 그 이 기능은 구현할 가치가 없습니다.

어떤 사람들은 이것이 스토리 템플릿에서 실제로 가장 먼저 생각하기에 이것이 중요하다고 생각합니다 .

하기 위해 [...]

[...]로

나는 [...]

일부 Thoughtworks 사람들의 대화에 대한 좋은 예가 있습니다. 고객 중 한 명이 매우 독창적 인 형식으로 인쇄 된 보고서를 원했습니다. 컨설턴트가 "Why"를 물었을 때, 그들은 다시 입력하기가 더 쉽다고 말했습니다. 따라서 보고서 형식화 기능을 구현하는 대신 네트워크를 통해 보고서를 전송했습니다. 은 "그래서"절없이, 그들은 것입니다 여전히 다른 부서에 걸쳐 메일 링 다시 그들를 입력 한 부서에서 theose 용지를 인쇄 할 수.


위에서 설명한 것을 Five Whys ( en.wikipedia.org/wiki/5_Whys ) 라고하며 요구 사항 엔지니어링에서 품질 관리, 프로세스 개선에 이르기까지 (소프트웨어) 엔지니어링 분야에서 일반적으로 유용합니다. 개발하기에 좋은 기술 일 것입니다.
토마스 오웬스

ThoughtWorks 이야기를 좋아하십시오. "So that"은 스토리를 뒷받침하는 컨텍스트를 제공하고 개발자가 더 나은 솔루션을 제공하도록 돕는 데 매우 유용합니다. 분석가 / 고객은 종종 솔루션에서 너무 빨리 좁혀집니다. 개발자에게 컨텍스트를 제공하면 분석가가 고려하지 않았거나 가능하지 않은 기술 솔루션을 생각하고 설계 할 수 있습니다.
Mathias

7

"그래서"는 목표의 이유를 제공합니다.

예를 들어, 지난 달의 판매량을 표시하는 것이 목표 일 수 있습니다. 그것으로 작업 할 수는 있지만 더 깊은 요구 사항을 얻을 수 있도록 표시하려는 이유 를 알아야하는 한 가지 이유가 있습니다 . 판매량 또는 잠재 고객과 어떤 관계가 있습니까? 이 정보를 알면 응용 프로그램에 대한 통찰력을 높이고 고객이 원하는 것을 수행 할 수있는 사용자 인터페이스를 설계 할 가능성이 높아집니다.

이유의 또 다른 용도는 이야기의 우선 순위를 정하는 것입니다. 두 가지 이야기가있는 경우 :

지난 달의 판매량을 표시하고 싶습니다.
잠재 고객 목록을 표시하고 싶습니다.

그러나 오직 하나만 할 수있는 자원이 있습니다. 이유가 없다면 당신은 단지 추측하고 올바른 시간에 맞지 않을 수도 있습니다. 고객이 먼저해야 할 일을 말해야하기 때문에 이것이 중요하지 않지만 때로는 그렇지 않습니다.


이야기의 우선 순위를 정하는 것이 아니라 더 깊은 요구 사항이라고 생각합니다. 고객이 스토리를 우선시해야합니다. 그러나 "so that"을 사용하면 사용자에게 가치를 부여하는 추가 요구 사항 (기능, 비 기능 및 품질 속성)을 도출 할 수 있습니다. 부가가치 극대화의 개념은 많은 민첩한 방법의 강점 중 하나라고 생각합니다.
토마스 오웬스

@ 토마스-좋은 지적. 나는 그 이유를 바꿀 것입니다-우선 순위가 있다고 생각하지만 중요하지는 않습니다.
ChrisF

1

언급 된 내용 외에도 요구 사항에 대한 이유를 제공하면 요구 사항의 유효성을 판단 할 수 있습니다. 사용자가 잘못된 이유로 사물을 원할 수 있습니다. "그래서"그렇게하면 이유가 명확 해 지므로 분석가는 요청이이 방법으로 가장 잘 만족되는지 확인할 수 있습니다.

예:

AI는 모든 회사 직원 목록에서 직원을 선택할 수 있기를 원합니다.

BI는 5 년 전 회사를 떠난 직원을 삭제할 수 있도록 모든 회사 직원 목록에서 직원을 선택할 수 있기를 원합니다.

(B)는 중간 규모 조직에서도 의미가 없지만 사용자 요구 사항을 확인하고 고객이 요구 사항을 충족시킬 수있는 다른 방법을 제안 할 수 있습니다.


+1-문제의 근원에 도달하는 데 도움이됩니다. 그렇지 않으면 잠재적 인 해결책이 주어집니다.
JeffO
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.