PM 추천 도서 - 사용자 스토리 (1)

최근 지라(JIRA) 사용 방법에 관련된 글을 여러 번에 걸쳐서 작성했는데요. 아래와 같은 순서대로 의식이 흐르면서 갑자기 근본적인 학습이 필요하다는 생각이 들어서 예전에 읽었던 '사용자 스토리(User Stories)'를 다시 꺼내들었습니다.

프로덕트 매니저/스크럼 마스터로서 지라(JIRA)를 활용하기 전에 꼭 읽어야 할 책 - 사용자 스토리(User Stories)

<의식의 흐름>

1. 지라(JIRA)를 잘 활용하려면 어떻게 해야 할까?

   1. 왜 지라(JIRA)를 사용하려고 하는지 이해해보자.

2. 왜 지라(JIRA)를 사용할까?

   1. 애자일(Agile)하게 소프트웨어를 개발하려면 지라(JIRA)를 사용해야 한다고 들었기 때문에(?)

3. 그러면 지라(JIRA)를 잘 사용하면 애자일하게 소프트웨어를 개발할 수 있을까?

   1. 음... 그렇지 않다.

   2. 애자일(Agile)하게 소프트웨어를 개발하려면 지라(JIRA)라는 도구 자체가 필요한 것이 아니고 애자일(Agile) 철학/가치를 잘 이해한 상황에서 스크럼/칸반 등의 방법론을 적용해보는 것이 중요할 것 같다. 그리고 이 때 지라(JIRA)는 프로덕트팀이 애자일(Agile) 철학/가치를 실현하는데 도움을 줄 뿐이다.

4. 그러면 지라(JIRA)를 잘 활용한다는 것의 의미는 무엇일까?

   1. 지라(JIRA)라고 하는 소프트웨어의 기능을 이해하는 것도 중요하지만

   2. 애자일(Agile) 철학/가치를 잘 이해하는 것이 매우 중요하다.

그래서 애자일(Agile) 철학/가치를 잘 이해하는데 도움이 되는 사용자 스토리(User Storeis)를 다시 읽고 내용을 조금 정리해봅니다. 사실 이 책이 나온지는 꽤 되었습니다. 초판이 2006년도에 나왔으니 지금으로부터 벌써 14년전... 흐억 ㅎㅎ 그래서 굉장히 올드하다고 느끼실 수도 있겠지만 가끔씩 제가 현업에서 느끼는 부분들이 이 책에 그대로 표현되어 있는 것들을 보면 아직도 이 책의 가치는 굉장하다고 생각합니다. 그래서 프로덕트를 개발하는데 참여하는 많은 분들이 일단 이 책을 읽고 프로덕트 개발을 시작하면 좋을 것 같아요. 개발자, 프로덕트 매니저, 프로덕트 오너, 디자이너, 사용자, 고객, 이해관계자 분들이 이 책을 통해서 프로덕트를 개발하는 방법에 대한 시각을 공유한다면 더 나은 방향으로 프로덕트를 개발하는데 큰 도움이 될 것입니다. (책 광고는 아니고요. ㅎㅎ 추천 입니다.)

1부 시작하기

1장 개요

첫 장부터 뼈때리는 구절들이 있습니다.

"소프트웨어 요구사항은 의사소통(communication)의 문제다. 소프트웨어를 사용하거나 팔기를 원하는 사람은 그것을 만드는 사람들과 의사소통을 해야 한다. 프로젝트가 성공하기 위해서는 다양한 사람들의 머리에서 나오는 정보가 필요하다. 일부는 고객, 사용자, 때로는 분석가, 해당 분야 전문가, 소프트웨어를 사업적, 조직적 시각에서 바라보는 사람들이며, 그 반대편은 기술팀이다.
만일 어느 한쪽이 의사소통에서 우위를 차지한다면 프로젝트는 실패하게 된다. 비즈니스 쪽 사람들이 우위를 차지하게 되면, 그들은 기능과 마감 시한을 동시에 요구할 것이다. 개발자들이 이 두 가지 목표를 달성할 수 있는지, 요구사항을 정확히 이해했는지 등에 대해서는 별로 고려하지 않을 것이다. 반면 개발자들이 의사소통에서 우위를 차지하게 되면, 비즈니스 언어 대신 기술적인 용어들이 난무하게 될 것이고 개발자들은 정작 필요한 것이 무엇인지 알 수 없게 될 것이다.
우리에게 필요한 것은 함께 일하는 방법이다. 그리하여 어느 한쪽이 우위를 점하지 않으며, 감정적으로 흐르거나 혹은 정치적일 수 있는 자원 할당 문제를 공동의 문제로 공유하는 것이다."

크... 사실 저도 항상 겪고 있는 문제이지만 내적 성장이 부족하여 유연하게 대처하지 못했던 부분이 있었는데요. 이 책을 읽으면서 자아성찰을 많이 하게 된 것 같습니다.


