술(述)/풀이

사용자 스토리(User story)

쪼랩전사 2021. 11. 10. 19:01
728x90

유저 스토리나 사용자 이야기라고 안 부르고 보통 사용자 스토리라고 부른다. 왤까...

 

사용자 스토리는 사용자 스토리 맵, 스크럼 등 생각보다 많은 곳에서 사용된다. 그런데 참 많은 사람이 사용자 스토리를 잘 알지 못하는 것 같다.

 

이 포스팅에서는 사용자 스토리가 무엇인지, 어떻게 사용하는 것이 좋은지에 대한 내용을 서술하겠다.

사용자 스토리

사용자 스토리는 협업을 위한 수단이다. 사용자 스토리는 철저히 사용자 측면에서 작성되며, 사용자가 원하는 기능에 대한 간략한 설명이다.[각주:1]

사용자 스토리는 기능에 대한 설명일 뿐, 공식적으로 어떠한 형식을 쓰라는 것은 지정되어 있지 않다. 하지만 보통 아래와 같은 형식을 취한다.

As a [페르소나]
I want [목표]
so that [이유]

"[페로소나]로서, 나는 [이유]하기 위해 [목표]를 원한다." 정도로 해석하면 된다.

페르소나[각주:2]는 특정 사용자 혹은 사용자 집단을 의미한다. 보통 페르소나 용어 사전을 사용해 페르소나를 관리한다. 페르소나는 영희, 철수로 사용해도 되고 사이트 사용자처럼 어떤 집단을 사용해도 된다. 단, 페르소나 이름이 불분명한 경우에는 페르소나 사전에 페르소나의 목적을 명확히 기재해야 한다.

 

사용자 스토리의 예시는 다음과 같다.

As a site member,
I want to describe myself on my own page
so that others can learn about me.

"사이트 이용자"로서, 나를 "알리기" 위해 "나의 페이지에 나에 대한 것을 기술"하고 싶다. 정도로 해석된다.

이처럼 사용자 스토리는 사용자 측면에서 작성된다.

 

종종[각주:3] 끔찍한 사용자 스토리가 있는데 이는 다음과 같다.

As a user,
I want to store data in mysql
so that data persistence.

"사용자"로서, "데이터 영속성"을 위해 "mysql에 데이터를 저장"하고 싶다.

만약 이거와 비슷하거나, 같다면 사용자 스토리 사용을 멈춰라. 시간 낭비일 뿐이다.

사용자 스토리에는 개발자를 위한 기술적인 용어가 들어가선 안 된다. 또한, 사용자가 어떤 사용자인지 페르소나가 명확하지 않아도 사용자 스토리의 의미가 퇴색된다.

좋은 사용자 스토리의 6가지 특징

다시 말하지만, 사용자 스토리는 협업을 위한 수단일 뿐이다. 어떻게 작성하건 공식적인 규칙이 회사든 본인에게든 정해져 있기만 하면 된다.

여기서 설명하는 좋은 사용자 스토리는 일반적으로 좋다고 알려진 특징일 뿐이다.

그 특징은 INVEST[각주:4]라고 하며, 아래와 같다.

  • Independent(독립적): 독립적으로 동작할 수 있어야 한다.
  • Negotiable(협상): 사용자 스토리는 추가/제거될 수 있다.
  • Valuable(가치): 사용자에게 가치 없는 사용자 스토리는 구현할 필요가 없다.
  • Estimatable(측정): 추정이 가능하도록 사용자 스토리는 상세화/세분화되어야 한다.
  • Small(작음): 스프린트[각주:5] 기간 내에 완료할 수 있어야 한다.
  • Testable(테스트): 테스트를 통해 완료할 수 있어야 한다. 즉, 완료의 기준이 있어야 한다.

마치며...

사용자 스토리는 사용자와 협업을 원활하게 할 수 있다. 하지만, 사용자 스토리의 잘못된 사용은 프로젝트를 늪에 빠지게 할 뿐 아니라, 사용자 스토리가 나쁘다는 잘못된 인식을 심어준다. 만약, 사용자 스토리가 협업을 방해하는 존재가 된다면 과감히 버리고 다른 방법을 사용하길 바란다. 다시 말하지만, 사용자 스토리는 협업의 수단일 뿐이다.


  1. 사용자가 불명확하거나, 혼자만 사용하는 프로그램을 개인적으로 만드는 거라면, 사용자 스토리는 의미가 없다. [본문으로]
  2. 어원: 고대 그리스 가면극에서 배우들이 사용한 가면 [본문으로]
  3. 정말 종종이다. 사용자 스토리에 대한 이해 없이 기술하면 끔찍한 사용자 스토리가 만들어진다. [본문으로]
  4. SOLID 원칙도 그렇고, 똑똑한 사람들 참 많다. 기억하기 쉽게 이름 짓는 것을 참 잘한다. [본문으로]
  5. 개발 주기이다. 보통 2주 정도이며, 스크럼에서 사용하는 용어이다. [본문으로]

'술(述) > 풀이' 카테고리의 다른 글

headless server(헤드리스 서버)  (0) 2021.11.22
횡단 관심사(Cross-cutting concerns)  (0) 2021.11.18
UUID  (0) 2021.11.14
버전(Version)  (0) 2021.10.20
결합도와 응집도  (0) 2021.10.12