제가 있는 팀에서는 현재 어떤 정형화된 소프트웨어 개발 프로세스도 도입해서 쓰고 있지 않습니다. 전에 다른 회사에서 스크럼 프로세스를 경험해 본 적이 있는데, 장점도 있지만 단점도 많았습니다. 다른 분야로부터 도입된 여러 소프트웨어 방법론이 대부분 그렇듯이, 스크럼 프로세스도 소프트웨어 개발, 특히 게임 개발엔 왠지 부적합해 보입니다.
스크럼 프로세스에선 일정 기간 단위로 스프린트라는 것을 정해서 계획을 미리 잡아 두라고 합니다. 그런데 게임 개발에서 30일 단위로 할 일을 정하고 일정을 정하는 게 과연 의미가 있을까요? 일정을 고정시키면 변화하는 상황에 빠르게 대처할 수 없고, 반대로 일정을 바꾸면 계획의 의미가 퇴색됩니다. 개발을 진행하다 보면 무수한 변수가 발생해서, 일정을 언제나 수정해야 할 때가 대부분입니다.
스프린트 첫날에 일정을 잡는 게 과연 정확할까요? 충분한 사전 정보 없이 일정을 잡는 게 큰 의미가 있을까요? 구현하다 보면 예상치 못한 문제가 생기기 마련이고, 그 문제를 해결하는 데 얼마나 시간이 걸릴지는 아무도 모릅니다. 따라서 스프린트 첫날에 비교적 정확한 일정을 잡는다는 것은 불가능에 가깝습니다.
스크럼 프로세스에선 회의를 매일 하기를 권장합니다. 그런데 그게 과연 큰 의미가 있을까요? 필요할 때마다 참석해야 하는 사람끼리 모여서 회의를 하는 게 낫지 않을까요? 특별한 의제 없이 회의를 한다는 것은 시간 낭비입니다.
스크럼 프로세스에선 스프린트 단위로 결과를 공개하고 회고하기를 주장합니다. 이것도 역시 필요할 때마다 공개하는 게 나아 보입니다. 외부의 요청이 있을 때 즉시 공개할 준비는 언제나 돼 있어야 하는 것이고, 반면에 회고는 필요할 때마다 하면 충분해 보입니다.
스크럼에선 스프린트 단위로 한 가지 목표를 정하라고 하는데, 별로 의미가 없습니다. 한 달 단위로 어떤 목표를 세우기가 애매합니다. 왜냐하면, 한 달 동안 한 가지 큰 일조차 못할 수도 있고, 많은 중요한 일을 할 수도 있기 때문입니다.
스크럼 프로세스에 대해 전체적으로 생각해 보면, 고정 생산 분야에나 적합한 방식을 연구 개발 위주의 소프트웨어 분야에 무리하게 적용시킨 것 같습니다.
댓글을 달아 주세요
관리자만 볼 수 있는 댓글입니다.
외부의 요청을 선택적으로 수용하는 용도라면, 스프린트 기간을 고정하는 것 대신에 요청의 우선순위에 따라서 날짜를 조정하면 충분하다고 보여요. 우선순위가 낮은 일은 자연히 나중에 처리하게 될 테니까요.
스프린트라는 것은 스프린트마다 어떤 유일하고 분명한 목표가 있을 때 의미가 크다고 생각해요. 그런데 게임 개발에선 스프린트 단위로 어떤 목표를 세우기가 어렵죠. 그러므로 스프린트 자체가 별로 의미가 없어 보여요.
일일 회의 시간의 의사소통이 정말 효과적인지 저는 궁금해요. 만약 서로 얘기할 게 있다면 일일 회의 시간에 얘기할 게 아니라, 그 즉시 얘기하는 게 나아 보여요.
음... 아직은 프로그래밍이 더 재미있으신가 보군요. ㅎㅎㅎ