[세미나] 모바일 소프트웨어 개발을 위한 Agile 방법론 ★★★★☆

세미나 정보

일시 : 2013.9.5 - 2013.9.6

장소 : T-Academy

강사 : 정대선

세미나 참가 동기

경력이 쌓이면서 업무에서 프로그래밍 외적인 부분이 점점 늘어나기 시작했다. 업무를 스스로 관리하는 것은 물론, 동료들과의 협업과 조율이 중요해지기 시작했다. 하지만, 이런 부분은 책을 읽어서 생기는 능력이 아니란걸 깨닫고는 경험이 많은 사람들에게 조언을 구하고 새로운 기술들을 찾기 시작했다.

그렇게 Agile 이라는 프로젝트 방법론을 찾게 되었고, 지난 프로젝트에서 느꼈던 불편함을 해결 해줄 것 같은 느낌에 많은 관심을 갖게 되었다. 많은 웹사이트를 둘러보던 중 2년 전 좋은 기억을 갖고 있는 T-Academy 에서 Agile에 대한 강좌를 발견하여 참여하게 되었다.

세미나 내용

Android 개발자가 될 수 있었던 가장 큰 계기는 T-Academy를 통해서 였다. 3학년 2학기. 졸업작품을 당장 만들어야 했던 나는 개발보다 기획이 문제였다. 학교에서 배웠던 지식은 모두 개발을 하기 위한 스킬이였고, 기획에 대한 지식이 전혀 없었던 나는 우연히 알게된 T-Academy를 통해서 '앱 비즈니스 기획' 과정을 수강하게 되었다. 무료로 진행되지만 퀄리티있는 T-Academy의 강좌에 푹 빠져 프로그래밍 과목도 수강하게 되었다.

당시 아이폰과 안드로이드 두 과목에 모두 신청을 하였는데, 아이폰 과정은 1주, 안드로이드 과정은 3주 과정이었다. 안타깝게도 두 과정이 겹치는 바람에 좀 더 많은 시간 배울 수 있는 안드로이드 과정을 수강하게 되었다. 안드로이드와의 만남은 그때부터 지금까지 계속되고 있다.

졸업과 취업을 앞둔 3학년 2학기 겨울방학. 마지막이라는 각오로 배움에 불태웠던 그 장소를 다시 찾으니 학생이 된 것 같아 설레였다.

프로젝트. 누구를 위함인가?

작은 앱을 만드는 프로젝트라도 실무에서는 PM과 QA, 기획자, 디자이너, 서버개발자, 앱개발자 등 해당 포지션에 한명씩만 하더라도 최소 6명의 인원이 된다. 6명의 인원이 한가지 목표를 향해 3~6 개월동안 전력질주를 하기는 쉬운 일이 아니다.

가장 쉽고 빠른 효과를 보기 위하여 대부분의 프로젝트가 택하는 방법은 PM을 중심으로 한 폭포수 방식의 프로젝트다. 폭포수 모형은 기획, 디자인, 개발, 테스트 그리고 출시를 순서로 하는 전통적인 프로젝트 방법이다. 폭포수 모형은 각 포지션에서의 완벽함을 전제조건으로 한다. 기획, 디자인, 개발이 모두 한번에 완벽한 업무를 마쳐야 테스트 과정에서 처음으로 돌아가는 일이 적으며, '일정' 을 지킬 수 있게 된다.

안타깝게도 사람은 완벽한 업무를 할 수 없고 폭포수 모형의 마지막 단계인 테스트 단계에서 대부분의 오류를 찾아낸다. 결국 프로젝트 초기에는 넉넉하던 시간이 프로젝트 마지막에는 모두가 힘든 상황이 되고, 프로젝트는 늘 힘들게 끝이 나게 된다.

Agile. 만병통치약이 아니다.

Agile(이하 애자일)은 '날렵한, 민첩한, 기민한 등' 의 뜻을 가지고 있다. 사실, 애자일에 대한 강의를 듣기 전 각종 웹사이트 자료를 읽어보면서 애자일에 대한 환상이 쌓여갔다. 다양한 툴과 시스템으로 프로젝트를 좀 더 빠르고 완벽하게 해낼 수 있게 돕는 것이라 착각하였다. 하지만 이틀동안 애자일을 교육하면서 강조한 애자일의 핵심은 이것이다.

