아무리 좋은 방법론도 사람들이 지키려는 의지가 없거나, 불가능한 것이라면 아무런 소용이 없기 때문이죠.

이런 문제에 대해서 제가 내린 결론은 다음 두 가지입니다;

• 일련의 훈련, 연수나 교육을 통해서 사람들이 해당 방법론에 익숙해질 기회를 준다. (애자일 컨설팅에서는 그런 서비스를 제공한다고 합니다.)
  
• 위의 과정에서 불구하고, 합의한 방법론을 지키지 않는 사람에게는 몇 차례의 경고를 주되, 계속 반복할 경우, 프로젝트에서 제외시킨다.
  

가혹할지 모르지만, 게임 개발은 전장과 다를 바가 없습니다. 생명이 위험한 전장에선, 한 사람을 조직에 맞게 바꾸는 것보다, 적합한 사람을 찾는 게 더 효율적입니다. (물론 그런 사람을 찾기는 어렵지만, 그래도 결코 포기해서는 안된다고 생각합니다.)



2.

• 애자일 방법론을 교과서적으로 따라하지 않고, 팀 실정에 맞게 적당히 적용.
  
• 애자일 실천법의 기술적인 성공에만 치우치려 하지 않음 -> 재미있는 게임을 만드는 것이 목표
  

특이한 점이 있다면, AGD를 실정에 맞게 적당히 적용한다는 점입니다.

저 역시, Agile은 방법론이 아니라 일종의 체계(framework)이고, 따라서 "재미를 빨리 포착하여, 그걸 점진적으로 개발한다."라는 목적을 위해서 얼마든지 바꾸어도 좋다고 생각합니다.

다만 이것은 AGD를 충분히 실행하고, 그 의도들을 파악한 다음에 응용해야하는 것이 바람직하지 않을까 싶습니다. 예를 들어서, 자유영을 할 때, 처음에는 어색하더라도 팔을 굽히지 않고 젓도록 가르칩니다. 그래야만 나중에 익숙해졌을 때, 무의식적으로 최대한 뻗어서 젓게 되기 때문입니다.

남기룡 님도 제대로 적용하고 싶었으나, 아마도 1번의 이유로 그럴 수 밖에 없었던 것이 아닐까 싶네요. 그럴 경우에는 (지금 저도 그렇게 하듯이) 어쩔 수 없이, 일단 가능한 것부터 시행해서, 사람들을 하나둘씩 설득하는 수밖에 없겠죠.


3.

• 스크럼 팀이 프로그래머로만 구성되어 제한이 많다. 기획자, 아티스트의 참여 부재.
• 디렉터가 고객의 역할을 담당
• 고객 역할자의 스토리 완료에 대한 평가가 미약하다. 완료된 스토리를 재작업하는 일이 번번히 생김.

역시 Scrum에 아티스트와 기획자들을 포함시켜야 하지 않나 싶습니다. 이와 관련해서,  마침 번역중인 게임으로 오세요: 게임 개발자들에게 배워야 할 점들에 아래와 같은 내용이 나옵니다;

처음에 우리는 프로그래밍 부서에만 Scrum을 적용시켰다. 아티스트와 기획자들은 Scrum 프로그래밍 팀들을 조직하는 프로젝트의 고객들이었다. 우리는 고객의 요구를 전달받지 못했기 때문에(due to lack of customer input), 매 Sprint 마다 수백 번의 진행 장애를 겪고 있다는 점을 재빨리 깨달았다. 우리가 Scrum 팀들이 대부분의 장애물을 내부적으로 즉시 해결할 수 있도록 자급자족적이어야 한다는 사실을 깨달았을 때, 아티스트들과 기획자들이 팀에 합류했다.

좀더 자세한 내용은 나중에 GDC2007 - Agile Game Development Tutorial을 번역할 때, 언급하겠습니다.