개요

소프트웨어 개발 프로젝트는 초기부터 어떻게 진행될지 완벽하게 예측하는 것이 불가능한 일이다. 필요할 때마다 소프트웨어의 요구사항을 잘 전달하기(의사소통) 위해 함께 일하는 방법이 필요하다. 즉, 프로젝트를 착수하는 시점에 모든 것을 포괄하는 결정을 하기보다, 프로젝트 전 기간에 걸쳐 의사를 결정해야 한다. 이를 위해 가능한 자주, 신속하게 필요한 정보를 가져다 주는 프로세스가 있어야 한다.

사용자 스토리

사용자 스토리란 소프트웨어의 사용자나 구매자에게 가치를 줄 수 있는 기능을 서술한 것이다.

사용자 스토리는 3가지 측면으로 구성된다.

• 서술: 계획하거나 기억하기 위한 단서로 사용
• 대화: 대화를 통해 세부사항을 구체화
• 테스트: 테스트를 통해 세부사항을 문서화 하고 전달하며, 스토리의 완료 여부를 판단

구직, 채용 웹사이트의 사용자 스토리 예시로 "사용자는 자신의 이력서를 웹 사이트에 게시할 수 있다."가 있다. 이런 스토리는 사용자에게 가치를 평가 받을 수 있도록 기능을 표현해야 한다.

스토리는 너무 큰 것보다는 많은 것이 더 낫고 한두 명의 개발자가 반나절에서 길어야 2주일 안에 구현하고 테스트할 수 있는 정도의 크기가 적당하다. 세부사항과 관련해 스토리를 모두 작성하기 보다 개발팀과 세부사항에 대해 고객이 논의하는 것이 더 나으며 이것이 정말로 중요한 시점에 되었을 때 그에 관해 대화를 나눈다.

합의된 내용은 스토리가 정확하게 개발되었는지를 증명하는 테스트 형태로 문서화 된다.

인수 테스트

프로젝트에서 사용자들이 기대하는 바를 이해하는 것은 중요하며 이러한 기대는 인수 테스트의 형태로 표현하는 것이 가장 효과적이다.

→ 인수 테스트란 고객이 기대한 대로 정확히 동작하는 지를 입증하는 과정이다.

"사용자는 검색 조건과 일치하는 채용 정보를 볼 수 있다"라는 스토리의 인수테스트 예시

채용 정보를 입력하지 않고 시도해 본다.
채용 정보를 아주 길게 넣어 본다.
급여 정보가 빠진 경우를 확인해 본다.
여섯 자리 급여로 시도해 본다.

테스트의 서술은 간결해야하며 목적은 스토리에 대한 부가 정보를 통해 개발자가 자기 일을 끝냈다는 것을 알 수 있도록 하는 것이다.

고객 팀

고객 팀에는 소프트웨어가 사용자의 요구를 만족하는지 보증해 줄 사람들로 테스터, 제품 관리자, 실제 사용자, 상호작용 설계자등이 포함된다.

프로세스

전통적인 폭포수 방식과 달리 고객과 사용자의 참여가 프로젝트를 하는 기간 내내 계속 된다. 고객과 대상 사용자는 스토리 작성에 적극적으로 참여해야 한다. 스토리 작성 과정은 시스템을 사용할 사용자의 유형을 고려하는 데서 시작하는 것이 가장 좋다.

스토리 작성은 주로 고객팀이 작성하는데 비즈니스 언어로 작성해야 우선순위를 결정할 수 있다. 또한 제품의 주된 기획 주체로 고객팀은 제품의 동작을 가장 잘 설명할 수 있다.

이후 이터레이션 길이를 정하고 이터레이션 동안의 작업량(속도라고 부름)을 추정한다. 이를 기반으로 각 스토리의 우선순위를 구하고 개발 비용을 고려해 이터레이션과 릴리즈 계획을 세운다.

사용자 스토리의 장점

• 문서보다 구두 의사소통을 강조
• 고객이나 개발자 모두 이해
• 계획 수립에 적당한 크기
• 반복적 개발에 효과적으로 사용
• 무엇이 필요한지 잘 알 때까지 세부사항을 뒤로 미룰 수 있게함

스토리 작성하기

다음은 좋은 스토리의 여섯 가지 특성이다.

• 독립적이다
• 협상 가능하다
• 사용자 및 고객에게 가치가 있다
• 추정 가능하다
• 작다
• 테스트 가능하다

독립적이다

스토리간에 의존성을 배제하도록 신경 써야 한다. 의존성이 있으면 우선순위 결정과 계획 수립에 문제를 야기하기 때문이다.

예시

// 상호 의존성이 높은 스토리들
1.  기업은 채용 공고를 게시할 때 비자카드로 할 수 있다.
2. 기업은 채용 공고를 게시할 때 마스터카드로 결제할 수 있다.
3. 기업은 채용 공고를 게시할 때 아메리칸익스프레스 카드로 결제할 수 있다.

이런 형태의 의존성에서는 2가지 방법을 시도해볼 수 있다.

• 의존성이 있는 스토리들을 합쳐 좀더 큰 하나의 독립적인 스토리로 만듦
• 스토리들을 다른 방식으로 분리

위 예제의 경우 모두 더한 스토리의 크기가 적당하기 때문에 하나의 스토리로 합치는 방식이 적절하다.

그러나 스토리들의 작업 추정치가 좀더 길다면 아래와 같이 나눌 수 있다.

1. 고객은 한 종류의 신용카드로 결제할 수 있다.
2. 고객이 결제할 수 있는 신용카드는 두 종류가 더 있다.

이렇게 분리하는 것이 어렵다면, 각 스토리에 작업 추정치를 두 개씩 부여하는 방법으로 하나는 다른 스토리보다 먼저 개발되는 경우, 다른 하나는 나중에 개발되는 경우 추정치로 나눌 수 있다.

협상 가능하다

스토리는 계약서나 요구사항 명세서처럼 꼭 구현해야 한다고 기록된 것이 아니다. 단지 대화를 이끌기 위한 단서이며 완성된 상세한 요구사항이 아니기 때문에 모든 세부사항까지 포함할 필요가 없다.

스토리에 적당한 주석은 필요하지만 너무 많은 주석은 작업량을 증가시킬 뿐이다. 또한 이는 고객과 더 의논할 필요가 없을 거라는 그릇된 믿음으로 이어질 수 있다. 따라서 스토리 카드는 개발자와 고객이 대화를 재개할 수 있는 단서 역할로 다음의 내용으로 구성하는 것이 유용하다.

• 대화를 재개할 단서 역할을 하는 한두 문장
• 대화중에 해결된 쟁점에 대한 주석

사용자와 고객 혹은 구매자에게 가치 있다

사용자의 가치 평가와는 별개의 스토리도 사용한다. 직접 사용하는 '사용자'와 소프트웨어를 구매하는 '구매자'가 다를 수 있기 때문이다.

정말 피해야 할 스토리는 개발자에게만 가치 있는 스토리로 내포된 의미는 결국 고객을 위한 것인 경우가 많다. 고객이나 사용자에게 제공하는 이점이 드러나도록 작성해야한다.

스토리가 고객이나 사용자에게 가치 있도록 하는 가장 좋은 방법은 고객이 직접 스토리를 작성하게 하는 것이다. 스토리 카드가 정식 요구사항이 아님을 언급하고 나중에 대화를 재개할 수단으로 사용된다는 개념에 익숙해지면 고객들이 스토리를 자발적으로 작성할 것이다.

추정 가능하다

추정이 쉽지 않은 3가지 경우가 있다.

1. 해당 분야의 지식(도메인 지식)이 부족하다.
   • 스토리를 잘 이해하지 못한다면 그것을 작성한 고객과 직접 의논해야 한다. 또한 스토리에 대해 전반적으로는 이해하고 있어야 한다.
2. 기술적인 지식이 부족하다.
   • 먼저 스파이크(문제 영역을 살펴보는 작업)를 수행하도록 해 작업을 추정할 수 있을 정도로 내용을 습득하게 한다.
3. 스토리가 너무 크다.
   • 에픽(스토리가 큰)을 작성하는 것이 쓸모있는 경우가 있다. 이는 논의되지 않은 부분을 리마인드 시키거나 나중에 세분화된 스토리로 대체하기 위한 자리매김 역할을 해준다.
   • 의식적으로 특정 부분을 덮어두고자 한다면 에픽을 한두 개 작성해 일단 마감하는 방법도 고려해 볼 만하다.

작다

어떤 스토리가 적절한 크기인지는 개발 팀의 역량이나 사용하는 기술에 따라 결정된다.

