'Agile의 의미'와 '기민한 계획 수립'
('What it means to be agile' & 'Agile Planning')



(아래의 첨부 파일를 받으시길 권합니다.
위의 미리보기에서는 에니메이션이나 슬라이드 노트를 볼 수 없습니다.)


GDC 2007에서 있었던 Agile Game Development Tutorial의 일부인 'Agile의 의미'와 '기민한 계획 수립'의 한글 번역입니다:
(강연자인 Mike Cohn의 허가를 받고 번역하였습니다.)

마지막으로 여러분의 소감, 비판, 경험 혹은 계획을 Trackback이나 댓글로 달아주시면 정말 감사하겠습니다.
신고

댓글을 달아 주세요


포스팅이 늦었지만, 남기룡 님의 팀에서 현황판(War Room)을 개량했다고 합니다:

우리팀의 바뀐 일정판
사용자 삽입 이미지

자세한 설명은 위의 Link에 있습니다.



아실 분들을 다 아시지만, 제 Blog만 보실 분들을 위해서 써둡니다.

마지막으로 "심심할 때마다 괴롭히도록 한다." 원츄!


P.S. 제가 실감한 이 일정판의 가장 큰 장점은, 사장님이 와서 일일히, '그거 들어갔나?' 혹은 '그 문제는 어떻게 되었어?'라고 묻는 경우가 줄어든다는 겁니다. (웃음) 물론 반대로 저도 작업자들에게 일일히 묻는 경우가 줄어들죠.

신고

댓글을 달아 주세요

  1. Favicon of http://kell.tistory.com BlogIcon Kell 2007.06.13 00:16 신고 Address Modify/Delete Reply

    아무래도 그렇겠네요 ^^ 개발인력이 아니더라도 현재 프로젝트 진행 상황을 한눈에 알아볼 수 있겠습니다.

    • Favicon of http://betterways.tistory.com BlogIcon 김기웅(Kay Kim) 2007.06.13 10:39 신고 Address Modify/Delete

      예. 그외에도 여러가지 장점이 있습니다:
      -. 각 작업자들이 전체에서 자신의 작업이 어떤 의미인지 알 수도 있고,
      -. 진행중이었던 작업을 완료로 옮길 때의 성취감이라던지.


