August 14-15 2006

애자일 게임 개발 애자일 게임 개발 :: 최전선의 이야기 최전선의 이야기

(Agile Game Development:(Agile Game Development:Tales from the Trenches)Tales from the Trenches)

강연강연 : : (N oelLlopis (N oelLlopis.llopis@ convexhullcom.llopis@ convexhullcom ))

, Senior Architect H igh M oon Studios , Senior Architect H igh M oon Studios번역번역 : : 김기웅 김기웅 (( 4 .gam e kay@ gm ailcom4 .gam e kay@ gm ailcom )) . .betterw ays w o to. .betterw ays w o to

August 14-15 2006

목차 ( )C om ing up Agile D evelopm ent

조직 차원의 Agile 기법 Agile 기법을 이용한 프로그래밍

우리가 얻은 교훈들

August 14-15 2006

제 1부 : Agile D evelopm ent

August 14-15 2006

Agile D evelopm ent 를 채택하게 된 동기 계속 바뀌는 요구사항

새로운 재미 요소의 발견

불필요한 재작업 , 연이은 철야의 방지

예측하지 못했던 기술적 제약

August 14-15 2006

Agile D evelopm ent란 ?[ 상황에 따라 ] 적시 ( - - )Just in tim e 에 결정한다 .

변화에 적응한다 . ( .)Adaptto change

꼭 필요하지 않은 것을 최대한 덜 개발한다 . ( .)M axim ize w ork notdone

August 14-15 2006

Agile D evelopm ent란 ?

출발

[ 계획 ] 도착

출발

[ 실제 ?] 도착

출발

[ ] Agile 원래 목표

도착

August 14-15 2006

Agile D evelopm ent란 ?

0

20

40

60

80

100

Time

발견된 재미의 비율

희망

폭포수

August 14-15 2006

Scrum

잠재적으로 배 포 가능한 제품

일일 Scrum 회의

August 14-15 2006

( )Extrem e Program ing XP 익스트림 프로그래밍

고객에 의한 고객에 의한테스트테스트

테스트 주도 테스트 주도개발개발

공동 소유 공동 소유권권

코딩코딩표준표준

짝 프로그 짝 프로그래밍래밍

리팩토링리팩토링

안정적인 안정적인속도속도

단순한 단순한설계설계

지속적인 지속적인통합통합

작고 빈번한 작고 빈번한출시출시

계획 게 계획 게임임

포괄적인 포괄적인팀팀

메타포메타포

August 14-15 2006

제 2부 : 조직 차원의 Agile 기법

August 14-15 2006

우선 순위의 결정“ ”고객 은팀의 방향을 결정할 책임을 가진사람이다 .

고객은 다음에 할 가장 중요한 사항들 (“사 ”용자 스토리 ) 을 결정한다 . 팀은 각 사용자 스토리들의 소유 시간을 추

정한다 . 고객과 팀 사이의 의사소통은 필수적이다 .

August 14-15 2006

짧은 주기Scrum 은 30일을 , XP 는 2 주를 추천 .

둘 다 해본 후 , 현재는 2 주를 선택 . “각 주기마다 진정한 게임플레이의 독립적 인 한 부분 ( a )verticalslice ” 을 만들어 내 기 위해 노력한다 .

이전 주기에서의 결과를 다음 주기에 반영( )feed 한다 .

August 14-15 2006

짧은 주기

마일스톤마일스톤33 달달

SprintSprint22 주주

August 14-15 2006

짧은 주기

August 14-15 2006

누가 무엇을 하나 사람들은 어떤 작업 ( )task 이든 자신들이 하

고 싶은 작업을 고른다 . 사기를 촉진시키고 지식을 확신시키는데 매

우 효과적이다 . 분야별 전문가들 ( )dom ain experts 을 합류

시킬 것 .

August 14-15 2006

일정 관리

August 14-15 2006

팀의 구성 여러 개의 작은 팀들 . (8~ 12명 .)

