NC Soft의 일각에서 사용한다는 소문을 들었을뿐, 현재 외부에 공개된 것으로는 MAIET entertainment가 유일한 사례가 아닌가 싶습니다. (저 자신도 작년부터 시험적으로 사용하고 있지만, 사람들의 반발과 기타 여건상 매우 제한된 것만을 사용하고 있습니다.)
주의: 이 글은 남기룡 님의 사례 발표에 반박하려는 의도는 아닙니다. (무엇이든지 하기는 어렵고, 그걸 비판하기는 쉬운 법이죠.) 그저 의견을 덧붙이는 걸로 생각해 주십시요.
1.
팀원들의 참여 의지
팀원들에게 애자일 방법론을 강요하지 않음
리더를 포함하여 팀원 모두 애자일 개발에 미숙함.
남기룡 님의 글을 보고 역시 공감하는 것은, (프로젝트 관리 자체가 그렇지만) "Agile을 적용할 때, 가장 중요한 것은 역시 사람."이라는 점입니다.
아무리 좋은 방법론도 사람들이 지키려는 의지가 없거나, 불가능한 것이라면 아무런 소용이 없기 때문이죠.
위의 과정에서 불구하고, 합의한 방법론을 지키지 않는 사람에게는 몇 차례의 경고를 주되, 계속 반복할 경우, 프로젝트에서 제외시킨다.
가혹할지 모르지만, 게임 개발은 전장과 다를 바가 없습니다. 생명이 위험한 전장에선, 한 사람을 조직에 맞게 바꾸는 것보다, 적합한 사람을 찾는 게 더 효율적입니다. (물론 그런 사람을 찾기는 어렵지만, 그래도 결코 포기해서는 안된다고 생각합니다.)
2.
애자일 방법론을 교과서적으로 따라하지 않고, 팀 실정에 맞게 적당히 적용.
애자일 실천법의 기술적인 성공에만 치우치려 하지 않음 -> 재미있는 게임을 만드는 것이 목표
특이한 점이 있다면, AGD를 실정에 맞게 적당히 적용한다는 점입니다.
저 역시, Agile은 방법론이 아니라 일종의 체계(framework)이고, 따라서 "재미를 빨리 포착하여, 그걸 점진적으로 개발한다."라는 목적을 위해서 얼마든지 바꾸어도 좋다고 생각합니다.
다만 이것은 AGD를 충분히 실행하고, 그 의도들을 파악한 다음에 응용해야하는 것이 바람직하지 않을까 싶습니다. 예를 들어서, 자유영을 할 때, 처음에는 어색하더라도 팔을 굽히지 않고 젓도록 가르칩니다. 그래야만 나중에 익숙해졌을 때, 무의식적으로 최대한 뻗어서 젓게 되기 때문입니다.
남기룡 님도 제대로 적용하고 싶었으나, 아마도 1번의 이유로 그럴 수 밖에 없었던 것이 아닐까 싶네요. 그럴 경우에는 (지금 저도 그렇게 하듯이) 어쩔 수 없이, 일단 가능한 것부터 시행해서, 사람들을 하나둘씩 설득하는 수밖에 없겠죠.
3.
스크럼 팀이 프로그래머로만 구성되어 제한이 많다. 기획자, 아티스트의 참여 부재.
디렉터가 고객의 역할을 담당
고객 역할자의 스토리 완료에 대한 평가가 미약하다. 완료된 스토리를 재작업하는 일이 번번히 생김.
처음에 우리는 프로그래밍 부서에만 Scrum을 적용시켰다. 아티스트와 기획자들은 Scrum 프로그래밍 팀들을 조직하는 프로젝트의 고객들이었다. 우리는
고객의 요구를 전달받지 못했기 때문에(due to lack of customer input), 매 Sprint 마다 수백 번의 진행 장애를 겪고 있다는 점을 재빨리 깨달았다. 우리가 Scrum 팀들이 대부분의 장애물을 내부적으로 즉시 해결할 수 있도록 자급자족적이어야 한다는 사실을 깨달았을
때, 아티스트들과 기획자들이 팀에 합류했다.
