Clinton Keith가 Agile Game Development with Scrum(스크럼과 함께 하는 애자일 게임 개발)라는 책을 쓰고 있습니다.

현재 "Chapter 3 Scrum"까지 나왔고, 사라진 "Chapter 1 Crisis"과 Chapter 2 Why Agile은 이곳에서 받으실 수 있습니다.


자세히 살펴보지는 않았지만, 시작은 흥미롭습니다:

비디오 게임 개발의 개척기는 완전히 사라졌습니다. 혼자서 기획하고, 프로그래밍하고, 그림을 그렸던 프로그래머는 전문가 집단으로 대체되었습니다. 제품을 지퍼락 봉투에 담아 팔던 산업이 이제는 헐리우드 박스 오피스보다 더 많은 돈을 긁어들이고 있습니다. 산업으로서 우리는 한 차원 성장했습니다.

하지만 너무 급격히 성장한 나머지, 우리는 몇 가지 실수를 저질렀습니다. ...(중략)... 우리는 재미있는 게임으로부터 엄청난 재미를 제거하는 괴물을 만들어냈습니다. 그 괴물은 수백만 명을 즐겁게 만들겠다는 희망을 품고 게임 산업에 들어온 재능이 넘치는 사람들의 열정을 먹어치웠습니다. 수개 월의 야근으로 점철된 프로젝트들이 그 괴물을 살찌웠습니다. 많은 개발자들이 게임 산업을 떠나가면서, 수년간의 경험도 함께 가져가 버렸습니다. 이렇게 될 필요까지는 없었는데. 

- Clinton Keith, <Agile Game Development with Scrum> Chapter 1 Crisis


제2장은 애자일이 게임 개발에 어떤 이점을 가져다 주는지를 설명하고 있습니다. 제게 인상 깊었던 구절은 다음과 같습니다:

애자일을 도입할 때의 난관은 구체적인 실천법의 적용이 아닙니다. 실천법은 단순합니다. 진짜 난관은 개발 조직(studios)과 애자일 사이의 충돌에 있습니다. 스크럼과 같은 애자일 프레임워크는 모든 것을 투명하게 합니다. 최선의 결과물을 방해하는 모든 결함들을 낱낱이 밝혀냅니다. 기획 문서를 신봉하기 보다, 매 개발 주기마다 게임은 자신의 가치를 스스로 증명해 보여야 합니다. 만약 게임의 가치가 보이지 않는다면, (프로젝트의 취소와 같은) 어려운 질문에 답할 필요가 있습니다.

투명성에 근거한 개발이 애자일 적용의 성공 열쇠입니다. "측정과 적응(inspect and adapt)"의 원칙은 모든 수준에서 적용되 필요가 있습니다. 그것은 현재 상태를 위협할 것이기 때문에, 그것은 용감한 지도자와 성공을 향한 넓은 시각을 필요로 합니다. 끈기를 가지고 끝까지 지켜보고, 현상을 유지하려는 타성과 싸우는 사람들에게 애자일은 더 나은 게임과 경력을 위한 길을 열어줄 수 있습니다.

- Clinton Keith, <Agile Game Development with Scrum>, Chapter 2 Why Agile?

실천법 자체는 지극히 상식적이며, 간단합니다. 문제는 언제나 기존 가치관과의 충돌에 있습니다. 하지만 그 문제를 해결하는 방법은 언제나 스크럼 밖에 있고, 그게 제 책장에 설득과 컨설팅에 관한 책들이 가득한 이유일 것입니다.


무엇보다 저는 뒤의 Chapter들이 기다려집니다. 그 이유는, 얼마전부터 스크럼의 한계를 느끼고 있고, 좀더 유연한 린(Lean)에서 보완책을 찾고 있었는데, 마침 작년부터 Clinton이 칸반과 가치 흐름과 같은 린의 개념들을 소개하고 있기 때문입니다. 어떤 대답이 나올지, 또 그것은 제 것과는 어떻게 다를지 조금은 기대됩니다.

