Top

애자일 소프트웨어 개발 [스크럼과 함께하는 게임 개발]

  • 원서명Agile Game Development with Scrum (ISBN 9780321618528)
  • 지은이클린턴 키스(Clinton Keith)
  • 옮긴이박현철, 전장호
  • 감수자김낙일
  • ISBN : 9788960778221
  • 35,000원
  • 2016년 02월 05일 펴냄
  • 페이퍼백 | 440쪽 | 188*235mm
  • 시리즈 : 애자일

책 소개

요약

이 책은 소프트웨어 개발 고유의 어려움을 애자일과 스크럼으로 해결해나갈 수 있도록 도와준다. 방법론의 실행뿐 아니라 철학을 설명하고, 애자일을 사용해 게임을 출시했던 수많은 스튜디오들과 저자의 경험에서 얻은 통찰을 기반으로 현실적인 적용 방안을 제시한다. 게임 업계에 몸담고 있지 않더라도, 애자일과 스크럼을 소프트웨어 개발에 적용해보고 싶거나 현재 애자일 프로젝트에 참여하고 있다면 좋은 지침서가 될 것이다. 특히, 다양한 역할, 많은 조직들과의 효율적인 협력뿐만 아니라 비즈니스 비전 및 계획에 따른 추적과 지속적 통합에 이르는 큰 그림을 살펴볼 수 있다.

이 책에 쏟아진 찬사

“스크럼을 이용한 비디오 게임 개발과 스크럼을 이용한 여타 ‘전통적인’ 소프트웨어 개발 간의 차이를 느낀 적이 있다면, 이 책은 당신을 위한 것이다. 클린턴은 원칙에 필요한 약간의 조정, 각자의 역할, 게임 개발 고유의 프로세스와 프로젝트 단계를 아우르고, 명쾌한 사례와 실용적 조언으로 이를 완벽하게 뒷받침함으로써 이 간극을 메우고 있다. 간단히 말하면, 이 책은 현재 회사에서 스크럼 또는 다른 애자일 프로세스를 사용하고 있거나 사용할 계획이 있는 게임 개발자를 위한 필독서다.”
-제프 린지 / 롱테일 스튜디오 프로듀서

“클린턴 키스가 15년 전으로 거슬러 올라가서 이 책을 저술할 수 있었으면 좋겠다. 그랬다면 내가 사물을 다른 관점으로 바라보는 데 큰 도움이 되었을 것이다. 스크럼 애자일 게임 개발은 스크럼 기법 사용에 관심 있는 게임 팀에게 모든 것을 제공해줄 수 있는 원스톱 숍이다.”
-CJ 콘노이 / 트레이아크 게임 프로듀서

“당신이 정신을 차리고 이 책이 정말로 필요함을 깨닫게 되었을 때는 이미 당신의 프로젝트가 엉망진창이 된 후일 것이다. 너무 늦기 전에 애자일로 뛰어들어 클린턴을 당신의 안내자로 삼으라. 게임 개발에 참여 중인 사람이라면 클린턴의 지혜를 읽음으로써 진정한 게임 개발의 열정 아래 검증된 게임을 만들 수 있다.”
-제이슨 델라 로카 / 페리미터 파트너스 설립자 겸 국제 게임 개발자 협회 전임 집행 이사

“클린턴 키스는 실무자와 학생 모두에게 도움을 줄 수 있는 훌륭한 책을 저술했다. 그는 대규모 게임 개발의 도전에 대한 심층 분석과 스크럼 사용에 대한 직접적인 조언을 잘 융화시켰다. 그의 재미있는 일화는 그가 실제로 대규모 컴퓨터 게임에서 치열한 경험을 했다는 것을 보여준다.”
-벤딕 비그스타드 / 노르웨이 IT 학교 정보시스템학과 교수

“클린턴 키스는 비디오 게임 개발 고유의 어려움에 스크럼 철학을 적용하기 위해 비디오 게임 개발자와 스크럼 철학을 적용하는 애자일 실무자의 서로 다른 두 가지 경험을 하나로 조화시킨다. 클린턴은 스크럼 이론을 넘어 철학을 설명하고, 스크럼의 성공적 응용에 대한 일상의 이야기와 경험을 공유하며, 개발 스튜디오에 숨을 불어넣는다.”
-에릭 테스 / 38 스튜디오 수석 프로듀서

“클린턴은 자신의 광범위한 게임 및 소프트웨어 개발 경험을 애자일 방법론과 융합했다. 그 결과, 애자일 게임 개발에 대한 사려 깊고 명확할 뿐 아니라 가장 중요하면서 현실적인 적용 방안을 만들어냈다.”
-센타 야곱센 / 다이스 수석 개발 이사

추천의 글

클린턴 키스에게 스크럼(사실, 일반적으로 애자일 소프트웨어 개발을 의미)과 게임 개발이 거의 완벽하게 잘 어울린다는 통찰은 놀라운 것이 아니었다. 그는 스튜디오의 최고 기술 책임자로서 스크럼과 게임 개발의 결합을 이끈 선구자였다. 일부는 회의적이기도 했지만 클린턴은 가능성을 봤고, 결과적으로 스크럼을 사용해 개발한 첫 번째 게임을 선보였을 뿐 아니라 그의 팀이 다시금 게임 개발에 재미를 붙일 수 있게 도와주었다.

게임 개발은 왜 재미없고 수익성도 낮을까? 게임 산업이 공격적인 마감 기한으로 악명 높고 개발 팀들이 매우 유동적인 시장에서 애매모호한 요구사항을 바탕으로 작업하고 있는 것은 사실이지만, 바로 이것이야말로 스크럼으로 큰 도움을 받을 수 있는 환경이다. 스크럼은 반복적이고 점진적이며, 팀에게 적어도 2~4주마다 게임을 수행 가능한 상태로 만들게 하기 때문에, 팀 구성원들은 새로운 피처와 시나리오 개발을 바로 눈앞에서 확인할 수 있다.