업무의 소요 시간을 추정하는 공식으로, 게임 프로듀서 핸드북(The Game Producer's Handbook)에서 발췌했습니다.

업무에 필요해서 번역한 김에 올려둡니다.

업무의 소요 시간 = ( B + 3W + 2ML ) / 6
6번의 시도 중, 한 번 정도는 예상보다 약간 빨리 완료된다. 그리고 세 번은 예상보다 아주 늦게, 두 번은 예상에 매우 근접하게 완료된다.

이것을 적용하며 다음과 같다;

[ 5 + (3*12) + (2* 6) ] / 6 = 8.3일
  • 최선의 경우(Best): 05일
  • 최악의 경우(Worst): 12일
  • 대게의 경우(Most Likely): 06일

6으로 나누는 이유는, 가중 평균을 사용할 경우 각각이 일정에 미치는 영향을 바로 보여주기 때문이다.

최악의 경우는, 임계 경로(the critical path)에서 끝나기 때문에, 일정에 매우 중요한 경향을 미친다.

한편, 아주 가끔 일이 잘 처리되어서, 최선의 경우가 발생할 수 있다. 그러나 이런 경우가 일정에 미치는 영향은 미비하다.

만약 일정 산출에 보다 복잡한 인수와 변수들을 사용한다면, 일정 산출은 지나치게 복잡해지고 그 자체로 고통이 된다. 또한 그 덕분에 프로젝트의 진행 파악을 게을리 하게 된다면, 때에 따라서는 안하느니만 못한 경우가 될 수도 있다.


이외에도 GDC 2007에서 Duane Webb(Bioware의 제작 이사)가 강연했던 Predicting the Future - Effective Project Scheduling Tools and Techniques에도 많은 기법들이 나오는데, 나중에 시간이 되면 번역해 올리겠습니다.

신고

댓글을 달아 주세요

  1. 보고 2007.07.24 21:35 신고 Address Modify/Delete Reply

    대체 뭔 필요???

    • Favicon of http://betterways.tistory.com BlogIcon 김기웅(Kay Kim) 2007.07.26 23:36 신고 Address Modify/Delete

      '좀더 합리적으로 일정을 추정하자.'라는 의도에서 나온 것 같습니다.
      저는 제안서 등을 위해서 사전에 계획을 세울 때, 누적된 '소멸 차트'를 기반으로 추정을 하면서 써봤습니다.

어제 Dev Rookie의 스터디 (뒷풀이)에 참석했다가, "왜 게임 개발은 늘 지연될까요?"라는 질문을 들었다.

맞다. 사실 나도 의문이다;
  • 혹시 개발자들이 게을러서 그런 건 아닐까? 게임을 좋아하는 넘들이 게임을 만드니까 말이다.
    • 아니다. 성실한 사람들(우훗, 나!)도 일정이 지연된다.
  • 아니면 무능력한 건 아닐까? 생각해보면 학교를 제대로 졸업한 놈들은 대기업을 가거나, 공무원이 되지 않냐 말이다.
    • 아니다. 내 상사가 KAIST 출신에, 유학가서 금융 수학도 가르친 수재였고, 그외에도 삐까번쩍한 인물들이 있었지만, 그래도 일정이 지연된다.
  • 그것도 아니면 "개발자"란 족속은 원래 그렇게 태어난 걸까? 
    • 그럴지도 모르겠다. 이것은 자신이 없다. 사방에서 개발이 지연된다는 걸로 봐서.

이런 문제를 고민해본 성현이 혹시 계시지 않을까? 아니나 다를까, 흥신소 Google에 물어보니, Thomas Demachy가 쓴 "Extreme Game Development:  Right on Time, Every Time" 라는 글이 있다.


그 글에 따르면 각 게임들이 늦어지는 공통적인 원인들은 다음과 같다 :
  1. 기술이 너무 빨리 발전한다. (맞아!)
  2. 개발자들은 언제나 최선을 다하고 싶어한다. (당연하지!)
  3. 배급사들이 마음을 자주 바꾼다. (씨바!)

1. 기술이 너무 빨리 발전한다. 기술이 너무 빨리 진화하고 있다는 것은 사실이다. 현재 시장엔 3개의 주요 콘솔 제조업체들이 있으며 각 콘솔 제조업체들은 대략 5년마다 한 번씩 새로운 콘솔을 시장에 출시하고 있다. 결과적으로 최신 기술들을 적용하라는 강력한 마케팅 압력이 존재한다. 이러한 상황은 계속 진화하는 PC도 마찬가지다. 개발사들은 여기에 적응을 해야 한다: 보통 한 가지 기술을 한 콘솔에서 게임 한두 개 만드는데 쓰고나면 더 이상 사용할 수 없다. 이쪽 업계는 언제나 최신 기술과 함께 진화하고 있으며, 개발자들도 새로운 기술들을 계속 발견하고 있다. 새로운 기술이 좋긴 하지만, 이런 신기술들을 배우고 게임에 적용시키기 위해서는 시간이 필요하다. 물론, 이게 업계의 재미있는 점이기도 하다!

2. 개발자들은 언제나 최선을 다하고 싶어한다. 팀들은 언제나 최선을 다하고 싶어한다: 최고의 모델 제작, 최적화된 코드, 양질의 텍스처 제작 등. 이런 완벽에 대한 욕구는 동기부여의 매우 중요한 요소로 작용한다. 팀에게 최선의 실력을 발휘하도록 요구하지 않는 것은, 프로젝트를 망치는 지름길이라고 볼 수 있다.


결국 개발자들은 개발이 완전히 완료된 후(only when it's done)”에 게임을 출시하는 것을 꿈꾼다. [다시 말해서] 자신들이 게임의 세세한 부분들 하나하나에 모두 자신감이 있을 때 말이다. 그러나 이런 완벽에 대한 집착은 일정을 지연시킬 수 있다. 내부 자금이 풍부한 곳[1]이 아닌 이상, 이런 엄격한 완벽주의를 갈망하며 지연된 일정을 감당할 수 있는 팀은 없다.


3. 배급사들은 마음을 자주 바꾼다. 새로운 기술에 당황하는 것은 개발자들만이 아니다; 배급사 역시 같은 경험을 한다. 제작자들은 새로운 그래픽 카드의 가능성들을, 보고 개발팀에게 이런 것들의 이점을 이용하라고 요구한다. 또한 배급사들은 콘솔 제조업체들에게 독점 출시권을 협상한다. 한편, 콘솔 제조업체들은 개발사들을 인수하여, 자신들의 하드웨어에 맞는 게임만을 만들도록 한다. 이러한 요소들은 게임 엔진 개발에 치명적인 악영향을 주며, 결국 일정 지연의 원인이 된다.


배급사들이 마음을 바꾸는데는 또 다른 이유가 있다. 게임이 대중 시장 제품(mass market products) 이므로 마케팅 부서가 (당연히) 배급사의 정책에 대해 영향력이 있다. 만약 경쟁사의 최근 타이틀이 성공을 거두었다면, 제작자에게 해당 게임의 핵심적인 특징들을 게임에 삽입하라고 요구할 수 있다.


이런 것들은 게임 개발 과정의 큰 결점들 중 하나를 보여준다. 프로젝트가 뚜렷이 보이고 규모를 측정할 수 있는 건축업계와는 다르게 게임 개발자들이 만들어내는 제품은 무형(無形)이다. 그 누구도 건축 설계사에게 거의 완성된 건물에 두 층을 더 올리자고 말하지 않을 것이다. 그러나 게임 업계에서는 배급사가 게임 개발자에게 불과 게임 출시 몇 주 전에 한 두 개의 맵(level)을 더 추가하라는 요구가 번번히 일어나고 있는 실정이다.



[1] [역자주] Blizzard가 바로 이런 매우 드문 경우에 속한다. 여기에도 단점이 있는데, 10년 동안 게임을 두 개밖에 못만들 수도 있다.

신고

댓글을 달아 주세요

  1. 퍼즐랩 2007.04.30 15:08 신고 Address Modify/Delete Reply

    흥신소 말이 맞네요.. 결국 질문은,
    게임개발 일정을 왜 그렇게 항상 빠듯하게 잡았던가?가 되고 마는군요.. ^^

    • Favicon of http://betterways.tistory.com BlogIcon 김기웅(Kay Kim) 2007.04.30 17:25 신고 Address Modify/Delete

      문제는 (기획/설계하는 시점에서는) 그 누구도 모든 걸 예측할 수 없다는 거죠.

      그래서 변화에 적응하는 Agile 기법이 유용한데, 그 이유는;
      1) 실제 측정한 값을 사용하여 계획을 세우도록 유도하고,
      2) 주기와 다음 주기 사이에 계속적으로 변화를 수용하도록 되어 있며,
      3) 개발자가 아닌 사용자(혹은 그 대리인)이 원하는 가치(예: 재미, 편의성)에 집중하도록 해서, 만들고 보니 엉뚱한 게 나오는 걸 줄여주고,
      4) 게임이 계속적으로 돌아가도록 유지함으로써, 실제 프로젝트 진도를 파악가능하게 한다는 것입니다.

  2. Favicon of http://blog.naver.com/gamediz BlogIcon gump 2007.05.04 10:16 신고 Address Modify/Delete Reply

    너무 좋은글 잘 보고 갑니다 ^^

  3. Favicon of http://www.archflow.co.kr BlogIcon loki 2007.05.07 12:35 신고 Address Modify/Delete Reply

    기술은 현실에 맞춰야 하고, 아이디어는 미래를 맞춰야 하는데...
    보통, 대개, 일반적으론 기술을 미래에 맞추고, 아이디어를 현실에 맞추기 때문에 고루하고, 지겹고, 재미없고, 평범하고, 베낀티가 팍팍 나는 게임이 나와서 그걸 뜯어 고치다 보니 늦어진다고 보고 있습니다. ㅎㅎㅎ

    욕심을 조금만 덜 부리면 충분히 맞출수 있겠죠.

티스토리 툴바