팀원들을 탁 트인 사무실에 배치 . 짧고 빠 른 토론과 의사소통에 매우 유용 .

원래는 오로지 프로그래머들에게만 적용되었으나 , 현재는 모든 영역이 다 포함 .

대규모 팀은 Scrum 들의 (Scrum Scrum of)scrum s 형태를 권장 .

August 14-15 2006

팀의 구성

August 14-15 2006

안정적인 속도

August 14-15 2006

안정적인 속도

시간

업무강도

계획 구현 Alpha B eta 출시

주기

August 14-15 2006

제 3부 : Agile 을 기법을 응용 한 프로그래밍

August 14-15 2006

짝 프로그래밍( )Pair Program m ing

August 14-15 2006

August 14-15 2006

짝 프로그래밍 프로그래머 한 명이 하는 것보다 두 배의 효

과가 날까 ? 약간 낮지만 ( 약 1.7배 ), 다른 어마어마한

장점들이 있음 : 훨씬 좋은 품질의 코드 훨씬 좋은 품질의 코드

지식지식 // 철학의 확산 철학의 확산 공동체 정신 공동체 정신 ( )Team spirit( )Team spirit

장기적인 측면에서는 커다란 이익 .

August 14-15 2006

짝 프로그래밍 모든 사람들이 선호하는 것은 아니지만 , 정

말 많은 프로그래머들이 실천하고 있다 . 어떤 팀들은 거의 항상 사용하지만 , 어떤

팀들은 그보다 적게 사용한다 . 그 밖의 장점 : 강도 높은 근무와 높은 집중력 . 느슨해지거나 , 늘어질 여유가 별로 없다 . 8 시간 동안 열심히 일하고 나면 기진맥진해진다 !

August 14-15 2006

테스트 - 주도 개발

체크 - 인체크 - 인

테스트작성

코드작성

리팩토링

August 14-15 2006

테스트 - 주도 개발요점 : 테스트 - 코딩 - 리팩토링의 반복 .

모든 코드마다 프로그래머가 유니트 테스트 를 작성한다 .

설계 방법론 . 이렇게 하면 리팩토링 및 최적화하기가 훨

씬 쉬워진다 .

August 14-15 2006

테스트 - 주도 개발 유니트 테스트 프레임워크 ( ++)U nitTest 를 사용

한다 .X 360box 에서 실행하는 것은 좀더 힘들지만 ,

실행 가능하다 . 프로그램을 실행하고 출력값 ( )output 과 반환값

( 최종 결과 ) 을 기록할 수 있어야 한다 .Xbreboot 가 실제로 그 역할을 한다 .

H igh M oon Studio 는 XboxM anagerC lass API 를 사용했다 .

August 14-15 2006

지속적인 통합 작고 매우 빈번한 체크 - 인 . ( 약 3~ 5 분

마다 .) 코드가 체크 - 인 되자마자 , 구축이 시작된

다 . 구축이 실패할 경우 , 즉시 사람들에게 알린

다 . 유니트 테스트는 게임을 안정화시키는데 매

우 유용하다 .. C ruiseC ontrolN et 강추 !

August 14-15 2006

August 14-15 2006

지속적인 통합 우리만의 규칙 : 어느 누구도 자신의 마지막

체크 - 인이 제대로 구축되는지 확인될 때까 지 퇴근할 수 없다 .

구축을 빨리 하면 할수록 좋다 . 따라서 논 리적이고 물리적인 의존 관계에 주의를 기

울일 것 . ( 일반적인 체크 - 인에 대한 응답 시간은 보통 10~ 20 초 정도 .)

단 , U nrealEngine 의 경우에는 훨씬 오래걸린다 .

August 14-15 2006

코드 공동 소유“ 코드 소유권의 실종 ( no code

)ow nership ” 이 아닌 , 진정한 코드 공동 소유 .

유니트 테스트와 공유하고 있는 배경 지식 에 달려 있다 .

August 14-15 2006

자동화된 테스트TD D 에 따른 유니트 테스트는 자동화된 테