스토리 나누기

에픽은 두 가지 중 하나다.

• 복합적인 스토리
  • 작은 스토리를 여러 개 포함하는 에픽
  • 일련의 작업 단위에 따라 나눌 수 있음(생성, 수정, 삭제)
  • 데이터의 경계에 따라 스토리를 나눌 수 있음
• 복잡한 스토리
  • 스토리 자체에 대한 불확실성 때문에 복잡
  • 문제를 조사하는 스토리 / 기능을 개발하는 스토리로 나눌 수 있음
  • 보통은 조사하는 스토리만 추정이 가능
  • 이렇게 스토리를 분할하면 고객이 조사 작업에 대해서도 별도의 우선순위를 부여할 수 있음(스파이크 스토리가 기능을 구현하는 것이 아닌 조사만 실시한다는 것을 인식하고 우선순위 부여)

스토리 합치기

너무 작은 스토리들은 반나절에서 며칠 정도의 작업량이 되도록 스토리를 합쳐 새 이름을 부여하고 일정 계획이나 작업 시에 다른 스토리들과 동일한 방법으로 다룬다.

테스트 가능해야 한다

스토리는 테스트 가능하도록 작성해 테스트를 통과해야 그 스토리가 성공적으로 개발되었다고 확인할 수 있어야한다.

테스트가 불가능한 스토리들은 비기능 요구사항에서 주로 나타나는데 아래와 같은 예시가 있다.

- 사용자가 소프트웨어를 쉽게 사용할 수 있어야 한다.
- 어떤 화면도 사용자를 오래 기다리게 해선 안된다.

이런 스토리는 테스트를 할 수 없으므로 '새 화면은 95%의 경우에 2초 안에 나타나야 한다'와 같이 다시 작성해야 한다.

사용자 역할 모델링

사용자 역할이란 비슷한 유형의 사용자들을 모아 이런 집단이 시스템과 어떤 상호작용을 하는지 규정하는 속성의 집합이다. 한 시각만으로는 스토리를 작성할 수 없기 때문에 여러 사용자의 경험, 배경, 목적 등이 스토리에 반영되어야한다.

역할 모델링 절차

효과적인 사용자 역할 목록을 만들기 위해 아래와 같은 절차를 따른다.

1. 사용자 역할 목록 초안을 위한 브레인 스토밍
   • 사용자 역할을 식별하기 위해 고객과 함께 가능한 많은 개발자들이 한방에 모여 회의를 한다.
   • 각자 생각할 수 있는 한 많은 사용자 역할 카드를 작성한다.
   • 구체적인 사용자를 나타내는 역할을 식별해야하며 실제로 시스템을 사용하는 주체여야 한다.(특정 사용자 개인을 나타내면 좋음)
2. 목록 초안 조직화
   • 역할 식별 이후 역할들 사이의 관계에 따라 위치를 조정
   • 역할이 중복되면 카드를 겹친다.
   • 사용자 역할 정의 시 시스템 보다는 시스템을 사용하는 사람에 초점을 맞춰야하며 프로젝트의 성공과 실패를 좌우할 중요한 사람들에 대해 역할을 찾고 정의해야한다.
   • 단, 예외가 있을 수 있고 비인간 사용자 역할을 추가하는 것이 도움이 된다면 그렇게 하라.
3. 역할 통합하기
   • 앞 단계에서 완전히 겹쳐진 카드를 가지고 시작한다.
   • 토론을 거쳐 동등하다면 통합하거나 둘 중 하나를 찢어버린다.
   • 중복되는 역할 통합과 함께 중요하지 않을 것같은 역할에 대한 카드는 모두 찢는다.
4. 역할 다듬기
   • 역할에 대한 속성을 정의함으로써 역할 모델링을 할 수 있다.
   • 역할 속성은 어떤 역할을 수행하는 사용자에 대한 사실 혹은 사용자와 관련된 유용한 정보다.
   • 소프트웨어의 성격에 따라 사용자를 잘 설명할 수 있는 속성을 찾아야 한다.

도움이 되는 기법 두 가지

• 등장인물(persona)
  • 사용자 역할을 대표할 만한 가상 인물
  • 시장 및 인구통계에 근거해 충분한 조사가 선행되어야 함
  • 시스템이 절대적으로 어떤 사용자 역할을 만족시켜야만 한다면 그들이 바로 등장인물의 후보가 된다.
• 극단적 인물
  • 지나칠 수 있는 스토리를 발견하게 해준다.
  • 소프트웨어을 어떻게 사용할지에 대한 생각을 해볼 수 있고, 이로부터 통찰을 얻을 수 있다.

현장 사용자

실제 사용자와 함께 일할 경우 그들이 원하는 모습으로 소프트웨어를 개발할 수 있는 가능성을 높여준다. 그러나 실제 사용자라고 해도 꼭 필요로 하는 사용자 혹은 사용자 구성원이라고 볼 수 없다. 따라서 간단하게라도 역할 모델링을 수행해보는 것이 좋다.

스토리 수집하기

요구사항을 식별하는 행위를 끌어내기 혹은 잡아내기라는 단어로 설명한다. 그러나 이러한 표현은 요구사항이 어딘가에 흩어져 있고 우리가 할 일은 그저 그것들을 끌어내어 잡아서 설명을 붙이고 우리에 넣어 자물쇠를 채우면 된다는 오해를 낳는다.

이러한 표현보다 그물질이라는 말이 더 잘 어울린다. 이 메타포는 배에서 그물을 끌어 당겨 요구사항들을 잡아내는 듯한 이미지를 줄 뿐만아니라 다양한 측면에서 적절해 보인다.

• 다른 크기의 요구사항들을 잡아내기 위해 다른 크기의 그물을 사용
  • '크기'는 비즈니스적인 가치가 얼마인가, 소프트웨어 구현에 얼마나 필요한가 등의 척도로 생각
• 요구사항이 물고기처럼 성장하고 죽을 수도 있다는 발상
  • 현 시스템에는 그 요구사항이 필요하지 않을 수 있음
• 물고기를 낚을 때 그 지역의 물고기를 다 못 잡는 것처럼 모든 요구사항을 찾아내지는 못함
• 그물질이라는 메타포는 요구사항을 찾는 데 숙련된 기술이 중요한 역할을 한다는 것을 드러냄

기존 명령적 프로세스는 프로젝트 초기에 모든 요구사항을 도출하고 그것들을 문서화하는데 많은 비중을 둔다. 그러나 애자일 프로젝트에서는 한번에 모든 사용자 스토리를 낚을 수 있을 정도로 촘촘한 그물을 사용하는 것이 불가능하다는 점을 인정한다. 초기에 스토리를 모두 작성하는 것이 불가능함을 인정하지만 할 수 있는 만큼은 스토리를 모두 작성하려고 시도해보아야 한다.

스토리를 이용한 개발 진행 장점은 다양한 수준으로 상세화할 수 있다는 것이다. 스토리를 작성하고 나중에 이 스토리를 더 작고 좀더 쓸만한 스토리로 나누면서 발전시킬 수 있다.

그렇다고 스토리를 작성하는데 오랜 시간을 보내는 것을 추천하는 것은 아니다. 사전에 애플리케이션의 규모에 대한 감을 잡는 것이 중요한 경우 정밀도가 낮은 개략적인 사용자 스토리를 작성하는 데 신중을 기해야 한다.

스토리는 프로젝트 기간 동안 발전하고, 나타나고, 사라지기 때문에, 반복적으로 사용할 수 있는 스토리 수집 기법이 필요하다.

사용자 인터뷰

• 성공 포인트는 인터뷰 대상자 선정에 존재
• 무슨 일이 있어도 꼭 실제 사용자와 인터뷰를 해야 함
• 대부분의 사용자는 정말 필요한 것이 무엇인지 제대로 알지 못해 이를 위한 기술 혹은 기법이 필요
• 사용자 요구의 핵심에 다가갈 수 있는 최고의 기법은 사용자에게 직접 질문하는 것
• 자유롭게 응답하는 개방형 질문을 통해 응답자들의 깊이 있는 의견을 끌어낼 수 있음
• 암시적으로 특정 답변을 유도하지 않고 질문자의 선호도가 나타나지 않는 문맥 무관 질문을 통해 사용자로부터 넓은 범위의 답변을 얻게 될 가능성을 열어 둘 수 있음

설문

