출처: p. 24, Better Software (November, 2006)

작성: Clinton Keith

번역: 김기웅, Nikopole(교정), Khazad(교정)

SUPPORTING THE DISCIPLINES

서로 다른 분야들에 대한 지원

Agile을 적용하기 전에, 우리 프로젝트 팀들은 각각 일단의 프로그래머들, 기획자들, 아티스트들로 분리되어 있었다. 이것은 공통된 분야의 기술(shared disciplinary skills)을 갖고 있을 경우에는 훌륭한 방식이었으나, 게임이 정상적으로 돌아가도록 하는 간접 비용(the overhead)을 증가시켰다. 우리가 Agile을 적용했을 때, 이 점이 명확해졌고, 변화가 필요했다. 초반에 저항이 있었고, 이것이 결과적으로는 우리를 요소 제작팀들(feature teams)로 변화시켰다.

처음에 우리는 한 개의 특정 분야가 주도하는 여러 개의 “기능 제작팀들(functional teams)”을 구성했다. (예를 들어, AI 팀은 대부분 프로그래머로 이루어진다.) 몇 달 후, 문제들이 발생했다. AI 팀은 ‘진공 상태’[1]에서 자신들의 작업물을 만들었다. AI의 요구사항(requirements)이 실제 게임 내에서 개발되고 시험되기 보다는, AI를 사용하는 모든 팀들이 필요로 하는 아키텍처를 제공하는데 초점을 둔 프로그래머 위주의 팀에 의해 개발되었던 것이다. 따라서 매 주기가 끝날 때마다, 아키텍처는 진보했으나, 실제 게임에서의 활용도는 별로 증가하지는 않았다.

그 다음, 우리는 기능 제작팀들(functional teams)에서 “요소 제작팀들(feature teams)”로 변화해갔다. 요소 제작팀들(feature teams)은 사격이나 주행 메카닉과 같은 서로 다른 분야의 연계가 필요한 게임 플레이의 독립적인 한 부분(a vertical slice of game play)을 만드는데 초점을 맞추었다. 목표는, 게임 플레이의 독립적인 한 부분을 반복적으로 개발하는데 필요한, 개발의 모든 분야를 취급하는 자급자족적인 팀이다.

“요소 제작팀들(feature teams)”로 전환한 결과, 핵심 기술의 개발 노력이 분산되었다. 예를 들어, 우리는 하나의 기능별 조직이 전체 프로젝트를 위한 하나의 AI를 만드는 대신, 각 요소 제작팀들(feature team)의 한두 명이 각각 AI를 만들도록 했다. 이 조치는 여러가지 문제들을 일으켰는데, 우선적으로는 기술 개발이 분열되는 양상을 초래했다. 이런 방식은 다양한 가능성을 탐색하는 초기(early exploration)에는 좋을지 몰라도, 전적으로 문제가 많았다. 우리는 마치 별개의 게임을 만드는 것처럼 행동하고 있었지만, 결과적으로 우리가 전체 게임을 위한 단 하나의 AI 시스템이 필요하게 될 것이라는 것을 알았다. 또한 우리는 요소 제작팀들(feature teams)이 자원을 놓고 서로 경쟁하는 것을 목격했다. 이 방식은 모든 팀들이 전체 프로젝트의 일부분이라는 인식을 심어주지 못했다.

해결책은 추가로 각 전문 분야마다 가상의 팀들(virtual teams)을 조직하는 것이었다. 프로그래머들은 자신들의 Scrum Master[2] 한 명과 팀을 이루고, 그들은 일주일에 최소 한 번 이상 만나서, 팀의 기술적인 발전 방향을 논의했다. 프로그래밍 분야의 Scrum Master는 다른 분야(아트 및 기획)의 Scrum Master들과 만나서 게임의 비전을 창출한다. 이것은 각각의 분리된 팀들이 보다 효과적으로 의사 소통하도록 해줄 뿐만 아니라, 그들 모두가 최종 제품의 한 부분이라는 점을 인식시켰다.

DEVELOPMENT PHASES

개발 단계

Agile 게임 개발법은 폭포수(waterfall) 모형에서 제시된 프로젝트 단계들을 인정한다. 예를 들어서, 컨셉 발전 단계(the concept-development phase)에서는 고객이 창조적인 목표들을 전반적으로 그려볼(visualize) 수 있도록, 게임의 창조적인 가능성들과 한계들을 실험해본다. 개발 도중에는 게임 프로젝트의 가능성을 충분히 탐색하기가 불가능하다. 고객은 게임을 위한 라이센스와 함께 마케팅적인 척도나 요구사항들을 갖고 있을 것이며, 이것은 사전-시각화(pre-visualization)[3]와 원화(concept art)를 필요로 한다.

CRUNCH TIME

야근

SUMMARY

요약

우리는 Agile을 어떻게 비디오 게임 개발에 응용할 것인지를 계속해서 탐색해 보고자 한다. 대가는 크다. 진보된 방법론은 게임 가격이 합리적이 되도록, 개발비를 줄여준다. 또한 극소수만이 창조적인 도전을 기꺼이 받아들이고, 나머지 대부분은 위험을 무릅쓰려 하지 않는 추세(the increasing risk-averse trend)에 편승하지 않도록 도와준다. 현재 영화나 스포츠 라이센스를 기반으로 한 게임들과 성공적인 전작의 후속작들이 시장의 많은 부분을 차지하고 있다. 새로운 지적 재산이나 참신한 아이디어를 이용한 타이틀들을 개발하는 데, 막대한 돈을 투자하는 것은 너무 무모해 보일지도 모른다. 그러나 엔터테인먼트 산업에서 소비자의 돈과 관객의 관심은 더없이 소중하다. 비디오 게임의 전반적인 가치와 재미를 감소시키는 추세는 시장을 축소시켜서, 게임 산업의 모두에게 피해를 줄 것이다. Agile은 새로운 경험을 실험하고, 참신한 아이디어를 반복적으로 개발하여, 게임 속에서 재미를 빨리 그리고 자주 찾을 수 있도록 해주며, 우리의 고객을 즐겁게 하는 동시에 증가시키는, 보다 나은 길을 열어주는 체계(framework)를 제공할 것이다. {끝}

해당 주제에 대한 보다 자세한 정보를 원한다면, www.StickyMinds.com/bettersoftware에 들러볼 것.

l  사전 제작: 재미의 요소들(Pre-production: elements of fun)