애자일, 워터폴, 스크럼, 칸반.... 이게 다 뭐람?
제품 개발 방법론
어떤 제품을, 왜 만들어야 하는지 그리고 그 제품을 어떻게, 누구와 만드는지 알았다면, 이 전체를 어떻게 효율적으로 관리할 수 있을까? 정해진 규칙과 원리 없이 그때그때 상황에 따라 처리한다면 많은 문제가 생길 것이며 또한 이를 이끄는 PM/PO에 대한 신뢰도도 떨어질 것이다. 이 때문에 나온 것이 바로 제품 개발 방법론이라는 것인데, 아마 스타트업에 관심있는 누구라면 애자일이라는 단어를 들어봤을 것이다. 쿠팡, 배달의 민족, 토스 등 요즘 핫한 기업들이 모두 애자일 방법론을 도입하여 성장에 성장을 거듭하고 있다. 그렇다면 애자일은 무엇이고, 제품 개발 방법론에는 어떤 것들이 있는지 알아보자.
워터폴(Waterfall) vs 애자일(Agile)
워터폴 방식은 전통적인 개발 방법론으로, "요구분석 > 기획 > 디자인 > 개발 > 테스트 > 출시"의 과정을 순서대로 진행된다. 폭포가 떨어지는 식으로 순차적인 단계를 밟는다고 하여 폭포수 방식이라고 불린다. 일반적으로 요구사항 분석 및 기획 단계에서 모든 걸 100% 예상할 수가 없다. 이럼에도 불구하고, 워터폴 방식은 중간에 수정이 어렵고, 하나의 단계가 완료되어야 다음단계로 넘어갈 수 있어, 피드백을 즉각 반영하기가 힘들다. 결국 해결되어야할 문제들이 처리되지 않은 채 엉키게 되고, 요구사항도 만족시키지 못한 상태에서 제품 출시가 이뤄질 수밖에 없다.
그럼에도 불구하고 아직 워터폴 방식을 따르는 기업이 많은 이유는, 팀 규모에 상관없이 따르기가 쉽고, 필요한 예산과 자원이 초기에 확정되어 있어 예상되는 결과와 리스크를 통제하기가 쉽기 때문이다. 또한 요구사항이 정의되어 있기 때문에 실행하기가 수월하며, 목표 변경이 자주 일어나지 않는다.
제품 개발 방법론 1. 워터폴(Waterfall)애자일은 요구 사항들을 민첩하고 기민하게 충족시켜 개발하자는 방법론이다. 아주 작은 핵심 요소만으로 제품 혹은 샘플을 만들어서 소비자 반응을 확인하고 점점 살을 붙여 나가는 방식으로, 사용자의 반응을 봐가며 진행 여부를 결정해야 하는 경우에 적용된다. 때문에 애자일 프로세스는 언제든지 계획이 변경될 수 있다는 것을 전제로 하며, 최대한 짧은 기간에 한 단위의 개발 사이클을 완료하는 것을 목표로 한다. 또한 개발자와 고객 간의 피드백과 구성원 간의 활발한 소통 및 상호 협력을 통해 제품의 지속적인 업데이트가 가능하다.
하지만 애자일 조직의 구성원은 잦은 변화에도 빠르게 적응하여 업무를 진행할 수 있어야 하며, 팀원 간의 커뮤니케이션을 어려워하지 않아야 한다.
제품 개발 방법론 2. 애자일(Agile)워터폴과 다르게 애자일은 실행하는 방법이 여러 가지가 있는데, 바로 스크럼과 칸반이다. 다시 말해, 스크럼과 칸반은 애자일을 실현하는 도구이다. 1) 스크럼은 스프린트 기반으로 애자일 방법론을 실행하고, 2) 칸반은 WIP(Work In Process)를 제한하여 애자일 방법론을 실행한다. 그럼 이제 스크럼과 칸반에 대해 자세히 살펴보자.
스크럼(Scrum)
스크럼은 소규모의 다기능 팀이 반복적인 개발 주기인 스프린트를 기반으로 제품을 개발하는 프레임워크이다. 스크럼 프레임워크가 작동하는 원리는 아래와 같다.
1) 우리는 고객을 잘 모른다.
2) 그렇기 때문에 빠르게, 그리고 자주 고객에게 릴리즈하고 새롭게 발견해야 한다.
3) 그렇게 여러 번의 가설 검증 단계를 거치고,
4) 우리가 진짜 필요한 것이 무엇인지, 피해야 할 것이 무엇인지 알아내야 한다.
5) 그렇게 우리는 이해관계자들에게 더 빠르게, 더 잘 그들이 원하는 것을 전달할 수 있다.
위의 원리를 바탕으로, 스크럼이 어떻게 진행되는지 자세히 알아보자. 아래의 그림을 따라가면서 읽으면 쉽게 이해할 수 있다.
스크럼 프레임워크 (출처: 워킹어스)제품 책임자(Product Owner)는 기업의 비전과 성장 로드맵에 따라 해야 할 일들의 목록(Product Backlog)을 작성하고, 이 목록들을 실행할 일정(Release Planning)을 세운다. 이후, 모든 팀원이 모여 실행할 업무 계획을 공유(Sprint Planning)하고, 스프린트 동안 해야 하는 일들(Sprint Backlong)을 선정한 후, 스프린트를 시작하게 된다.
스프린트 진행 중에는 데일리 스크럼을 통해 팀원들이 모여 현재 일의 진행상황과 직면한 문제를 공유하며 함께 업무를 완수하여 매 스프린트마다 결과물(Increment)을 산출하게 된다. 마지막으로 결과물에 대한 스프린트 리뷰와 팀원들 간의 회고 시간을 가지면서 한 스프린트를 마친다.
프로덕트 오너(PO, Product Owner)
그럼 스크럼 프레임워크에서의 PO는 어떤 역할을 할까? 스크럼 가이드를 통해 알아보자. 스크럼에서의 PO는 스크럼 팀의 결과물의 가치를 극대화하는 책임을 갖는다. 제품에 대한 요구사항 즉 백로그(Backlog)를 작성하는 주체로서, 개발할 제품에 대한 모든 요구사항의 오너쉽을 가지게 된다. 때문에 어떤 백로그부터 개발을 시작할지 우선순위를 정하는 유일한 사람이다. 따라서 백로그를 관리하는 것 외에도 다음의 사항도 함께 고려되어야 한다.
- 프로덕트 목표를 세우고 명쾌하게 소통하는 것
- 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
- 프로덕트 백로그 아이템을 우선순위에 따라 정렬하는 것
- 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것
PO는 위에 언급된 일을 직접 하거나 위임하고, 어떤 식으로든 최종 책임을 져야 한다. 또한 팀에 소속되어 있지만, 이해관계 당사자들(고객, C레벨 등등)과 대화를 해야 하며, 외부의 압력을 관리하여야 하는 사람이다. 때문에 팀원들은 PO의 결정을 존중하여 성공적인 프로젝트의 완료로 이끌 수 있게 도와야 한다. 동시에 PO 역시 팀원들의 목소리에 귀를 기울여 일정, 리스크/이슈를 해결하며, 우선순위를 결정해야 한다.
스프린트
스프린트란 위에서 언급한 것처럼 반복적인 개발 주기를 말한다. 꾸준하게 스프린트를 진행하기 위해서 1주에서 한 달 기간으로 진행한다. 스프린트 기간 동안에는
- 스프린트 목표 달성을 저해하는 변경을 해서는 안 된다.
- 품질을 떨어뜨려서는 안된다.
- 필요한 수준까지 프로덕트 백로그를 정제해야 한다.
- 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상할 수 있다.
아래와 같이 PO는 팀원 간의 다양한 방식의 소통을 통해 스프린트를 진행하며, 프로덕트 목표를 달성하기 위해 필요한 모든 업무를 수행해야 한다.
- 스프린트 계획 회의(Sprint Planning Meeting) :
스프린트를 시작하는 날, 목표와 스프린트 기간 동안 할 업무를 계획
- 데일리 스크럼 회의(Daily Scrum Meeting) :
매일 모든 팀원이 짧게 어제한 일과 오늘 할 일에 대해 공유하는 시간
- 스프린트 리뷰(Sprint Review Meeting) :
제품 릴리즈 및 스프린트를 진행하면서 느낀 개선점, 잘한 점, 문제점 등을 공유
PO는 직접 작업을 진행하기 보다는 사람 리소스를 잘 활용하여 해야할 일을 성공적으로 마칠 수 있게 해주는 역할을 하는 것 같다. 때문에 상대방에 대한 이해와 커뮤니케이션 능력이 필수일 듯 싶다. 권한은 없지만 책임은 져야하는 사람. 또한 스프린트가 올바른 방향으로 갈 수 있도록 다양한 회의를 주관해야 해야 한다.
칸반(Kanban)
칸반의 핵심은 WIP(Work In Progress)의 제한이다. 즉, 동시에 개발이 진행될 수 있는 아이템의 수를 제한하여, 업무의 병목 현상과 리소스 낭비를 처리할 수 있도록 돕는데 목적을 두고 있다. 이를 위해 칸반 보드에 팀과 조직의 작업을 시각화하여 작업의 흐름을 파악한다.
우선순위가 낮은 이슈를 아래에 배치하고, 해당 이슈의 작업이 끝나면 다음 이슈를 진행한다. 스크럼처럼 언제까지 처리해야 한다는 종료일이 없다. 그래서 기한 없이 백로그에 해야 할 작업이 쌓이고, 연속적인 일의 흐름에서 급한 작업 단위 순서대로 In Progress로 칸을 옮겨 처리한다. 이때, In Progress에 넣을 수 있는 이슈 카드를 제한시키는 것이다.
칸반애자일(Agile) vs 워터폴(Waterfall) vs 스크럼(Scrum) vs 칸반(Kanban)
그럼 우리 조직은 어떤 개발 방법론을 적용해야 하는 것일까? 힙한 기업들이 사용한다는 애자일? 그럼 스크럼? 칸반? 뭐, 어쩌라고. 첫 번째로 애자일과 워터폴 방식 중에서 제품 개발 방식을 선택한 후, 만약 애자일이 선택된 경우, 애자일을 실행할 도구로 스크럼과 칸반을 선택하면 된다.
먼저 애자일과 워터폴 중에서 고려할 때는 아래와 같이 3요소를 고려한다.
- 스코프: 업무 범위가 얼마나 되는가 (무슨 기능을 만들어야 하는가)
- 스케줄: 투입 가능한 시간이 어떻게 되는가, 시간이 얼마나 있는가, 기한이 언제인가
- 리소스: 투입할 수 있는 리소스(돈과 자원, 사람 등)가 얼마나 있는가
스케줄과 투입 가능한 리소스의 경우 대부분 제한적이기 때문에 요구사항의 범위(스코프)에 따라 개발 방식이 결정될 가능성이 높다. 개발 범위가 고정적이고 개발 기간 동안 변화가 될 가능성이 낮을 경우 워터폴 방식으로 개발해도 무방하나 개발 범위가 유동적이고 개발 기간동안 고객의 요구사항이 유동적인 경우 애자일로 개발하는 방식을 검토하는 것이 좋다.
이후, 위의 기준대로 애자일을 선택했다면, 애자일 실행 도구로서 칸반과 스크럼 중 무엇이 적합한지 어떻게 결정할까? 칸반은 시간제한 상관없이 전체적으로 개발이 지속적으로 흐르는지 확인이 가능하고, 스크럼은 정해진 시간 내에 모든 작업이 스프린트 별로 진행되고 있는지를 확인할 수 있다. 따라서 작업을 완료해야하는 시간이 정해져 있고, 확실한 계획이 있다면 스크럼을, 이것이 아니라 작업의 상태, 진행상황, 문제를 파악하는 것이 주 목적이라면 칸반을 선택하면 된다.
애자일(Agile) vs 워터폴(Waterfall) vs 스크럼(Scrum) vs 칸반(Kanban)