• 이미 가지고 있는 스토리에 대한 정보를 수집하는 효과적인 기법
• 큰 사용자 집단 대상으로 스토리에 우선순위를 매기거나 특정 질문에 대한 답을 얻을 때 유용
• 스토리를 새로 그물질 하는 경우에 설문을 1차적인 수단으로 사용하는 것은 대부분 적절치 않음
• 필요에 따라 추가 질문을 하기 쉽지 않고, 대화와 달리 사용자에게 갑자기 떠오르는 내용을 쫓아가는 것도 불가능
• 한 방향으로 전달되며 질문과 응답의 시간 간격이 길기 때문에 스토리 수집의 주된 수단으로 사용은 비추천

관찰

• 전반적인 아이디어를 얻을 수 있는 좋은 방법
• 사용자 인터페이스를 어떻게 개선할지, 생산성을 어떻게 높일지에 대한 아이디어 제공
• 사용자 자신들이 필요로 하는 것을 제대로 알지 못하더라도 관찰을 통해 알 수 있음

스토리 작성 워크숍

• 개발자, 사용자, 제품 고객, 그 외 스토리 작성에 기여할 수 있는 사람들을 포함하여 진행
• 많은 스토리를 아주 빠르게 작성할 수 있음
• 좋은 스토리 작성 워크숍은 브레인스토밍 + 충실도 낮은 프로토타입의 장점을 모은 것
  • 충실도 낮은 프로토타입은 인덱스 카드, 화이트보드를 활용해 소프트웨어와의 고수준 상호작용을 보여줌
  • 개념적인 작업흐름을 규정
  • 시스템의 어떤 사용자 역할 혹은 등장인물로 시작할지 결정하고 그 사람들이 할 수 있는 동작이 무엇이 있는지 생각을 말함
  • 동작마다 연결선과 새로운 박스를 그리고 제목을 붙인 후 스토리를 작성
  • 깊이 우선 방식 작업의 흐름을 따라 참가자들이 가능한 많은 스토리를 생각할 수 있음
  • 사용자 역할과 등장인물에 따라 새로운 스토리가 식별될 수 있고 이를 당장 논의하기 어렵다면 메모
• 스토리의 질 보다 양에 초점을 두어야 함
• 스토리 작성을 어려워 한다면 다른 경쟁 제품이나 비슷한 제품을 살펴보는 것이 큰 도움이 될 수 있다.
• 스토리에 대해 평가하지 않는 것이 중요
• 가능한 짧은 시간에 최대한 많은 사용자 스토리를 작성하며 아주 높은 수준의 논의가 이뤄져야 함을 강조

대리 사용자와 일하기

소프트웨어 프로젝트에서 고객 팀에 실제 사용자를 포함해 원하는 바를 알아야 한다. 그러나 이를 팀에 포함시키기는 쉽지 않아서 대리 사용자에 의존해야하는 경우가 많다. 실제 사용자의 빈 자리를 메워 줄 여러 부류의 대리 사용자들을 살펴보자.

사용자들의 관리자

관리자가 실제 사용자라 하더라도 일반 사용자와는 소프트웨어를 사용하는 패턴이 다를 것이다. 실제 사용자가 요구하는 기능과 달리 중요성이 낮고 자주 사용되지도 않는 기능들이 최종 제품에서 부각될 수 있다.

이러한 경우 프로젝트의 성공을 위해 최종 사용자들에게 다가갈 수 있는 길을 찾아야만 한다.

개발 팀 관리자

개발 팀 관리자는 대리 사용자로는 최악의 선택이다. 실제 사용자와는 목적이 다른 경우가 많다. 대부분의 개발 팀 관리자는 자신들이 개발하는 소프트웨어에 대한 실무 경험이 없으며, 해당 분야 전문가도 아니다.

영업사원

영업사원의 위험요소는 대상 제품의 특정 기능에만 주의를 기울인다는 데 있다. 따라서 기업의 전략적, 장기적 비전을 놓치기 쉽다.

영업사원을 고객에게 여러분을 소개하는 연결고리로 활용하면 좋을 것이다.

해당 분야 전문가

사용자로서 유용한지 여부는 비슷한 소프트웨어를 사용하는지, 혹은 사용해 본 경험이 있는지에 따라 달라진다. 도메인 모델을 개발하고 비즈니스 규칙을 식별해야 할 때는 해당 분야 전문가들이 이상적인 자원이지만, 작업 흐름이나 사용 방법에 대한 문제에서는 실제 사용자들에게 답을 구하는 것이 더 낫다.

또 다른 잠재적 문제점은 최종 소프트웨어가 전문가 정도의 지식 수준에 맞추어질지도 모른다는 것이다. 따라서 너무 복잡하거나 대상 사용자 층을 잘못 선택하는 결과를 가져올 수 있다.

마케팅 그룹

사용자를 이해하기보다는 오히려 시장을 더 잘 이해하는 경향이 있다. 그래서 각 기능의 품질보다는 제품에 포함된 기능 목록에 치우치게 된다.

이전 사용자

최근 사용 경험이 있는 이전 사용자는 대리 사용자로 최고지만, 소프트웨어 사용 목적이나 동기가 이번 실제 사용자들과 완전히 일치하는지의 여부를 검토하는 것이 중요하다.

고객

구매 결정을 내리는 사람들로, 반드시 소프트웨어를 사용하는 것은 아니다. 예시로 기업에서 사용하는 OA 소프트웨어는 고객과 사용자가 다른 전형적인 경우이다. IT 직원들이 회사 전체에서 사용할 소프트웨어를 선정하고, 사용자는 기업의 전 사원이다.

교육 담당 및 기술 지원

교육 담당을 대리 사용자로 사용하면 괜찮을 수 있지만, 시스템이 교육하기 쉬운 데 초점을 맞출 수 있다.

비즈니스 분석가 또는 시스템 분석가

기술적인 영역과 소프트웨어를 도입하려는 분야 양쪽에 몸을 담고 있어 좋은 대리 사용자가 될 수 있다.

하지만 일부 분석가들은 문제에 관하여 '연구'하기보다는 '공상'하기를 더 좋아하는 문제점을 보여준다. 또한 프로젝트 초기의 선행 작업에 시간을 너무 많이 할애하려 한다는 문제점이 있다.

대리 사용자와 일할 때 조심할 점

대리 사용자와 일하는 경우 성공 가능성을 높일 수 있는 기법들을 알아보자.

사용자가 있지만 접근이 제한될 때

최선의 방법은 두어 명 이상의 실제 사용자가 포함된 '사용자 태스크포스'를 구성하도록 요구하는 것이다. 이는 대리 사용자의 의견에 대한 반응을 확인하기 위해 구성한 것이며 최종 의사결정은 여전히 대리 사용자의 몫이다. 이를 통해 대리 사용자의 잘못된 의사결정에서 비롯될 수 있는 위험을 완화할 수 있게 된다.

대리 사용자는 프로젝트의 전략적 방향을 설정하게 하고, 구현 세부사항에 관한 문제는 사용자 태스크포스에게 넘긴다.

정말 만날 수 있는 사용자가 없을 때

대리 사용자를 서로 다른 부류에서 두 명 이상 확보하도록 한다. 경쟁하는 경우라면 경쟁 제품 자체로부터 스토리를 이끌어 내는 방법도 있다. 또 다른 방법으로 제품을 가능한 빠르게 릴리즈하여 실제 사용자와 대리 사용자 생각 사이의 차이를 아는 것이다.

개발자가 직접 할 수 있을 까?

대리 사용자를 확보하려는 노력도 없이 개발자가 직접 사용자 역할을 대신하는 우를 범해서는 안된다. 실제 사용자를 대신하는 데 있어 다른 대리 사용자 유형보다 훨씬 문제가 많다. 마케팅 배경 지식이나 경험이 없어 각 기능들의 상대적인 가치를 이해하기 어렵다.

고객 팀 조직하기

무엇보다도 실제 사용자가 대리 사용자보다 우선이라는 사실을 명심해야 한다. 고객팀을 구성하는 절차는 아래와 같다.

1. 실제 고객을 추가한다.
2. 고객 팀의 구성원 중에서 프로젝트 챔피언을 한 명 식별해낸다.

• 고객 팀은 가능하면 일관된 의견을 내놓을 책임이 있다.

3. 프로젝트를 성공으로 이끄는 데 필수적인 요인을 결정한다.

• 프로젝트 핵심 성공 요인을 고객 팀에 전달하기 위해 관련 지식, 능력, 경험을 갖춘 대리 사용자를 보충한다.

사용자 스토리 인수테스트

인수테스트는 고객과 개발자가 대화를 나누는 과정에서 언급된 세부사항들을 나타내기 위함이다. 또한 스토리가 완전히 개발되었는지를 결정하는 기본적인 기준이 되기도 한다. 테스트는 두 단계로 이루어진다.

