스크럼을 이용한 게임 개발 Agile Game Development with Scrum

Reid Lee reid@socialinus.com

게임을 만드는 과정을 떠올려봅시다.

제일 먼저 뭘 해야 할까요? !기획을 먼저 할까요? !코딩은 기획이 끝나야 시작하나요? !테스트는 언제 해야 할까요? !기획이 중간에 바뀌면 어떻게 하죠?

지금 여러분은 ‘개발 프로세스’가 필요한 이유를 보셨습니다. 개발 프로세스는 절차를 이야기합니다.

이번에는 조금 다르게 묻겠습니다. 여러분이 만들고 있는 게임은 어떤 ‘개발 프로세스‘를 따르고 있나요?

모든 업무가 그렇듯이 소프트웨어 개발에도 프로세스가 있습니다.

폭포수 모델waterfall model 일의 흐름이 층을 이룬 폭포에서 물이 떨어지는 모습을 닮았어요.

요구사항 분석 설계 구현 테스트 유지보수

건물 한채를 지어봅시다. !- 거주자의 요구사항을 수집/분석하고 - 설계도를 그리고 - 미장하고 공구리쳐서 완성을 시킨 후, - 마감이 잘 되었는지 확인합니다. - 이후, 시공 업체는 지속적으로 유지보수하겠죠.

완공 된 아파트의 설계에 결함이 발견되었습니다. 부수고 다시 만들까요? !공구리를 치기 전에 설계가 완벽해야 합니다.

폭포수 모델은 공학 분야에도 잘 적용되어 왔습니다. 소프트웨어 개발에도 물론 문제 없습니다.

소프트웨어를 만들어봅시다. !- 고객 요구를 수집하여 기획서를 완성하고 - 코딩하여 구현 한 후, - QA 테스트를 거쳐 완성. - 이후 개발사는 지속적으로 유지보수합니다.

CRM, ERP... 폭포수 모델에 딱 들어맞는 프로젝트들입니다. !이들은 코딩을 시작하기 전에 설계가 완벽해야 합니다.

그렇다면...

(은근한 목소리로) 게임은 어떤가요?

게임은 기능이 아니라 재미를 설계해야 합니다. !기능은 누가 보아도 확실한 정답이 있지만, 재미는 보는 사람마다 다른 정답을 가지고 있습니다.

게임은 만들어 보지 않고 설계를 완성시키기 매우 어렵습니다.

지금까지의 개발 방법론으로는 문제가 해결되지 않습니다. !그 때, 소프트웨어 개발 전반에 걸쳐 새로운 바람이 불었습니다.

애자일 소프트웨어 개발 선언

!우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의

더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었

다:

!공정과 도구보다 서로의 상호작용을

포괄적인 문서보다 작동하는 소프트웨어를

계약 협상보다 고객과의 협력을

계획을 따르기보다 변화에 대응하기를

!가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것

들에 더 높은 가치를 둔다는 것이다.

게임에 빗대자면, !재미있는 게임을 만들기 위해 변화를 적극적으로 수용하고 더 많은 대화로 서로 협력하며 문서를 작성하기 보다 실제로 작동하는 게임을 만들어 확인하자.

애자일이 가져다 준 변화 !! 생산성이 향상되었다 ..... 87% 원하는 시점에 시장에 내놓게 되었다 ..... 86% 버그가 없어졌다 ..... 86% 비용이 절감되었다 ..... 63% !!http://www.versionone.com/pdf/stateofAgiledevelopmentsurvey.pdf

애자일이 가져다 준 변화: !!!!!!!!!2005년 waterfall software .... 72% scrum agile ..... 28% !http://yusufarslan.net/agile-and-scrum-really-better-waterfall

2013년 waterfall software ..... 22% scrum agile ..... 78%

폭포수 모델이 이전 단계가 완료되어야 다음 단계로 넘어갈 수 있었던 문제가 있었던 것에 반해서, !애자일은 이 일련의 과정을 잘게 나누어 여러번 반복합니다.

요구사항 수집 개발

피드백출시/유지보수

그리고 개발 프로세스로 ‘스크럼’을 제시합니다.

스크럼의 핵심: !

- 원활한 커뮤니케이션 - 반복 개발 - 테스트 가능한 결과물

자, 이제부터 스크럼을 게임 개발에 적용해서 차례대로 살펴봅시다.

