기획자가 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) : 어떠한 결과가 나타나야 한다.
화면 하나에서 위 3가지 조건에 맞춰 기능을 명세하면 그것이 바로 유저 스토리가 될 수 있다.
보통의 기능은
- 사용자 액션이 필요한 버튼에서 정의되거나
- 또는 페이지 로딩이나 조건에 따른 시스템에 의한 동작에서 정의될 수 있다.
이럴 땐 능동형과 수동형을 구분해서 작성을 하면 좋다고 생각한다.
- 사용자는 할 수 있다.
- 시스템은 되어야 한다.
유저 스토리는 시나리오만 작성되었다고 하여 완성된 것이 아니다.
실제 뒷면에 작성되어야 하는 TASK 가 중요하다.
필자는 TASK 를 두 가지로 분류한다. (론 제프리 3C)
- Conversation : 개발자가 작성하는 실제 개발 TASK (상황과 행위, 결과가 명시되어야 한다.)
- Confirmation : 품질담당자가 작성하는 유저 스토리를 만족하는 조건 (상황+행위에 대한 올바른 결과와 올바르지 않은 결과를 명시해야 한다.)
유저 스토리의 구성을 보면
- 사용자 요구사항 : 일반적인 상세 요구사항을 작성
- 시스템 요구사항 : 시스템 또는 관련된 문서들
- 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
론 제프리의 3C 에 대하여, 사용자 스토리에는 세 가지 중요한 측면이 있다. 바로 Card, Conversation and Confirmation 이다.
6987.tistory.com
댓글