1. 나중에 무엇을 테스트할지에 관한 짧은 메모를 스토리 카드 뒷면에 짧게 적어 놓는 것
2. 테스트에 관한 메모를 완전한 형태의 실행 가능한 테스트로 옮기는 과정

인수 테스트는 고객이 자신이 명시해야 하며 기대하거나 가정하는 내용은 반드시 테스트로 작성해 두어야 한다. 또한 직접 이 테스트를 실행할 책임이 있다

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

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

인수 테스트가 있으면 프로그래머는 코딩을 시작하기 전에 유용한 정보를 많이 얻을 수 있다.

테스트는 '코드 작성이 끝난 다음'하는 것이 아닌 개발 프로세스의 일부로, 가능한 많은 테스트를 생각해 작성하고 스토리의 세부사항이 진척됨에 따라 추가 테스트를 명시해야 한다.

그렇다고 불필요하게 중복하여 작성할 필요는 없다. 스토리의 의도가 개발자에게 명확하게 전달되도록 하는 데 초점을 맞추어 테스트를 작성해야 한다.

스토리를 테스트하는 것은 프로그램의 기능이 기대한 대로 구현되었는지를 확인하는 기능 테스트인 경우가 대부분이지만 다른 테스트 종류도 고려해 보아야 한다.

• 사용자 인터페이스 테스트: UI가 예상한 대로 동작하는 지
• 사용성 테스트: 쉽게 사용할 수 있는지
• 성능 테스트: 다양한 작업 부하에서 얼만큼 성능 보이는지
• 스트레스 테스트: 사용자 초과, 트랜잭션 과다 등의 상황에서 어떻게 동작하는지

좋은 스토리를 위한 지침

• 목적 스토리로 시작하라.
  • 한번에 하나씩 사용자 역할을 선택해 그 사용자가 새 시스템을 사용하는 주 목적을 식별하는 것이 가장 효과적이다.
  • 목적을 달성하기 위한 세부 목적들을 확인하고 이를 스토리를 추가로 작성하는 데 사용할 수 있다.
• 케이크 자르듯 나누어라
  • 큰 스토리를 만났을 때 그것을 작은 스토리 조각으로 나눌 수 있음
  • 스토리를 나누는 좋은 방법은 각각의 스토리가 시작부터 끝까지의 기능을 제공하도록 나누는 것
    • 애플리케이션 아키텍처의 모든 계층을 포함하도록 하여 마지막 순간에야 특정 계층에서 문제가 발견되는 리스크를 줄일 수 있음
    • 기능이 일부만 구현되었더라도 기능들이 시스템의 처음부터 끝까지 포함한다면 실제 사용을 목적으로 사용자에게 릴리즈될 수 있기 때문
• 닫힌 스토리를 작성하라
  • 의미 있는 목적을 달성하는 형태로 작성되어 사용자로 하여금 무언가를 해냈다고 느끼게 하는 스토리
  • ex) '채용 담당자는 자신이 게시한 채용 공고를 관리할 수 있다' → 닫혀 있지 않은 스토리(완료될 수 있는 성질의 것이 아님)
  • ex) '채용 담당자는 채용 공고의 지원 마감일을 변경할 수 있다' → 닫힌 스토리
• 제약사항 기록하기
  • 스토리가 직접 구현될 내용은 아니지만 시스템이 꼭 지켜야 하는 내용인 경우 '제약사항'이라는 표식을 달아둔다.
  • 인수 테스트를 작성할 때 제약사항을 위반하지 않도록 하거나 어딘가에 붙여 잊지 않도록 함으로써 유용하게 사용된다.
• 스토리의 크기는 시간축에 맞추어라
  • 가까운 미래에 일어날 일에 더 집중하는 것을 의미
  • 바로 다음에 진행할 이터레이션은 일정을 계획할 수 있는 수준으로 작은 스토리
  • 훨씬 나중에 처리할 스토리는 정확하지 않더라도 더 크게 작성
• 되도록 사용자 인터페이스를 배제하라
  • UI에 관한 세부사항이 과도하게 포함되어 있을 가능성이 높다.
  • 프로젝트 초기에 이런 스토리를 작성할 이유가 없다.
• 스토리가 아닌 것들
  • 모든 경우에 스토리가 적합한 것은 아님
  • 다른 형식으로 표현하는 것이 효과적인 경우 그 방법을 사용하자.
• 스토리에 사용자 역할을 포함하라
  • 사용자 역할을 적극 이용하여 구체적인 사용자가 생각 속에 자리잡을 수 있도록 하자.
• 한 명의 사용자를 대상으로 작성하라
  • 한 명의 사용자를 대상으로 작성하였을 때 읽기가 수월하다.
  • 좀더 명확하게, 더 분명하게 스토리를 작성할 수 있다.
• 능동태로 작성하라
  • 능동태로 작성하는 것이 읽거나 이해하기 더 쉽다.
• 고객이 작성하라
  • 고객은 스토리의 우선순위를 매겨야하는 책임이 있어 각 스토리를 이해하고 있어야 한다.
  • 가장 잘 이해하는 방법은 직접 작성하는 것이다.
• 스토리 카드에 번호를 부여하지 마라
  • 무의미한 업무 부담만 늘리고 구체적인 기능을 논의하는 데 불필요한 추상성을 개입시킴
• 목적을 잊지 마라
  • 스토리 카드의 주 목적은 구현할 기능을 논의하기 위한 단서 역할이다.
  • 단서는 간결해야 한다.

사용자 스토리 추정

스토리를 추정하기 위한 방법의 특징

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

스토리 점수

앞에 열거한 특징을 만족시키는 방법 중 하나로 '스토리 점수'가 있다. 이는 팀마다 정의가 다른데 저자는 이상적 작업일로 정의하는 걸 선호한다고 한다. 그 이유는 아래와 같다.

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

팀 전체가 함께 추정한다

스토리 추정은 팀에서 공동으로 해야한다.

• 스토리를 추정하는 시점에 누가 어떤 스토리를 맡아 작업할지 아직 결정하지 않아 스토리를 팀 전체가 맡았다고 보는 것이 가장 정확
• 개인이 추정하는 것보다 팀이 추정하는 것이 더 정확

추정하기

반복적 방법을 이용한다. 스토리 하나에 대해 스토리가 무엇인지 듣고 각자 추정을 마치면, 추정치를 적은 카드를 다른 사람들이 볼 수 있게 한다. 추정치 차이가 많이나면 서로 토의를 하고 다시 추정하며 비슷하게 나올 때까지 반복한다.

삼각측량

스토리 추정치를 다른 스토리의 추정치들과 비교한다. 이를 쉽게 하기 위해서는 크기를 기준으로 스토리 카드를 벽에 붙이는 방법을 이용해 '거의 비슷한 정도'의 스토리가 해당 열에 존재하는지 빠르게 확인해볼 수 있다.

스토리 점수 활용

이터레이션 이후 팀 전체가 완료한 스토리들의 스토리 점수를 합산한다. 합산한 스토리 점수는 앞으로 같은 기간의 이터레이션에서 완료할 스토리 점수에 대한 예측치로 사용할 수 있다. 이를 속도라고 한다.

다만 속도 측정치 계속 사용하기 위해 세 조건을 만족해야 한다.

• 일반적이지 않은 사항들이 첫 번째 이터레이션의 생산성에 영향을 미치지 않았어야 한다.
• 추정치가 일관된 방식으로 추정된 것들이어야 한다.
  • 이는 팀 전체가 추정에 참여하는 방법을 이용하는것이 최선
• 첫 이터레이션에 선택된 스토리들이 독립적이어야 한다.

짝 프로그래밍을 하는 경우

짝 프로그래밍과 그렇게 하지 않았을 경우 측정한 팀의 속도가 다를 수 있다.(이상적 짝 작업일 vs. 이상적 개인 작업일) 수치는 다르지만 두 경우의 속도는 동일하며 단위의 차이는 속도에 반영되어 있으므로 단위가 중요한 것은 아니라는 것을 의미한다.

잊지 말아야 할 몇 가지

스토리 점수를 적절하게 사용하기 위해서 다음 사항을 잊지 말아야 한다.

• 각 팀마다 스토리 점수는 동등하지 않다. 같은 일이더라도 팀마다 스토리 점수 추정이 다를 수 있다.
• 나누어진 스토리들의 추정치 합은 원래 스토리에 대한 추정치와 같을 필요가 없다.
• 하위 작업들의 추정치 합이 원래 스토리의 추정치와 같을 필요가 없다.