사용자 스토리란 무엇인가?

사용자 스토리는 소프트웨어의 사용자나 구매자에게 가치를 줄 수 있는 기능을 서술한 것이다. 사용자 스토리는 다음 세 측면으로 구성된다.

- 서술(written description): 스토리는 서술 형태로 기록되며, 계획하거나 기억하기 위한 단서로 사용된다.
- 대화(conversation): 스토리는 대화를 통해 세부사항을 구체화한다.
- 테스트(test): 스토리는 테스트를 통해 세부사항을 문서화하고 전달하며, 스토리의 완료 여부를 판단한다.
(중략)
사용자 스토리를 가장 잘 설명한 표현은 다음과 같을 것이다. "카드"는 스토리의 본문(text)을 담고 있지만, 세부사항은 "대화"를 통해 결정되며 구현을 "확인"하기 위한 테스트를 포함한다.

스토리의 크기

사실 스토리가 너무 큰 것보다는 스토리가 많은 것이 더 낫다.
(중략)
하지만 스토리를 나눌 때 모든 세부사항을 하나 하나 스토리로 만들지는 않는다. '사용자는 검색 조건과 일치하는 채용 정보를 볼 수 있다'는 스토리는 아주 합리적이고 현실적이다. 이것을 더 나누어 다음과 같이 만들 필요는 없다.

- 사용자는 채용 정보에서 설명을 볼 수 있다.
- 사용자는 채용 정보에서 급여 수준을 볼 수 있다.
- 사용자는 채용 정보에서 위치를 볼 수 있다.

(중략)
이러한 모든 세부사항들까지 스토리롤 작성하는 것보다, 개발팀과 고객이 이런 세부사항에 대해 논의하는 것이 더 낫다. 즉 세부사항이 정말 중요한 시점이 되었을 때 그에 관해 대화를 나누는 것이다. 스토리 카드 1.2처럼 의논한 내용을 주석으로 달아두는 것은 문제되지 않는다. 다만 대화를 나누는 것이 핵심이지 스토리 카드에 달아 놓은 주석이 중요한 것은 아니다. 개발자나 고객 중 누구도 세 달쯤 지나 카드를 가리키며 "하지만 여기 보면 내가 그렇게 얘기하지 않았습니까"하고 말해서는 안 된다. 스토리는 계약과 같은 구속이 아니다.

2장 스토리 작성하기

'좋은 스토리의 여섯 가지 특성'

- 독립적이다(Independent)
- 협상 가능하다(Negotiable)
- 사용자 및 고객에게 가치가 있다(Valuable)
- 추정 가능하다(Estimatable)
- 작다(Small)
- 테스트 가능하다(Testable)

INVEST라는 이름을 제안하였다고 합니다. (Extreme Programming Explored와 Refactoring Workbook의 저자 윌리엄 웨이크)

4장 스토리 수집하기

기법

- 사용자 인터뷰
- 설문
- 관찰
- 스토리 작성 워크숍

6장 사용자 스토리 인수 테스트

테스트는 두 단계로 수행된다. 첫 단계는 나중에 무엇을 테스트할지에 관한 짧은 메모를 스토리 카드 뒷면에 짧게 적어 놓는 것이다. 누구든 새로운 테스트가 떠오를 때 첫 단계를 실행한다. 다음 단계는 테스트에 관한 메모를 완전한 형태의 실행 가능한 테스트로 옮기는 과정이다. 두 번째 단계에서 만들어지는 테스트는 해당 스토리가 정확하고 완전하게 개발되었는지 입증하는 데 사용된다.

코딩하기 전에 테스트 부터 작성하기

인수 테스트는 일반적으로 다음과 같은 때에 작성한다.

- 고객과 개발자가 스토리를 가지고 대화를 나누는 도중, 명백한 세부사항을 기록하기 위해
- 이터레이션 초기 코딩을 시작하기 전에 스토리를 명확하게 이해하고자 할 때
- 프로그래밍 중이거나 그 이후라도 스토리에 필요한 새로운 테스트를 발견할 때

테스트는 버그를 확인하기 위한 것이지 실행을 확인하기 위한 것이 아니다.

7장 좋은 스토리를 위한 지침

닫힌 스토리를 작성하라

예를 들어 BigMoneyJobs 웹 사이트 프로젝트에서 '채용 담당자는 자신이 게시한 채용 공고를 관리할 수 있다'는 스토리가 있다고 하자. 이 스토리는 닫혀 있지 않다. 무언가를 관리하는 것은 완료될 수 있는 성질의 것이 아니다. 오히려 계속 이어지는 활동이다. 다음과 같이 닫힌 스토리로 나누어 작성하는 것이 더 낫다.

