애자일 게임 개발: 최전선의 이야기(Gamefest 2006)
Upcoming SlideShare
Loading in...5
×
 

애자일 게임 개발: 최전선의 이야기(Gamefest 2006)

on

  • 2,961 views

Gamefest 2006에서 있었던, '애자일 게임 개발: 최전선의 이야기(Agile Game Development:Tales from the Trenches)'의 한글판. ...

Gamefest 2006에서 있었던, '애자일 게임 개발: 최전선의 이야기(Agile Game Development:Tales from the Trenches)'의 한글판.

자세한 것은 http://betterways.tistory.com/183 참조.

Statistics

Views

Total Views
2,961
Views on SlideShare
2,881
Embed Views
80

Actions

Likes
3
Downloads
45
Comments
0

3 Embeds 80

http://betterways.tistory.com 78
http://www.hanrss.com 1
http://blog.naver.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 05/02/07 19:01 ©2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

애자일 게임 개발: 최전선의 이야기(Gamefest 2006) 애자일 게임 개발: 최전선의 이야기(Gamefest 2006) Presentation Transcript

  • August 14-15, 2006
  • 애자일 게임 개발 : 최전선의 이야기 (Agile Game Development: Tales from the Trenches)
      • 강연 : Noel Llopis ( [email_address] )
      • Senior Architect, High Moon Studios
      • 번역 : 김기웅 ( [email_address] )
      • betterways.wo.to
  • 목차 ( Coming up)
    • Agile Development
    • 조직 차원의 Agile 기법
    • Agile 기법을 이용한 프로그래밍
    • 우리가 얻은 교훈들
  • 제 1 부 : Agile Development
  • Agile Development 를 채택하게 된 동기
    • 계속 바뀌는 요구사항
    • 새로운 재미 요소의 발견
    • 불필요한 재작업 , 연이은 철야의 방지
    • 예측하지 못했던 기술적 제약
  • Agile Development 란 ?
    • [ 상황에 따라 ] 적시 ( Just-in-time) 에 결정한다 .
    • 변화에 적응한다 . ( Adapt to change.)
    • 꼭 필요하지 않은 것을 최대한 덜 개발한다 . ( Maximize work not done.)
  • Agile Development 란 ? 출발 [ 계획 ] 도착 출발 [ 실제 ?] 도착 출발 [Agile] 원래 목표 도착
  • Agile Development 란 ?
  • Scrum 잠재적으로 배포 가능한 제품 일일 Scrum 회의
  • Extreme Programing (XP) 익스트림 프로그래밍 고객에 의한 테스트 테스트 주도 개발 공동 소유권 코딩 표준 짝 프로그래밍 리팩토링 안정적인 속도 단순한 설계 지속적인 통합 작고 빈번한 출시 계획 게임 포괄적인 팀 메타포
  • 제 2 부 : 조직 차원의 Agile 기법
  • 우선 순위의 결정
    • “ 고객”은 팀의 방향을 결정할 책임을 가진 사람이다 .
    • 고객은 다음에 할 가장 중요한 사항들 (“ 사용자 스토리” ) 을 결정한다 .
    • 팀은 각 사용자 스토리들의 소유 시간을 추정한다 .
    • 고객과 팀 사이의 의사소통은 필수적이다 .
  • 짧은 주기
    • Scrum 은 30 일을 , XP 는 2 주를 추천 .
    • 둘 다 해본 후 , 현재는 2 주를 선택 .
    • 각 주기마다 진정한 “게임 플레이의 독립적인 한 부분 (a vertical slice) ” 을 만들어 내기 위해 노력한다 .
    • 이전 주기에서의 결과를 다음 주기에 반영 ( feed) 한다 .
  • 짧은 주기 마일스톤 3 달 Sprint 2 주
  • 짧은 주기
  • 누가 무엇을 하나
    • 사람들은 어떤 작업 (task) 이든 자신들이 하고 싶은 작업을 고른다 .
    • 사기를 촉진시키고 지식을 확신시키는데 매우 효과적이다 .
    • 분야별 전문가들 ( domain experts) 을 합류시킬 것 .
  • 일정 관리
  • 팀의 구성
    • 여러 개의 작은 팀들 . (8~12 명 . )
    • 팀원들을 탁 트인 사무실에 배치 . 짧고 빠른 토론과 의사소통에 매우 유용 .
    • 원래는 오로지 프로그래머들에게만 적용되었으나 , 현재는 모든 영역이 다 포함 .
    • 대규모 팀은 Scrum 들의 Scrum( Scrum of scrums) 형태를 권장 .
  • 팀의 구성
  • 안정적인 속도
  • 안정적인 속도 시간 업무 강도 계획 구현 Alpha Beta 출시 주기
  • 제 3 부 : Agile 을 기법을 응용한 프로그래밍
  • 짝 프로그래밍 ( Pair Programming)
  •  
  • 짝 프로그래밍
    • 프로그래머 한 명이 하는 것보다 두 배의 효과가 날까 ?
    • 약간 낮지만 ( 약 1.7 배 ), 다른 어마어마한 장점들이 있음 :
      • 훨씬 좋은 품질의 코드
      • 지식 / 철학의 확산
      • 공동체 정신 (Team spirit)
    • 장기적인 측면에서는 커다란 이익 .
  • 짝 프로그래밍
    • 모든 사람들이 선호하는 것은 아니지만 , 정말 많은 프로그래머들이 실천하고 있다 .
    • 어떤 팀들은 거의 항상 사용하지만 , 어떤 팀들은 그보다 적게 사용한다 .
    • 그 밖의 장점 : 강도 높은 근무와 높은 집중력 . 느슨해지거나 , 늘어질 여유가 별로 없다 . 8 시간 동안 열심히 일하고 나면 기진맥진해진다 !
  • 테스트 - 주도 개발 체크 - 인 체크 - 인 테스트 작성 코드 작성 리팩토링
  • 테스트 - 주도 개발
    • 요점 : 테스트 - 코딩 - 리팩토링의 반복 .
    • 모든 코드마다 프로그래머가 유니트 테스트를 작성한다 .
    • 설계 방법론 .
    • 이렇게 하면 리팩토링 및 최적화하기가 훨씬 쉬워진다 .
  • 테스트 - 주도 개발
    • 유니트 테스트 프레임워크 (UnitTest++) 를 사용한다 .
    • X box 360 에서 실행하는 것은 좀더 힘들지만 , 실행 가능하다 .
    • 프로그램을 실행하고 출력값 (output) 과 반환값 ( 최종 결과 ) 을 기록할 수 있어야 한다 .
    • Xbreboot 가 실제로 그 역할을 한다 .
    • High Moon Studio 는 XboxManagerClass API 를 사용했다 .
  • 지속적인 통합
    • 작고 매우 빈번한 체크 - 인 . ( 약 3~5 분 마다 .)
    • 코드가 체크 - 인 되자마자 , 구축이 시작된다 .
    • 구축이 실패할 경우 , 즉시 사람들에게 알린다 .
    • 유니트 테스트는 게임을 안정화시키는데 매우 유용하다 .
    • CruiseControl.Net 강추 !
  •  
  • 지속적인 통합
    • 우리만의 규칙 : 어느 누구도 자신의 마지막 체크 - 인이 제대로 구축되는지 확인될 때까지 퇴근할 수 없다 .
    • 구축을 빨리 하면 할수록 좋다 . 따라서 논리적이고 물리적인 의존 관계에 주의를 기울일 것 . ( 일반적인 체크 - 인에 대한 응답 시간은 보통 10~20 초 정도 .)
    • 단 , Unreal Engine 의 경우에는 훨씬 오래 걸린다 .
  • 코드 공동 소유
    • “ 코드 소유권의 실종 (no code ownership)” 이 아닌 , 진정한 코드 공동 소유 .
    • 유니트 테스트와 공유하고 있는 배경 지식에 달려 있다 .
  • 자동화된 테스트
    • TDD 에 따른 유니트 테스트는 자동화된 테스트의 일부분에 지나지 않는다 .
    • 기능 테스트 ( Functional tests) : 프로그램 전체나 그 일부에 시행한다 .
    • 완전 자동화 . 빌드 서버에서 최소 하루에 한 번씩은 시행한다 . (High Moon Studios 는 매 2 시간마다 시행 .)
    • 동시에 목표로 하는 플랫폼들에서도 테스트한다 .
  • 자동화된 테스트
  • 제 4 부 : 우리가 얻은 교훈들
  • 어떤 효과가 있나 ?
    • 중요한 것들을 먼저 발견한다 . ( We're discovering the important stuff first.)
    • 엄청나게 향상된 코드의 품질 .
    • 더욱 견고해진 빌드들 .
    • 정말 행복해하는 사람들 . ( People are really happy.)
  • 개선의 여지가 있는 부분들은 ?
    • 팀의 구성
      • 어떻게 더 많은 자원들을 공유할 것인가 ?
      • 서로 다른 업무와 사고 방식을 가진 사람들을 융합시킬 것인가 ? ( 프로그래머 , 아티스트 , 기획자 .)
  • 개선의 여지가 있는 부분들은 ?
    • 팀의 자율
      • Scrum 의 중요한 목표 . 많은 진보가 있었지만 , 발전의 여지가 남아 있다 .
      • 팀은 자신들의 업무를 완수하기 위한 것이라면 무엇이나 할 수 있는 권한을 위임 받았다는 점을 깨달을 필요가 있다 .
      • 약간의 리더쉽이 필요할 때가 가끔 있다 .
  • 개선의 여지가 있는 부분들은 ?
    • 비생산적인 시간
      • Scrum 은 검토와 계획에 각각 하루씩 할당할 것을 권장한다 .
      • 따라서 10 업무일 중 2 일이 소비된다 . 팀이 여러 개일 경우에는 더 늘어난다 .
      • 최근 우리는 불필요한 시간을 최소화하기 위해서 몇 가지를 바꾸었고 , 현재는 검토와 계획을 같은 날 한다 .
  • Agile Development 의 도입
    • 우리는 Scrum 의 표준 규칙들을 게임 개발에 맞게 변경했다 .
    • 처음에는 규칙대로 하고 , 나중에 실정에 맞게 바꿔라 .
    • 프로젝트의 한 부분을 담당하는 작은 팀에서부터 시작하라 .
    • XP 는 아무런 큰 변화없이 쉽게 도입 가능하다 .
  • 참고 자료
      • Games from Within http://www.gamesfromwithin.com
      • Agile Game Development http://www.agilegamedevelopment.com
      • [email_address]
    질문 ? ( 오역이나 수정에 대한 의견은 아래의 주소로 언제든지 연락을 주십시요 : [email_address] )