[SW요구사항] 유저스토리 작성하기, Given When Then

기획자가 Agile 을 공부한다는 건 유저 스토리에 대한 접근이 아닐까라고 생각해본다.
도서를 보더라고 Agile 의 한 부분으로 유저 스토리만을 다룬 책들이 많이 있다.
프로젝트의 단추인 만큼 중요하지만 다루는 것은 그다지 쉽지 않은 부분이다.

사전 지식으로 Agile 에 대한 이해가 필요하다.

---

서론의 시작

대충... 빠르게 개발해서 고객에게 전달하는 개발 방식이다. 
그럼 어떻게 빠르게 개발을 할 수 있는가?

1. 개발할 내용을 작고 작은 조각으로 쪼갤 수 있어야 하고.
2. 작게 쪼갠 조각은 독립적으로 동작할 수 있어야 한다.

여기서 포인트!

- 두 개의 문장을 작성했을 뿐인데... 막연하다. 어떻게 작성하라고?? 
- 유저 스토리를 작성하는 방법들이 나온 이유일 것이다.
- As a, I want, So that 그리고 Given-When-Then
- 본론에서 필자 나름의 설명이 가미된다.

 

3. 쪼갠 조각은 명확하게 개발 항목(TASK)로 상세화 할 수 있어야 한다.
4. 상세화된 TASK는 검증 가능하도록 작성되어야 한다.

여기서 포인트!
- Agile 은 별도 테스터를 명시하지 않는다. 이유는 개발 항목을 명확하게 하여 오류를 줄이는 것이 기본이기 때문이다.
- 오류를 유발하고 코드에 자신이 없다면 Agile 프로세스 흉내내기도 힘들다.

 

5. 빌드/배포 자동화가 구축되어 있어야 한다.
6. 통합되어 배포된 산출물은 검증되어 고객에게 배포된다.

이렇게 빠른 주기로 개발을 할 수 있게되고.. 이를 위해 첫 단추인 유저 스토리가 중요하다.

 

---

본론은 진흙탕

 

유저스토리는 보편적으로 크기에 따라 명칭을 부여한다.

Theme > Epic > User story > Task

 

간단하게 짚어본 주관적 설명

- Theme (테마) : 맡은 서비스, 제품에서 큰 덩어리로 볼 수 있는 부분 (예> 초기 화면, 홈 화면 등등)
- Epic (에픽) : 테마를 구성하는 큰 기능의 단위 (예> 로그인 관련)
- User Story (유저 스토리) : 에픽을 상황이나 방법등 기준에 의한 사용자의 한 가지 액션 행위 (예> 구글 계정으로 로그인할 수 있다.)
- Task (태스크) : 유저 스토리를 구현하기 위한 상세한 개발 항목 (예> 구글 인증, 입력 필드 구성 등)

제목에서 언급한 Give-When-Then 은 유저 스토리를 작성하는 방법 중 1개이다.
필자가 작성한 Scrum 프로세스에서는 위 4개지 항목을 모두 다루고 있고 기준이나 설명은 개인적으로 작성되어 있으니 위키나 도서에서 이론과 개념을 배우는 것이 좋다고 생각한다.

유저 스토리는 카드 타입으로 구성된다고 배우게 된다.

앞면에는 유저 스토리를 As a, I want, So that
뒷면에는 Given-When-Then 으로 상세하게 작성하도록 한다.

 

아래 Katalon 사이트의 예제로 설명 (이미지 먼저 확인)
- 테스트 분야에서 사용된 예로... 유효한 스토리와 유효하지 않은 스토리를 구분하여 작성됨.
- As a, I want, So that, Given-When-Then 이 모두 포함됨.

Feature : 로그인 기능 
=> 에픽과는 개념이 다르지만 유저 스토리의 기능을 함축적으로 표현하여 여러 개를 묶을 수 있는 개념이다.

User Story : 사용자는 Cura 시스템에 로그인하여 약속을 잡을 수 있어야 한다.
=> 실제 사용자의 행위를 정의한 유저 스토리로 누가, 무엇을, 왜 하는가를 작성한다.
=> 여기서 As a, I want, So that 이 사용된다.

Given : Cura 시스템 홈페이지로 이동하여
=> 사전 상황을 명시한다.

When : 약속 버튼을 선택하고
=> 사용자 액션을 명시한다.

And : 이름과 비밀번호를 넣고

And : 로그인 버튼을 누르면
=> 추가적인 사용자 액션을 명시한다.
=> When 이나 Then 다음에 추가 액션을 명시할 수 있다.