릴리즈 계획

대부분의 소프트웨어 프로젝트에서는 두 달에서 여섯 달마다 새로운 릴리즈를 내놓는 것이 가장 좋다. 우선 새 릴리즈에 포함될 기능들을 모으는 것 부터 시작하는 것이 도움이 된다. 개략적인 개발 로드맵이 있다면 이것을 바탕으로 릴리즈 계획을 시작할 수 있다.

개략적인 제품 개발 로드맵을 바탕으로 아래의 두 질문을 통해 릴리즈 계획을 시작하게 된다.

• 언제 릴리즈할 것인가?
  • 반복적인 스토리 주도 프로세스에선 릴리즈 날짜를 정확히 지정하기 쉽지만 해당 릴리즈 날짜까지 어떤 기능들이 포함될지 결정하는 것은 어려움
  • 릴리즈 날짜가 대외적으로 확정된 경우 고려할 변수가 더 적어 릴리즈 계획이 좀더 쉽지만 어떤 스토리를 넣고 뺄지를 결정하는 문제는 더 어렵다.
• 각 스토리의 우선순위는 어떻게 되는 가?
  • 고객이 스토리에 우선순위를 매겨야 함
    • 필수: 시스템에 아주 중요한 기초
    • 희망: 중요하지만 단기적으로는 차선책이 있음
    • 선택: 시간이 부족한 경우 다음 릴리즈로 미루거나 누락될 수 있는 것들
    • 보류: 좋기는 하지만 다음 릴리즈에 포함될 것으로 미루는 것들

스토리 우선순위 매기기

스토리를 정렬하는 기술적인 요인

• 스토리 미완성에 대한 리스크
• 스토리 구현을 늦췄을 때 다른 스토리에 미치는 영향

고객과 사용자가 가진 자신들만의 스토리 정렬 기준

• 사용자나 고객 다수가 원하는 정도
• 다수는 아니지만 중요한 사용자나 고객이 바라는 정도
• 다른 스토리와의 응집성

고객은 개발 팀에서 제공하는 정보 없이 우선순위를 매길 수 없다. 고객은 각 스토리가 대략 얼마나 걸릴지 알아야 하고 각 스토리에 대한 가치 평가와 추정을 참고해 조직에 전달하는 가치가 최대가 되도록 스토리를 정렬한다.(비용에 따라 우선순위기 바뀔 수 있다.)

혼합된 우선순위

고객이 우선순위를 매기는 것을 어려워 한다면 스토리를 나눌 필요가 있음을 의미할지도 모른다. 하나의 스토리에 반드시 필요한 스토리 항목이 아닌 다른 스토리가 있는지 알아보고 나눌 수 있다면 여러개의 스토리로 나눠 우선순위를 좀 더 편하게 정할 수 있다.

리스크 높은 스토리

애자일 접근법은 수지에 맞는 부분을 먼저 개발하는 쪽에 속한다. 이는 프로젝트에서 가장 가치가 높은 기능이 준비되자마자 바로 릴리즈하는 것을 가능하게 한다.

일반적으로 개발자들은 우선순위 결정 시 리스크가 가장 높은 스토리를 먼저 개발하고자 하는 경향을 보인다. 하지만 그 결정은 개발자가 아닌 고객이 내려야 한다.

기반구조에 대한 우선순위

리스크가 있는 스토리들은 성능 특성과 같은 비기능 요구사항이나 기반구조와 연관된 경우가 많다. 이러한 스토리는 처음에는 낮은 우선순위여서 신경을 쓰지 못하고 있다가 점점 시스템을 전반적으로 리팩터링 하기 어려워 우선순위가 높아질 수 있다. 이런 경우 개발자들은 고객에게 구현을 미루는 것에 대한 비용이 얼마나 들지 고객들이 알 수 있도록 해야한다.

이터레이션 길이 선택

이터레이션의 길이는 개발자와 고객이 함께 결정한다. 보통 1~4주 정도가 적당하다. 긴 이터레이션 보다는 프로젝트의 방향을 자주 수정할 수 있고 진척 상황에 대한 가시성을 확보하기 쉬운 짧은 인터레이션이 낫다.(이터레이션마다 오버헤드는 존재)

가능하면 이터레이션 길이를 일정하게 유지하여 개발 페이스를 지속하는데 도움이 되도록 한다.

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

모든 스토리 카드에 우선순위를 매기고 개발 팀이 추정한 점수가 100점이라 하자. 이때 속도를 이용해 프로젝트 수행 기간을 예측할 수 있다.

속도는 3가지 값중에 하나를 선택할 수 있다.

1. 이전 프로젝트에서 사용한 값
   • 팀 구성원이 변함 없는 경우에만 가능
   • 불행히 비슷한 프로젝트를 완전히 똑같은 팀이 수행하는 경우가 드묾
2. 첫 이터레이션을 진행하여 얻은 값
   • 이렇게 할 수 있는 경우가 많지 않음
3. 어림잡은 값
   • 속도를 어림 잡을 방법이 필요
   • 일반적으로 이터레이션 전체 개발자-일 / 3 or 2 사이에서 속도를 선택함

릴리즈 계획 생성하기

릴리즈 계획 공유하는 방법 예시

• 팀이 같은 공간에서 작업할 수 있는 경우 각 이터레이션을 나타내도록 열을 지어 스토리 카드를 벽에 붙인다.
• 스프레드시트를 이용하는 경우 할당된 이터레이션에 따라 스토리를 정렬하고 각 이터레이션 마지막 스토리 아래에 굵은 선을 넣어 구분한다.
• 관련자들이 원격지에 있는 경우 한 페이지에 3개, 페이지를 줄이려면 6개씩 스토리 카드의 사진을 찍는다. 각 이터레이션의 처음에 커버 페이지를 넣어 구분하여 보낸다.
• 원격지의 높으신 분들이 관련자인 경우 간단한 간트 차트를 그린다. 차트에 '이터레이션 #1'과 같은 항목을 넣고 하위에 해당 이터레이션에 수행할 스토리의 이름을 나열한다.

릴리즈 계획은 아무것도 없는 상태에서 초기 예측으로서 사용하기 위한 것이다. 이러한 예측들은 새로운 정보를 얻게 되면서 지속적으로 재조정해야 한다.

이터레이션 계획

각각의 이터레이션을 시작할 때가 되면 더 세부적인 계획이 필요하다.

이터레이션 계획 개요

팀 전체가 이터레이션 계획 회의에 참석해야 한다. 이터레이션 계획 회의는 일반적으로 다음과 같은 절차에 따라 진행된다.

1. 스토리에 대해 토의한다.
   • 개발자들은 스토리 개발 난이도에 대한 의견 변경할 수 있음
   • 고객도 스토리의 우선순위를 변경할 수 있음
   • 스토리의 모든 세부 사항을 완전히 이해할 필요는 없음
   • 계획 회의가 끝난 뒤라도 스토리의 세부사항에 대해 고객과 더 논의할 수 있음
2. 스토리를 작업 단위로 나눈다.
   • 작은 하위 작업으로 나누는 것이 일반적으로 더 효과적
   • 스토리 하나를 개발자 한명이 처음부터 끝까지 개발하지 않기 때문
     • 개인마다 전문 분야와 일을 분담하는 것이 스토리를 더 빨리 구현할 수 있어서 한 스토리를 여러 개발자가 나누어 개발함
   • 스토리는 사용자나 고객의 관점에서 기능을 기술한 것이기 때문에 개발자의 작업 목록으로는 적절하지 않음
     • 세부 작업으로 변환하는 것은 개발자가 놓칠지 모를 사항을 정리하는 데 도움을 준다.
     • (작업으로 나누는 과정은) 폭포수 모형의 사전 설계를 대체하는 신속한 적시 설계의 예
     • 스토리를 나누는 지침
       • 추정하기 어려운 작업이 있다면 해당 작업을 스토리의 다른 부분들과 따로 분리
       • 나누어 진행할 수 있는 작업이 있으면 나눔
       • 스토리의 일부분만 완료되어도 도움이 된다면 그 부분을 별도의 작업으로 나눈다.
3. 각 작업마다 개발자 한 명이 책임을 맡는다.
   • 이터레이션에서 해당 작업이 확실히 완료되도록 하는 것은 이 사람의 책임
   • 실제로는 작업이 완료되도록 할 책임은 팀 구성원 전체에게 있음(모두가 함께 한다는 마음가짐)
   • "내가 맡은 일은 다 끝냈어. 그런데 톰은 아직도 작업이 몇 개 남았군"이라고 말하는 일은 없어야 함