이 책에서 클린턴은 우리에게 그의 경험과 통찰을 공유해준다. 그는 우리에게 게임 개발의 힘든 부분에 성공적으로 스크럼을 사용하기 위해 알아야 하는 모든 것을 알려준다. 그럼으로써 애자일과 스크럼에 대해 소개하고, 이것이 대부분의 게임 개발 활동이 직면하는 복잡도 증가에 대한 관리를 어떻게 도울 수 있는지 알려준다. 그는 초대형 콘솔 게임만큼 크고 통합된 게임을 점진적으로 개발할 수 있는 방법을 설명한다. 그 과정에서 애자일 방식으로 모두 함께 일하기 위해, 게임 프로젝트에 필요한 모든 전문가에게 유용한 가르침을 제공한다. 또한 게임회사와 함께 일할 때 스크럼을 사용하는 방법에 대해서도 알려준다. 이 모든 가르침을 제공함에 있어, 클린턴은 고난을 마다하지 않는다. 그 대신, 우리가 그런 어려움 중 일부를 피할 수 있도록 아낌없이 자신의 조언을 공유한다.

나는 여러분이 들고 있는 책이 게임 프로젝트와 스튜디오에 큰 영향을 미칠 수 있을 것이라는 사실에 대해 한 치의 의심도 없다. 일단 스크럼을 시작하고 익숙해지면 팀 구성원은 다른 방법으로 일하고 싶어 하지 않을 것이다. 클린턴이 오래 전에 깨달은 것처럼, 그들도 스크럼이 게임 개발의 복잡성과 불확실성을 처리하는 가장 좋은 방법이라는 사실을 깨닫게 될 것이다.
-마이크 콘 / 스크럼 연합 및 애자일 연합 공동 창설자

이 책에서 다루는 내용

게임 개발 맥락에서의 스크럼 목표, 역할, 실천방안에 대한 이해

게임의 비전, 피처, 진행 계획과 의사소통

격주마다, 심지어는 날마다 게임을 실행 가능한 상태로 유지하는 반복 기술 사용

모든 팀 구성원이 자신의 역할을 성공적으로 수행하기 위한 지원

개발 과정에 대한 안정성과 예측 가능성 개선

유동적인 시장의 모호한 요구사항에 대한 관리

스크럼을 지리적으로 분산된 개발 팀으로 크게 확장

스크럼 시작하기: 관성을 극복하고 조직의 현재 프로세스에 스크럼을 통합

이 책의 대상 독자

이 책은 프로그래머, 프로듀서, 아티스트, 테스터, 기획자로 구성된 애자일 팀을 구성하고, 팀 안팎으로 효율적인 협력을 촉진하는 전 과정을 다룬다. 또한 장기적인 계획에서부터 진척에 대한 추적과 지속적인 통합까지, 저자가 현실에서 어렵게 얻은 경험을 바탕으로 수많은 팁과 트릭, 해결책을 제시한다.

이 책의 구성

1부, '문제와 해결책'은 게임 산업의 역사로부터 시작한다. 게임 산업의 상품과 개발 방법론이 어떻게 변화되어 왔는가? 무엇이 우리를 비대한 예산, 절대로 맞출 수 없는 일정, 프로젝트 초과근무, 죽음의 행진으로 이끌었는가? 이어서 애자일에 대한 개요를 소개하고 애자일 가치가 어떻게 게임 개발 관리의 문제에 도움을 줄 수 있는지 이야기한다.

2부, '스크럼과 애자일 계획'에서는 스크럼, 스크럼의 역할과 실천방안, 스크럼을 게임 개발에 적용하는 방법에 대해 살펴본다. 또 게임의 비전, 피처, 진척에 대해 의사 소통하고, 계획하고, 단기 및 장기적으로 반복하는 방법을 설명한다.

3부, '애자일 게임 개발'에서는 일부 스크럼 실천방안에 프로덕션을 위한 린 실천방안 및 칸반 실천방안을 보강할 수 있는 것을 포함해, 게임 개발 프로젝트 전반에 걸쳐 애자일을 사용하는 방법을 설명한다. 또한 애자일 팀과 전 세계에 걸쳐 분포되어 있는 대규모 직원들에게 스크럼을 확장하는 방법을 알아본다. 또한, 팀이 게임을 구축하는 모든 사항을 반복하는 데 필요한 시간을 줄임으로써 지속적으로 자신의 개발속도를 향상시키는 방법에 대해 검토한다.

4부, '애자일 관심 분야'에서는 광범위하고 다양한 각각의 분야가 한 애자일 팀에서 함께 일하는 방법에 대해 살펴본다. 또한 각 분야 리더의 역할과 리더를 스크럼 역할에 매칭시키는 방법을 설명한다.

5부, '시작하기'에서는 당신의 스튜디오와 게임회사에 애자일 실천방안을 도입하는데 따르는 어려움과 해결책을 상세히 알아본다. 문화적 관성을 극복하고 애자일 원칙의 훼손 없이 스튜디오 고유의 프로세스에 통합시키는 것은 시간이 걸릴 수 있고 도중에 많은 어려움이 생긴다. 5부를 구성하고 있는 내용은 이런 어려움을 헤쳐나갈 수 있도록 안내해준다.

이 책은 애자일 게임 개발을 위한 출발점이지 결코 종착점이 아니다. 스크럼, XP, 린, 칸반, 사용자 스토리, 애자일 계획 등 게임 개발에 대한 좋은 책들이 있다. 이런 책들은 지속적인 향상으로 가는 길에 필요한 모든 세부사항을 제공해준다.

아이폰, PC, 대규모 멀티플레이어 온라인 게임 개발자는 여기에 설명한 실천 방안들을 사용한다. 나는 기술적 배경을 바탕으로 한 많은 이야기를 공유했고 이중에는 애자일 프로그래머를 위한 실천방안들이 많지만, 이 책은 전체 산업에 적용할 수도 있다. 다양한 분야, 장르, 플랫폼에 관계된 많은 사람들로부터 얻은 이야기와 경험들도 이 책에 모두 담았다.

저자/역자 소개

지은이의 말