제일 먼저 해야 할 것은 ‘프로토타이핑’입니다. !

이 아이디어가 정말 괜찮을까? 머리속에 머물던 궁금증을 실제로 풀어보는 과정입니다. !프로토타이핑이 성공하면 드디어 프로젝트가 킥오프됩니다.

게임이 갖출 기능들을 모아봅니다. !- 브레인스토밍처럼 추상적인 단계가 아니에요. - 기능을 구현하는데 걸리는 시간도 예측합니다. - 기능을 목록Product Backlog으로 정리해보세요.

PLANNING

출시일을 계산합니다. !- 예측한 시간들을 모두 더합니다. - 시간의 압박, 자금의 한계로 출시일을 당겨야 한다면, - 낮은 우선순위의 기능들을 제거합니다.

FINAL

릴리즈를 구상합니다. !- 완전한 형태의 결과물들을 만들어 내는 시점입니다. - 마일스톤으로 불리기도 합니다. - 각 릴리즈의 기능을 목록Release Backlog으로 정리해보세요.

FINALREL1 REL2 ALPHA CBT OBT

릴리즈를 스프린트로 쪼갭니다. !- 스프린트는 짧게는 2주에서 길게는 1개월 정도로 잡습니다. - 스프린트의 결과물은 완성된 형태로 동작하는게 중요합니다. - ‘기능’을 ‘태스크’로 쪼개어 목록Sprint Backlog으로 정리합니다.

REL1 REL2SP1 SP2 SP3

스프린트 플래닝Sprint Planning !- 지난 스프린트의 결과를 토대로 기획을 수정합니다. - 스프린트에 완성시킬 기능을 태스크로 쪼갭니다.

SP1 SP21 2 3 4 5 6 ...

스프린트 플래닝

스프린트 리뷰Sprint Review - 결과물을 테스트하고 피드백을 받습니다. !회고Retrospective - 이번 스프린트에서 좋았던 점, 아쉬웠던 점을 이야기합니다. - 다음 스프린트에서의 각오를 이야기합니다.

SP1 SP21 2 3 4 5 6 ...

스프린트 리뷰 / 회고

스크럼은 매일마다 커뮤니케이션을 합니다. !- 매일 스크럼 회의를 합니다. - 한 명씩 돌아가며 한일, 할일, 애로사항을 이야기합니다. - 하고 있는 일을 이야기하는게 아니에요. - 일정에 지장을 주는 애로사항은 바로바로 꺼내놓으세요.

1 2SP1MS1

번다운 차트burndown chart !- 스크럼은 현재 작업의 진척 상황을 함께 공유합니다. - 스크럼은 작업의 예측 완료 시각과 실제 완료 시각을 압니다. - 예측에 비해 원활한지 문제가 있는지 쉽게 파악됩니다.

남은 작업 시간 (hour)

진행 일자

프로젝트 마감 시점에 남은 작업 시간이 0이 되는, 가장 이상적인 기울기입니다.

번다운 차트burndown chart !- 팀의 역량에 비해 너무 과도한 일을 하고 있나요? - 다음 스프린트에서는 일정 예측에 조금 더 신경 써봅시다.

남은 작업 시간 (hour)

진행 일자

번다운 차트burndown chart !- 팀의 역량을 과소평가 한 건 아닌가요? - 스프린트가 반복 될 수록 일정 예측은 점점 정밀해집니다.

남은 작업 시간 (hour)

진행 일자

여기까지 스크럼이 어떤 방식으로 동작하는지 알아봤습니다. 그런데 잠깐 고민해봅시다. !!!!!!!!스크럼은 우리에게 무얼 강조하고 있는건가요?

스크럼이 추구하는 핵심 가치 세 가지를 다시 돌아봅시다: !- 원활한 커뮤니케이션 - 반복 개발 - 테스트 가능한 결과물

침묵은 위기, 서로 좀 더 이야기를 많이 하자. 기획 변경을 두려워하지 말자. 항상 개발중 개발중 개발중 하지 말고, 실제로 돌아가는 게임을 만들어보자.

스크럼은 사실 이런 가치를 실현하기 위한 도구 일 뿐입니다.

스크럼은 무엇이고 어떻게 하는 것인가를 알아보았습니다. !이번에는 스크럼이 프로젝트를 어떻게 변화시킬 수 있는지 살펴봅시다.

나는 누구인가 여기는 또 어디인가 !