"빠르고 잦은 피드백"

권투로 따지면 빠른 잽. 축구로 따지면 빠르고 짧은 패스다. 빠르고 짧은 주기로 제품의 릴리즈를 많이 가져가며, 이를 통해 제품에 대한 피드백을 많이 받아 제품의 질을 상승시키는 것이다.

많은 방법 중 애자일이 피드백의 주기와 횟수를 핵심으로 선택한 이유는 다음과 같다.

<프로젝트의 4개 축>

프로젝트에는 4개의 축이 있는데, 기간, 기능, 비용, 품질이 그것이다. 이 4가지 축을 모두 고정시킬 수는 없으며 한 가지 축을 늘리면 나머지 축은 줄어들게 되어 있다.

흔히 프로젝트에서 무조건 고정되어야 하는 축은 '비용' 과 '기간' 이다. 고객은 이 두가지 축을 고정하며 기능 추가를 요구한다. 이 기능 추가는 프로젝트 내내 이루어지며, 특히 개발이 완료된 테스트 기간에 집중된다. 

한 사이클로 진행되었던 폭포수 모델이 급하게 하루, 이틀내로 기획, 디자인을 거쳐 개발까지 완성되기 때문에 당연히 제품의 속도 저하, 자잘한 버그 등의 품질 문제가 생기며 약속한 프로젝트 기간이 되면 결국 낮은 품질의 제품이 출시되는 것이다.

결국 프로젝트가 실패하는 가장 큰 원인 중 하나는 기능의 추가와 변경 등의 문제다. 하지만 고객의 요구조건을 프로젝트의 기획단계가 끝났다는 이유로 거절 할 수도 없는 노릇이다. 때문에 애자일 방법론에서는 다음을 인정한다.

"요구사항의 불확실성을 기본 전제로 인정한다."

요구사항이 변한다면 나머지 축 또한 변하게 된다. 하지만 어느 하나 줄이거나 늘릴 수는 없는 것이 현실이다. 때문에 고객의 불확실한 요구를 확실하게 만들기 위해서 피드백을 좀 더 빠르고 많이 가질 필요성이 생긴다.

이렇게 되면 고객은 프로젝트의 진행 상황을 문서가 아닌 제품으로 받아보며 자신이 상상했던 제품과 실제 제품을 비교하여 피드백을 주고, 프로젝트는 고객의 요구를 좀 더 정확히 구현하여 결과적으로 제품의 질을 높일 수 있게 되는 것이다.

이렇게 애자일은 기존의 프로젝트 방법론을 모두 깨는 아주 획기적인 방법론이 아니라 현재 가지고 있는 자원을 좀 더 효율적으로 사용함으로써 좀 더 높은 퀄리티의 제품을 만들어 내는 것이다.

스크럼과 프로젝트를 돕는 효과적인 툴.

애자일이 나오게 된 배경과 실체를 알게 되면서 놀라움과 실망감을 동시에 가진 것이 사실이다. 그저 똑같은 방법을 좀 더 자주 함으로써 결과를 다르게 얻는 것이 가능할지 의문이었다.

우리는 애자일 프로세스 중 가장 널리 쓰이는 스크럼을 통해 애자일을 사용해보기로 하였다.

<스크럼 프로세스 / 출처 - http://daddycat.blogspot.kr/2011/06/scrum.html>

스크럼은 위와 같은 프로세스를 가진다. 

Product Backlog는 제품의 모든 기능을 명시한다. 즉, 프로젝트에서 고객이 원하는 기능이 모두 명시되는 것이다.

Sprint 는 2-4 주 동안 스크럼 팀이 프로젝트를 수행하는 시기이다. Sprint Backlog는  Sprint 기간동안 제품의 기능을 Product Backlog에서 선택한 것이다. 스크럼 팀은 Sprint 기간 동안에는 Sprint Backlog 의 기능만 완성시키면 된다.