이 책은 애자일 방법론을 사용하고 있거나 그 의미에 대해 호기심을 갖고 있는 게임 개발자를 위해 저술되었다. 또한 애자일 제품 개발의 다양한 영역으로부터 얻은 많은 정보를 제공하며, 게임 산업 고유의 생태계에 적용하는 것에 대해 언 급한다. 이 책은 지난 6년간 애자일을 사용해 게임을 출시했던 수많은 스튜디오들의 경험을 바탕으로 한다.

게임 업계에 몸담고 있지 않은 사람이라도 게임 산업이나 애자일에 호기심을 갖고 있다면 이 책을 즐길 수 있을 것이다. 이 책은 모든 분야와 의사소통해야 하기 때문에 그중 어떤 한 분야의 세부적인 부분에 얽매이지 않는다. 예를 들어, 다분야통합 팀에서 일을 잘하기 위해 아티스트는 같은 팀의 프로그래머가 직면한 어려움과 해결책을 이해해야 한다.

제목에서 알 수 있듯이 이 책은 애자일의 다른 영역보다 스크럼에 더욱 초점을 맞춘다. 스크럼은 애자일 게임 개발 프로세스를 구축하기 위한, 분야에 구애받지 않는 프레임워크다. 스크럼에는 미리 정의된 아트, 설계, 프로그래밍 프로세스가 없다. 스크럼은 게임을 만들고 가장 적합한 실천방안을 적용하는 방법에 대한 모든 면을 검사해볼 수 있게 해주는 토대다.

애자일과 게임 개발은 어떻게 만났을까? 내 경우 2002년 새미 스튜디오에서 시작했다. 많은 스튜디오와 마찬가지로 우리는 ‘재앙’을 피하기 위해 애자일을 선택했다. 새미 스튜디오는 2002년 일본 파친코 제조회사에 의해 설립되었다. 그들의 목표는 서양 게임 업계에서 최대한 빨리 입지를 구축하는 것이었다. 이를 위해 그들은 새미 스튜디오가 이 목표를 달성하는 데 필요한 것은 뭐든지 재정적으로 지원하고 권한을 부여해주었다. 경험이 많은 프로젝트 관리자였던 우리는 〈다크워치(Darkwatch)〉라는 주력 게임 프로젝트에 필요한 모든 세부사항 관리를 돕기 위해 마이크로소프트 프로젝트 서버의 라이선스를 포함한 프로젝트 관리 체계를 수립했다.

〈다크워치〉의 계획은 야심 찼다. 이 게임은 걸출한 1인칭 콘솔 슈팅 게임으로, 〈헤일로〉의 경쟁 게임이었다. 당시 우리에게는 자원이 있었고 계획 관리 소프트웨어를 사용하는 한 우리가 관리할 수 없는 문제가 발생해 일을 그르칠 가능성은 거의 없다고 생각했다. 하지만 그리 오래지 않아 많은 것에 문제가 생기기 시작했다. 1년 만에 예정보다 6개월 뒤처졌고 상황은 매일매일 악화되어 갔다. 왜 이렇게 된 걸까?

각 분야가 별도의 계획으로 작업했다

각 분야는 많은 시간 동안 독립적으로 작업하는 목표를 갖고 있었다. 예를 들어, 애니메이션 기술은 어떤 것이 입증되기도 전에 그들만의 많은 피처를 개발하는 계획에 따라 프로젝트를 진행했다. 애니메이션 제작자는 간단한 전환 작업을 만들면서 애니메이션 프로그래머가 잘라낼지도 모르는 팔, 다리에 관한 작업도 수행했다. 이런 문제를 수정하기 위해서는 정기적으로 주요 일정을 점검해야 했다.

빌드가 항상 깨져 있었다

동작하는 게임의 최신 버전을 얻는 데에는 별도의 노력이 필요했다. 전자 게임 전시회E3 데모에 필요한 빌드를 제작하기 위해 디버깅 및 해킹에 한 달 이상 노력을 기울였다. 그럼에도 불구하고 개발자는 데모 컴퓨터를 자주 재부팅해야만 게임을 실행해볼 수 있었다.

추정과 일정이 언제나 너무 낙관적이었다

작은 작업부터 주요 마일스톤에 이르는 모든 일정이 너무 늦는 것처럼 느껴졌다. 예상치 못한 작업은 개인적인 시간에 수행하거나 이후로 미뤄두었다. 이는 결국 수많은 야근과 주말 초과근무로 이어졌다.

관리자는 지속적으로 ‘불을 꺼야만 했고’, 큰 그림을 해결할 시간을 가진 적이 없었다

관리자는 매주 해결해야 할 문제 중 하나를 선택했고 이를 해결하기 위해 하루 종일 진행되는 대규모 회의를 했다. 문제들의 목록은 해결할 수 있는 능력을 넘어서 빠르게 증가했다. 우리에게는 미래를 내다보고 프로젝트를 이끌 시간이 없었다.

이와 같은 문제는 계속 적어내려갈 수 있을 정도로 많았고 점점 늘어났다. 대부분의 문제는 한 달 이상의 포괄적인 계획에 대한 추정을 정당화할 수 있는, 많은 프로젝트 세부사항을 예측하지 못했기 때문에 발생했다. 결론적으로 우리의 계획 방법론이 잘못된 것이었다.

결국 우리의 일본 모기업은 핵심 구성원을 바꿔 달라고 우리에게 요청했다. 메시지는 명확했다. 우리가 원하는 모든 가용 리소스는 관리자에게 주어져 있었기 때문에 모든 문제는 우리의 잘못이었고, 이를 수정하라는 짧은 통지를 받았다. 일뿐만 아니라 스튜디오의 생존이 위기에 처해 있었다.

내가 상황을 바꾸기 위한 프로젝트 관리 방법을 찾기 시작했던 것은 이 절망적인 시기였다. 우리는 그때까지 스크럼, 익스트림 프로그래밍XP과 같은 애자일 실천방안을 알지 못했다. 새미 스튜디오의 기존 CTO는 우리에게 XP를 시도하게 했고, 프로젝트 리더는 몇 가지 스크럼 실천방안을 실험했다.

