이 책은 애자일 방법론 중 스크럼, XP, 린을 소개하며 이를 적용하는 방법을 소개한다. 게임 개발이라는 특수한 환경에서 애자일 실천방안이 어떻게 적용되는 확인해준다.
🎈 1. 서론
🕹 1.1 게임 개발자의 변화
-
비디오 게임 초창기에는 아티스트, 기획자, 프로그래머 직군의 구분이 필요하지 않았다
오직 한 가지 게임을 위해서 하드웨어가 개발되었고, 때문에 전기기사가 개발자의 역할을 대신하게 되었다. 기술이 발전함에 따라 하나의 하드웨어에서 다양한 소프트웨어가 탑재된 게임들이 증가하기 시작되었다. 게임 개발자는 구현하는 프로그래머가 되었다.
=> 게임 개발 초기에 사용된 모델은 하드웨어 능력에 맞추어졌다. 때문에 하나의 하드웨어에 탑재되는 카트리지와 같은 현재의 소프트웨어 기능의 게임들이 즐비했고, 공장형식으로 게임들을 찍기 시작했다.
-
하드웨어의 성능이 날이 갈수록 증가함에 따라 그 성능을 맞춘 게임을 개발하기 위한 제작 비용이 증가하기 시작했고 더이상 게임 개발은 혼자서 할 수 없는 일이 되었다. 커져가는 위험을 줄이기 위해 게임 개발 방법론에 소프트웨어 방법론의 바이블과 같은 워터폴 모델을 도입했다(윈스턴 로이스)
=> 오늘날 처럼 다양한 직군이 생기게 되었다. -
하드웨어의 성능은 무어의 법칙을 따르지만 게임 제작 도구나 프로세스는 그렇지 못했다. 때
문에 인력들을 무차하게 투입시켰고 결과적으로 투입 노동력의 비대해졌다.
=> 시장의 성장 보다 게임 제작에 들어가는 노력이 커지게 되었다. -
매번 히트 게임을 만들어 낼 수 없기 때문에 게임 제작 비용을 절감하는 방법과 시장 출시 훨씬 전부터 큰 실패를 미리 발견할 수 있는 방법을 찾아야 한다.
비용이 줄이기 위해 리스크가 작은 상업적인 게임들의 시도만 이루어졌고, 이것은 게임시장의 콘텐츠의 단순화로 이루어졌다. 하지만 내부에서는 가장 적은 비용으로 최대의 효과를 누리기 위해 크런치가 성행하게 되었고 이것은 게임 회사들의 뿌리깊은 악순화를 만들어 냈다. 때문에 능력있는 개발자들은 점차 산업을 떠나게 되었다.
" 산업의 변화 함께 게임 개발에도 그에 최적화된 개발 프로세스의 연구가 필요해졌다. "
🎮 2. 애자일 개발 그리고 게임 개발
2.1 게임 개발이 어려운 이유
- 80년대들어 폭포수 개발 방법론을 도입한 많은 기업들의 대규모 프로젝트는 실패가 이어져왔고 해당 방법론에 대한 회의론이 제기되었다. 절차적 방법론에서 반복적 방법론으로 소프트웨어 특성에 맞는 방법론이 필요해졌고, 그에 따른 다양한 방법론이 대두되었다.
당시 게임 개발을 어렵게 만드는 원인들로는 크게 세가지 있다.
피처 크립: 게임 또는 소프트웨어 등 제품에 새로운 기능을 계속 추가해서 범위를 지속적으로 확장하는 것.
=> 이것은 소비자에게는 피로감을 기업에게는 막대한 손해를 안겨줄 수 있다.
BDUF(Big Designs Up Front): 프로그램의 설계가 구현을 시작하기 전에 완벽해야하는 개발 접근법 설계를 구현보다 더 비중있게 다루어야 좋은 품질의 소프트웨어를 생산할 수 있다.
=> 하지만 이것은 게임 개발에 맞지 않다. 시작부터 게임의 모든 것을 알 수 없기 때문
낙관적인 일정: 간단한 심부름조차도 예기치 못한 문제가 불쑥 튀어나와 추정을 벗어나기 마련임.
ex) 다진마늘 심부름을 하러갔는데 다진마늘이 없음.프로덕션의 어려움: 프로덕션 실제 게임을 구현하는 단계다. 프리 프로덕션에서 설계한 내용을 구체화한 단계이다.
" 애자일 프로젝트는 이 모든 것을 반복을 통해 불확실성과 낭비를 없애도록 한다. "
2.2 애자일 방법론의 적용
💡 그렇다면 어떤 부분부터 위의 문제를 해결할 수 있을지 알아보자
개발 노하우
- 게임은 개발하면서 배워나간다. 게임 장비가 어떤 게임에 적합한지. 대상 플랫폼에는 어떤 것이 보기 좋을지 지식은 메일마다 쌓인다.
비용과 품질
게임 개발에서 그렇다면 줄여야 하는 것 부터 확인해보자
- 외주를 줄이는 것
미들웨어 솔루션: 다른 개발자로부터 구매한 기술- 내용을 줄이는 것
- 성공적인 IP를 기반으로 만드는 것
- 아이디어 무시
=> 단 이렇게 되었을때 게임의 품질이 낮아지는 것은 불가피하다. - 우선 재미를 찾는 것 부터
=> 폭포수 개발의 재미는 프로젝트가 3/2이상 진행되어야만 찾을 수 있다. 마지막 단계가 되어야 명확한 구현물을 확인 할 수 있기 때문에,
=> 애자일 개발은 재미라는 가치를 초첨을 두고 반복적인 개발을 추구한다 .때문에 폭포수모다 훨씬 이른단계에서 구현물을 명확히 확인하고 재미를 찾을 수 있다.
=> 애자일 실천방안은 프로젝트 내 낭비 제거를 초첨을 둔다.
애자일을 재미를 우선으로 초기부터 가치를 찾아낸다. 반복적인 개발 방법을 통해 개발 비용을 쉽게 예측하고, 만들 수 있는 사람들이 함께 일하는 효율성을 향상 시킨다. 게임 개발 비용을 줄일 수 있는 지속적인 개선 문화를 만든다.
애자일 선언문으로 확인하는 게임 개발
- 개인의 상호작용이 프로세스와 도구보다 우선
- 프로젝트가 커질 수 록 고착화된 프로세스로 인해 커뮤니케이션 비용이 증가하고 이는 소극적인 업무 자세와 불 가능한 예측으로 인해 게임의 품질을 떨어 뜨릴 수 있다.
- 이런 고착화된 프로세스를 깨기 위해 좋은 팀 구조를 가지도록 노력하며, 이를 위해 아주 작은 문제를 해결하는 책임만 맡도록 동기를 부여한다. 이는 점차 큰 문제를 해결하기 위해 발판이 될 수 있다.
- 제대로 동작하는 소프트웨어가 문서보다 우선
- 약간의 문서는 필요하다 이해관계자 얘를 들어서, 경영진들의 판단이 필요한 부분이 있어야할때 그들을 설득하기 위해서
수치화된 문서를 통해 설득력있는 것을 보여주는 것도 중요.
- 고객과의 협력이 계약 협상보다 우선
- 게임회사와 개발자 사이의 능동적 협력관계는 더 많은 비즈니스 협력을 가지며 더 나은 품질을 가져다 줄 수 있다.
- 변경에 대응하는 것이 계획에 따르는 것보다 우선
- 계획은 프로젝트에 필요한 기술과, 요구사항에 대한 명확함을 알고 있을때 가장 잘 적용된다
=> 회사 신입들에게는 무리이다.
2.3 애자일 프로젝의 모습
애자일 프로젝트는 계획을 회피하지 않는다. 프로젝트를 진행함에 따라 변화를 허용하는 계획 방식을 사용한다.
애자일 개발 프로세스
- 고객과 이해관계자가 피처 및 그외 요구사항을 확인
- 제품 책임자에 의해 이 요구사항에 대한 우선순위를 포함한 백로그를 불리는 리스트에 기술됨.
- 각 팀들은 부여받은 제품 백로그에서 한 개 이상의 사용자 스토리를 완료하고 향상 시킨 게임 버전을 시연한다.
스크럼 마스터는 결과적으로 진행에 방해되는 것을 제거하고 결과적으로 합의된 프로세스를 따르도록 하여 스크럼 팀을 돕는다.
규모가 큰 애자일 게임 프로젝트의 대부분은 콘센트 => 프리프로덕션 => 프로덕션 => 포스트 프로덕션과 같은 일련의 릴리스 과정을 수행한다.
애자일 적용
애자일 적용이라는 것은 단지 실천방안만을 적용하는 것이 아니다. 실천방안은 간단하다.
진짜 도전은 스튜디오 문화, 게임회사, 그리고 애자일 간 충돌에서 발생한다.
=> 스크럼 방법론을 이를 적용하기 위한 최적의 방법론이라고 필자는 말한다. 투명성을 만들고
일의 가장 좋은 흐름을 방해하는 모든 결함은 조사를 통해 파악한다. 문서를 믿기 보다는 반복적인 게임 자체에 신뢰를 가진다.
2.4 스크럼
스크럼은 애자일 구현하기 위한 하나의 프레임 워크
- 스크럼은 실천방안이나 방법론이 아니다.
- 스크럼은 여러 방면의 아이디어를 통합한 것이다.
80년대 중반 '새로운 신제품 게임 개발(다케우치와 노나카)' 라는 제목의 획기적인 기사는 기존 방식과의 제품 개발의 차이점을 제시해주었다.
이를 기반으로 점진적이고 반복적인 제품 개발 프로세스에 대해서 대두되기 시작했고
'고약한 문제, 합당한 해결'(1990) 이란 책에서 처음으로 스크럼을 소프트웨어 개발 모델을 언급했다.
스크럼 게임 개발 프로세스
스크럼으로 개발한 게임의 경우에는 6~10명의 다분야 통합팀을 구성하고
2~4주간 반복 또는 스프린트를 통해 제품을 만든다. 스프린트를 시작할때 팀은 스프린트 계획 회의에서 제품 백로그로 불리는 우선순위가 정해진 피처 목록에서
몇개의 피처를 선택한다.
- 제품 백로그의 각 피처를 제품 백로그 아이템이라고 함.
EX) 제품 백로그 아이템(플레이는 점프를 할 수 있다) => 스프린트 백로그(각 팀별로 업무를 분담하는 것, 애니메이션 팀에 점프 애니메이션을 생성, 프로그래머 팀에게(점프 조작을 구현, 물리를 구현), 기획자(점프 동작 조정) - 팀은 오직 스프린트를 달성할 수 있다고 판단한 피처에만 열중하여 사소한 업무성과부터
달성할 수 있도록 지속적인 동기부여를 시작한다. - 스프린트가 끝난 팀은 이해관계자(관리자, 디렉터, 직원들) 스프린트 목표를 달성했는지를 평가하고, 알게 된 것을 기반으로 다음 스프린트를 위한 제품 백로그를 갱신하기 위해 스프린트 리뷰 회의에 모인다.
- 마지막으로는 스프린트 회고를 통해 지난 스프린트에서 얼마나 효과적으로 함께 일을 했는지에 대해서 돌아보고 실천방안을 개선할 방법을 찾는 것을 목적으로 한다.
스크럼 원칙
- 경험 주의 : 스크럼은 실제 데이터를 축적하여 대응한다.
- 출현 : 게임을 개발하면서 무엇이 게임을 더 재미있게 하는지 무엇이 가능하게 하는지
시작부터 모든 것을 알 수 없다는 사실을 금지하지 않는다. - 시간 제한 : 스크럼은 반복적이다. 정기적으로 가치를 인도하고 가치가 드러남에 따라 이해관계자와 개발자가 이해도를 맞추고 프로젝트에 미세 조정 할 수 있도록 한다
- 우선순위 결정 : 이해관계자를 설득하기 위하며, 고객에게 좀더 가치있는 게임을 전달하기 위해
- 자기 조직화 : 함께 일하는 방법을 지속적으로 향상시키도록 한다.
스크럼 구성
제품 백로그 : 제품 백로그는 게임, 게임을 만들기 위한 파이프라인에 대한 요구사항,
또는 PBis라 불리는 우선순위를 정한 목록이다.
ex) 게임에 입자 효과추가 etc..
- 제품 백로그는 스프린트 후에 변경할 수 있다.
- 각 기능이 플레이어에게 주는 가치의 우선순위를 산정하여 백로그 우선순위를 결정한다.
스프린트 : 스크럼 개발 프로젝트는 각 스프린트 안에서 제품을 만든다. 이 반복이 곧
프로젝트의 심장 박동이다.
- 스프린트는 2~4주간의 시간제한이 있다.
- 목표는 변하지 않는다.
- 부분 업무 기능을 제작한다 = 작은 프로젝트와도 같다
- 스프린트는 출시 가능한 게임을 제작하는데 필요한 모든 것, 설계, 코딩, 자산 생성, 디버깅, 최적화 모든 것을 포함한다.
릴리스 : 릴리스는 게임의 새로운 주요 피처를 가져와서 출시에 가까운 상태로 만들기 위한
스프린의 묶음이다.
- 릴리스는 2~4개월 동안 지속된다.
스크럼의 역할
스크럼 팀은 스크럼마스터, 제품 책임자, 개발 팀으로 구성된다.
스크럼 마스터: 구성원들이 스스로 수립한 실천방은 따르도록 스크럼에 대해 팀을 교육시킬 책임이 있다. 문제 해결을 용이하게 하고, 필요하면 팀을 위해 닭에 맞서 귀찮은 일을 마다하지 않는다.
- 이 역할을 팀장도 또는 관리자도 아니다. 코칭, 그리고 가치를 인도하는 것으로부터 팀의 혼란을 빠드리는 모든 것을 제거함으로써 스크럼을 향상 시킨다.
- 무조건적으로 스크럼을 성공시키는 것이다. 스크럼 원칙을 적용하고 실천방안을 통해 능숙하게 팀을 이끌어야한다.
=> 팀 내에 오너십을 키워내는 것. - 책임 : 장애가 해결되는 것을 보장, 진행 모니터링, 계획/리뷰/회고를 용이하게 함, 지속적인 개선을 장려, 이해관계자와 팀 간 의사소통을 도움
제품 책임자 : 게임 비전을 의사소통하고 투자수익률을 극대화할 책임이 있다. 제품 백로그내
피처의 우선순위를 정함으로써 투자수익률을 극대화한다.
- 게임의 투자수익률 관리
- 고객과 개발자간 게임의 공유 비전 수립
- 구축할 것과 어떤 순서로 할 것인지를 구분
- 출시 계획을 만들고 출시일을 수립
- 스프린트 계획과 리뷰 지원
- 게임을 구입하는 플레이어를 포함한 고객을 대표
팀 : 스프린트 동안 목표를 달성하기 위해 필요한 모든 분야의 모든 사람을 포함한다.
우리쪽 프로세스를 개선하기 위해서 요청사항을 전달하지만 그쪽에서는 불필요한 커뮤니케이션 비용이 증가하는 업무가 하나 있었다.
요청을 받은 부서에게 최대한 기분이 나쁘지 않으면서도, 최대한 설득력과 논리력이 동반되어
이 업무가 단순히 불필요한 커뮤니케이션 비용만 증가하는 것이 아니구나를 알려주는 것이 굉장히 힘듦.
스프린트
- 일반적으로 2~4주
- 팀은 스프린트 목표 완료에 전념
- 팀 외부사람이 추가사항이나 변경사항을 만들지 않는다.
계획하기
스프린트 우선순위 결정 회의를 통해서 결정하며, 목표를 확인한다.,
- 팀의 수용 능력에 맞는 스프린트 업무량을 산정하자
- 개개인이 업무를 실행하나가는 과정을 과소평가하지 말자.
일일 스크럼 회의
- 15분
- 방해물 제거
- 구성원간 노력을 동기화
회고
스프린트 회고는 아마도 가장 중요하지만 가장 방치된 실천방안이다.
단 1%라도 향상 되는 것도 지속적인 스프린트 회고를 통해서 변화가 이루어져 나갈 것이다.
- 회고를 위한 회의에는 전체 스크럼팀이 참여한다.
- 회의를 시작하기 전에 분명한 시간제약을 둔다.
- 유연하게 대체한다. 이번 회고에서 확인되지 않은 항목은 다음 항목에서 확인한다
방법은 1. 무엇을 중단해야하는가 2. 무엇을 시작해야 하는가 3. 계속해야 하는 잘 되는 것은 무엇인가
스프린트 실패
- 스프린트는 어떤 과업에도 유연하게 대처할 수 있을 것 같지만 업무라는 것이 생각보다 단순하지 않다. 예상치 못한 과업이 발생할 수 있다.
스프린트 리셋
- 스프린트에서 가장 극단적인 선택 방법은 새로 시작하는 법.
- 팀이나 이해관계자가 스프린트 목표를 변경해야 하거나 스프린트가 끝날때까지 일을 완료할 수 없다는 것을 의미한다. 이것은 프로젝트를 다시 시작해야하는 것과 같다.
이렇게 리셋을 야기하는 문제는 여러가지가 있다.
- 목표 변경
- 시간 부족
=> 이를 해결하기 위한 방법번다운 차트
작업 부족
사용자 스토리
의사소통은 게임 개발에 있어 가장 큰 도전 중 하나이다. 그 중 문제는 바로 언어이다.
비즈니스 언어, 프로그래머들은 그들의 지식이 함축된 언어 아티스트들의 언어 등.
그래서 좋은 부분은 도구를 쓰는 것이 오히려 좋을 수 있다. 도구에서는 사용자가 누구든지
동일한 단어선택을 통해 기능을 제공하기 때문에
사용자 스토리 : 사용자 관점에서 게임의 요구사항 세부사항에 대해 대화하기 위한 플레이스홀더이다.
- 팀은 스프린트 당 하나의 사용자 스토리를 완료한다.
💡 책을 읽고 나서
PM으로서 다양한 유관부서와 소통을 하지만, 실제 마주하는 업무적인 프로세스 궁금중이 날로 커졌다. 지금 진행하고 있는 프로세스는 어떤 개발 프로세스인지 유관부서의 조직의 문화는 어떤 문화를 적용하는지 등 실제 게임 개발에 사용하는 애자일 방법론의 적용 사례에 대해 정독하고 나니 100%는 아니지만, 조금은 애자일 이 무엇이고 어떤식으로 적용을 해야할지에 대해 구체화 할 수 있었다.
