애자일 게임 개발을 이용한 게임 기획
(Game Design in Agile Development)


...
Agile의 역사는 60년전으로 거슬러 올라갑니다. 좀더 자세히 말하자면 일본 캐논 카메라입니다. 당시 캐논은 심각한 재정난에 봉착해 있었죠. 그래서 회사는 기술자들과 영업사원들 및 생산직 근로자들을 한 곳에 몰아놓고는, "회사를 구할 신제품을 만들어라!"는 특명을 내렸습니다.
그에 따라, 제품 개발 전영역에 걸친 여러 사람들이 한 방에 매일 모여서, 이야기를 나누고, 브레인스토밍을 하고, 협력한 끝에, 마침내 회사를 구할 신제품을 만들어냈습니다.
...
High Moon Studios에서는 어떤 기능(feature)의 가치를 기획서가 아니라, [게임에 넣어서] 직접 화면으로 보고 평가합니다. 게임 개발자는 기획서를 파는 게 아니라, 게임을 팝니다. 그렇지 않습니까?
...
(애자일에서는) 프로세스와 프로젝트 관리 도구보다 사람들과 의사 소통을 더 중요시합니다. 이게 정확히 무슨 뜻인지 예를 들어서 설명해보죠.
엑셀 시트의 간트 차트(Gantt chart)에 기능 A가 40시간에 끝난다고 나온다고 합시다. 반면에 프로그래머에게 얼마나 걸려냐 물으니, "2주 정도 걸릴 것 같은데."라고 하는 겁니다.
이 경우에, 우리는 간트 차트보다는 프로그래머의 의견에 더 비중을 두며, 이것이 바로 프로세스와 프로젝트 관리 도구보다 사람들과 의사 소통을 더 중요시한다는 의미입니다.


GDC 2007에서 있었던 "애자일 게임 개발을 이용한 게임 기획(Game Design in Agile Development)"의 강연 녹음입니다. 애자일 게임 개발을 이용한 게임 기획(Game Design in Agile Development)의 슬라이드와 함께 보시면 더욱 좋습니다.

(안타깝지만 당연히도) 영어이고, MP3 Player에 넣어서 일하시거나 출퇴근할 때 들으시면 좋습니다.

10Mb 이상을 올릴 수 없어서 두 개로 쪼개서 올립니다.
:



애자일 게임 개발(Agile Game Development) 강연 녹음