4. 자신이 맡은 작업들의 작업량을 추정한다.
   • 이터레이션 안에 모두 완료할 수 있을지 현실적으로 평가해야 함
   • 시간이 부족하다면 아래와 같은 선택사항 존재
     • 모든 작업을 그대로 가져가고 잘 되기를 희망
     • 팀의 다른 누군가에게 작업의 일부를 넘겨 받을 것을 요청
     • 고객에게 해당 스토리를 누락해도 되는지 물어봄

속도 측정 및 모니터링

속도는 계획뿐만 아니라 관리 도구로도 유용하게 사용될 수 있기 때문에 지속적으로 관찰하는 것이 중요하다.

속도 측정

속도는 이터레이션 동안 완료한 스토리들의 점수를 그대로 합하면 된다.

릴리즈 계획에서 가정한 속도가 23과 많이 다르다면 프로젝트 전체 계획을 고쳐야 할 수 있지만 너무 일찍 릴리즈 계획을 조정하는 것은 조심해야 한다. 개발 초기에는 속도가 변하기 쉽기 때문이다. 좀더 장기적인 관점에서 속도의 추이가 어떠한지 알 수 있을 때까지 이터레이션을 두세 번 지켜보아야 한다.

이터레이션이 끝날 때까지 완료하지 못한 스토리는 속도 계산에 포함하면 안된다. 그 이유는 다음과 같다.

• 몇 퍼센트나 완료했는지 결정하는 것은 쉽지 않음
• 소수점을 사용하여 속도의 정확성에 대한 그릇된 인상을 갖지 않도록 해야함
• 완료하지 못한 스토리는 고객에게 가치를 제공하지 못함
• 스토리가 커 부분점수만 더하는 것은 스토리가 너무 크다는 것을 말함
• 90% 완료했다 하더라도 남은 10%에 가장 복잡한 부분이 숨어 있을 수 있음

완료되지 않은 스토리지만 속도 계산에 포함해야 한다고 판단한다면 스토리를 더 작게 만드는 것을 고려해야 한다.

계획 속도와 실제 속도

이터레이션의 계획 속도와 실제 속도를 함께 그려보면 얼마나 차이나는지 어떤 조치를 취해야하는 지 모니터링 할 수 있다.

속도 추이가 무엇을 말하는 지, 출시 일자를 조정해야 할 것인지 말 것인지 판단은 누적 스토리 점수 그래프도 함께 살펴봐야 한다.

이 그래프를 보면 세 번째 이터레이션 부터 계획보다 늦어지고 있음을 알 수 있다. 이를 보고 고객에게 상황을 알리는 도구로 활용할 수 있다.

이터레이션 소멸 차트

진행 상황을 지켜보기 위해 이터레이션 소멸 차트를 이용하는 것도 유용하다.

이는 릴리즈의 진행 상황을 반영할 뿐만 아니라 해당 릴리즈에 남아 있는 계획된 스토리 점수의 변동사항 까지 반영해 준다.

소멸 차트는 개발 팀의 속도를 보여주지는 않지만, 프로젝트 진행상황에 대한 종합적인 관점을 제공한다는 점에서 유용하다.

이터레이션 진행 중의 소멸 차트

소멸 차트는 이터레이션을 진행하는 동안에도 프로젝트 진행상황을 추적하는 훌륭한 관리 도구로 사용할 수 있다. 이터레이션 진행 중에는 일일 소멸 차트를 통해 해당 이터레이션에 남아 있는 작업량을 시간 단위의 추정치로 나타낸다.

차트와 함께 화이트보드에 남은 작업시간을 직접 수정하도록 하여 최신 상태로 유지하게 한다.

스토리가 아닌 것

스토리가 무엇인지 더 잘 이해하려면 스토리가 아닌 것에는 무엇이 있는지 살펴보는 것이 중요하다.

사용자 스토리는 IEEE 830이 아니다

IEEE 830은 IEEE 컴퓨터학회에서 출판한 소프트웨어 요구사항 명세서 작성에 관한 가이드라인이다. IEEE가 권장하는 방법은 '시스템은 ~해야 한다' 형태의 문장을 사용한다. 하지만 이러한 형식으로 자세하게 문서화하다 보면 장황해지기 쉽고 실수하기도 쉬우며 시간도 많이 든다. 또한 이런 문서는 읽기에 지루하다.

IEEE 830에서는 요구사항 명세서에 기술된 소프트웨어에 대한 변경 요청이 있을 경우, '범위 변경'이라고 부른다. 그러나 이 말은 2가지 이유로 잘못된 것이다.

• 어떤 시점에 그 범위라는 것이 충분히 알려져 있다는 것을 가정한다.
• 사용자가 의도한 목적을 달성하는 것과는 상관없이 단지 요구사항에 나열된 기능만을 구현하면 소프트웨어가 완성되는 것이라고 믿게 만든다.

사용자의 목적 자체에 변화가 있다면 이 용어를 사용하는게 적절하지만 단순히 세부적인 내용만 변하였을 때 이 용어를 적용하는 것은 적절치 않다.

이 요구사항 기술방식은 사용자의 목적보다는 요구사항 목록 자체에 주의를 기울이게 하기 때문에 프로젝트가 방향을 잃는 경우가 많다. 사용자 스토리는 목적에 초점을 맞춤으로써 사용자의 필요를 더 잘 만족시키는 솔루션을 얻을 수 있다.

사용자 스토리와 달리 IEEE 830은 요구사항을 모두 기술하기 전에는 개별 요구사항을 구현하는데 드는 비용을 잘 알 수 없다.

사용자 스토리는 유스케이스가 아니다

유스케이스는 시스템과 하나 이상의 행위자 사이의 상호작용을 기술한다. 여기서 행위자는 사용자나 다른 시스템을 말한다.

사용자 스토리와 유스케이스 간의 차이점

• 다루는 범위가 다름
  • 대부분 유스케이스가 훨씬 큰 범위를 포함
• 완결성
  • 사용자 스토리가 유스케이스의 주 성공 시나리오에 대응
  • 테스트들이 유스케이스의 확장 부분에 해당
• 수명
  • 유스케이스는 개발 기간이나 유지보수 기간에 계속 사용
  • 사용자 스토리는 개발한 이터레이션이 지나면 제거
• 세부사항 포함
  • 분량이 많고 별도로 사용자 인터페이스 요구사항을 집어넣을 적절한 곳이 없어 유스케이스에 포함
  • 유스케이스를 작성하는 사람들이 소프트웨어 구현 사항에 너무 일찍부터 초점을 두기 때문
• 작성 목적
  • 유스케이스는 고객과 개발 팀 간의 합의를 문서화 하는게 목적
  • 사용자 스토리는 릴리즈나 이터레이션의 계획을 세우는 데 도움을 주고, 사용자의 상세한 요구들에 관해 대화를 나누기 위한 매개체의 목적
• 유스케이스 요약(비구조적인 텍스트)과의 차이점
  • 보통 유스케이스 요약이 더 넓은 범위를 다룸(하나 이상의 사용자 스토리)
  • 산출물의 수명동안 사용되도록 만들어짐
  • 분석 작업의 결과물로 작성

사용자 스토리는 시나리오가 아니다

시나리오란 사용자와 컴퓨터 간의 상호작용에 대한 상세한 기술을 의미한다. 일반적으로 상호작용 설계 시나리오가 더 광범위하고 포괄적인 내용을 담는다. 시나리오는 다음 요소들을 포함한다.

• 설정
  • 스토리가 발생하는 곳
• 행위자
  • 여러 행위자를 가질 수 있음
  • 주 행위자와 부 행위자가 존재
  • 행위자는 항상 사람이어야 함
• 목표 혹은 목적
  • 하나 이상의 목적을 이루고자 함
  • 주 목적과 부 목적으로 구분
• 행위 및 사건
  • 줄거리라고도 부름
  • 행위자가 목적을 이루기 위해 수행하는 일련의 단계와 그에 대한 시스템의 반응을 의미

사용자 스토리와의 주요 차이점으로 다루는 범위와 상세함이 있다. 일반적으로 훨씬 시나리오가 상세하며 여러 스토리를 포함하고 상세하다. 하지만 시나리오가 상세함에도 불구하고 여전히 고려해야 할 사항들을 남긴다.

왜 사용자 스토리인가?

다른 요구사항 분석 기법들과 비교해 사용자 스토리의 장점들에 대해 살펴보자.

구두 의사소통을 강조

고객은 '기록된 것(문서)'에 대해 개발자들이 해석한 내용을 받지만 그들이 '원했던 것'이 아닐 수 있다.

