Upload
kay-kim
View
2.629
Download
0
Embed Size (px)
Citation preview
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 )