한 가지 더 말씀드리고 싶은 게 있다면, 애자일 게임 개발은 게임을 만드는 방법이 아니라, 그저 '프로세스'에 지나지 않는다는 것입니다. (중략) 끝내주는 게임을 만드는 최소한의 조건은 [끝내주는 프로세스가 아니라] 끝내주는 팀을 만드는 겁니다. (중략) 더  좋은 프로세스가 더 좋은 게임을 만든다는 걸 말하려는 게 아닙니다. 그저 좋은 팀이 [더 좋은 결과를 낼 수 있도록] 돕는 것뿐이죠.
(The other thing I'd like to mention as well, I'm not apealing this is the way to make games. This is a just a process. ... Really bottom line is a great game makes a great game. ...  It's not about which better process gonna produce a better game. This is just helping great teams.)



GDC 2007에서 있었던 "애자일 게임 개발(Agile Game Development)"의 강연 녹음입니다. 애자일 게임 개발(Agile Game Development)의 슬라이드와 함께 보시면 더욱 좋습니다.

(당연하지만) 영어이고, MP3 Player에 넣어서 일하시거나 출퇴근할 때 들으시면 좋습니다.

10Mb 이상을 올릴 수 없어서 두 개로 쪼개서 올립니다.
:

애자일 게임 개발: 최전선의 이야기
(Agile Game Development:Tales from the Trenches)



(아래의 첨부 파일를 받으시길 권합니다.
위의 미리보기에서는 에니메이션이나 슬라이드 노트를 볼 수 없습니다.)
영어 원문

..
..
MS Gamefest 2006의 에서 있었던 '애자일 게임 개발: 최전선의 이야기(Agile Game Development:Tales from the Trenches)'의 한글 번역입니다:
  • Agile Development
  • 조직 차원의 Agile 기법
  • Agile 기법을 이용한 프로그래밍
  • 우리가 얻은 교훈들

(강연자인 Noel Llopis 씨의 허가를 받고 번역하였습니다.)

마지막으로 여러분의
소감, 비판, 경험 혹은 계획을 Trackback이나 댓글로 달아주시면 정말 감사하겠습니다.

:

'Agile의 의미'와 '기민한 계획 수립'
('What it means to be agile' & 'Agile Planning')



(아래의 첨부 파일를 받으시길 권합니다.
위의 미리보기에서는 에니메이션이나 슬라이드 노트를 볼 수 없습니다.)


GDC 2007에서 있었던 Agile Game Development Tutorial의 일부인 'Agile의 의미'와 '기민한 계획 수립'의 한글 번역입니다:
(강연자인 Mike Cohn의 허가를 받고 번역하였습니다.)

마지막으로 여러분의 소감, 비판, 경험 혹은 계획을 Trackback이나 댓글로 달아주시면 정말 감사하겠습니다.
:

애자일 게임 개발: 현실 세계의 혼돈을 다루는 법
(Agile Game Development: Dealing With Chaos In The Real World)



(가급적 아래의 압축 파일을 받으시길 권합니다.
위의 슬라이드에는 '슬라이드 노트'와 에니메이션이 없습니다.)

영어원문: http://www.gamesfromwithin.com/articles/0411/000047.html


MIGS 2004에서, Noel Llopis가 발표한 "애자일 게임 개발: 현실 세계의 혼돈을 다루는 법"의 슬라이드 한글판입니다.

주요 내용은 다음과 같습니다:
  • 왜 Agile Game Development이 필요한가?
  • Agile Development와 게임 개발
  • Scrum과 게임 개발
  • XP와 게임 개발
2004년의 내용이라, 그 뒤에 발표된 내용들과 다른 점들이 있습니다. 특히 어떤 기준으로 Scrum팀을 조직하는가에 대한 부분은 슬라이드 노트에 적은 자료를 참고하시기 바랍니다.

:

애자일 소프트웨어 개발에는 여러가지 기법들이 있습니다. 여기서 언급되는 XP와 Scrum은 그것들 중 하나죠. 다음 글에서는 애자일 게임 개발에서 언급되지 않았던 다른 몇가지 기법들을 소개합니다:


애자일 소프트웨어 개발

애자일 소프트웨어 개발은 90년대 후반에 시작되었다. 이 당시에는 Kent Beck이 소프트웨어 플래닝, 코딩, 디자인, 테스팅의 가치와 원리와 방법론을 통해 Extreme Programming (XP)을 선보였던 때이다. (Extreme Programming: A gentle introduction 참조)

모든 애자일 소프트웨어 개발 방식에는 여러 가치들이 있다:

  • 잦은 검사와 적용
  • 주기적인 배포
  • 협업과 긴밀한 커뮤니케이션
  • 반응적 향상
  • (점증적인) 요구 사항, 기술, 팀 기능의 탄생
  • 권한 부여와 자가 구성
  • 인도물이 아닌 현재의 것 다루기
  • 용기와 존경

오늘날 다양한 애자일 방식들은 각기 다른 방법들을 강조하고 있다.

2001년 2월, Agile Manifesto가 만들어지면서, 개인과 프로세스와 툴을 통한 인터랙션, 포괄적인 문서를 통한 소프트웨어 작동, 계약 협상을 통한 고객 협업, 플랜을 따르는 것 이상으로 변화에 대응하는 것 등에 가치가 매겨졌다. 이는 오늘날 사용되는 모든 애자일 방식의 토대가 된다.

먼저, 가장 일반적으로 사용되는 애자일 방식을 설명하고자 한다. 이들 중 많은 것들이 SOA 개발에도 유용하다. SOA는 소프트웨어 개발 그 이상이라는 것은 우리도 알고 있다. SOA는 비즈니스와 IT 아키텍처에 관한 것이기도 하다. 따라서 소프트웨어 개발 방식을 생각할 때면 언제나 이것이 SOA에 적합한지를 평가해야 한다. 적합성 평가에 대해서는 다음 시리즈에서 다루도록 하겠다.


Scrum

Scrum은 단순해 보이지만 작업에 영향을 주고 핵심적인 애자일 특징을 지닌 방식을 갖추고 있다. Scrum의 특징은 스스로 방향을 설정한 팀, 매일 매일의 팀 평가, 규정된 프로세스 지양이라는 특징이 있다. 다음은 Scrum의 기본적인 특징이다.

  • 스스로 방향을 설정하고 구성한 팀
  • 특별한 문제(무엇을 했는가, 무엇을 할 것인가, 문제가 무엇인가) 들을 주제로 한 매일 매일의 미팅
  • 30일 주기 반복
  • 매번 반복을 시작할 때 고객 위주의 적응성 플래닝
  • (각 반복의 끝에) 스테이크홀더에 기능을 선보임

엔터프라이즈의 경우, 프로젝트 간 의존성을 이해하고 관리하는 것이 중요하다. 이것은 Scrum에서 "글로벌 백로그(global backlog)"를 통해 잘 관리되고 있다. 이는 사용자가 가치를 두고 있는 기능적 요구 사항과 비기능적 요구 사항을 엔터프라이즈 관점에서 본 것이다. 글로벌 백로그에서는 전체적인 우선순위가 정해진다. 각 프로젝트는 글로벌 백로그에서 자신들에게 가장 중요한 부분들을 취한다. 프로젝트 간 동기화 역시 Scrum of Scrums"에서 다루고 있다. 팀들간 동기화를 위해서 각 팀의 대표들과 이틀에 한번 또는 매주 미팅을 갖는다.


XP

XP (http://www.extremeprogramming.org와 http://www.xprogramming.com)는 협업, 빠른 소프트웨어 구현, 매우 기술적인 개발 방식을 강조한다. 이것은 주요 관행들(함께 앉기, 전체 팀, 정보가 풍부한 작업 공간, 짝(pair) 프로그래밍, 주간 반복, 여유, 10분 구현, 연속 반복, 테스트 우선 프로그래밍, 점증적인 디자인)과 부차적인 관행들(실제 고객 개입, 점증적인 전개, 뿌리 원인 분석, 공유 코드, 싱글 코드 기반, 협상된 범위 계약, 사용에 따른 비용 지불)로 구성된다.


Crystal

Crystal은 주기적인 인도(delivery), 긴밀한 통신, 반응적인 향상을 강조하는 방법론이다. Crystal의 특징은 다음과 같다:

Crystal에서 우선순위는 프로젝트 결과의 안정성, 개발 효율성, 규율 지키기 등이다. 프로젝트 팀은 7 개의 특징을 지니고 있다. (첫 번째 세 개는 Crystal의 핵심이고, 다른 것들은 안정성을 위해 필요한 것들이다.):

  • 잦은 검사와 적용
  • 주기적인 배포
  • 긴밀한 커뮤니케이션; 개인적인 안정성
  • 포커스
  • 전문 사용자들로의 쉬운 액세스
  • 자동화된 테스팅을 갖춘 기술 환경
  • 설정 관리
  • 잦은 통합


Dynamic Systems Development Method

The Dynamic Systems Development Method (DSDM)는 시스템을 구현하고 관리하는 제어 프레임웍을 제공한다. 촉박한 시간 제약을 맞추고 반복적인 Rapid Application Development (RAD) 성공을 위한 방법을 제시한다. 이 방식은 개발자 관점의 RAD 뿐만 아니라 효과적인 시스템 개발에 관심이 있는 모든 사람들의 요구들을 포용한다. 아래 리스트는 DSDM의 관리 원리이다:

  • 적극적인 사용자 개입이 필요하다.
  • DSDM 팀은 결정을 내릴 수 있어야 한다.
  • 목표는 제품의 주기적인 인도이다.
  • 비즈니스 목적에 맞추는 것은 인도물의 필수 기준이다.
  • 반복적이고 점증적인 개발은 정확한 비즈니스 솔루션으로 수렴되어야 한다.
  • 개발 시 모든 변경 사항들은 원상으로 되돌릴 수 있어야 한다.
  • 요구 사항들은 고급 레벨을 기반으로 우선순위가 정해져야 한다.
  • 테스팅이 라이프 사이클에 통합된다.
  • 모든 이해 관계자들간 협업이 필요하다.

출처: http://www.ibm.com/developerworks/kr/library/ws-agile1/index.html
원문: http://www.ibm.com/developerworks/webservices/library/ws-agile1

위의 글은 발췌본이니, 가능하시다면 전문을 한 번 읽어보시길 권해드립니다.

:

Yahoo Group의 Scrum Development에 올라왔던 글. (Agile Game Develoment blog에서 재인용.)

Scrum은 다음의 두 경우 모두에 매우 효과적입니다:
  1. 일정이 고정되어 있지만 개발 범위는 유동적이거나,
  2. 개발 범위가 고정되어-하지만 늘상 그렇듯 늘어나죠-있고 일정이 유동적일 때.
하지만 만약 일정과 개발 범위 모두 고정되어 있다면,

저는 당신께 폭포수나 RUP(Rational Unified Process)를 권하겠습니다.

최소한 다른 일자리를 알아볼 몇달 간의 시간을 벌어줄테니까요.



웃기면서도 굉장히 진지한 조언이군요. 적용할 때, 염두에 두어야 할 듯 합니다. (웃음)
:

애자일 게임 개발을 이용한 게임 기획
(Game Design in Agile Development)


GDC 2007의 "애자일 게임 개발을 이용한 게임 기획(Game Design in Agile Development)"입니다.

다루고 있는 내용은 다음과 같습니다: 애자일 게임 개발을 적용할 때,
  • 게임 기획자들이 입는 혜택
  • 달라지는 점들
  • 주의해야 할 난관들

대부분의 애자일 관련 자료들이 프로젝트 관리나 프로그래밍을 다루고 있다는 점에서, 현재까지는 게임 기획에 관한 유일한 자료입니다.

이것으로 '(좋은 것 같긴 한데) 그래서 애자일을 어떻게 내 업무에 적용할까?'라는 기획자의 고민이 조금이나마 줄었으면 좋겠습니다.


..

(아래의 PPT를 받으시길 권합니다.
아래의 PPT에는 중요한 슬라이드 노트와 애니메이션이 포함되어 있습니다.)



Rory Mcguire의 허가를 받고 번역하였으며, 원문(의 축약판)은 이곳에서 받으실 수 있습니다.

마지막으로 여러분의 의견을 Trackback이나 댓글로 남겨주시면, 다른 분들과 의견을 공유하고, 다음 번역에 더 큰 도움이 될 듯 합니다.

감사합니다.

===============================================================================================
갱신 이력
  • 2007년 06월 12일
    • 맞춤법 교정.
  • 2007년 06월 04일
    • p.9, p.32: 슬라이드 노트 추가
    • p.11, p.47: 맞춤법 교정.
===============================================================================================
:

마이크로소프트웨어(2007년 3월호)에 실린 Agile에 대한 특집입니다. 이미 애자일 이야기오픈마루 블로그를통해서 보신 분들도 있겠지만, 아닐 분들을 위해서 올려둡니다.


변화를 꿈꾸는 개발 방법론 애자일(Agile)
  1. 애자일이란 무엇인가? (강석천)
  2. 오픈마루 개발 환경에서 본 애자일 (강규영)
  3. 애자일의 미래 (김창준)

:

Scrum을 설명하는 좋은 글이 올라왔길래 추천해드립니다.
사용자 삽입 이미지


글을 올려주신 jeddli 님께 감사드립니다!
: