Scurm에서는 Product Backlo의 할 일들을 User Story 형태로만드는 것을 추천한다.
User story 형식
"<고객/사용자>는 <목적/목표>를 위해 <필요/욕구>를 원한다. "
ex) 채용자는 구직자들이 검색을 통해 일자리 정보를 얻을 수 있도록 사이트에 구인 게시물을 올리길 원한다.
💖User story
1. User story는 고객이 원하는 내용을 고객의 언어로 한 것이다.
2. User story는 고객에게 가치가 있는 내용이 있어야 한다.
3. User story는 Use-case 명세서만큼 자세하지는 않지만 User story를 서로 비교하여 난이도 및 중요도를 판단할 수 있을 만큼 자세해야 한다.
4. User story 중 하나가 선택되어 Sprint Backlog가 된다.
Immediately actionable
Negotiable
Valuable
Estimable
Sized to fit
Testable
💖Epic과 User story
Epic은 구체적이지 못하고 정제되어 있지 않다. Epic을 정제하여 User story를 만든다.
우수고객으로, 나는 고객 우대 프로그램으로 편하게 항공편을 예약하고 싶다. 그래서 나는 시간을 절약하고자 한다.
→우수고객은 시간을 절약하기 위해서 고객 우대 프로그램으로 쉽게 항공편을 예약하길 원한다.
<고객/사용자>우수고객
<목적/목표>시간 절약
<필요/욕구>고객 우대 프로그램으로 쉽게 항공편 예약
💖Sprint Backlog
1. Product Backlog를 우선순위에 따라 하나를 선택하여 Sprint Backlog로 선택한다.
Product Backlog(User stories)→Sprint Backlog(User story)
2. 선택된 하나의 User story는 여러 개의 Task로 나눈다.
Sprint Backlog(User story)→Tasks
3. 각 Task는 개발시간을 추정할 수 있을 정도로 구체적으로 작성한다.
4. User story 중 하나가 선택되어 Sprint Backlog가 된다.
Product Backlog: User stories
Sprint Backlog: User story
Task: 개발시간을 추정할 수 있을 정도로 구체적
💖Sprint Backlog Planning Meeting
선택된 하나의 User story를 여러개의 Task로 나눈다.
각 Task에 대한 내용을 잘 정리한다.
각 Task는 개발시간을 추정할 수 있을 정도로 구체적이어야 한다.
팀원의 능력, 지원 환경 등을 고려하여 작성한다.
💖Example. 은행 시스템
User Story #1
Sprint Backlog) 고객(사용자)는 계좌 조회를 하기 위하여 로그인을 하고자 한다.
Task
사용자는 공인인증서를 클릭하거나 아이디/비밀번호를 입력하여 로그인 한다.
사용자의 아이디와 비밀번호가 시스템의 고객 데이터베이스 테이블에 저장되어져 있다.
고객의 아이디와 비밀번호가 DB 테이블에 저장되어 있다면 로그인을 허용한다.
단, 비밀번호 입력 오류 횟수가 3회를 넘지 않으면 로그인을 허용한다.
고객의 비밀번호 입력횟수가 3회 이상이 되면 비밀번호 분실신고 화면으로 전환된다.
비밀번호를 잘못 입력했을 경우 비밀번호 입력 오류 횟수를 증가한다.
사용자의 아이다가 잘못 입력된 경우에는 계속 시도할 수 있도록 허용한다. 사용자가 아이디 검색을 원하면 자신의 이름과 계좌번호 그리고 이메일 정보를 입력한 후에 시스템에 저장된 아이디이면 이메일로 그 아이디를 전송한다.
사용자가 비밀번호를 알고자 한다면 핸드폰을 이용한 본인 인증 절차를 거친 후에 아이디와 이메일을 입력하면 시스템에 저장된 것과 일치한다면 이메일로 새로운 비밀번호를 보낸다.
핸드폰 본인 인증을 위해서 통신사 또는 이를 지원하는 회사 시스템과 연동된다.
공인인증서로 로그인한 경우 공인인증서를 저장하고 있는 매체(HDD, USB) 등과 연동이 되어야 한다.
사용자의 아이디/비밀번호는 자사가 제공하는 방식으로 암호화 한다.
→좋은 사례는 아니다. 시나리오에 가깝다.
Comments