더불어 내년 즈음에 이 책으로 또 인사를 드릴 수 있으면 좋겠네요.

:

이번 KGC 2008에서 '애자일 게임 개발 도입하기 (월드 카페)'를 개최합니다.


원활한 진행을 위해서 사전 신청을 권해드립니다: http://www.onoffmix.com/e/istoriae/439

특히, 전체에게 자신의 경험을 발표(약 5분, 슬라이드 10장 이하)하시는 10분께는 KGC 2일권을 드립니다.

:
지인에게 책을 추천하면서, 애자일 관련 서적을 적어보았습니다. 혹시나 빠진 책이 있으면 댓글이나 트랙백으로 달아주십시요.

출간 서적
불확실성과 화해하는 프로젝트 추정과 계획
카테고리 컴퓨터/인터넷
지은이 마이크 콘 (인사이트, 2008년)
상세보기
 
스크럼
카테고리
지은이 켄 슈와버 (인사이트, 2008년)
상세보기
애자일 프랙티스
카테고리 자연과학/공학
지은이 벤캣 수브라마니암 (인사이트, 2007년)
상세보기
애자일 회고
카테고리 컴퓨터/인터넷
지은이 에스더 더비 (인사이트, 2008년)
상세보기
사용자 스토리
카테고리 자연과학/공학
지은이 마이크 콘 (인사이트, 2006년)
상세보기
린 소프트웨어 개발
카테고리 자연과학/공학
지은이 메리 포펜딕 (인사이트, 2007년)
상세보기
린 소프트웨어 개발의 적용
카테고리 자연과학/공학
지은이 메리 포펜딕 (위키북스, 2007년)
상세보기
엔터프라이즈급 애자일 방법론 (예약판매)
카테고리
지은이 딘 레핑웰 (에이콘출판, 2008년)
상세보기
익스트림 프로그래밍(Extreme Programming)
카테고리 자연과학/공학
지은이 켄트 벡 (인사이트, 2006년)
상세보기
EXTREME PROGRAMMING INSTALLED
카테고리 컴퓨터/인터넷
지은이 론 제프리즈 외 (인사이트, 2002년)
상세보기
EXTREME 프로그래밍
카테고리 자연과학/공학
지은이 스튜워트 베어드 (인포북, 2003년)
상세보기
XP로 접근하는 IT 프로젝트 관리와 구현
카테고리 컴퓨터/인터넷
지은이 박형일 (사이텍미디어, 2005년)
상세보기
테스트 주도 개발 (CD-ROM 포함)
카테고리 자연과학/공학
지은이 켄트 벡 (인사이트, 2005년)
상세보기
레거시 코드 활용 전략 (예약판매)
카테고리
지은이 마이클 C. 페더스 (에이콘출판, 2008년)
상세보기
실용주의 프로그래머
카테고리 컴퓨터/인터넷
지은이 앤드류 헌트 (인사이트, 2007년)
상세보기
실용주의 프로그래머를 위한 프로젝트 자동화
카테고리 컴퓨터/인터넷
지은이 마이크 클라크 (인사이트, 2005년)
상세보기
실용주의 프로그래머를 위한 버전관리 USING CVS
카테고리 컴퓨터/인터넷
지은이 데이비드 토머스 (인사이트, 2004년)
상세보기
단위 테스트
카테고리 컴퓨터/인터넷
지은이 데이비드 토머스 외 (인사이트, 2004년)
상세보기
지속적인 통합: 소프트웨어 품질을 높이고 위험을...
카테고리 컴퓨터/인터넷
지은이 폴 M. 듀발 (위키북스, 2008년)
상세보기
윈도우 프로젝트 필수 유틸리티
카테고리 컴퓨터/인터넷
지은이 이재홍 (한빛미디어, 2008년)
상세보기
리팩토링
카테고리 자연과학/공학
지은이 마틴 파울러 (대청미디어, 2002년)
상세보기
리팩터링 워크북
카테고리 자연과학/공학
지은이 윌리엄 웨이크 (인사이트, 2006년)
상세보기
패턴을 활용한 리팩터링
카테고리 자연과학/공학
지은이 조슈아 케리에브스키 (인사이트, 2006년)
상세보기
AGILE 소프트웨어 개발
카테고리 자연과학/공학
지은이 ALISTAIR COCKBURN (피어슨에듀케이션코리아, 2002년)
상세보기
소프트웨어 개발의 지혜 (AGILE SOFTWARE...
카테고리 자연과학/공학
지은이 로버트 C.마틴 (야스미디어, 2004년)
상세보기
성공적인 소프트웨어 개발 프로젝트를 위한 실용...
카테고리 자연과학/공학
지은이 자레드 리차드슨 (위키북스, 2007년)
상세보기

 

근간 예정 서적

요즘 USD도 올랐는데, 좀더 기다리셨다가 레이옷의 저주를 피하시기 바랍니다.
Scrum and Xp from the Trenches
Henrik Kniberg
(역자: 심우곤한주영, 엄위상)


관련 서적

제가 애자일을 이해하거나, 실천하거나, 도입하는데 도움이 되었던 책들을 적어봅니다.
죽음의 행진(문제 프로젝트에서 살아남는 법)
카테고리 경영/경제
지은이 에드워드 요든 (소동, 2005년)
상세보기
:
"스크럼: 팀의 생산성을 극대화시키는 애자일 방법론" 표지

"스크럼: 팀의 생산성을 극대화시키는 애자일 방법론"(원제: Agile Software Development with Scrum)은 스크럼을 정식으로 소개하는 최초의 책으로서, 그야말로 필독서라고 할 수 있습니다.

스크럼(Scrum)은 익스트림 프로그래밍(XP)와 더불어 애자일에서 가장 널리 사용되는 기법입니다. 익스트림 프로그래밍이 엔지니어링에 가깝다면, 스크럼은 프로젝트 관리에 가깝습니다. 그러나 이런 상호보충적인 성격으로 인해서 실제로는 둘을 동시에 사용하는 경우가 많습니다.

이 책을 통해 얻을 수 있는 것들은 다음과 같습니다:
  • '폭포수' 같은 기존의 방법론들이 왜 실패할 수밖에 없는가?
  • 그렇다면 어떻게 다르게 해야 하는가(실천법practice)?
  • 궁극적으로 우리가 추구해야할 것들(가치value)은 무엇인가?


:
단위 검사를 위한 VisualStudio Addin인, VisualUnitTest++ v0.1이 나왔습니다:
사용자 삽입 이미지

UnitTest++뿐 아니라, CppUnitLite, CppUnitLite2도 지원한답니다. (압박을 가해주신 윤창필 님께 감사.)

다만 Addin이다 보니 버그가 있어서 죽는 경우는, Visual Studio가 뻗어버린다네요. (그 경우에는 이곳에 댓글로 상세한 버그 리포팅을 해달랍니다.)

참고로 Project page는 다음과 같습니다: http://vutpp.springnote.com

마지막으로 제작해주신 쑥갓 님께 진심으로 감사드립니다!

:
2007년을 마감하는 의미에서 '애자일 게임 개발이란 무엇인가?'의 발표 자료를 올립니다:

(사내 교육용으로 시작해서, KGDS 2007, DevRookie의 스터디, KGC 2007를 거치면서 조금씩 갱신되었습니다.)

이 자료의 제작 목적은 애자일 게임 개발의 개념과 도입의 실마리를 제공하는 것입니다:
  1. 왜 애자일 게임 개발이 필요한가?
  2. 애자일 게임 개발이란 무엇인가?
  3. 애자일 게임 개발은 기본 개발과 어떻게 다른가?
  4. 애자일 게임 개발 사례들
  5. 애자일 게임 개발을 도입하려면 어떻게 해야 하지?
  6. 애자일, 그래서 한 마디로 하면 뭔데?
  7. 참고 자료 목록


제 강연에 참석해주신 분들, Blog를 방문해주신 분들, 댓글과 Tracback을 보내주신 분들, 모두 감사드립니다.

새해에 복 많이 받으십시요!
:

"애자일 게임 개발: 실천과 도입" in KGC 2007은 실수도 있었고, 의도하지 않은 방향으로 흘러간 점들도 있지만, 사람들의 관심을 불러일으키는 데에는 어느 정도 성공한 듯 합니다:

제 입장에서 오늘의 하이라이트는 바로 이 세션이었다고 저는 생각합니다. XP, SCRUM, TDD등을 실제로 게임 업계에서 적용해본 사례들을 여러 패널분들의 경험담을 통해 들을 수 있었고, 애자일 개발에 대한 패널들의 조언이나 생각들을 들어볼 수 있는 멋진 시간이 되었다고 생각합니다. 1시간이란 시간이 이렇게 아쉽게 느껴지기는 오랜만이었습니다.
출처: http://sizuha.egloos.com/3477350
총 세 개의 session을 들었는데, 모두 Agile 방법론과 관련된 session이었습니다. 세 session 모두 나쁘지 않았지만, 마지막 session이었던 panel 토의 시간이 가장 좋았습니다.
출처: http://opengameprogramming.net/sureong/414


사실 이번 패널 토의는 DevRookie에서의 강연 방식을 응용한 것이었습니다:
스터디를 애자일 하게 진행하시겠다는 기웅님의 예고가 있었는데, 역시나 시작부터 기민한 대응을 하시더군요. 프로젝트가 아닌 평면 TV를 보시더니 잘 안보이지 않을까 하면서 책상을 뒤로 치우자 하셨고, TV 앞에 의자를 끌어 당겨 모이게 하였습니다. 그렇게 서로의 간격을 30cm 내외로 두고 모두 TV앞에 모인체로 스터디가 시작 되었습니다. 

기웅님의 강연을 기다리고 있는데, 스터디를 어떻게 진행할지, 궁금한 사항이 뭔지, 스터디 참가자가 토론을 통해 정하게 하시더군요. 결국 5분의 회의를 통해 '애자일이란 무엇인가', '애자일 개발의 성공 사례', '애자일 개발 도입' 이란 주제가 정해졌고, 이에 대한 스터디가 시작 되었습니다. 

뭔가를 소개하거나 새로운 개념을 강연하는 방식이 아닌 약간의 설명과 질문 그리고 답변이 반복적으로 진행 되는 스터디였는데 뭔가 다들 참여하고 있구나 하는 생각이 들었습니다. 스터디 중간 중간에도 계속해서 참가자들의 피드백을 구하시고 강연이 아닌 토론을 하는듯한 스터디였습니다. 평소보다 40분 정도 늦게 끝났지만, 예고하셨던 대로 애자일한 재미있는 스터디였습니다

출처: http://cafe.naver.com/devrookie/1488

하지만 제가 몇 가지 놓친 점이 있었습니다:
  • 청중이 불과 수십 명일 거라 예상했는데, 130여 명에 달했다. (그래서 패널리스트들과 청중들 사이의 거리가 매우 멀었다.)
  • 전에는 3시간 정도였지만, 이번에는 1시간밖에 주어지지 않았다.

그래서 다음 번에는 이렇게 해보려고 합니다:
  1. 한 질문 당 논의 시간을 정해서 빠듯하게 가야 한다. (그 외에도 한 주제에 발언할 수 있는 발언자의 수를 제한하거나, 한 번 발언당 2분을 넘지 않는다 등.)
  2. (오늘처럼 시간이 부족한 경우에는) 진행자가 누가 발언하겠냐고 묻지 말고, 바로 발언자를 지목하는 게 효과적일 수 있다.
  3. 사전에 질문을 확정하고 토의를 시작하자. Blog, Email 혹은 Wiki를 통해서 미리 질문을 선별하고, 여유가 있을 때에 현장에서 별도의 질문을 받자.
  4. 미리 준비하자. 특히 자세하지는 않더라도, 사전에 간단하게 제목만이라도 적힌 PPT를 준비하자.
  5. 패널 토의를 두 개 이상로 나누어서, 청중의 수를 작게 유지하자.


마지막으로 "애자일 게임 개발: 실천과 도입" in KGC 2007에 참석해주신 130여 명의 분들께 모두 감사드립니다! 덕분에 흥미로운 경험과 좋은 교훈을 얻었습니다!!!

:

KGC 2007에 참석하시는 분들 중 애자일 게임 개발'에 대해서 궁금한 게 있으신 분은 Ntreev Zone에 들러주세요!

제가 근무하는 Ntreev에서 KGC 2007에 Ntreev Zone라는 휴게실을 열니다.
  • 편히 앉아서 쉴 수 있는 의자
  • 다른 사람들과 이야기를 나눌 탁자가 있고,
  • 커피나 녹차 같은 음료수도 제공하고,
  • 인터넷 접속이 가능한 PC들도 몇대 놓여 있습니다.
  • 더 좋은 점은, 무료이고 누구나 올 수 있다는 점!
  • 위치는 KINTEX 307호입니다.

예를 들자면, 아래에 있는 Google Developer Night의 그것과 비슷한 거죠:

사용자 삽입 이미지

주의: 본 사진과 Ntreev Zone은 직접적인 연관이 없습니다.



저는 강연을 듣거나 하는 게 아니라면, 8일과 9일 양일에 걸쳐서 이곳에 쉬고 있을 것 같습니다.

저와 함께 놀아주실 분은 이곳에 들러주세요! :)

