초간단 User Stories (사용자 스토리) 요약

‘User Stories Applied’로 유명한 Mike Cohn의 웹사이트에서 User Stories에 대해 잘 정리된 글을 발견하였다. (엄청 짧다)
이 정도로도 충분한데 대체 300페이지가 넘는 두꺼운 책은 왜 쓰셨는지.

아래는 그 짧은 글의 내 입맛대로 요약본.

User Story란?

실 사용자의 관점에서 작성된 해당 기능의 짧고, 간단한 설명.
아래와 같이 보통 작성한다.

As a _____, I want _____ so that _____.

예제를 보자

아래는 epics, 즉 아주 커다란 사용자 스토리의 예이다.

As a user, I can backup my entire hard drive.

당연히 이건 한 번의 iteration으로 끝낼 분량이 아니다. 따라서, 아래와 같이 여러 개로 쪼갠다.

As a power user, I can specify files or folders to backup based on file size, date created and date modified.

As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.

세부사항을 넣어야 한다면 어떻게?

일단 해당 사용자 스토리를 잘게 쪼개본다. 또는 “Conditions of satisfaction(CoS)” 항목을 추가한다.

CoS는 간단히 말해 high-level acceptance test로 볼 수 있는데, 아래 사용자 스토리 예를 보면 좀 더 명확해진다.

As a vice president of marketing, I want to select a holiday season to be used when reviewing the performance of past advertising campaigns so that I can identify profitable ones.

이렇게 작성하다보니 뭔가 추가적으로 적어주어야 할 것 같은 의무감 같은 것이 생겼다.
그래서 아래와 같이 CoS를 추가해서 세부사항을 언급해주었다.

  • Make sure it works with major retail holidays: Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.
    Support holidays that span two calendar years (none span three).
  • Holiday seasons can be set from one holiday to the next (such as Thanksgiving to Christmas).
  • Holiday seasons can be set to be a number of days prior to the holiday.

누가 사용자 스토리는 쓰나?

누구든 상관 없다. product backlog를 관리하는 것이 PO의 의무이긴 하지만, PO가 반드시 사용자 스토리를 쓰란 법은 없다.

언제 쓰나?

프로젝트 기간 내내. 적어도 3 ~ 6개월 주기로 product backlog의 (재)작성, 수정 등의 작업은 필요하다.

사용자 스토리는 요구사항 정의서를 대체하는 것인가?

적어도 애자일 프로젝트에서는 사용자 스토리가 가장 선호되는 product backlog 양식이다.

“As a user, I want …” 부분을 실 요구사항에 대한 포인터로 사용하는 것도 좋은 생각이다. 즉 사용자 스토리는 Workflow diagram이나, 계산방법을 보여주는 Spreadsheet, 또는 팀이나 PO가 필요로하는 어떤 형태의 artifact도 가리킬 수 있다.

 

추가적으로, 아래 링크에서 조금 더 세부적인 내용을 확인할 수 있다.
여전히 짧은 글이지만 조금 더 많은 예제와 ‘INVEST’ 등의 사용자 스토리 작성 원칙들이 기술되어 있다.

http://www.yodiz.com/blog/writing-user-stories-examples-and-templates-in-agile-methodologies/

맘에 들지 않는 Visual Studio의 Editor

Visual Studio 새 버젼 출시에 앞서 개인적으로 가장 많이 바랬던 기능은 Editor의 개선이었다.

얼마 전 2017 버젼이 출시되었는데, 사실 C++ 쪽만 쓰고 있어서 개발 결과물에 대해서는 큰 바램이 없다.
그보다 프로그램 구동부터 종료 때까지 거의 대부분 Editor와 Output(Debug 시에는 둘 다)을 바라보는데 이 부분은 근 10년이 넘도록 변화가 없는 듯 하다.

매일 사용하는 JetBrains IDE나 Sublime Text는 그 자체로도 훌륭한 Tool이지만, 가장 맘에 드는 것 중 하나는 Editor/Console 화면이다.
테마 지정은 물론, 폰트와 줄간 크기를 내 입맛대로 조정할 수 있는데 – 예를 들어 PyCharm의 경우 Font 14, Line Space 1.1 – 이것만으로도 완전히 다른 환경에 온 듯한 느낌을 받는다.
CLion을 보면 심지어 Editor용 배경화면도 지정할 수 있는데 이건 좀 오버 같고.

왜 Visual Studio 팀은 이런데 신경을 안 쓰는지 모르겠다.
타 기능 개선에 비해 어려운 일도 아닐 것 같은데.