즉 요구사항 문서로만은 원하는 것을 만들기에 부족하다.

불명확하게 기록된 내용이라든가 여러 의미가 있는 단어 등 혼동을 일으키는 요인이 많다. 반면 대화는 서로 즉각적인 피드백을 주고 받을 수 있고, 상호학습과 이해를 증진시킨다.

'완벽한' 요구사항을 작성한다는 것은 이룰 수 없는 목표라고 생각하며 세부사항들까지 문서로 기록하는 것이 아닌 나중에 대화를 이어갈 수 있을 정도의 내용을 담은 짧은 문장들을 기록한다.

완벽한 요구사항보다 훨씬 가치 있는 것은 '적절한 스토리'와 '잦은 대화'를 병행하는 것

모든 사람이 이해 가능

스토리는 간명하고 항상 고객과 사용자의 가치를 표현하도록 작성된다. 따라서 비즈니스를 하는 사람이든 개발자든 쉽게 이해할 수 있다.

스토리의 형태는 언급된 행위의 회상을 촉진할 뿐만 아니라 언급되지 않은 행위의 회상도 촉진

계획 수립에 적합한 크기

IEEE 830 스타일의 요구사항 문서는 문장이 너무 많아 우선순위를 부여하기 어렵다. 유스케이스나 상호작용 설계 시나리오의 경우 항목 하나 하나의 크기가 너무 크다는 것이 문제이다.

스토리는 관리하기 적합한 크기로 릴리즈를 계획하거나, 개발자들이 프로그램을 작성하고 테스트를 수행하는 데 적절히 사용할 수 있게 한다.

반복적 개발에 효과적

스토리를 처음에 모두 작성할 필요가 없다. 코딩 이후에 테스트하고 이 스토리를 작성하는 과정을 반복한다. 또한 원하는 만큼 적절한 수준의 세부사항만 작성하면 된다.

IEEE 830 스타일의 문서는 점진적으로 상세한 내용을 기술하는데 적합하지 않다. 요구사항 문장이 없으면 그렇게 하지 않는 것으로 간주하기 때문이다.

시나리오는 요구사항을 한번에 상세하게 기술하는 방법으로 점진적인 방법은 시나리오의 장점을 살리지 못하는 방법이다.

유스케이스는 상세한 정도를 조절할 수 있지만 대부분의 경우 표준 템플릿을 정의해 빈 공간을 모두 채워야하는 강박관념인 완전주의가 존재한다.

세부사항을 나중에 고려할 수 있게함

필요할 때 내용을 추가할 수 있다.

기회주의적 설계를 지원

탑 다운 방식은 다음과 같은 이유로 프로젝트를 진행하기 어렵다.

• 일반적으로 사용자와 고객은 자신이 원하는 것을 정확히 알지 못함
• 많은 세부사항은 시스템을 개발하면서 비로소 명확해짐
• 모든 세부사항은 인간인 이상 이해하기 힘듦
• 변경 사항이 발생
• 실수를 함

기회주의적 접근법은 문제점을 인정하고 극복하게 해준다.

• 사용자가 사전에 자신들의 요구사항들을 완전히 알고 있다고 가정하지 않음
• 개발자들이 모든 세부사항을 완전히 이해할 수 있다고 가정하지 않음
• 변화를 포용

참여적 설계를 유도

사용자가 시스템을 사용하는 목적을 이야기함으로써 시스템에 관해 더 흥미로운 대화를 나눌 수 있다. 또한 스토리와 시나리오는 사용자들이 쉽게 이해할 수 있으므로 사용자가 소프트웨어 설계에 참여하도록 유도한다.

사용자가 자신의 요구사항을 스토리로 만드는 데 익숙해지면 그것으로 이득을 보게 되는 개발자로 사용자의 참여를 독려하고 이러한 선순환 구조가 생긴다.

암묵적 지식 구축

대화를 많이 나눌수록 팀에 더 많은 지식이 축적된다.

왜 스토리를 택하지 않나?

• 스토리가 많을 때 스토리 사이의 관계를 이해하기 어려움
  • 사용자 역할을 사용하거나 개발에 들어가기 전까지 적당한 수준 이상으로 스토리를 유지함으로써 문제를 완화할 수 있음
• 요구사항 추적성이 요구되는 경우 스토리 외에 문서를 추가로 작성해야 할지도 모른다는 것
• 스토리의 장점인 암묵적 지식 강화는 매우 큰 규모의 팀에서 그대로 적용되지 않음
  • 규모가 큰 팀에서는 팀 전체에 정보가 전달되도록 기록이 필요한 대화가 있음

스토리 냄새 카탈로그

사용자 스토리를 사용할 때 나타나는 '나쁜 냄새'들의 카탈로그를 알아보자.

• 너무 작은 스토리
  • 증상: 추정치를 빈번히 조정해야 함
  • 논의: 작은 스토리에 대한 작업 추정치는 구현 순서에 따라 크게 달라질 수 있기 때문. 따라서 하나로 합치는 것이 계획 수립에 용이
• 상호 의존적인 스토리
  • 증상: 의존성 때문에 이터레이션을 계획하기가 어려움
  • 논의: 너무 작아서 상호 의존적인 것 같다면 하나로 합쳐서 해결. 적절한 크기처럼 보이면서 상호 의존적이라면 어떠한 방식으로 나누어진 것인지 살펴보자. 스토리가 애플리케이션의 모든 계층의 기능을 포함하도록 나누어야 한다.
• 금도금
  • 증상: 개발자들이 스토리를 구현하는 데 필요한 것 이상의 작업을 함
  • 논의: 금도금은 불필요한 기능들을 추가하는 것을 말한다. 보통 멋진 기능으로 고객을 놀라게 해주고 싶어하거나 지속적인 개발로 인해 극심한 압박을 회피하기 위해, 프로젝트에 자신만의 흔적을 남기는 것을 즐겨서 이런 금도금이 발생한다. 각자 무엇을 진행하고 있는지 일일 회의를 하거나 이터레이션 종료 시점에 모든 기능을 자세히 시연하는 이터레이션 검토 회의를 하면 이를 파악하는 데 도움이 된다.
• 너무 상세한 스토리
  • 증상: 세부사항들을 모으는 데 시간을 과도하게 소비
  • 논의: 인덱스 카드에 스토리를 작성하는 것은 작성할 공간이 제약되는 이점은 준다. 공간이 부족하다고 느끼면 '더 작은' 카드를 사용하여 의식적으로 스토리에 세부사항을 덜 포함시키도록 만든다.
• 사용자 인터페이스와 관련된 세부사항을 너무 일찍 포함시키기
  • 증상: 프로젝트 초기에 인터페이스와 관련된 세부사항들을 포함한다.
  • 논의: 상세한 내용을 넣는 것을 가능한 늦춘다. 또한 스토리에 페이지를 직접 언급함으로써 프로젝트 자체를 제약하는 일은 피해야 한다.
• 너무 앞서 생각하기
  • 증상: 여러가지 증상으로 확인할 수 있다. 스토리를 인덱스 카드에 기록하기 어렵다거나, 카드보다 소프트웨어를 활용하려고 한다거나, 세부사항을 잡아내기 위해 스토리 템플릿을 제안한다거나 등등..
  • 논의: 사전 작업에 익숙한 팀에서 흔히 발생하는데 스토리의 강점에 대해 복습해 보자. 사용자 스토리를 사용하는 가장 근본적인 이유는 모든 요구사항을 사전에 식별해낼 수 없다는 데 있다.
• 스토리를 너무 많이 나누기
  • 증상: 이터레이션 계획 시 작업량을 맞추기 위해 스토리를 나누는 경우가 많다.
  • 논의: 일반적으로 스토리를 나누는 이유는 스토리가 너무 커서 이터레이션에 포함할 수 없거나 스토리가 우선순위의 하위 스토리들을 포함하고 고객이 그 중에서 우선순위가 높은 하위 스토리들만 다음 이터레이션에서 구현하기를 원하기 때문이다. 이런 경우는 괜찮지만 그 외의 경우 남은 다른 스토리들을 훑어 보고 정말 나누어야 할 스토리인지 확인해야 한다.
• 고객이 우선순위 부여를 어려워 함
  • 증상: 스토리를 선택하고 우선순위를 부여하는 일은 어렵다.
  • 논의: 스토리의 크기를 살펴보자. 크기가 크다면 더 작게 쪼갠다. 스토리가 비즈니스적 가치를 표현하지 못한다면 고객에게 가치를 명확히 보여줄 수 있도록 다시 작성하거나 고객이 직접 스토리를 작성하게 한다.
