유저 스토리
유저 스토리는 사용자가 소프트위에어를 통해 특정 목적을 달성하기 위해 어떤 행동을 할 수 있는지를 간결하게 표현한 설명이다. 주로 애자일 방법론에서 사용되며, 사용자 중심의 요구사항을 명확히 이해하고, 개발 방향성을 잡는 데 도움을 준다.
예를 들어, "겨울이니까 방어 먹고 싶네"라는 가벼운 욕구가 생겼다고 해보자. 이때 "방어(🐟) 맛집을 찾아서 가고 싶다!"라는 구체적인 요구사항이 생긴다. 유저 스토리는 이렇게 사용자의 니즈를 충족시키기 위해 소프트웨어에서 구현해야 할 행동을 정의하는 것이다.
왜 씀?
유저 스토리는 사용자 중심의 요구사항을 소프트웨어적으로 풀어내는 방식이다. 여기서 말하는 소프트웨어적이란 뭘까?
- 사용자: 내가 찾은 방어 음식점의 메뉴 구성이 궁금해 🥹
- 유저 스토리: 고객은 방어 음식점의 리뷰와 사진을 볼 수 있다.
즉, 개발자들은 유저 스토리를 보고 내가 만들어야 할 기능을 정확히 이해할 수 있다.
유저 스토리의 구성 요소
유저 스토리는 사용자 관점에서 작성되며, 다음 형식을 따른다.
[사용자]로서, 나는 [기능]을 원한다. 그래서 [목표/이유]을 얻을 수 있다.
- 사용자(Persona)
- 행동(Action)
- 목표(Purpose)
스토리의 주체가 되는 사람. 예: 관리자, 고객, 방문자 등
사용자가 수행하려는 기능 또는 요구사항
사용자가 행동을 통해 달성하려는 목적이나 이유
유저 스토리 예시
- 사용자는 구매 의사 결정에 참고할 수 있도록 음식점의 리뷰와 사진을 확인할 수 있다.
- 온라인 쇼핑몰 사용자로서, 나는 주문 내역을 확인할 수 있어서 내가 구매한 상품을 추적할 수 있기를 원한다.
- CEO로서, 나는 제품당 대략의 평균 수익률을 알고 싶다. 그래서 어떤 제품에 투자할지 결정할 수 있다.
특징
유저 스토리를 작성할 때 몇 가지 중요한 점을 기억해야 한다.
- [왜]는 실무에서 잘 사용하지 않음
- 최대한 짧고 간결하게
대부분의 기능은 그 자체로 목적을 설명하기 때문에 굳이 "왜"를 추가로 설명할 필요가 없다. 예를 들어, "사용자는 구매 의사 결정에 참고할 수 있도록 음식점의 리뷰와 사진을 확인할 수 있다"라는 문장에서 중간 문장을 제거해도 의미가 충분히 전달된다.
유저 스토리가 길어진다고 더 좋은 제품이 만들어지지 않는다. 오히려 핵심이 흐려질 수 있다. 짧고 명확한 유저 스토리는 이해관계자 간 의사소통을 더 효과적으로 만들어준다.
인수 기준(Acceptance Criteria)
인수 기준은 특정 유저 스토리가 완료되었는지 판단하기 위한 명확한 조건이다. 쉽게 얘기해서 특정 기능이 다 만들어졌다고 판단하는 것은 A, B, C 조건이 다 만족되어야 한다.
이는 개발팀, 이해관계자, 테스트 팀 간의 공통된 이해를 돕는 기준으로, 작업이 성공적으로 수행되었는지 확인하는 데 중요한 역할을 한다.
왜 필요함?
- 명확한 목표 제공
- 오해 방지
- 테스트 가능성 확보
개발자와 QA팀이 어떤 기능을 구현하고 테스트해야 하는지 분명히 이해할 수 있다.
팀 간의 다른 해석을 방지하며, 작업이 완료되었는지에 대한 합의점을 제공한다.
구체적이고 측정 가능한 조건을 통해 해당 기능이 요구사항을 충족했는지 확인할 수 있다.
인수 기준 작성
유저 스토리
사용자는 구매 의사 결정에 참고할 수 있도록 음식점의 리뷰와 사진을 확인할 수 있다.
인수 기준
- 리뷰 표시
- 사용자가 선택한 음식점의 리뷰가 화면에 표시된다.
- 각 리뷰에는 작성자, 평점(별점), 작성일, 리뷰 내용이 포함되어야 한다.
- 사진 표시
- 음식점의 사진 갤러리가 제공되며, 사용자는 사진을 클릭해 확대해서 볼 수 있다.
- 최소 3장 이상의 사진이 표시되어야 한다.
- 정렬 기능
- 리뷰를 최신순, 평점 높은 순, 평점 낮은 순으로 정렬할 수 있는 옵션이 제공된다.
- 리뷰 평점 요약
- 음식점의 평균 평점(0~5)이 별점과 함께 표시된다.
- 총 리뷰 수가 평점 옆에 표시된다.
- 데이터 오류 처리
- 리뷰 또는 사진이 없을 경우, 적절한 메시지(예: "리뷰가 없습니다" 또는 "등록된 사진이 없습니다")가 표시된다.
- 데이터 로드 중에는 로딩 상태를 표시한다.