Sprint 기간동안에는 일일 스크럼을 통해 업무를 시작하기 전 아침 15분씩 해당 Sprint Backlog를 확인하고 Sprint 에 집중하기 위한 시간을 가진다.

여기서 핵심은 Sprint 기간 동안 스크럼 팀은 어떤 간섭도 받아서는 안된다는 것이다. 해당 Sprint 가 끝나면 스크럼 팀은 테스트가 가능한 제품을 만들어 다음 Sprint 를 위한 회의 및 해당 Sprint 의 회고를 하게 되고 이 시기에 고객은 제품을 빠르게 받아 볼 수 있다.

스크럼은 프로젝트를 여러번의 Sprint 로 나누어 애자일의 핵심인 "빠르고 잦은 피드백" 을 실현한다.

스크럼의 Sprint 를 돕는 몇가지 툴을 소개한다.

사용자 스토리

사용자 스토리는 쉽게 말해 프로젝트의 요구 조건을 구현하기 쉽게 잘게 나누는 작업이다. 프로젝트가 시작되면 많은 문서가 만들어지는데, 모든 문서를 외울 수 없거니와 계속해서 문서만 볼 수는 없다.

때문에 요구 조건을 보기 편하게, 그리고 머릿 속에 그리기 위해 사용자 스토리 과정을 사용한다.

<애자일 교재와 사용자 스토리 포스트잇. 그리고 요구조건 문서>

고객의 요구 조건을 다음과 같은 형식으로 포스트잇에 정리한다.

As a - 해당 스토리를 통해 가치를 얻는 사용자

I want - 스토리를 통해 얻고자 하는 가치 및 목표

So that - 목표를 달성하기 위해 취할 행동

수업에 사용된 한가지 예를 들어보겠다. 태블릿 e-book 교과서 앱을 만드는 프로젝트에서의 기능이다. 고객은 요구사항을 정하는 미팅에서 다음과 같이 이야기 한다.

'e-book 을 사용하면서 실제 공부하는 것처럼 내용에 마킹을 할 수 있었으면 좋겠어요. 그래야 언제든지 다시 중요한 부분을 확인 할 수 있죠.'

정리하면 고객은 e-book 사용자(학생)가 제품을 사용하다가 중요한 부분을 언제든지 다시 볼 수 있도록 마킹 기능을 원한다. 이를 사용자 스토리로 정리하면 다음과 같다.

<사용자 스토리>

이렇게 모든 요구사항을 사용자 스토리화 한다. 단, 이렇게 사용자 스토리를 만드는 것에도 몇 가지 법칙이 있는데 다음과 같다.

- 고객의 입장에서 작성한다.

- 작은 스토리로 나눈다.

- 한 스토리가 독립적으로 전달 가능한 가치를 가져야 한다.

- 닫힌(명확한) 스토리를 작성한다.

- 되도록 인터페이스를 배제한다.

플래닝 포커

위처럼 만든 사용자 스토리를 이용하여 모든 요구 조건을 나누었다면 이제 요구 조건을 구현하는데 걸리는 기간을 추정해야 한다. 프로젝트를 추정하는 방법은 LoC(Line of Code), 기능점수, CoCoMo, 3점 추정 등이 있는데 추정은 상대적인 작업이라 스크럼팀 모두가 공감 하는 추정을 하기는 쉽지가 않다.

또한 관계 없는 정보의 제공, 스펙 문서의 길이, 여분의 요구사항, 준거 효과 등 스크럼 팀의 심리를 흔들어 프로젝트 추정에 방해를 하는 요소들이 많다. 이 심리적 활동을 객관적으로 돕기 위한 방법으로 '플래닝 포커' 가 있다.

플래닝 포커는 0, 1/2, 1, 2, 3, 5, 8, 13, 20, ? 카드로 구성되며 피보나치 수열이다. 플래닝 포커를 사용하기 위해서는 기준이 되는 하나의 기능을 정하여 '1' 이라고 명시한다.

1이라 정해진 기능은 스크럼 팀 모두가 파악이 가능한 기능이어야 하며, 해당 기능보다 2배 복잡하면 2, 3배 복잡하면 3 식으로 숫자를 붙이는 방식이다. 0은 이미 완료 되었거나 당장 해결 할 수 있는 기능이며, 20은 사용자 스토리가 잘못 작성된 경우로 더 잘게 나눠야 한다. ?는 기능에 대한 정의가 부족한 경우에 사용한다.