스크럼(슈와버와 비들, 2002)에 대한 책을 읽고 난 후, 나는 스크럼을 우리 환경에 사용할 수 있을 것이라고 확신했다. 스크럼을 처음 알게 되었을 때, 게임 개발팀의 재능과 열정을 활용할 수 있는 프레임워크를 찾았다고 직감했다. 물론 쉽지만은 않았다. 스크럼 규칙들은 IT 프로젝트를 수행하는 프로그래머 팀 쪽으로 편향되었고 몇몇 규칙은 제대로 적용되지 않았다.

이는 애자일이 가진 의미와 게임 개발자들이 이를 적용하는 것에 대한 일련의 끝없는 발견의 시작이었다. 나는 2005년에 애자일 게임 개발에 대해 이야기하기 시작했다. 이때는 스튜디오가 Xbox 360과 플레이스테이션3 게임 타이틀을 개발하고 있을 무렵이었다. 100명 이상의 팀이 일반적이었고 프로젝트 실패에 대한 비용은 수백억 원에 이르렀다.
안타깝게도 많은 사람들이 애자일의 메시지를 너무 과장되게 받아들였고, 몇몇은 이를 모든 것을 해결할 수 있는 만병통치약으로 여겼다. 2008년 수십 개의 스튜디오에서 수백 명의 개발자와 이야기를 나눠본 후, 나는 게임 개발자의 애자일 도입을 돕는 풀타임 코치가 되기로 결심했다. 나는 현재 여러 스튜디오를 코치하며 공개 강의를 통해 개발자에게 스크럼마스터가 되는 방법을 가르치고 있다. 이 개발자들과 함께 작업하며 배운 경험으로 이 책을 쓸 수 있었다.

지은이 소개

클린턴 키스(Clinton Keith)

게임 개발자와 게임 개발자가 아닌 모두가 스크럼, 익스트림 프로그래밍(XP, eXtreme Programming), 칸반(kanban)과 생산성, 직장(작업 공간), 제품 품질을 크게 향상시킬 수 있는 기타 애자일 실천방안을 적용하는 데 도움을 주는 프리랜서 애자일 코치이자 공인 스크럼 트레이너다.

25년 동안 첨단 전투기 및 수중 로봇을 위한 전자기기 프로그래밍과 〈미드타운 매드니스(Midtown Madness)〉, 〈미드나잇 클럽(Midnight Club)〉 등의 인기 비디오 게임 프로그래밍을 경험했다. 여러 스튜디오를 거치며 프로그래머, 프로젝트 디렉터, CTO, 제품 개발 디렉터로 활동했고, 프레젠테이션과 자신의 인기 블로그를 통해 2005년 비디오 게임 산업에 스크럼을 도입했다. CTO로서 하이 문 스튜디오를 2005년, 2006년 IT 매거진이 선정한 기술 혁신 ‘톱 50’ 리스트에 올렸고, 2005년, 2006년, 2007년에는 샌디에고에서 최고의 인사관리 기업 대상을 차지하는데 크게 기여했다. www.ClintonKeith.com에서 더 자세한 내용을 볼 수 있다.

옮긴이의 말

내가 처음 애자일을 접한 것은 1999년이다. 개발자, 설계자, 프로젝트 관리자 등으로 활동했던 나는 당시 수백억 원을 들여 많은 외국인들과 함께 웹 기반 투자 시스템을 만드는 회사에 신용분석(CreditAnalytics) 팀장으로 합류했었고, 쉽지 않은프로젝트 상황을 잘 이끌어가려고 고군분투하고 있었다. 여러 명의 인도 출신 개발자들이 풀(Pool) 형태로 존재했고, 새로운 일이 내게 주어질 때마다 개발자 풀에서 협업을 해본 경험이 없는 사람을 데려와서 매우 생소한 개발 업무를 맡겨야만 했다. 업무를 가르쳐주기도 어려웠고, 전체 아키텍처 및 관련 모델, 개발 환경 등을 짧은 시간 내에 전달하는 것도 쉽지 않았으며, 이전 프로젝트 결과들과 지속적인 통합을 하면서 일관성을 유지하는 것도 쉽지 않았다.

이때 XP를 알게 되었다. 풀로부터 데려온 개발자에게, 비즈니스 전문가들과 논의해 만들었던 스펙 내용을 보면서 코딩하는 것을 한 시간쯤 시범적으로 보여주었고, 한 시간은 직접 코딩하도록 시키면서 업무, 공통 모듈, 프로그래밍 스타일 등에 대한 개발 관련 코칭을 수행했다. 그렇게 P C 한 대로 일주일쯤 함께 짝 프로그래밍(Pair Programming)을 진행하면, 이후에 필요한 일은 스펙을 통해 적절하게 협업할 수 있는 상황이 되었다. 이전 프로그램이나 다른 사람들이 작성한 프로그램들을 개발자가 직접 개선하기 위해 코드 소유권을 공유할 수밖에 없었고, 프로그램 대부분이 기업 회계를 위한 계산과 각종 금융 상품 처리 등에 관한 것이다 보니 계속 회귀 테스트를 할 수밖에 없는 상황이어서, 항상 테스트를 염두에 두고 개발해야만 했다.

회사 전체의 개발/관리 프로세스를 따르면서 우리 팀은 UP(Unified Process) 방법론을 관리의 틀로 활용하며 로즈(Rose)라는 모델링 도구로 UML 모델을 만들고, 로직이 없는 스켈레톤 코드(Skeleton Code)를 생성해 개발자에게 배포했으며, XP를 통해 개발자들과 의사소통했다. 그 당시 빌드를 전담하는 전문 빌드 마스터가 있어서, 지속적 통합 빌드 체계도 유지할 수 있었다. 프로젝트 관리자는 미국인 여성으로 MBA 출신이었고, 소프트웨어 아키텍트는 중국계 캐나다 사람이었으며, 영국이나 홍콩 등 다양한 출신의 영업 및 국제법 전문가 등도 있었다. 그리고 투자사들은 항상 우리들의 성과에 대해 관심을 표명하고 있었다. 우리는 급변하는 금융 상황에 대처할 수 있는 빠른 피드백이 필요했고, 내게 XP는 그 당시의 어려운 상황을 타개할 수 있는 유일한 탈출구였다.