- 채용 담당자는 자신이 게시한 채용 공고에 지원한 사람들의 이력서를 검토할 수 있다.
- 채용 담당자는 채용 공고의 지원 마감일을 변경할 수 있다.
- 채용 담당자는 채용 조건에 맞지 않는 지원서를 삭제할 수 있다.

2부 추정과 계획

8장 사용자 스토리 추정

스토리를 추정하기 위한 방법은 다음의 특징들을 가져야 한다.

- 스토리에 대해 새로운 내용을 알게 되면 언제든지 추정치를 수정할 수 있어야 한다.
- 에픽이든 작은 스토리든 그 크기에 상관없이 적용할 수 있어야 한다.
- 추정하는 데 시간이 많이 걸리지 않아야 한다.
- 진척 상황 및 남아 있는 작업량에 대해 유용한 정보를 제공해야 한다.
- 추정치가 정확하지 않더라도 큰 문제가 되지 않아야 한다.
- 릴리즈 계획에 사용할 수 있어야 한다.

스토리 포인트를 어떻게 추정하는 것이 좋을지에 대해서 고민을 많이 했었는데요. 이 책의 저자는 스토리 1 포인트를 이상적 작업일로 정의하는 것을 선호한다고 하네요. 2가지 장점이 있다고 합니다.

첫째, 경과 시간으로 추정하는 것 보다 쉽다.
둘째, 이상적 시간으로 추정하는 것이 모호한 단위로 추정하는 것보다 조금 더 신뢰할만한 근거를 제공한다.

처음에 스토리 포인트를 산정하는데 어려움이 있다면 일단 "이상적 작업일 = 스토리 포인트"로 생각하는 것도 좋을 것 같아요. 그리고 팀 전체가 함께 추정하는 것을 기본으로 하는 것이 좋습니다. 또한 저자는 추정할 때는 델파이(Wideband Delphi)법을 선호한다고 하네요. 스크럼에서는 "플래닝 포커"를 사용하게 되는데요. "플래닝 포커"도 기본적으로는 델파이법과 같은 역할을 하고 있습니다.

9장 릴리즈 계획

제품 개발 로드맵은 시간이 지나면서 분명히 변경될 것이고, 사실 그것이 바람직하다. 변경된다는 것은 우리들이 제품과 시장에 관하여 더 알게 되고, 그만큼 제품을 더 잘 개발할 수 있게 되었다는 것을 의미하기 때문이다.

스토리 우선순위 매기기

개발자들은 대체로 그들이 구현하고 싶은 스토리를 위에 올려 두며, 고객 역시 마찬가지다. 순서가 일치하지 않는 경우에는 항상 고객의 의견이 우선이다.
하지만 고객은 개발 팀에서 제공하는 정보 없이 우선순위를 매길 수 없다. 최소한, 고객은 각 스토리가 대략 얼마나 걸릴지는 알아야 한다. 스토리에 우선순위를 매기기 전에 스토리 카드 9.1과 같이 추정치가 스토리카드에 기록되어 있어야 한다.

비용에 따라 우선순위는 바뀐다

스토리 점수로부터 예상 기간 산정하기

물론 해답은 속도를 이용하는 것이다. 8장 「사용자 스토리 추정」에서 배운 것처럼, 속도는 이터레이션 동안 완료하는 작업의 양을 나타낸다. 일단 팀의 속도를 알게 되면, 이상적 작업일을 실제 작업일로 변환하는데 사용할 수 있다. 예를 들어 속도가 25인 팀이 추정한 프로젝트의 이상적 작업일이 100일이라면, 프로젝트를 완료하는데 이터레이션이 100 ÷ 25 = 4번 걸릴 것으로 추정할 수 있다.

경고!

릴리즈 계획을 너무 믿지 않도록 조심하라. 이번 장에서 소개한 기법들은 대략적인 프로젝트 기간을 추정하도록 도와주며, "이번 제품은 5~7 이터레이션 정도면 릴리즈할 수 있습니다"하고 말할 수 있게 해준다. 그러나 "6월 3일이면 완료됩니다"처럼 말할 수 있 정도의 정확성을 기대할 수는 없다. 릴리즈 계획은 아무것도 없는 상태에서 초기 예측으로서 사용하기 위한 것이다. 그리고 그러한 예측들은 새로운 정보를 얻게 되면서 지속적으로 재조정해야 한다. 이터레이션마다 속도를 모니터링하고, 기존의 추정치에 영향을 미치는 새로운 사실을 배울 때마다 스토리를 재추정해야 한다.

프로덕트를 개발하다 보면 일정에 대해서 굉장히 압박스러운 상황을 많이 받게 되는데요. 음... 이러한 사상/철학에 대해서 프로덕트팀만이 아니라 관련 부서의 공감대가 있어야 의사소통을 하는데 안전감을 느낄 것 같다는 생각이 조금 드네요. 그렇지 않으면 굉장히 정확한 일정을 요구 받기 쉽고 그러면 프로덕트팀도 방어적으로 일정을 전달할 수 밖에 없기 때문입니다.

