저는 보고 소름이 돋더군요:
일본의 통신어체를 한국에 맞게 정확히 번역하다니, Sims 이후의 최고의 번역입니다.

:

실전 애자일 게임 개발
(Agile Game Development From The Trenches)


===================================================================================================
갱신 이력
  • 2007년 06월 02일: p. 33~35쪽의 슬라이드 노트를 추가했습니다.
===================================================================================================


이번에는 "실전 애자일 게임 개발"입니다. Noel LlopisMontreal International Game Summit 2006에서 발표한 내용을 번역했습니다.

주요 내용은 Agile 기법들 중의 하나인 XP를 다루고 있습니다. Clinton Keith가 주로 다룬 Scrum이 프로젝트 관리에 가깝다면, XP는 좀더 프로그래밍에 가깝습니다. 실전이라는 표현답게, 비교적 구체적인 실천 사항들(practices)을 이야기합니다. (from the trenches를 직역하면 '(최전선의) 참호로부터'가 됩니다.)

(가급적 아래의 압축 파일을 받으시길 권합니다.
위의 슬라이드에는 '슬라이드 노트'가 없습니다.)



한편 Noel Llopis의 허가를 받고 번역했으며, 원본의 출처는 이곳입니다.

마지막으로 마음껏 퍼가시되, 가능하다면 trackback을 남겨주시면 서로 관심사나 정보를 공유하는데 도움이 되지 않을까 싶습니다.
:


Microsoft의 소프트웨어 개발 방법
(21 Rules of Thumb - How Microsoft develops its Software)



목차:

제1부: 일정 맞추기
   1. 아는 체 하지 마라.
   2. 상황을 파악한 다음에 움직여라.
   3. 제품-일정-비용의 삼각형을 기억하라.
   4. 어둠 속으로 돌진하지 마라.
   5. 무결점 이정표를 사용하라.
   6. 팀워크를 유지하라.
   7. 일정에는 조삼모사가 없다.
   8. 일정이 밀리면, 전열을 가다듬으라.
   9. 밑바닥 기술이 중요하다.
  10. 설계할 때는 설계만 한다.
  11. 만들어야 출시할 수 있다.
  12. 호환성은 카누 만들 때나 필요하다.

제2부: 위대한 소프트웨어
  13. 고객을 감동시켜라.
  14. 통일성이라는 한 가지 명제만 기억하라.
  15. 설계 사상을 명확하게 잡아라.
  16. 비교하라.
  17. 균형을 맞춰라
  18. 발전시켜라.
  19. 제품을 층층이 쌓아라.
  20. 공유할 비전을 정하라.

제3부: 출시
  21. 팀을 항상 출시 모드로 유지하라.

전문


Agile이라 불리던, 실용주의라 불리던, 혹은 경험에서 우러나온 어림짐작(Rule of thumb)이건, 성공적인 소프트웨어를 만드는 건 똑같다는 생각이 듭니다. 위의 21가지 중에서 Agile에서도 강조되는 것들을 골라보면 다음과 같습니다:
   6. 팀워크를 유지하라.
   7. 일정에는 조삼모사가 없다.
  11. 만들어야 출시할 수 있다.
  13. 고객을 감동시켜라.
  18. 발전시켜라.
  19. 제품을 층층이 쌓아라.
  21. 팀을 항상 출시 모드로 유지하라.

:

마이크로소프트웨어(2007년 3월호)에 실린 Agile에 대한 특집입니다. 이미 애자일 이야기오픈마루 블로그를통해서 보신 분들도 있겠지만, 아닐 분들을 위해서 올려둡니다.


변화를 꿈꾸는 개발 방법론 애자일(Agile)
  1. 애자일이란 무엇인가? (강석천)
  2. 오픈마루 개발 환경에서 본 애자일 (강규영)
  3. 애자일의 미래 (김창준)

:

사용자 삽입 이미지

서쪽/남쪽에서 침입하는 적이 각각 동쪽/북쪽에 도달하지 못하도록 막아라!


IGDA Causal Game SIG메일링 리스트에서 발견한 플래쉬 게임입니다:
  • 게임의 목적은 서쪽과 북쪽에서 들어오는 적들이 각각 동쪽과 남쪽에 도달하지 못하도록 막는 것입니다.
  • 이를 위해서 공격 기능을 갖춘 탑들을 배치합니다.
  • 적을 죽이면 돈을 얻고, 그것으로 새로운 탑을 건설하거나, 기존 탑을 업그레이드할 수 있습니다.
  • 팁을 알려드리면, 동쪽과 남쪽 주변의 길을 빙돌아가도록 탑을 건설하는 것입니다.
  • 단, 날아다니는 적(Flying)은 지상의 진로를 무시하니, X축과 Y축에 따라 별도의 대공망(Antiair Tower)를 구축하시길 권해드립니다.


:

einsub 님이 10대 공개 게임 엔진 (Top 10 Open Source Engines)을 올려주셨군요.
  1. OGRE
  2. Irrlicht
  3. Crystal Space
  4. jME
  5. Panda3D
  6. Reality Factory
  7. The Nebula Device 2
  8. RealmForge GDK
  9. Blender Game Engine
  10. OpenSceneGraph
이중에서 접해본 건 Ogre3D 하나뿐이네요.

Reality Factory는 "C++ 코딩을 할 줄 모르는 사람들이 간편하게 게임을 제작할 수 있도록 래핑했다"는데, 그래서 어느 정도의 프로그래밍 실력이 필요한지 궁금합니다. XNA와 비교할 때, 어느 쪽이 더 나을런지. (요즘 주요 관심사 중의 하나는 쉽고, 간단하게 Prototype을 만드는 거라.)