• 고객이 스토리를 작성하거나 우선순위를 부여하지 않으려고 함
  • 증상: 고객이 스토리를 작성하고 우선순위를 부여하는 책임을 지지 않으려고 한다.
  • 논의: 고객이 궁지에서 벗어날 수 있는 방법을 찾는다. 고객의 생각을 표현하게 만드는 위협적이지 않은 방법(일대일 대화 or 최종 결정에 대한 책임은 고객에게 없다고 말하기 등등..)을 찾는다.

스크럼에서 사용자 스토리 사용하기

사용자 스토리는 익스트림 프로그래밍의 일부로 시작되었기 때문에 XP의 다른 실천법들과 잘 맞는다. 애자일 프로세스 중 하나인 스크럼에서 스토리가 어떻게 사용될 수 있는 지 알아보자.

스크럼은 반복적이고 점진적이다.

• 반복적 프로세스: 계속적인 정련 작업을 통해 진행되는 프로세스
  • 조각과 비유해 모양을 갖추도록 돌을 조각(큰 틀 먼저 작업)
  • 세부사항을 조각(작은 부분 작업)
• 점진적 프로세스: 소프트웨어를 여러 부분으로 나누어 각 부분을 개별적으로 개발하고 전달하는 프로세스
  • 증가분에 해당하는 각 부분은 그 자체로 온전한 기능을 수행
  • 조각과 비유해 한 부분이 완료될 때까지 거기에만 집중하고 그 다음 다른 부분을 선택해 최대한 완벽하게 조각하며 이를 반복한다.

스크럼의 기본

스크럼은 스프린트라고 불리는 30일 단위의 이터레이션을 통해 진행한다. 수행할 작업들을 제품 백로그라 불리는 우선순위가 매겨진 목록에서 선택한다. 이를 스프린트 백로그로 옮기고 일일 스크럼 회의에서 현재 진행 상황을 파악하고 대처할 수 있도록 한다.

스크럼 팀

4~7명의 개발자로 구성하며 전문 분야만 담당하기보다 '모두 함께 한다'는 자세를 공유한다. 전문 테스터들이 바쁘다면 팀원 중 한 사람이 테스트를 한다. 이외에 제품 소유자와 스크럼 마스터가 존재하는데, 제품 소유자는 XP의 고객에 해당하며 스크럼 마스터는 프로젝트 관리자보다 리더에 가깝다.

제품 백로그

제품에 필요한 모든 기능을 담은 주 목록으로 제품의 명백한 기능들을 기록한다. 제품 소유자는 제품 백로의 항목들을 우선순위에 따라 정렬한다.

스프린트 계획 회의

스프린트를 시작할 때마다 열린다. 계획 회의 전반부에는 제품 소유자가 팀에게 제품 백로그에 남아 있는 항목 중에서 우선순위가 높은 항목들을 설명한다. 팀원들은 계획회의 후반부엔 스프린트 백로그로 옮길 항목들을 결정할 수 있도록 충분한 질문을 통해 각 항목들을 숙지한다.

팀원들은 제품 소유자와 함께 팀이 이루고자 하는 것을 간략히 기술한 스프린트 목표를 정의한다. 스프린트 종료 시점에 하는 스프린트 검토 회의에서 이 목표를 달성했는지에 따라 스프린트 성공 여부를 평가한다.

계획회의 후반부에 개발 팀이 따로 모여 설명한 기능들을 논의하고 이번 스프린트 동안 수행할 작업량을 결정한다. 스프린트가 시작되면 개발 팀만이 스프린트에 작업을 추가할 수 있다.

스프린트 기간 동안에는 스프린트의 내용을 변경하지 않을 것이라는 약속을 조직으로부터 받는다. 대신 해당 스프린트에서 선택한 작업들을 완료하겠다는 이행 약속을 한다.

스프린트 검토 회의

스프린트에서는 잠재적으로 출시 가능한 형태의 증거분을 제품 소유자에게 인도해야 한다. 이 잠재적으로 출시 가능한 형태는 테스트까지 모두 마친, 사용 가능한 형태이다. 스프린트 종료 시점에 스프린트 검토회의에서 새로 추가된 기능들을 데모하는 식으로 진행된다.

일일 스크럼 회의

업무에 큰 지장 없이 프로젝트의 진행 상황을 체크할 수 있게 해준다. 보통 15분 남짓 진행하며 어제 무엇을 했는지, 오늘 무엇을 할 것인지, 장애요소는 무엇인가 질문하고 공유한다. 이런 회의의 목적은 개발자들이 동료들 앞에서 이행 약속을 하는 것이다. 시스템 일부분에 대한 설계나 제기된 문제 해결은 일일 스크럼 이후 해결하도록 한다.

일일 스크럼 회의를 통해 프로젝트에 관심이 있는 사람들에게 어느 때나 진행 상황을 알려줄 수 있다. 또한 모든 팀원이 현재 프로젝트가 어디까지 왔는지 알 수 있고, 작업 분배를 재고하기에 일일 스크럼은 좋은 시간이다.

스크럼에 스토리 추가하기

스토리와 제품 백로그

스크럼의 백로그 항목들을 사용자 스토리의 형태로 작성하여 제품 소유자가 우선순위를 부여하는 것이 훨씬 쉬워진다.

스프린트 계획 회의에서의 스토리

스토리는 고객에게 가치 있는, 즉 고객이 가치를 평가할 수 있는 내용을 담기때문에 스프린트 계획 회의의 진행이 더 쉽고 빨라진다.

스프린트 검토 회의에서의 스토리

스프린트에서 완료된 부분을 쉽게 알 수 있어서 스프린트 검토 회의도 쉬워진다. 제품 백로그가 고객이나 사용자에게 가치 있는 스토리로 이루어져 항목들을 데모하기 쉽기 때문이다.

스토리와 일일 스크럼 회의

스토리는 고객과 최종 사용자의 요구에 초점을 두므로 일일 스크럼 회의가 수월하게 진행될 수 있게 해준다.

그 밖의 주제

비기능 요구사항 처리하기

비기능 요구사항의 경우 스토리로 표현하기 어렵다. 이런 사항들은 시스템의 동작 방식에 제약을 가하는 경우가 많은데 사용자 스토리로 표현하기 어렵다면 적절한 양식을 사용하여 서로 이해할 수 있게 해야한다.

종이? 소프트웨어?

사용자 스토리를 인덱스 카드에 적어야 하는지 소프트웨어에 저장해야 하는지 각각 장단점이 있다.

• 인덱스 카드
  • 장점
    • 로우 테크 특성으로 인해 스토리의 부정확성을 지속적으로 떠올리며 대화를 촉진
    • 스토리 작성 시 스토리 내용의 양을 자연스럽게 제한
    • 다양한 방법으로 정렬하기 쉬움
  • 단점
    • 테스트 케이스 작성 시 카드의 크기가 제한되어 있음
• 소프트웨어
  • 장점
    • 추적성을 확보하는데 소프트웨어가 편리
    • 팀이 한 곳에 모여 있지 않은 경우에 인덱스 카드보다 소프트웨어 선호
  • 단점
    • 스토리들이 IEEE 830 스타일의 요구사항처럼 보이게 되어 스토리 작성자가 불필요한 세부 사항을 추가할지도 모른다.

환경을 살펴보고 인덱스 카드와 소프트웨어 중 적절한 환경을 선택하자.

사용자 스토리와 사용자 인터페이스

사용자 인터페이스를 설계하는 것에 관한 이슈들을 스토리는 무시한다는 지적이 있다. 이는 수긍이 가는 지적이며 스토리 기반의 애자일 접근법을 따르는 것이 갖는 잠재적 리스크를 이해해야 한다. 이를 사용자 스토리를 통해 해결하려면 아래와 같은 방법이 있다.

1. 사용자 역할 모델링 수행
2. 고수준의 사용자 스토리 수집
3. 스토리에 우선순위 부여
4. 상위 우선순위와 중간 우선순위의 스토리들 정련
5. 스토리들 그룹 짓기
6. 종이 프로토타입 제작
   • 사용자들에게 보여주고 그들의 의견을 반영함
7. 프로토타입 정련
8. 프로그래밍 시작

스토리 보관하기

보통 보관하는 편이 스토리 카드를 찢어버리거나 없애는 것보다 낫다.

버그 스토리

버그 리포트를 하나의 스토리로 간주하는 것이 좋다. 스토리 하나를 구현하는 것과 비슷한 시간이 걸린다면 스토리와 마찬가지로 취급할 수 있다.