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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

  • 2,088 views
Published

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

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

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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,088
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
51
Comments
0
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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.

Transcript

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