:

일일 스크럼 회의를 제안하자, 관리자가 당신에게 윽박을 지릅니까?

"테스트 주도 개발"에 대해 이야기할 때마다, 동료들이 여러분을 비웃습니까?

짝 프로그래밍을 하고 싶지만, 누구도 함께 하려하지 않나요?


여러분이 이제는 이게 당연하다고 생각할지도 모르겠습니다.

하지만 우리는 다르게 생각합니다.

만약 여러분이나 여러분이 아는 누군가가 이와 같은 상황에 놓여 있다면,
"애자일 게임 개발: 도입과 실천"에 참석해보십시요.

우리가 어떻게 여러분을 도울 수 있을지 확인해 보십시요.


여러분의 생각, 방법과 길이 틀리지 않았다는 확신을 얻어가십시요.

당신의 동료들과 관리자를 데려와서, 우리가 여러분을 대신해서 싸우게 하십시요.

폭력을 이용한 협박이 아니라, 우리의 성공 사례로 그들을 설득하게 해주십시요.

그 밖에도 여러분이 원하시는 바를 댓글로 달아주시면 참고하겠습니다.




'Game > Production' 카테고리의 다른 글

Ntreev Zone으로 놀러오세요!  (2) 2007.11.07
Scrum의 핵심  (6) 2007.10.11
Agile에 관한 난상토론 참가자 접수 시작!!!  (6) 2007.09.27
:
(Link가 잘못 걸려 있어서 수정했습니다.)

고맙게도 황상철 님께서  정리해주셨네요:

전적으로 제가 생각하기에, 좀 무거운 도구들(Bugzilla)도 포함되어 있고, 게임 개발에 일반적으로 잘 사용하지 않는 기술이나 언어(예: Java)도 포함되어 있지만, 참고할만 하다고 생각합니다.

언제 애자일 (게임) 개발을 위한 도구들을 정리해서 올려보겠습니다.

'Game > Programming' 카테고리의 다른 글

UnitTest++용 GuiRunner가 나왔습니다.  (2) 2007.11.17
테스트 주도 개발 ,1년째  (4) 2007.08.27
리팩토링 카달로그(Refactoring catalog)  (0) 2007.08.26
: