1. 애자일 게임 개발이란 무엇인가?, 김기웅, 강연 30분 + 질문 10분
   
2. 사례를 중심으로 알아보는 SCRUM & XP, 남기룡, 강연 30분 + 질문 10분
   
3. 중간 휴식, 10분
   
4. 테스트 주도 개발(TDD): 사례와 시연을 중심으로, 박일, 강연 30분 + 질문 10분

• 애자일 게임 개발이란 무엇인가?
  
• 그것을 도입하기 위해서는 어떻게 해야 하는가?
  
• 실제 현장에 도입했을 때, 어떤 효과가 있었고, 풀어야할 숙제는 무엇인가?
  
• 그래서 개인의 실제 업무에서는 어떻게 해야 하나? (시연에서는 실제 XP의 Practice들 중 하나인 TDD를 다룸.)

• 애자일에 관심이 있으나, 정확히 무엇인지 잘 모르는 사람.
  
• 1개 타이틀 이상의 개발 경험을 가진 사람.
• (애자일에 대해서 경험이 풍부하신 분은 참석하셔서, 질문/답변 시간이나, 토의에서 활약해주시면 감사하겠습니다!!!)
  

• 이 강연은 기존 자료들을 종합, 편집한 것으로 애자일 게임 개발에 대해서 알고 있는 분들께는 약간 지루할 수 있습니다.
  
• 그러나 이 강연의 무게 중심은 질문과 답변에 있습니다.
  
• 나아가 합숙이라는 KGDS의 특성에 맞추어, 08일(토) 저녁에 비공식적인 (패널) 토의를 계획하고 있습니다.
  

• 발표:  서미트 참가자를 상대로 게임개발과 관련된 주제를 선정하여 발표
  
• 패널:  3~5명의 인원이 게임개발과 관련된 주제를 선정하여 토론
  
• 일반:  참가비 2만원 지불. 국민은행 36143704001290 (사)한국게임개발자협회 (입금시 행사참가자와 입금자가 동일해야 합니다.)
  
• 운영진: 행사운영진으로 15명을 모집합니다.
  

• Email: hylee@kgda.or.kr
  
• 전화: 02-3153-2781
  
• Fax: 02-3153-2780

퀘이사 방법론

‘에어로너츠’ 팀은 정형화된 프로세스를 탈피, 자신들만의 독창적인 프로세스를 개발했다. 기민한 방법론(Agile Methodology)에 기초한 퀘이사(‘에어로너츠’ 개발 스튜디오 명) 방법론이 바로 그것. 순서대로 짜여있는 개발 일정에 맞춰서 개발하는 것이 아니라, 개발 진행상황에 따라서 우선순위를 두는 방법이다. 중요한 단계에 모든 힘을 집중할 수 있고 유동적인 관리가 용이해서 게임 개발에 큰 힘이된다는 것이 팀원들의 중론.

프로그램 파트 김성용 팀장은 “소규모 단위의 프로젝트에서는 무엇보다 인력 이동이 자유로워야 한다”며 “퀘이사 방법론은 ‘에어로너츠’ 개발에 많은 도움을 줬다”고 말했다. ‘에어로너츠’팀을 보조하는 각 팀들의 도움이 체계적으로 이뤄지는 점 또한 타 개발사와 다른 모습이었다. 제이씨에서 개발하는 모든 그래픽 작업은 아트센터를 통해 이뤄진다. ‘에어로너츠’도 예외는 아니다. 팀 내에 그래픽 파트가 존재하지 않지만, 더 좋은 퀄리티의 그래픽을 완성했다.

박원정 실장은 “첫 기획 단계부터 아트센터에서 파견을 나와 게임에 대한 전반적인 계획을 같이 논의하고 중간 단계마다 회의를 거치고 있다”며 “각 파트별로 떨어져 있어도 커뮤니티에는 문제가 없다”고 말했다. 이 밖에도 기술개발지원 센터에서 프로그램 인력지원, Q/A지원 등 ‘에어로너츠’팀의 개발에 전폭적인 지지를 아끼지 않고 있었다.

출처: http://www.khgames.co.kr/biz/article_g.htm?code=g_zoomin&idx=27

솔직히 말해서 실망했다. 더 크고, 확실한 성과를 기대했던 것이다.

코드의 품질이 나아질 거라고 말했지만, 사실 내 코드의 품질은 더 나빠졌다. (사실은 제대로 읽어보면, 실질적으로 나뻐진 게 아니라, 잘못 사용하고 있던 것들을 들춰내서 표면적으로 나뻐졌다는 이야기가 나옵니다.)

끝내주는 비방(silver bullet) 같은 게 아니었다.

[그러나] 내가 말하고 싶은 것은, 나는 결코 [테스트 주도 개발(이하 TDD)을 하기] 이전으로 돌아가지 않으리라는 것이다.

코드의 품질을 낮아졌지만, 코드에 대한 나의 이해는 높아졌다.

누군가는 이렇게 말할지 모르겠다. "어떤 규칙 같은 걸 만들어서, 네가 변경하는 코드를 제대로 이해하고 있는지 확인하는 건 어때? 그걸 위해서 굳이 TDD [같은 번거로운 것]을 할 필요까지는 없잖아?" 글쎄, 나는 거의 항상 변경하려는 코드를 이해하고 있다고 생각한다. 그런데 그러고 보니까 내가 정말 내가 그러고 있기는 하나? 이게 바로 TDD가 정말 도움이 되는 부분이다.

이것이야 말로, 내가 듣지 못한 TDD의 커다란 장점이다.

출처: 테스트 주도 개발 ,1년째

• 국문판: PDF
  
• 영문판: PDF, CHM 1/2 2/2