모델링 및 프로그래밍 관련 저서를 출간했던 나는 저술 경험을 살려 XP에 대한 좋은 경험을 공유하고자 번역서인 『XP 도입을 위한 실전 입문: Extreme Programming Installed』를 2002년 출간했다.

이후 삼성생명 비전속 등 다양한 프로젝트들을 수행하면서 팀 활동에 XP를 적용해 빠른 피드백을 만들어낼 수 있었고, 2007년에는 증권사의 차세대 프로젝트에 스크럼(Scrum)을 적용해서 프로젝트 성공에 크게 기여할 수 있었다.

2007년 7월부터 2009년 5월까지 증권사 차세대 프로젝트에서 내가 맡았던 역할은 소프트웨어 아키텍트(Software Architect)이자 변화관리자(Change Agent)였다. 프로젝트 진행 중에 증권사 CIO 및 현업과 전산 리더들, 수행사였던 삼성SDS의 PM, PL, QA 등 주요 리더들, PMO를 모두 포함한 스크럼 조직을 구성했고, 나는 스크럼마스터(ScrumMaster)가 되어 매일 스크럼 미팅(Daily Scrum Meeting)을 진행했다. 또한, 매일 진행된 미팅을 뉴스페이퍼(Daily News Paper)로 만들고 인쇄해서 프로젝트 관련 전체 인원(250여명)에게 배포했다.

20년이 넘는 나의 IT 경력에서 가장 값진 경험을 바로 이때 얻었다. 스크럼마스터로서 전사 프로젝트의 의사소통 메커니즘을 이끌어냈고, 날마다의 대면 이슈 관리를 통해 빠른 상황 대처를 할 수 있었다. 그리고 필요한 정보 공유를 통해 전체 프로젝트의 이해 공유(Shared Understanding)를 향상시킬 수 있었다. 비록 전체 프로젝트의 공식 방법론이 정보공학 방법론이었고 C 언어가 주 언어였지만, 스크럼과 같은 애자일 방식이 전사 차원의 프로젝트 성공에도 일조할 수 있다는 확신을 갖게 해주는 사례를 만들 수 있었다.

크고 작은 프로젝트 수행이 끝날 때마다 프로젝트 경험을 정리하면서 모델링이나 프로젝트 관리 관련 책과 애자일 관련 책의 번역 작업을 꾸준히 해올 수 있었고, 덕분에 내 통산 열 번째 책인 『애자일 소프트웨어 개발』을 IT 전문가와 함께 출간하는 기쁨을 얻을 수 있었다. 이 모든 것에 대해 하느님께 감사드리며, 어려운 IT 환경에 조금이라도 도움이 되기를 희망한다.
박현철

소프트웨어 개발 환경은 급속도로 변화하고 있다. 우리가 소프트웨어로 해결해야 하는 문제는 점점 더 복잡해지고 있으며 프로젝트의 불확실성과 복잡도도 함께 높아졌다. 전통적인 개발 방법으로 이를 대처하기란 역부족임을 주변의 많은 프로젝트 실패가 보여주었다. 폭포수 개발에 익숙한 개발자나 프로젝트 매니저가 이 책을 읽고 있다면 아마 적어도 한두 번쯤 실패했던 기억을 어렵지 않게 떠올릴 수 있을 것이다. 이때 등장한 애자일 방법론이 이러한 환경에서 소프트웨어를 개발함에 있어 발생하는 많은 문제를 해결해줄 것으로 기대되고 있지만, 실제로 애자일 철학과 실천방안들을 우리의 소프트웨어 개발에 제대로 적용하는 것이 쉽지만은 않다. 현장에서 프로젝트에 애자일, 스크럼을 적용해봤다면 충분히 공감하는 문제일 것이다.

이 책은 애자일의 철학뿐 아니라 스크럼을 통해 소프트웨어 개발에 어떻게 그 철학을 적용하고 우리 자신의 것으로 만들어낼 수 있는지 알려준다. 또한 개발 프로세스뿐 아니라 조직에도 어떻게 스크럼 역할들을 적용하고 확장할 수 있는지 설명해준다. 저자인 클린턴 키스는 이 책에서 자신의 통찰과 잘 구조화된 지식을 자신의 경험담과 함께 재치 있게 이야기한다. 『애자일 소프트웨어 개발』은 단순히 방법론과 특정한 실천방안, 기술만을 소개하는 책이 아니다. 이 책을 통해 우리의 프로젝트를 어떻게 더 좋게 만들 수 있는가에 대한 해답을 찾을 수 있도록 코칭해준다.

스크럼은 단순하고 쉽다. 전체 실천방안을 설명하는 데 몇 분 정도면 충분하지만, 애자일과 스크럼의 철학을 이해하고 ‘왜 해야 하는가?’에 대한 답을 찾고 우리가 일하는 환경에 맞도록 이를 적용하는 것은 매우 오랜 시간이 필요할 수도 있다. 하지만 여전히 스크럼은 간단한 것으로부터 시작하며, 이로써 우리는 작은 실험들을 통해 소프트웨어 개발 시간과 결과를 점차 긍정적으로 바꿔나갈 수 있다. 독자들도 자신의 환경을 돌아보며 이 책을 따라가다 보면 답을 찾기 위한 여러 실험들을 적용해보고 싶은 마음이 생길 것이다. 그러므로 당장 실행해보라고 권하고 싶다.

아울러 이 책은 게임 개발을 주요 맥락으로 애자일과 스크럼을 이야기하고 있지만, 개발자가 아니더라도 또 게임 외 다른 산업에 종사하는 독자라도 모두 도움을 받고 통찰을 얻을 수 있다. 소프트웨어 개발 프로젝트에 참여하는 구성원뿐 아니라 이해관계자들도 애자일 소프트웨어 개발에 대한 합리적인 시각과 태도를 갖는 데 조금이나마 이 책이 도움이 되었으면 한다.
전장호