스트의 일부분에 지나지 않는다 . 기능 테스트 ( ) Functionaltests : 프로그램

전체나 그 일부에 시행한다 . 완전 자동화 . 빌드 서버에서 최소 하루에

한 번씩은 시행한다 . ( H igh M oon Studios 는 매 2 시간마다 시행 .)

동시에 목표로 하는 플랫폼들에서도 테스트한다 .

August 14-15 2006

자동화된 테스트

August 14-15 2006

제 4부 : 우리가 얻은 교훈들

August 14-15 2006

어떤 효과가 있나 ? 중요한 것들을 먼저 발견한다 . ( ' W e re

.)discovering the im portantstuff first

엄청나게 향상된 코드의 품질 . 더욱 견고해진 빌드들 . 정말 행복해하는 사람들 . ( People are .)really happy

August 14-15 2006

개선의 여지가 있는 부분들은 ? 팀의 구성

어떻게 더 많은 자원들을 공유할 것인가 어떻게 더 많은 자원들을 공유할 것인가 ?? 서로 다른 업무와 사고 방식을 가진 사람들을 융 서로 다른 업무와 사고 방식을 가진 사람들을 융

합시킬 것인가 합시킬 것인가 ? (? (프로그래머프로그래머 , , 아티스트아티스트 , , 기획기획자자 .).)

August 14-15 2006

개선의 여지가 있는 부분들은 ? 팀의 자율

ScrumScrum 의 중요한 목표 의 중요한 목표 . . 많은 진보가 있었지만 많은 진보가 있었지만 , , 발전의 여지가 남아 있다 발전의 여지가 남아 있다 ..

팀은 자신들의 업무를 완수하기 위한 것이라면 팀은 자신들의 업무를 완수하기 위한 것이라면 무엇이나 할 수 있는 권한을 위임 받았다는 점을 무엇이나 할 수 있는 권한을 위임 받았다는 점을

깨달을 필요가 있다 깨달을 필요가 있다 .. 약간의 리더쉽이 필요할 때가 가끔 있다 약간의 리더쉽이 필요할 때가 가끔 있다 ..

August 14-15 2006

개선의 여지가 있는 부분들은 ? 비생산적인 시간

ScrumScrum 은 검토와 계획에 각각 하루씩 할당할 것 은 검토와 계획에 각각 하루씩 할당할 것 을 권장한다 을 권장한다 ..

따라서 따라서 10 10 업무일 중 업무일 중 22 일이 소비된다 일이 소비된다 . . 팀이 팀이 여러 개일 경우에는 더 늘어난다 여러 개일 경우에는 더 늘어난다 .. 최근 우리는 불필요한 시간을 최소화하기 위해 최근 우리는 불필요한 시간을 최소화하기 위해

서 몇 가지를 바꾸었고 서 몇 가지를 바꾸었고 , , 현재는 검토와 계획을 현재는 검토와 계획을 같은 날 한다 같은 날 한다 ..

August 14-15 2006

Agile D evelopm ent 의 도입 우리는 Scrum 의 표준 규칙들을 게임 개발

에 맞게 변경했다 . 처음에는 규칙대로 하고 , 나중에 실정에 맞

게 바꿔라 . 프로젝트의 한 부분을 담당하는 작은 팀에

서부터 시작하라 .XP 는 아무런 큰 변화없이 쉽게 도입 가능하다 .

August 14-15 2006

참고 자료 G am es from W ithin G am es from W ithin

:// . .http w w w gam esfrom w ithin com:// . .http w w w gam esfrom w ithin com

Agile G am e D evelopm ent Agile G am e D evelopm ent:// . .http w w w agilegam edevelopm entcom:// . .http w w w agilegam edevelopm entcom

.llopis@ convexhullcom.llopis@ convexhullcom

질문 ?( 오역이나 수정에 대한 의견은 아래의 주소로 언제든지 연락을 주십시요 :

4 .gam e kay@ gm ailcom )