10장 이터레이션 계획

이터레이션 계획 회의의 일반적인 절차

1. 스토리에 대해 토의한다.
2. 스토리를 작업 단위로 나눈다.
3. 각 작업마다 개발자 한 명이 책임을 맡는다.
4. 모든 스토리에 대한 토의를 거쳐 각 작업마다 책임자가 결정되면, 개발자들은 자신이 과하게 책임을 맡지 않았는지 확인하기 위해 자신이 맡은 작업들의 작업량을 추정한다.

애자일 프로세스에 대한 비판 중 하나는, 폭포수 모형 프로세스에 있는 것과 같은 코딩에 앞선 사전 설계(upfront design) 단계가 없다는 점이다. 그것이 사실이긴 하지만, 대신 애자일 프로세스에서는 설계를 자주, 신속하게 한다. 스토리를 작업들로 나누는 것은 최소한의 설계가 머리 속에 그려질 때 가능하다. 이 과정은 폭포수 모형의 사전 설계를 대체하는 신속한 적시 설계(just-in-time design)의 예라고 할 수 있다.

설계를 자주, 신속하게 하는 것이 도움이 되는 이유는 최초에 했던 설계가 항상 가장 좋은 설계라고 할 수 없기 때문인 것 같아요. 실제 프로젝트를 진행하면서 프로덕트팀이 얻게 되는 도메인 지식과 경험들이 누적되고 앞선 설계를 변경하면서 진행하는 것이 훨씬 더 좋은 프로덕트에 가까워지는 것이기 때문입니다. 이 과정에서 항상 문제는 일정과 적절한 협상이 필요하다는 점입니다. 크... 항상 일정이 문제죠. ㅠㅠ

11장 속도 측정 및 모니터링

속도 측정

속도는 스토리 점수다. 각 스토리마다 점수가 부여되어 있으므로 속도를 계산하려면 이터레이션 동안 완료한 스토리들의 점수를 그대로 합하면 된다.

속도는 실제 시간으로 측정하는 것이 아니다.

속도를 계산할 때는 이터레이션을 시작하기 전에 부여한 스토리 점수를 이용한다는 점을 주목하기 바란다. 일단 이터레이션을 끝내면, 스토리에 부여했던 점수를 변경하면 안 된다. 예를 들어 어떤 스토리를 이터레이션의 시작 시점에는 4점이라고 추정했지만, 진행하는 중에 너무 작게 추정한 것이 밝혀져서 7점이 더 적절하다고 생각할 수 있다. 그렇다고 해도 이터레이션을 마치고 속도를 계산할 때, 해당 스토리의 점수는 7점이 아닌 4점으로 계산해야 한다.
일반적으로 이터레이션 계획에서 가정하는 속도는 선행 이터레이션 속도보다 크지 않도록 해야 한다. 하지만 스토리 중에 너무 작게 추정된 것이 있다고 팀 전체가 인정한다면, 그리고 이번 이터레이션에서는 더 많은 일을 해낼 수 있다고 모두 확신한다면, 조금 더 높은 속도를 기준으로 계획을 진행할 수도 있다.
이미 완료한 스토리의 스토리 점수는 변경할 수 없지만, 추정치와 실측치의 차이 정보는 추후 스토리 추정치를 조정할 때 적극 활용해야 한다.

소비 작업시간이 아닌 남은 작업시간을 추적한다.

일일 소멸 차트는 스토리나 작업에 대한 소비 작업량이 아닌 남은 작업량을 반영한다는 점을 주목하라. 소비 작업량을 추적하는 것도 나름대로 합당한 이유가 있다(계획 작업량과 실제 작업량의 비교를 통한 추정 능력 향상, 주별 실제 작업 시간 모니터링 등). 하지만 그렇게 하면 안 되는 더 중요한 이유가 있다(대부분의 개발자가 지나치다고 느낄 만큼의 관리, 부정확한 추정치 등).
게다가, 정말 중요한 것은 지금까지 작업량이 얼마나 투입되었는지가 아니라 앞으로 작업량이 얼마나 남았는가다.

1부와 2부를 정리하는 것만으로도 꽤 오래 걸렸네요. 허허허 3부, 4부는 다음 포스팅에서 이어가도록 하겠습니다. 역시 정리를 하다 보니 더 선명해지는 것들이 있네요. 역시 반복해서 학습하는 것만이.... 크.... ㅎㅎ 혹시 궁금한 점이 있으시다면 댓글은 항상 열려 있습니다.
요약한 내용에는 부족한 내용이 많기 때문에 정확한 정보를 얻으시려면 책을 꼭 보시는 것도 추천입니다.
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=640013

사용자 스토리