사용자 스토리 서평
등록일: 2021-04-17
수정일: 2021-04-17
소프트웨어 요구 사항은 의사소통의 문제다. 소프트웨어를 사용하거나 팔기를 원하는 사람은 그것을 만드는 사람들과 의사소통을 해야 한다. 소프트웨어를 사업적 시각에서 바라보는 사람들과 기술적인 시각에서 바라보는 사람들과의 의사소통이다.
만일 어느 한쪽이 의사소통에서 우위를 차지한다면 프로젝트는 실패한다. 비즈니스쪽 사람들이 우위를 차지하게 되면 그들은 기능과 마감시한을 동시에 요구할 것이다. 개발자들이 이 두 가지 목표를 달성할 수 있는지, 요구 사항을 정확히 이해했는지 등에 대해서는 별로 고려하지 않을 것이다. 반대로 개발자들이 의사소통에서 우위를 차지한다면 비즈니스 언어 대신 기술적인 용어들이 난무하고, 개발자들은 정작 필요한 것이 무엇인지 알 수 없게 될 것이다.
우리에게 필요한 것은 함께 일하는 방법이다. 우리에게 당면한 문제를 공동의 문제로 공유하는 것이다.
사용자들은 소프트웨어의 초기 버전을 보고 나면 새로운 아이디어를 가져오고, 처음과 생각도 달라진다. 그래서 완벽한 계획은 존재할 수 없다. 우리는 당장 우리가 알고 있는 정보를 가지고 결정을 해야 하고 자주 그렇게 해야 한다. 프로젝트를 시작하기 전에 모든 것을 계획하고 결정하기보다는 프로젝트 전 기간에 걸쳐 계획하고 결정해야 한다. 이렇게 하기 위해서는 가능한 자주, 빠르게 정보를 가져다주는 프로세스가 있어야 하는데, 사용자 스토리는 이를 위한 것이다.
사용자 스토리란 무엇인가?
사용자 스토리는 소프트웨어의 사용자나 구매자에게 가치를 줄 수 있는 기능을 서술한 것이다.
- 서술: 스토리는 서술 형태로 기록되며, 계획하거나 기억하기 위한 단서로 사용된다.
- 대화: 스토리는 대화를 통해 세부사항을 구체화한다.
- 테스트: 스토리는 테스트를 통해 세부사항을 문서화하고 전달하며, 스토리의 완료 여부를 판단한다.
사용자 스토리는 왜 사용해야 하는가?
- 스토리는 구두 의사소통 강조한다
- 사용자 스토리를 사용하는 목적은 우리가 바라는 기능들의 모든 세부사항까지 문서로 자세히 기록하자는 것이 아니다. 오히려 나중에 개발자와 고객이 대화를 이어나갈 수 있을 정도의 내용을 담은 짧은 문장들을 기록하자는 것이다.
- 문서를 공유하는 것은 이해를 공유하는 것이 아니다.
- 완벽한 요구 사항보다 훨씬 가치 있는 것은 적절한 스토리와 잦은 대화를 병행하는 것이다.
- 스토리는 이해하기 쉽다
- 스토리는 개발자와 사용자 모두 이해하기 쉽다
- 스토리는 고객과 사용자의 가치를 표현하도록 작성되기 때문에 비즈니스를 하는 사람이든 개발자든 쉽게 이해할 수 있다.
- 스토리는 계획 수립에 적합한 크기다
- 스토리는 계획 수립에 적합한 크기로 되어 있다. 그래서 관리하기 적합한 크기로 릴리즈를 계획하거나, 개발자들이 프로그램을 작성하고 테스트를 수행하는 데 적절히 사용할 수 있다.
- 스토리는 반복적 개발에 효과적이다
- 프로젝트를 시작하기 전에 모든 스토리를 작성할 필요가 없다. 몇 가지 스토리를 작성한 후 만들고 테스트한 뒤 이 과정을 필요한 만큼만 반복하면 된다.
- 스토리는 세부사항을 나중에 고려할 수 있게 해준다
- 초기에는 프로젝트의 목적을 기술하는 수준에서 시작하여 세부사항들이 필요할 때 내용을 추가해 나갈 수 있다.
- 스토리는 기회주의적 개발을 지원한다
- 스토리는 사전에 모든 요구 사항을 완전히 알고 있다고 가정하지 않는다.
- 스토리는 개발자들이 모든 세부사항을 완전히 이해할 수 있다고 가정하지 않는다.
- 스토리는 변화를 포용한다.
- 일반적으로 사용자와 고객은 자신이 원하는 것을 정확히 알지 못한다.
- 세부사항들은 시스템을 개발하면서 비로소 명확해진다.
- 모든 세부사항들을 미리 알 수 없고, 안다고 하더라도 모든 것을 이해할 수 없다.
- 모든 것을 이해했다고 하더라도 변경사항은 발생한다.
- 사람은 실수를 한다.
- 스토리는 참여적 설계를 유도한다
- 스토리는 사람들의 참여를 유도한다. 시스템의 특성이 아닌 사용자가 시스템을 사용하는 목적을 이야기함으로써 시스템에 관해 더 흥미로운 대화를 나눌 수 있다.
- 스토리는 암묵적 지식을 구축한다
- 스토리는 직접 대화하는 것을 강조하기 때문에 팀 전체에 암묵적 지식을 쌓도록 해준다.
사용자 스토리는 어떻게 써야 하는가?
- 목적 스토리로 시작하라
- 시스템을 사용하는 각 사용자 역할에 따라서 사용자의 목적이 무엇인지를 고려하는 것으로 시작해야 한다.
- 케이크 자르듯 나누어라
- 나누어진 스토리가 시작부터 끝까지 기능을 제공하도록 나누어야 한다. 그러면 애플리케이션 아키텍처의 모든 계층을 포함하도록 함으로써 마지막 순간에야 특정 계층에서 문제가 발견되는 리스크를 줄일 수 있다.
- 프로그램의 기능이 일부만 구현되었더라도 해당 기능들이 시스템의 처음부터 끝까지 포함된다면 실제 사용을 목적으로 사용자에게 릴리즈할 수 있기 때문이다.
- 닫힌 스토리를 작성하라
- 닫힌 스토리란 의미 있는 목적을 달성하는 형태로 작성되어 사용자로 하여금 무언가를 해냈다고 느끼게 하는 스토리를 말한다.
- 제약사항을 기록하라
- 어떤 스토리가 직접 구현될 내용은 아니지만 시스템이 꼭 지켜야 하는 내용인 경우 제약사항이라는 표식을 달아두어라. 제약사항을 잊지 않도록 하는 데 도움이 된다.
- 스토리의 크기는 시간축에 맞추어라
- 프로젝트 진행 일정에 따라 다양한 수준으로 스토리를 작성하라.
- 되도록 사용자 인터페이스를 배제하라
- 프로젝트 초기에 사용자 인터페이스에 대해서 고려하는 것은 시간 낭비다.
- 스토리가 아닌 것들
- 사용자 스토리를 무조건 사용하기보다는 사용자 스토리와는 다른 양식으로 요구 사항을 표현할 필요가 있다면 그렇게 하라.
- 스토리에 사용자 역할을 포함하라
- 사용자 역할을 식별해 냈다면, 스토리를 작성할 때 사용자 역할을 적극 이용하도록 하라. 예를들어 다음과 같이 작성할 수 있다. `나는 (역할)로서 (비즈니스 가치)를 위해 (기능)을 원한다.
- 한 명의 사용자를 대상으로 작성하라
- 스토리는 한 명의 사용자를 대상으로 작성하였을 때 읽기가 가장 수월하다. 예를들어 “구직자들은 사이트에서 이력서를 삭제할 수 있다.”보다는 “구직자는 이력서를 삭제할 수 있다”라고 작성하는 것이 좋다.
- 능동태로 작성하라
- 능동태로 작성하는 것이 더 이해하기 쉽다. 예를들어 “이력서는 구직자에 의해 게시될 수 있다”고 하기보다 “구직자는 이력서를 게시할 수 있다”가 더 이해하기 쉽다.
- 고객이 작성하라
- 스토리 카드에 번호를 부여하지 말라
- 스토리 카드에 번호를 부여하면 무의미한 업무 부담만 늘리고 구체적인 기능을 논의하는 데 불필요한 추상성을 개입시키는 문제가 있다.
- 목적을 잊지 말라
- 스토리 카드의 주 목적은 구현할 기능을 논의하기 위한
단서 역할이다. 그리고 단서는 간결해야 한다. 스토리 카드에는 나중에 대화를 재개하기 위해 기억하면 될 정도의 세부사항만을 써넣도록 하며, 너무 많은 세부사항을 써넣어 카드가 대화를 대신하지 않게 한다.
- 스토리는 독립적이어야 한다
- 가능하면 스토리 간에 의존성을 배제해야 한다.
- 의존성이 있게 되면 우선순위 결정과 계획 수립에 문제를 발생시킨다.
- 스토리는 협상 가능해야 한다
- 스토리는 고객과 개발팀이 대화를 통해 협상 가능해야 한다.
- 스토리는 대화를 이끌기 위한 단서지 그 자체로 완성된 상세한 요구 사항이 아니다.
- 스토리에는 대화를 재개할 단서 역할을 하는 한두 무장, 대화중에 해결된 쟁점에 대한 주석만을 내용에 담아라.
- 스토리의 크기는 작아야 한다
- 스토리의 크기는 한두 명의 개발자가 반나절에서 길어야 2주일 안에 구현하고 테스트할 수 있는 크기가 적당하다.
- 세부사항을 모두 스토리로 나눌 필요는 없다. 세부사항이 정말 중요해진 시점이 되었을 때 개발팀과 고객팀이 세부사항에 대해 논의하는 것이 더 좋고, 스토리에 주석으로 남길 수도 있지만 기능에 대해 증명하는 용도로 사용해서는 안 된다.
- 스토리는 추정 가능해야 한다
- 개발자들은 각 스토리의 크기 혹은 작업 소요 시간을 추정할 수 있어야 한다.
Sources