!!!!!!!!!!팀원 누구라도 내가 지금 어느 위치에 서있는지 알 수 있습니다. 비전은 언제나 모두에게 동일하게 공유되어야 합니다.

전력 질주를 합니다. !

!!!!!!!!!스프린트와 같은 단기 목표는 전력 질주를 가능하게 합니다. 장기 목표만으로 진행되는 프로젝트는 갈수록 지치게 마련입니다. 스프린트 리뷰마다 목표 달성을 기념하는 파티를 해보세요!

야근 없이도 잘 굴러갑니다. !

!!!!!!!!!!!출시 전 철야 작업은 반드시 거쳐야 하는 통과 의례가 아닙니다. 지속적으로 출시에 포함 될 기능을 구상하고 일정을 쪼갭니다. 분할 정복Divide and Conquer은 일정을 준수하기 위한 효과적인 방법입니다.

눈총받지 않고 기획을 변경합니다. !

!!!!!!!!!무턱대고 일정 중에 기획을 변경하면 팀원들은 멘붕에 빠집니다. 기획의 변경은 스프린트의 결과물을 토대로 진행합시다. 팀원들의 공감을 받는 기획 변경은 프로젝트 성공의 청신호입니다.

장애물들을 각개 격파합니다. !!!!!!!!!!!!스크럼 회의에서 가장 중요한 것은 작업 내용 공유가 아닙니다. 일정에 차질을 주는 애로사항을 팀에 공유하는 것이 가장 중요합니다. 프로젝트가 실패하는 큰 원인은 그 누구도 리스크를 이야기하지 않기 때문입니다.

순항중인지 폭풍우를 만났는지… !!!!!!!!!팀원들 모두가 프로젝트의 진행 상황을 잘 이해하게 됩니다. 잘 해내고 있는지, 혹시 암초를 만나서 기우뚱거리고 있지는 않은지… 번다운 차트는 프로젝트의 진행 상황을 한 눈에 보여주는 최고의 도구입니다.

일정을 정밀하게 예측합니다. !!!!!!!팀마다의 역량은 서로 다르게 마련입니다. 스프린트 플래닝과 회고를 반복하면서 팀의 능력에 맞는 일정 예측이 가능해집니다.

이처럼 스크럼은 여러가지 장점을 가져다 줍니다. 이제 단점을 이야기 할 때 인가요?

스크럼의 단점은 ‘어렵다’입니다.

스크럼이 추구하는 바를 이해하는 것은 생각처럼 쉽지 않습니다. !아침에 쑥스럽게 작업 보고 하는 것, 포스트잇이 많이 소비되는 것, 그냥 귀찮은 것 !으로만 인식하고 있다면 스크럼은 시간 낭비 일 뿐입니다.

하지만, 너무 걱정하지 마세요. 그런 상황은 어느 팀에서나 일어난답니다. !이를 극복하기 위해 희생하는 사람이 바로 ‘스크럼 마스터’입니다. !

스크럼 회의에서 팀원들이 리스크를 언급하는게 왜 중요한지 설명 해주어야 합니다.

스크럼은 경험을 통해서 얻어진 개발 프로세스입니다.

경험 많은 사람들은 소프트웨어 개발이 왜 실패하는지, 왜 성공하는지 이해합니다.

스크럼은 우리에게 ‘경험’을 선사합니다.

스크럼은 경험이 많지 않은 팀에게 그런 시행 착오를 겪지 않도록 도와줍니다. !

경험은 열정으로 극복되기도 합니다. 그런 팀에게 프로세스는 거추장스러운 장애물이 되기도 합니다.

한번 만 더 가져와봅니다. !- 원활한 커뮤니케이션 - 반복 개발 - 테스트 가능한 결과물

팀원들간의 원활한 소통으로 리스크를 제거하고 테스트가 가능한 결과물을 지속적으로 만들어 우리가 맞는 방향으로 가고 있는지 체크하며,

이 과정을 반복하여 최종 목표를 향해 나아가야 합니다. !!!!!!!!

마치 유도탄처럼!

스크럼, 해볼 만 하지 않나요?

긴 발표를 함께 해주셔서 고맙습니다. !

-끗-

스크럼에 대해 제가 작성한 다른 자료들이 있습니다: !'스크럼, 이걸 왜 하나요?' 블로그 글 ‘스크럼, 이걸 왜 하나요?’ 프리젠테이션 자료