Then : 로그인이 완료되어야 한다.
=> 사용자 액션에 대한 결과, 피드백을 명시한다.
=> 중요! Should 단어로 작성한다는 것!!

 

예> BDD 테스트 자동화에 적용된 내용 (출처 : docs.katalon.com/katalon-studio/docs/cucumber-features-file.html#add-feature-files)

 

필자는 "As a, I want, So that", "Given-When-Then" 을 좀 더 쉽게 표현하고 싶다.

• Screen (Given) : 어떠한 상황(화면), 조건에서
• Action (When) : 어떠한 행동을 하면
• Feedback (Then) : 어떠한 결과가 나타나야 한다.

다르게 보이지만 사실 의미가 같다. 따라서 이해하기 더 쉽다고 생각한... 이전 글에 언급된 내용 복기(요구사항 작성)

 

누구나 따라하기 쉬운 요구사항 작성 Tip, 템플릿

 

 

화면 하나에서 위 3가지 조건에 맞춰 기능을 명세하면 그것이 바로 유저 스토리가 될 수 있다.
보통의 기능은
 - 사용자 액션이 필요한 버튼에서 정의되거나
 - 또는 페이지 로딩이나 조건에 따른 시스템에 의한 동작에서 정의될 수 있다.

이럴 땐 능동형과 수동형을 구분해서 작성을 하면 좋다고 생각한다.
 - 사용자는 할 수 있다.
 - 시스템은 되어야 한다.

내가 본 일부 기획자들은 본인들이 창의적인 업무를 하고 있다는 착각에 빠져있고 실상 이쁜 화면 그리기에 빠져 있었다.

그래서 그들에게 맞게 설명을 위해 위와 같이 안내해주었다.

또한 유저 스토리라는 말 대신 요구사항 작성하는 것이라 알려주었다. 

 

"여러분은 화면설계서 작성 전 요구사항을 명확히 하는 작업을 하고 계십니다." 라고.

 

유저 스토리는 시나리오만 작성되었다고 하여 완성된 것이 아니다.
실제 뒷면에 작성되어야 하는 TASK 가 중요하다.

필자는 TASK 를 두 가지로 분류한다.
- Conversation : 개발자가 작성하는 실제 개발 TASK (상황과 행위, 결과가 명시되어야 한다.)
- Confirmation : 품질담당자가 작성하는 유저 스토리를 만족하는 조건 (상황+행위에 대한 올바른 결과와 올바르지 않은 결과를 명시해야 한다.)

 

유저 스토리의 구성 (2019)

유저 스토리의 구성을 보면

• 사용자 요구사항 : 일반적인 상세 요구사항을 작성
• 시스템 요구사항 : 시스템 또는 관련된 문서들
• Conversaton : UI 설계서를 보고 개발자가 정의하는 개발 태스크
• Confirmation : UI 설계서를 보고 품질 담당자가 작성하는 Valid 항목

그럼 위 유저 스토리 구성을 위해 베이스가 되는 화면설계서는 아래와 같다.
작성할 때부터 다음 프로세스까지 염두할 수 있어야 한다.

 

 

---

결론은 언제나

늘 그렇다.
이론은 이론이고 정석은 정석이다.
우리 조직과 나와 맞지 않다고 생각을 한다.

하지만 이론을 알고 정석을 이해해야지 목적에 어긋나지 않도록 사용할 수 있을 것이고 변질되지 않을 것이다.

빠른 개발 주기, 배포를 위해서는 명확하게 개발할 수 있는 작은 백로그가 필요하다. (Minimum Viable Product)
그것을 정제하는 것이 프로젝트 오너 또는 기획 담당자의 역할이 될 것이고.
서포트해서 개발이 원활하게 진행될 수 있도록 하는 것이 바로 팀이다.

나 하나 잘 나선 or 잘해서는... 안된다.

스크럼 마스터가 이를 얼마나 조화롭게 이끌어 낼 수 있는가에 따라 이상적인 Agile 의 첫 단추를 꿸 수 있을 것이다.

 

---

 

유저 스토리 카드 작성 예

1. 유저 스토리 (As a I want So that)

• 앞면 : As a OOO, I want OOO, So that OOOO
• 뒷면 : Given - When - Then

2. 유저 스토리 (feat, 욘나빠른 & Ron jeffries's Three Cs)

• 앞면 : Screen - Action - Feedback
• 뒷면 : Conversation, Confirmation

 

 

Ron Jeffries's Three Cs

좋은 유저스토리 작성 따라하기 INVEST