플래닝 포커를 사용하는 방법은 다음과 같다. 스크럼 팀은 모두 플래닝 포커를 가진 뒤, 해당 기능에 대하여 생각 할 시간을 갖는다. 생각이 정리되었다면 해당 카드를 뒤집어서 내놓고 동시에 오픈한다. 가장 낮은 숫자를 낸 사람과 가장 높은 숫자를 낸 사람이 자신의 생각을 이야기 하고 두, 세 번의 과정을 거치면 납득 할 만한 결과가 나온다. 그렇게 정해진 추정은 사용자 스토리의 우측 상단에 명시하여 모두가 볼 수 있게 한다. 

이 과정을 거치면 프로젝트의 모든 기능에 대해 모두가 납득 할 만한 추정의 결과가 나오게 된다. 

스플린터의 실행 그리고 회고

요구조건을 모두 세분화 하고 해당 기능들의 기간을 모두 추정하였다면 스플린터를 할 준비가 모두 끝이 났다. 이제 이 자료들을 가지고 고객과의 회의를 통해 스플린터의 주기와 해당 스플린터의 분량을 정해 수행하면 된다.

주의해야 할 점은 고객의 권한과 스크럼 팀의 권한이 다르다는 점이다. 고객은 기능의 우선 순위를 스크럼 팀은 기능의 양을 정할 권한이 있다. 물론 프로젝트 전체 일정은 준수한다는 전제 하에서 말이다.

그렇게 스플린트에 사용 될 스플린트 백로그를 정했으면 2-4주 동안 스플린트를 하면 된다. 단, 스플린트 기간동안 스크럼 팀은 스플린트에만 집중한다. 스플린트가 끝나기 전까지 스크럼 팀을 방해해서는 안된다. 또한 스크럼 팀은 매일 아침 15분 스탠딩 회의를 통해 스플린트의 방향을 제시하고 집중 할 수 있는 시간을 갖는데, 문제점이 발생되면 즉시 보완하도록 한다.

스플린트가 끝나면 스크럼 팀은 사용 가능한 제품을 완성해야 하고, 고객은 제품을 테스트 하여 자신의 요구 사항과 다른 점을 피드백 한다. 그렇게 받은 피드백을 가지고 스크럼 팀은 회고의 시간을 갖는데, 회고의 목적은 잘한 부분은 계승하고, 문제점을 개선하기 위함이다.

<TDD 실습 중>

처음 만난 애자일. 그리고 제품.

애자일은 자주 빠르게 피드백을 받는 것이 핵심인데, 사실 실무에서도 자주 빠르게 피드백을 받는다. 단, 그 시기가 프로젝트 마지막에 몰려있는 것이 유일한 차이점이다. 

애자일은 사실 귀찮은 부분이 있기도 하다. 좀 더 자주 릴리즈를 하게 되면 늘 피곤 할 수도 있고, 일을 더 많이 하게 될 수도 있다. 또한 우리나라의 대부분의 IT 산업인 SI 프로젝트와는 맞지 않는 부분이기도 하다. 때문에 좋은 방법론이라고 해서 전체를 도입 할 생각은 없다. 어차피 모든 프로젝트는 상대적이기 때문이다.

하지만 제품의 질을 높이고자 하는 프로젝트 참여자라면 애자일의 핵심에는 공감 할 것이다. '자주 빠르게 피드백을 받아 제품의 질을 향상시킨다'

빠르고 많은 피드백. 즉, 좀 더 빠르고 많은 커뮤니케이션이다. 애자일이 배우다 보면 특별하게 느껴지지 않는다면 상당히 프로의식이 강한 개발자라고 생각된다. 애자일은 철저히 제품의 질을 향상시키기 위한 방법론이다. 이미 애자일과 비슷하게 프로젝트를 진행하고 있다면 제품의 질을 높이기 위해 노력을 하고 있다는 증거다.

제품의 질을 생각하는 프로에게, 애자일은 좋은 방법론이라 생각한다.