옮긴이 소개

박현철

한때는 춤을 사랑했지만, 지금은 좋은 소프트웨어를 만들기 위해 글을 쓰는 것을 즐긴다. 다양한 분야에 걸쳐 많은 프로젝트를 경험했으며, 프로그래머로 시작해서 설계자, 프로젝트 관리자, 아키텍트, 멘토까지 다양한 역할을 수행하고 있다. IT 분야에서 보람과 행복을 많은 사람들과 함께 찾기 위해 노력하고 있다. 상원, 지원 두 아들과 아내 인숙을 사랑하며, 삶에 감사한다.

미국 샌디에고에서 스크럼 개발자 인증(Certified Scrum Developer)을 받았고, 필리핀 마닐라에서 제품 책임자 인증(Certified Scrum Product Owner)을 받았으며, 서울에서 스크럼 마스터 인증(Certified Scrum Master)을 받았다. 저서로는 『객체지향 분석 설계 Visual C++ 프로그래밍』(비앤씨, 1999), 『프로그래머 그들만의 이야기』(영진닷컴, 2003), 『실전 CBD Project』(영진닷컴, 2004), 『UML 이해와 활용』(한국소프트웨어컴포넌트컨소시엄, 2005)이 있고, 번역서로는 『XP 도입을 위한 실전 입문: eXtreme Programming Installed』(인사이트, 2002), 『엔터프라이즈 애자일 프로젝트 관리』(에이콘, 2010), 『Agile Project Management with Scrum(한국어판)』(에이콘,2012), 『UML을 활용한 객체지향 분석 설계』(에이콘, 2013), 『스크럼으로 소프트웨어 제품 관리하기』(에이콘, 2013)가 있다.

전장호

소프트웨어 개발자 겸 설계자로 시작해서 프로젝트 매니저, 강사 등 IT 분야에서 15년 가까이 다양한 역할을 통해 여러 프로젝트를 경험했고, 현재는 (주)카카오에서 광고 플랫폼 전략을 고민하며 프로젝트 매니저로 활동 중이다. 애자일 등 개발/프로젝트 방법론에 관심이 많아 프로젝트를 진행하는 동안 다양한 실험을 적용해보고 있으며, 항상 어떻게 하면 좀 더 효율적이고 즐겁게 일할 수 있을지 고민한다. 비즈니스의 복잡한 문제들을 기술적으로 해결하기 위해 연구와 실행에 빠지곤 하는데, 이런 시간을 제외하면 요리하거나 여행하는 것을 좋아하고 사랑하는 아내 남영과 시간을 보내는 것을 즐긴다.

감수의 글

게임의 본질은 오락으로서의 재미다. 그러므로 게임을 개발한다는 것은 게임적 재미를 찾아가는 것을 의미한다. 이러한 게임의 본질은 일반적인 소프트웨어를 개발하는 것과 크게 다른 근본적인 차이를 야기한다.

일반적인 소프트웨어는 사용자가 원하는 기능이 올바로 구현되면 성공적으로 개발되었다고 할 수 있다. 그러나 게임 소프트웨어는 ‘구현된 기능이 재미있는가?’라는 추가적인 요구사항이 따른다. 만약 재미가 없다면 그 기능이 완벽하게 개발되었더라도 수정되거나 삭제될 수밖에 없다.
문제는 이 게임의 재미라는 것이 상당히 주관적이며 예측하기 어렵다는 점이다. 몇 가지 기능이 재미있다 하더라도 전체 게임 시스템이 완성되었을 때의 재미 문제는 전혀 다를 수 있기 때문이다. 상당히 단순한 메커니즘을 가지고 있는 게임일지라도 그 메커니즘에서 재미를 극대화시킨다는 것은 대단히 어렵다는 점에 모든 게임 개발자들이 동의할 것이다.

이러한 게임의 불확실성과 복잡성 같은 속성들로 인해 게임 개발 프로젝트를 관리하는 것은 매우 어렵다. 이 책의 저자는 이러한 문제에 대해 게임 개발자들이 전통적인 계획 작성 도구와 규범화된 방법으로 접근을 시도했다고 봤다.

한국의 상황도 크게 다르지 않았다. 허들시스템 등의 프로젝트 관리 방법론은 전통적으로 규범화된 제품 개발 방법론이었고, 많은 개발 스튜디오들이 비슷한 폭포수 방식의 개발 방법론을 사용해왔다.
폭포수 방식의 개발 방법론이 지닌 문제는 명확하다. 기획 단계에서 구현되지 않은 게임의 재미를 예측해 설계하는 것은 대단히 어렵다. 더구나 기획 단계 시점과 게임 오픈 시점 간의 시차는 게임 업계의 시간 개념으로는 매우 긴 시간이기에, 그동안 시장과 게이머가 어떻게 바뀔지도 알 수 없다. 그런데 게임 시스템이 완성되어 테스트에 들어가는 시점이 되었을 때에야 비로소 게임의 실체를 테스트해볼 수 있게 되니 테스트 결과가 좋지 않더라도 이미 어쩔 수 없는 일이 되어 큰 폭의 수정 없이 그대로 오픈하게 된다. 다행히 재미있는 게임이었다면 성공하겠지만, 불행히도 한국의 게임 역사에서는 큰 실패를 안겨준 대작 게임들이 더 많았다.

클린턴 키스는 이러한 문제에 대해 애자일 스크럼이라고 하는 일 잘할 수 있는 방안에 대해 실증적이면서 구체적으로 설명한다.
이 책에서도 중요하게 인용되는 켄 슈와버와 제프 서더랜드는 그들의 문서 ‘스크럼 가이드(The Scrum Guide)’를 통해 다음과 같이 스크럼을 평가한다.

간단하고

이해하기 쉽지만

마스터하기는 어려운 프레임워크