혹시 위의 엔진들 중에서 사용해 보신 게 있으면 경험담을 Trackback이나 답글로 달아주시면 감사하겠습니다!


(마지막으로 출처인 DevMaster3D Engines Database을 통해서 상용 및 공개 게임 엔진들에 대한 정보를 제공하고 있으며, 여러가지 기준들(예: 물리, Graphics API, 지원 OS 등)에 따라서 손쉽게 찾아볼 수 있습니다.)
:

지난번의 "실전 애자일 게임 개발"의 지속적인 통합(Continuous Integration)을 하려면, 코드가 제출될 때마다, 구축을 해야 합니다.

이걸 일일히 하려다 보면, 프로그래밍할 시간을 앗아갈 것이 틀림없죠. 그런데 만약 이걸 놀고 있는 PC에게 대신시킬 수 있다면? 이걸 자동화해주는 게 바로 "CruiseControl"입니다.

CruiseControl이 하는 일은 크게 두 가지입니다:
  • 자동 구축: 정기적으로 혹은 필요할 때마다(예: 코드가 제출될 때마다) 자동으로 구축을 시도한다.
  • 결과 보고: 구축이 완료된 후, (HTML 형태의) 결과 보고서를 생성한다.
    • 왼쪽에서는 해당 프로젝트의 이름이전 빌드에 대한 정보를,
    • 오른쪽에서는 빌드의 결과(예:컴파일 오류, 테스트 결과, 이전 빌드 이후로 변경된 파일들)에 대한 정보를 제공한다.

사용자 삽입 이미지

CruiseControl의 결과 화면



따라서 CruiseControl를 사용하(여 지속적인 통합을 하):
  1. 프로그래머가 프로그래밍에 집중할 시간이 늘어나고,
  2. 오랜 시간이 걸리는 빌드를 퇴근한 후, 자동적으로 시행되게 할 수 있으며,
  3. 일일 빌드를 통해 모든 코드가 제대로 동작하는지 검증할 수 있습니다.

CruiseControl가 다른 도구들에 비해 가지는 장점들은:

CruiseControl 설치시에 참고할만한 글이나 서적은 다음과 같습니다:

지속적인 통합(CI)에 도움이 될만한 글들은 아래와 같습니다:

CruiseControl외의 고려해볼만한 CI Server들은 다음과 같습니다:

마지막으로 현재 CruiseControl을 사용하고 계신 분이 있다면, 그 사용 후기를 Trackback(혹은 답글)으로 부탁드립니다. 불행히도 저는 프로그래머도 아니고, TDD를 반기는 프로그래머들을 만나지 못해서, 아직까지 CruiseControl를 사용해보지 못했네요.
:

애자일 이야기에 "극과 극"으로 올라온 글로 생산성의 원동력에 대한 색다른 시각을 던져줍니다. (아래는 일부만 발췌했으니 원문을 꼭 보세요.)

XP 개발을 위한 개발 생산성 향상 파노라마 (2006/12/16)

"마이크로소프트(이하 MS)의 XIT Sustained Engineering 팀은 MS의 80여개의 애플리케이션을 유지 보수한다. 주로 버그 수정(작업 시간이 120시간 미만인 것들) 같은 작은 변경 요청을 처리하는데, 하나의 변경 요청이 처리되기까지 걸리는 시간(리드타임)이 통상 5개월이었다. 해당 팀은 비즈니스 유닛에서 최악의 퍼포먼스를 차지한 셈이다.

그런데, 새로운 자원을 추가하지 않고, 기존의 설계, 코딩, 테스팅 등의 엔지니어링 작업 방식에 변화를 주지 않으면서 어떻게 작업이 쌓이고(queue) 추정하는지를 바꾸는 것만으로 9개월 만에 리드타임을 14일로 줄였다. 아무리 긴 변경 요청도 5주를 넘지 않았다. 납기일을 맞추는 확률은 이전의 0%에서 90%가 넘는 수치로 바뀌었다.

이제 이 팀은 해당 유닛에서 최고의 팀으로 바뀌었다. 최악에서 최고로.

이 사례의 성공 요인은 린(Lean)과 제약 이론 그리고 애자일 원리를 적용한 데서 찾을 수 있다.

사람들은「우리는 인력이 부족해」라는 말을 쉽게 뱉는다. 그 말은 모든 다른 문제를 탈색시켜 버리는 강력한 효과가 있다. 「입 다물어」가되는 셈이다. 인력이 부족하다고 말하는 순간 더 이상 논의가 필요 없게 되는 것이다. 필자는 그 이면에 우선 상상력의 빈곤이 자리 잡고 있다고 본다."

출처: 마이크로소프트 (ZDnet에서 재인용)

참고로 제가 김창준 님을 익스트림 프로그래밍의 역자 이전에, ZDnet의 기고가로 기억하게 만든, 아주 인상깊은 글입니다.
:

고맙게도 남기룡 님께서 Noel LlopisA Day in the Life를 번역해주셨군요:

01


말마따나 XP 중에서짝 프로그래밍을 게임에 활용하는 모습을 생생하게 보여주고 있습니다.

(참고로 A Day in the Life는 개발자 지망생들에게 게임 개발자들의 일상을 소개하고자 하는 목적으로 개설된
Game Developer Magazine의 취업 안내서(Career Guide)의 한 코너입니다.)

마지막으로 시간을 쪼개서 번역해주신 남기룡 님께 감사드립니다!
:

Scrum을 설명하는 좋은 글이 올라왔길래 추천해드립니다.
사용자 삽입 이미지


글을 올려주신 jeddli 님께 감사드립니다!
: