프로덕트 백로그 관리가 막막하다면?
애자일의 기본 요소, 유저 스토리 뜯어보기
목차
1. 애자일 공부를 시작합니다.
2. 애자일 프로세스의 핵심
3. 유저 스토리로 돌아가는 애자일
하나라도 해당되면, 재밌게 읽을 수 있어요!
1. 프로덕트 백로그를 어떻게 다뤄야 하는지 모르겠다.
2. 애자일과 린 프로세스의 차이를 잘 모르겠다.
3. 생산성을 높여주는 업무 시스템이 고민이다.
애자일 공부를 시작합니다.
1. 오늘의 학습 교재, <애자일 마스터>
학교에서 만난 친구들과 창업을 시작했다. 기획자, 디자이너, 개발자로 구성됐고, 모두가 고객과 시장을 검증하는 데 뛰어들고 있다. 이 팀에서 기획자 겸 PO 역할을 하고 있는데, 어떤 시스템을 도입해야지 생산성을 더 높일 수 있을지 고민이다. 최근에 <애자일 마스터>라는 책을 공부하고 있는데, 애자일의 AtoZ를 체계적이고 이해하기 쉽게 잘 설명해준다. 애자일을 들어는 봤지만 자세히 모르는 분들에게 큰 도움이 될 것 같다.
사무라이가 인상적이다. 솔직히 사무라이는 못 참지!2. 린 프로세스와 애자일, 차이가 뭐야?
많은 분들이 '린 프로세스'와 '애자일'이 비슷한 게 아니냐고 생각한다. 둘 다, '빠른 이터레이션'이란 공통적 특징을 갖고 있어서 차이를 잘 모를 수 있다. 이 둘의 차이를 알기 위해선, 2가지 질문을 던져보면 된다. '어떤 것을 이터레이션 하는가?'와 '이터레이션의 목표는 무엇인가?'
린 프로세스는 가설을 세우고, 검증하는 사이클을 반복한다. 이 이터레이션의 목표는 팀이 잘 모르는 고객, 솔루션, 시장 등을 알아내고 학습하는 것이다. 이와 다르게, 애자일은 프로덕트의 기능 구현 사이클을 반복한다. 각 이터레이션마다 작은 규모의 기능을 구현 및 배포함으로써, 고객에게 최소한의 가치를 지속적으로 전달할 수 있다. 기능 구현 사이클에서 알 수 있듯이, 애자일은 개발팀에서 주로 이용하는 방법론이다. 그렇다고, 개발 외의 팀에서 애자일을 공부할 필요가 없다는 건 아니다. 애자일 방법론에서 일부 요소를 각자의 팀에 맞게 재해석하면, 엄청난 도움이 된다.
'애자일'과 '린'는 마치 '핑크 코랄'과 '코랄 핑크'랄까? 비슷해 보이지만 다르다.애자일 프로세스의 핵심
1. 애자일 두두둥장!
애자일은 왜 등장했을까?
(Agile dududunga, 출처 : <League of Legend>)애자일이 등장하게 된 배경을 알면, 애자일의 핵심을 더 쉽게 이해할 수 있다. 과거의 프로덕트 개발론은 필요한 모든 기능을 한 번에 개발하고, 이 최종 완성본을 바로 배포하는 방법이었다. 프로덕트의 규모가 작다면 괜찮지만, 큰 경우에 문제가 발생한다. 프로덕트에 구현할 기능이 많을수록, 더 오랜 시간을 필요로 한다. 과거의 방법론은 몇 개월 후의 날짜를 목표로 잡은 후, 개발에 전념한다. 현재 시점과 미래 배포 시점 사이의 거리감이 워낙 크다 보니, 현재 개발 속도가 충분한지 예측하기 어렵다. 예측이 어렵다는 말은 개발 로드맵, 스케줄을 날카롭게 짤 수 없음을 뜻한다.
무엇보다, 고객이 프로덕트를 실제로 사용하기까지 너무 오랜 시간이 걸렸다. 만약 몇 개월의 노력 끝에 프로덕트 개발을 완료했다고 해보자. 근데 막상 봐보니 고객이 원하지 않는 프로덕트라면? 지난 몇 개월의 노력이 모두 헛수고가 된다.
그래서 애자일이 뭔데?
애자일이란?
기능을 작게 구현하고, 바로 배포하는 이터레이션을 반복함으로써 고객에게 지속적인 가치를 제공하는 개발 방식
한 번에 많은 기능을 오랫동안 개발하는 게 문제라면, 기능을 조금씩 자주 개발하면 되지 않을까? 이 질문에서 애자일이 시작된다. 애자일은 기능을 작게 구현하고, 바로 배포하는 이터레이션을 반복함으로써 고객에게 지속적인 가치를 제공하는 개발 방식이다. 과거 방법론과 다르게, 몇 달 간의 긴 프로젝트 기간을 1~2주의 이터레이션들로 구성한다. 각 이터레이션마다 일부 기능을 배포함으로써, 고객은 프로덕트를 빠르게 사용해볼 수 있다. 목표 배포 일자가 1~2주 후이며, 이 이터레이션에서 구현할 기능도 명확하므로, 개발 테스크 관리도 상대적으로 쉽다.
2. 애자일의 핵심
최소 가치
애자일의 첫 번 째 핵심은 '최소 가치'다. 애자일은 1~2주의 이터레이션마다 고객에게 작은 가치를 제공한다.
프로젝트가 시작되면, 고객을 위해 어떤 기능을 구현해야 하는지 모두 리스팅 해서 프로덕트 백로그를 작성한다. 이후, 어떤 기능이 함께 있어야 로 시너지를 발휘에 고객에게 더 큰 가치를 전달할 수 있을지 고민하며, 릴리즈 계획을 세운다.
유연함
두 번째 핵심은 '유연함'이다. 앞서 말했듯, 매 이터레이션마다 고객에게 가치를 전달하기 위해 목표한 기능을 모두 개발 및 배포해야만 한다. 즉, 배포를 안 한다는 선택지는 없다. 근데 이터레이션이 끝나기까지 얼마 남지 않았는데 아직 구현해야 할 기능이 많이 남았다면? 리소스를 늘리는 건 사실상 불가능하다. 이미 개발자들이 몸을 갈아 넣고 있기 때문이다. 이때, 이터레이션의 구현 범위나 기능의 퀄리티를 조절한다. 애자일에서 말하는 유연함은 여기에 있다.
프로젝트를 시작하고, 프로덕트 백로그에 어떤 기능이 필요한지 모두 리스팅 한다. 이때, 고객 가치를 기준으로 우선순위를 반영해 백로그를 작성한다. 이후, 이터레이션을 진행하다가 시간이 부족하다고 판단될 시, 우선순위가 낮은 기능은 아예 다음 이터레이션으로 넘기고, 그 외에 리소스를 집중한다. 혹은, 우선순위가 낮은 기능은 구현하더라도, 퀄리티를 낮춰서 리소스를 아낀다.
이터레이션
세 번째 핵심은 '이터레이션'이다. 애자일에서 매 이터레이션을 시작할 때, 각 기능에 들어갈 리소스를 추정한다. 이터레이션이 끝날 때, 이 기능을 구현하는 데 쓴 리소스를 확인한다. 이렇게 리소스의 추정치와 실제 수치를 비교해 팀의 속도가 얼마나 빠른지, 이 속도로 가면 최종 목표일에 맞출 수 있는지 등을 계속 확인하다.
예를 들어, 3개월 동안 프로덕트 완성을 목표하고, 각 이터레이션 기간을 2주로 잡았다고 해보자. 그렇다면, 총 이터레이션 횟수는 대략 6번(=3개월 / 2주)이다. 이 6번 동안 프로덕트에 필요한 모든 기능을 구현해야 한다. 처음에는 필요한 기능을 6 분할해서 각 이터레이션마다 계획을 세운다. 하지만, 이터레이션을 진행하다 보면, 어떤 때는 생각보다 적게 기능을 구현할 때도 있다. 그러면, 그만큼을 다음 이터레이션에서 구현해야 한다.
유저 스토리로 돌아가는 애자일 시스템
1. 두꺼운 요구사항 문서는 그만!
프로덕트를 만들기 위해서 고객이 필요한 기능을 적은 요구사항 문서를 작성한다. 애자일은 이 요구사항 문서를 길고 자세하게 적을 필요가 없다고 말한다. 요구사항 문서가 자세할수록 오히려, 문서를 읽고 파악하는 데 오랜 시간이 걸려 비효율적이기 때문이다. 또한, 지금 문서에 적힌 기능이 언제 개발될지, 정말로 개발할지도 모른다. 열심히 쓴 요구사항이 뒤늦게 개발이 안 된다고 한다면, 문서 작성에 쓴 시간이 너무 아깝지 않은가?
유저 스토리란?
고객이 자신의 소프트웨어에 원하는 기능을 짧게 표현한 것으로, 프로덕트 백로그 관리에 사용된다.
애자일은 두껍고 길게 적힌 요구사항 서류 뭉치를 집어던지고, '유저 스토리'를 사용하라고 말한다. 유저 스토리는 고객이 자신의 소프트웨어에 원하는 기능을 짧게 표현한 것이다. 이 다양한 유저 스토리가 모여서 프로덕트 백로그를 이룬다. 프로덕트를 만들 때, '우리'가 아닌 '고객'이 원하는 것을 만들도록 신경 써야 한다. 유저 스토리는 고객 관점에서 작성된 기능 문서이기 때문에, '우리'에게 파묻히는 걸 막아준다. 고객이 어떤 부분에 더 큰 가치를 느낄지 생각하며 개발을 진행할 수 있다.
두꺼운 서류 뭉치와 이별! < 출처 : 이누야샤 >2. 유저 스토리 뜯어보기
[사용자]는 [목적]을 위해 [활동/작업] 하기를 원한다
유저 스토리를 쓰는 방법은 다양하지만, 그중 가장 대표적인 게 Jeff Patton의 유저 스토리 템플릿이다. '[사용자]는 [목적]을 위해 [활동/작업] 하기를 원한다(=As a [type of User], I want to [Action] so that [benefit])'라는 형식으로 각 스토리를 작성한다. 이 스토리 템플릿을 Who, Why, What 측면을 모두 담고 있다. 이 덕분에, 유저 관점에서 더 스토리를 생각할 수 있다.
과제(Task)와 테스크(Task)
각 유저 스토리에는 '과제(Task)'와 '테스트 기준'을 갖고 있다. '과제(Task)'는 이 유저 스토리를 구현하기 위위해 개발단에서 해야 하는 일이다. '과제(Task)'를 모두 달성했을 때, 유저 스토리 구현을 완료했다고 볼 수 있다. 구현이 완료된 유저 스토리가 정상적으로 작동하는지 평가해야 하는데, 이때 '테스트 기준'이 쓰인다. '테스트 기준'은 일종의 평가 항목으로, 이 항목이 모두 충족해야지 유저 스토리가 정상 작동한다고 본다.
3. 좋은 유저 스토리란?
좋은 유저 스토리의 요건으로, INVEST 가 있다. INVEST는 총 6가지 요소의 약자를 나타내는데, 'Independent(독립적)', 'Negotiable(협상 가능한)', 'Valuable(가치 있는)', 'Estimatable(측정 가능한)', 'Small(작은)', 'Testable(테스트 가능한)'로 구성된다.
Independent : 유저 스토리는 '독립적'이어야 한다. 서로 다른 유저 스토리에 지나치게 의존하면 안 된다.
Negotiable : 유저 스토리는 규모 측면에서 '협상 가능'해야 한다. 리소스를 고려해 규모를 유동적으로 해야 한다.
Valuable : 유저 스토리는 '가치'가 있어야 한다. 여기서의 '가치'는 고객 관점에서 평가해야 한다.
Estimatable : 유저 스토리 개발에 드는 리소스를 '측정 가능'해야 한다.
Small : 유저 스토리의 리소스는 범위가 작아야 한다. 그래야지 리소스를 정확하게 측정할 수 있고, 다른 스토리에 의존하지 않는다.
Testable : 유저 스토리가 잘 개발됐는지 알기 위해 '테스트 가능'해야 한다.
Independt : 독립적
프로젝트를 진행하다 보면, 예상치 못한 일로 계획이 바뀔 수 있다. 예를 들어, 저번 주까지 매우 중요한 기능이 상황이 바뀌어서, 이번 주에 그렇지 않게 될 수도 있다. 주어진 리소스가 한정됐으므로, 유저 스토리를 개발하는 데 우선순위를 고려해야 한다. 따라서, 이번 주는 저번 주와 다른 개발 로드맵을 가져야 한다. 이때, 서로 다른 스토리가 지나치게 의존하면, 유저 스토리 사이의 순위 변동이 어려울 수밖에 없다. 따라서, 하나의 스토리는 그 자체로 가치가 있어서, 다른 스토리와 독립적으로 존재할 수 있어야 한다.
Negotiable : 협상 가능한
특정 유저 스토리를 개발하는 데 여러 가지 방법이 있다. 책을 교환하는 서비스를 구현 중이고 '유저는 동네 친구와 책을 교환하기 위해, 상대방에게 연락한다.'라는 유저 스토리가 있다고 해보자. 상대방에게 연락하기를 위해 '실시간 채팅창'을 구현할 수 있고, 시간이 남는다면 '카톡으로 알림 보내기'도 함께 구현할 수 있다. 이처럼, 특정 스토리의 개발 규모는 비용에 맞춰 변화를 줄 수 있어야 한다.
Valuable : 가치가 있는
각 유저 스토리가 갖고 있는 기능의 가치는 '회사'가 아니라, '고객'이 평가한다. 고객은 특정 기능을 사용하면서 얻는 효익이 비용을 충분히 상쇄할 때, 이 기능(혹은 프로덕트)을 구매한다. 따라서, 유저 스토리도 '회사'가 아닌, '고객'의 관점에서 작성해야 한다. 기술적인 내용으로 유저 스토리를 쓰는 게 아니라, 비즈니스적으로 가치가 있을만한 형태로 작성해야 한다. 이를 통해, 어떤 기능이 고객 가치에 더 도움이 되고, 혹은 덜 도움이 되는지 한눈에 알 수 있다.
Estimatable + Small : 작고 측정 가능한
애자일에선 유연함을 강조한다. 개발 전에 추정한 리소스 추정치와, 실제 개발에 든 리소스를 계속 비교하고, 남은 이터레이션 기간 안에 고객에게 가치를 전달할 수 있는 기능 그룹을 구현할 수 있는지 판단한다. 만약 남은 기간 내에 현재의 기능 그룹을 구현하기 어렵다고 판단할 시, 이번 릴리즈 계획에 포함된 일부 기능의 규모를 줄이거나, 기능 그룹의 범위를 바꿔야 한다. 이처럼 유연함이 가능하려면, '추정 가능'이 전제가 돼야 한다. 이때 추정을 가능케 하기 위해선, 각 유저 스토리의 범위가 충분히 작아야 한다. 만약 범위가 매우 넓다면, 이걸 구현 완료하기까지 정확히 얼마나 걸리는지 예측하기 어렵다.
추정! 두뇌 풀 가동! (출처 : <SBS, 정신통일<Testable : 테스트 가능한
스토리가 잘 개발되어 제 기능을 하는지 알 수 있도록, 모든 스토리는 테스트가 가능해야 한다. 테스트 조건을 모두 충족시킨 걸 보고, 스토리를 잘 구현했는지 확신할 수 있다.
애자일과 유저 스토리 개념을 알았으니, 애자일스럽게 팀과 프로젝트를 운영하는 법을 다음 글에서 알아보자!
관련 아티클
http://www.yes24.com/Product/Goods/6289137