스크럼은 대단히 쉽게 배울 수 있는 방법론이다. 하지만 ‘어떻게 적용할 것인가?’에 대해서는 많은 고민과 성숙된 경험이 필요하다. 물론 스크럼을 잘 수행할 수 있는 팀을 갖추는 것은 더 어렵다. 하지만 이 책을 통해 독자들은 애자일 스크럼의 철학부터 게임 개발이라는 특수성에 맞는 구체적인 적용 방안에 대한 지식까지 얻을 수 있다. 최고 수준의 해외 게임 개발 스튜디오가 일하는 방법을 접해보는 것도 흥미로울 것이다. 참고로 이 책에서 다루는, CCP 게임즈(CCP Games)가 어떻게 〈이브 온라인(EVE Online)〉 개발 프로젝트에 애자일 스크럼 방법론을 적용 했는지에 대한 소개 영상도 유튜브에서 볼 수 있으니 반드시 시청하기 바란다(https://www.youtube.com/watch?v=GqsReCZD4hc).

게임 프로듀서로서 애자일 스크럼 게임 개발 프로젝트 관리의 바이블인 이 책이 마침내 한국에 소개되는 것이 매우 반갑다. 더군다나 이 책을 번역한 박현철 님, 전장호 님은 애자일 스크럼에 대한 풍부한 현장 경험과 지식을 갖춘 분들로, 이 책의 번역 작업을 맡아주셔서 업계의 한 사람으로서 깊이 감사한다. 일반적인 기술 서적과는 다른 특수성을 지닌 전문적인 내용을 번역하느라 많은 어려움이 따랐으리라 생각한다. 훌륭한 결과물과 그간의 노고에 박수를 보낸다.

감수자 소개

김낙일

석・박사 과정에서 게임과 애자일 프로젝트 관리를 연구했다. 지난 18년간의 IT 경력 중 10년 이상을 프로젝트 관리자로 일해왔고, 그 절반 이상이 게임 분야였다. 중견 게임회사에서 게임 사업 총괄 업무를 수행했고, 지금은 두 번째 게임 개발 스타트업에서 CEO 및 PD로 활동 중이다. 소프트웨어 개발자로 시작해서 게임 프로듀서가 되었으며 이 일을 잘하기 위해 최선을 다하고 있다.

PMP(Project Management Professional)로서 프로젝트 관리 전 분야에 걸쳐 연구한다. 다양한 프로젝트 관리 이론을 현장에 적용해봤던 경험을 바탕으로 ‘스타트업을 위한 프로젝트 경영’, ‘애자일 스크럼 세미나’ 등의 강의를 진행 중이며, 기업을 대상으로 애자일 코칭도 수행한다.

목차

목차
  • 1부 문제와 해결책
  • 1장 게임 개발이 직면한 위기
    • 간추린 게임 개발의 역사
      • 오락실 게임에서의 반복
      • 초기 방법론
      • 묻지마 투자의 종말
    • 위기
      • 줄어든 혁신
      • 떨어진 가치
      • 악화된 업무 환경
    • 한 줄기 희망
    • 추가 자료

  • 2장 애자일 개발
    • 프로젝트가 어려운 이유
      • 프로젝트 검토로부터 배우기
      • 문제
    • 왜 게임 개발에 애자일을 사용하는가
      • 아는 것이 열쇠다
      • 비용과 품질
      • 우선 재미를 찾는 것부터
      • 낭비 제거
      • 게임 개발에 적용하는 애자일 가치
    • 애자일 프로젝트 모습
      • 애자일 개발
      • 전체 프로젝트
    • 애자일 도전
    • 추가 자료

  • 2부 스크럼과 애자일 계획
  • 3장 스크럼
    • 스크럼의 역사
      • 큰 그림
      • 스크럼 원칙
    • 스크럼 구성
      • 제품 백로그
      • 스프린트
      • 릴리스
    • 스크럼 역할
      • 스크럼 팀
      • 스크럼마스터
      • 제품 책임자
    • 고객과 이해관계자
    • 돼지와 닭
    • 스크럼 크기 조정
    • 요약
    • 추가 자료

  • 4장 스프린트
    • 큰 그림
    • 계획하기
      • 스프린트 우선순위 결정
      • 스프린트 계획하기
      • 길이
    • 진척 추적하기
      • 작업 카드
      • 번다운 차트
      • 일일 스프린트 백로그 추세
      • 작업 보드
      • 전략 회의실
    • 일일 스크럼 회의
    • 실천방안
    • 스프린트 검토
      • 단일 팀 검토
      • 멀티 팀 검토
      • 게임회사 이해관계자
      • 스튜디오 이해관계자
      • 정직한 피드백
    • 회고
      • 회의
      • 결과 게시 및 추적
    • 스프린트 실패
      • 스프린트 중단
      • 스프린트 리셋
      • 팀이 실패했을 때
      • 작업 부족
    • 요약
    • 추가 자료

  • 5장 사용자 스토리
    • 운명적인 만남
    • 사용자 스토리란 무엇인가
    • 상세 수준
    • 만족 조건
    • 사용자 스토리 인덱스 카드 사용
    • 사용자 스토리의 INVEST
      • 독립적이다
      • 협상 가능하다
      • 가치가 있다
      • 추정 가능하다
      • 적절한 크기다
      • 테스트 가능하다
    • 사용자 역할
    • 완료 정의
    • 스토리 수집
    • 사용자 스토리의 장점
      • 대면 의사소통
      • 사용자 스토리는 모두가 이해할 수 있다
    • 요약
    • 추가 자료

  • 6장 애자일 계획
    • 왜 애자일 계획인가
    • 제품 백로그
      • 제품 백로그 우선순위 결정
      • 지속적인 계획
      • 미래 예측
    • 스토리 크기 추정
      • 추정에 얼마나 많은 노력을 기울여야 하는가
      • 스토리 크기는 얼마만큼 추정해야 하는가
      • 스토리 점수
      • 플래닝 포커
      • 스토리 점수 크기와 피보나치 수열
      • 이상적인 작업일
  • 릴리스 계획
    • 릴리스 계획 회의
    • 계획 발표
    • 릴리스 계획 갱신
    • 잡지 데모와 경화 스프린트
  • 요약
  • 추가 자료

  • 3부 애자일 게임 개발
  • 7장 비디오 게임 프로젝트 계획
    • <미드나잇 클럽> 이야기
    • 최소 요구 피처 목록
    • 단계의 필요성
    • 개발 단계
    • 단계 혼합
    • 릴리스로 단계 관리
    • 애자일 프로젝트에서의 프로덕션
      • 프로덕션 빚
      • 프로덕션에서 스크럼의 어려움
      • 린 프로덕션
      • 스크럼으로 작업하기
      • 스크럼 팀 전환
    • 요약
    • 추가 자료

  • 8장 팀
    • 좋은 팀
    • 팀에 대한 스크럼 접근법
      • 다분야통합 팀
      • 자기 관리
      • 자기 조직화
      • 팀 크기
      • 리더
    • 게임 팀과 협업
      • 피처 팀
      • 기능 팀
      • 프로덕션 팀
      • 공용 기반 환경 팀
      • 도구 팀
      • 풀 팀
      • 통합 팀
    • 스크럼 크기 조정과 분산
      • 대형 팀의 문제
      • 스크럼의 스크럼
      • 제품 책임자의 계층 구조
      • 스프린트 날짜 맞춤
      • 실천방안 커뮤니티
      • 종속성 피하기
      • 분산 팀
    • 요약
    • 추가 자료

  • 9장 빠른 반복
    • 반복 오버헤드는 무엇으로부터 비롯되는가
    • 반복 시간 측정 및 표시
      • 반복 시간 측정
      • 반복 시간 표시
    • 개인 반복과 빌드 반복
      • 개인 반복
      • 빌드 반복
    • 요약
    • 추가 자료

  • 4부 애자일 관심 분야
  • 10장 애자일 기술
    • 문제
      • 불확실성
      • 변경이 문제를 야기
      • 늦은 변경의 비용
      • 초기에 너무 많은 아키텍처
    • 애자일 접근법
      • 익스트림 프로그래밍
      • 디버깅
      • 최적화
    • 요약
    • 추가 자료

  • 11장 애자일 아트와 음향
    • 애자일로 해결하는 문제들
    • 애자일에 대한 우려
    • 아트 리더
    • 다분야통합 팀의 아트
      • 창의적 긴장
      • 아트 QA
      • 아트 지식 구축
      • ‘아직 끝나지 않은’ 신드롬 극복
      • 예산
      • ‘마지막 단계’ 음향
      • 프로덕션에서의 협업
    • 요약
    • 추가 자료

  • 12장 애자일 설계
    • 문제
      • 기획자는 지식을 만들지 않는다
      • 게임은 마지막에 드러난다
    • 스크럼으로 설계하기
      • 모든 팀에 기획자 한 명씩?
      • 문서의 역할
      • 차고 바닥의 부품들
      • 집합 기반 설계
      • 선임 기획자 역할
      • 제품 책임자로서의 기획자
    • 요약
    • 추가 자료

  • 13장 애자일 QA 및 제작
    • 애자일 QA
      • QA의 문제점
      • 애자일에서 테스트는 단계가 아니다
    • 애자일 게임 팀의 QA 역할
      • QA를 팀에 소속시켜야 할까, 풀에 두어야 할까
      • 팀에 몇 명의 테스터가 있어야 하는가
      • 버그 데이터베이스 사용
      • 수행 테스트
      • QA의 미래
    • 애자일 제작
      • 애자일 프로젝트에서 제작자의 역할
      • 스크럼마스터로서 제작자
      • 제품 책임자 지원 역할로서 제작자
      • 제품 책임자로서 제작자
      • 제작의 미래
    • 요약
    • 추가 자료

  • 5부 시작하기
  • 14장 스크럼의 신화와 도전
    • 은총알 신화
      • 스크럼은 당신을 위해 모든 문제를 해결해줄 것이다
      • 스크럼을 사용하는 프로젝트는 항상 제시간에 출시할 수 있다
    • 두려움, 불확실성, 의심: FUD
      • 끝없는 개발
      • 관리 방법에 대한 일시적 유행
      • 이중 잣대
      • 변화는 나쁜 것
      • 끝없는 회의
    • 스크럼 도전
      • 프로세스 및 문화 변화를 위한 도구, 스크럼
      • 스크럼은 작업의 추적이 아닌 가치를 추가
      • 현재 상태 vs. 지속적인 향상
      • 화물 숭배 스크럼
      • 스크럼은 모든 사람을 위한 것이 아니다
      • 초과근무
      • 크런치
    • 요약
    • 추가 자료

  • 15장 게임회사와 일하기
    • 어려움
      • 때 늦은 집중
      • 마일스톤 대가 지급과 협업
      • 제한된 반복
      • 게임기 하드웨어 제작사 문제
      • 포트폴리오가 날짜를 좌우한다
    • 신뢰 구축, 두려움 타파
      • 두려움
      • 애자일 이해하기
      • 게임회사 측 제품 책임자
      • 조기에 프로젝트 어려움을 해결하기
      • 프로덕션 계획 관리
      • 두려움 완화
    • 애자일 계약
      • 계획보다는 반복
      • 고정된 출시일
      • 애자일 프리프로덕션
      • 스테이지 게이트 모델
    • 요약
    • 추가 자료

  • 16장 스크럼 시작하기
    • 적용의 3단계
      • 견습생 단계
      • 숙련 단계
      • 달인 단계
    • 적용 전략
      • 교두보 팀
      • 대대적인 확산
    • 요약
    • 추가 자료

  • 결론
  • 도서 오류 신고

    도서 오류 신고

    에이콘출판사에 관심을 가져 주셔서 고맙습니다. 도서의 오탈자 정보를 알려주시면 다음 개정판 인쇄 시 반영하겠습니다.

    오탈자 정보는 다음과 같이 입력해 주시면 됩니다.

    (예시) p.100 아래에서 3행 : '몇일'동안 -> 며칠동안