03. 게임 기획 매니지먼트 스크럼을 이용한 개발

■. 스프린트 준비

스프린트(Sprint)에 대한 목표 설정이 완료되었다면 이제 각 스프린트를 달성하기 위한 보다 구체적인 해야 할 일 목록을 설정해야 한다. 이렇게 정리된 해야 할 일 목록을 나는 일감(Task)라 부른다. 일감은 쉽게 설명하면 스프린트가 진행되는 동안 스크러머(Scrummer) 개개인이 목표 달성을 위해 해야 하는 업무 목록이다.

<프로젝트 내부에는 다수의 스프린트가 존재하며 각 스프린트는 여러 개의 일감 목록으로 분리될 수 있다.>

 

스프린트 내부에 구성된 일감(Task) 구성을 완료했다면 각 일감은 보다 세부적인 항목으로 다시 구분될 수 있어야 한다. 예를 들어 몬스터 제작이라는 일감이 있다면 이를 달성하기 위해 필요한 세부 작업 내역을 추가할 수 있어야 한다.

<하나의 태스크는 이를 수행하기 위해 다수의 태스크 백로그로 구성될 수 있다.>

 

이렇게 구성된 세부 작업 내역을 나는 세부 항목(태스크 백로그 : Task Back Log)이라 부른다. 이러한 작업은 스크럼의 스프린트 진행 상황 파악과 스크러머(Scrummer)의 업무 할당 그리고 스프린트가 진행되는 동안 발생하는 이슈 대응에 매우 중요한 역할을 담당한다.

 

결과적으로 말하자면 프로젝트 오더(Project Order)는 목표 수행을 위해 1개 이상의 스프린트(Sprint)로 구성될 수 있다. 각 스프린트(Sprint)를 달성하기 위해 필요한 1개 이상의 일감(Task)으로 구성되며, 개별 일감은 세부 작업 내역(Task Back Log)으로 구성된다. 스크럼은 필요한 일감이 투명하게 관리되고 진행 사항을 확인할 수 있어야 한다. 그렇기 때문에 스프린트와 일감 그리고 세부 항목은 전체 작업을 알아보기 쉽게 순차적으로 구체화되는 과정이 필요하다.

 

다소 번거로워 보이는 이 과정이 필요한 이유는 구체적으로 해야 할 일들이 어떠한 것들 있는지에 대한 일차적인 업무 파악과 스프린트 진행(개발) 동안 추가적으로 발생되는 이슈(추가 연관 업무)등에 대한 태스크 확장을 위해 꼭 필요한 작업이다.

 

예를 들어 몬스터 제작 A라고만 일감을 정의한다면 일감에 투입되어야 하는 인력(담당자) 구성이 어떻게 되어야 하며, 작업 공정에 대한 진행 사항(진행율)을 파악하기가 쉽지 않다. 스크럼의 도입은 각 작업 공정을 투명하게 운영하고 연계된 작업의 누락과 예상하지 못한 이슈 발생의 최소화 그리고 발생된 이슈의 최단 시간 처리가 목적임을 잊어서는 안 된다.

 

■. 세부 항목(Task Back Log) 구성

스프린트(Sprint)와 일감(Task)과는 다르게 세부 항목(Task Back Log)의 구성은 게임 개발(또는 소프웨어 개발)에 어느 정도 경험이 없다면 구체적으로 어떻게 구성해야 하는지 예상하기 어려울 수 있다. 당신이 풍부한 경험을 가지고 있지 않다면 이와 같은 문제에 어려움을 느끼는 것은 당연하다. 이는 경험이 충분한 사람이라 하더라도 자신의 전문 영역이 아닌 다른 업무를 구체적으로 파악하기는 쉽지 않다.(하물며 자신의 전문 분야마저 진행에 필요한 세부 항목을 분류하는 것도 쉽지 않다.) 그렇다고 매번 세부 항목 구성을 위해 개별 담당자를 찾아가 일감과 세부 항목을 요청하는 것은 비 효율적이며 우리가 바라는 형태의 스크럼의 모습이 아니다. 그렇다면 당신은 세부 항목을 구성하기 위해 어떻게 해야 할까?

 

가장 기본적인 세부 항목(Task Back Log) 구성 방법 중 하나는 실제 기획서에 포함되는 항목을 우선 선정하는 것으로부터 시작된다. 예를 들어 몬스터 A에 대한 일감(Task)이 구성되었다면 몬스터 A의 기획서에 포함되는 내용이 세부 항목(Task Back Log)이 될 수 있다.

<게임에 따라 다르지만 3D RPG 게임을 기준으로 1개의 몬스터 제작에 필요한 항목은 이 정도 수준이다.>

 

몬스터 A 제작을 위한 주요 일감(Task)은 외형, 애니메이션, 시스템 데이터 작업 3가지와 외형, 애니메이션 제작에 필요한 몬스터 A의 기획서로 정도로 4개의 일감(Task)으로 구성할 수 있다. 그리고 각 일감(Task)을 달성하기 위한 세부 항목으로는 몬스터 A 콘셉트 기획서를 포함 11개의 세부 항목(Task Back Log)으로 구성될 수 있기 때문에 이를 기반으로 정리하면 아래와 같은 일감(Task) 형태로 정리될 수 있다.

<기본적으로 기획에 필요한 항목이 개발에 필요한 항목이 되기 때문에 초기 항목은 이를 기반으로 설정한다.>

 

물론 당신이 원한다면 Back Log 항목을 얼마든지 더 세부적으로 구성할 수 있다. 이러한 과정의 반복을 통해 세부화된 항목은 필요한 작업을 확인하고 이를 계획적으로 수행하기 위해 꼭 필요하다. 그러니 당신이 세부 항목을 작성한다면 가급적 생각 나는 가장 작은 단위의 업무를 등록해야 한다.

<가능하다면 Task를 구성하는 Back Log는 보다 세부적인 단계로 구성할 수 있도록 하자.>

 

당신이 작성한 일감과 세부 항목이 얼마나 완벽한지에 대해서는 아직 걱정하지 않아도 된다. 이러한 과정을 통해 완성된 스프린트(Sprint)는 스크럼에 참여하는 전원에게 공유되고 첫 스크럼 회의 때 일감과 세부 항목을 검토하고 불필요한 내용을 삭제하거나 추가 또는 수정하는 작업을 통해 추가로 완성해 나갈 수 있다. 이러한 과정은 스크러머들이 프로젝트와 스프린트에 자신이 기여(또는 관여)하고 있다는 소속감을 제공할 수 있다. 또한 이해를 돕기 위해 몬스터를 기준으로 설명했지만 이러한 형식의 일감(Task)과 세부 항목(Task Back Log)은 몬스터만이 아닌 스프린트에 필요한 시스템 개발에도 동일하게 적용할 수 있다.

 

■. 우선순위

스프린트(Sprint) 달성을 위해 다양한 일감(Task)과 세부 항목(Task Back Log)을 구성했지만 정작 어떠한 일을 먼저 시작하는 것이 가장 좋을지 판단하기는 쉽지 않다. 물론 충분한 경험을 가지고 있다면 최우선적으로 필요한 일감(Task)에 대한 우선순위를 설정할 수 있지만 그렇지 않다면 자연스러운 업무 진행을 위해 몇 가지 우선순위에 대한 지침을 활용할 필요성이 있다.

 

▶. 순차적으로 진행되며, 다음 작업자가 대기 중인가?

게임 개발은 병렬적으로 진행되는 경우가 많지만 앞선 업무 이후 연관 작업자의 업무가 이어지는 형태의 순차적인 작업 사항이 포함되어 있다. 이 과정에서 선행 업무의 지연이 발생했을 경우 다음 작업자의 일정 또한 함께 지연되거나 계획성 없이 즉흥적으로 업무가 진행되게 되면 당장의 문제는 해결될 수 있을지 모르겠지만 장기적으로 스프린트(Sprint)에 악영향을 줄 수 있다. 이렇듯 최우선순위로 진행되어야 하는 업무는 “일감(Task)의 중요도”로 구분되지 않고 선행 업무 이후에 연관된 다음 업무가 필수적인 대상이 우선 진행되어야 한다. 물론 선행 업무가 진행되는 동안 진행할 수 있는 다른 작업이 있다면 업무 분산이 보다 효율적인 선택이 될 수 있지만 그 과정에서 얻어진 시간적 여유는 다음 작업자가 대기해야 하는 업무 처리에 우선순위를 더 높여야 한다.
예를 들어 몬스터 A에 대한 일감(Task)을 처리해야 한다면 기본적으로 몬스터 A에 대한 기획 문서 업무가 처리되어야 연결된 다음 일감(Task)들이 진행될 수 있다. 만약 당신이 기획 업무를 진행한다면 연관된 담당자의 일감이 돌아오기 전 업무를 처리하고 연관작업자의 업무를 진행하는데 문제가 발생되지 않도록 처리해야 한다.

 

▶. 독립적으로 처리할 수 있는 업무인가?

순차적으로 진행되어야 하는 일감이 있다면 반대로 다른 일감과 연관성이 없는 독립적인 일감 또한 존재한다. 이러한 일감은 초기 스크럼(또는 스프린트)이 시작될 때 선행 작업이 완료되기까지 소요되는 시간을 활용할 수 있도록 각 담당자에게 우선 배정되어야 한다. 프로젝트가 완전하게 초기 상태에서 시작한다고 하더라도 정리된 일감을 확인하면 분명 하나 이상의 독립적으로 시작 가능한 일감은 존재한다. 만약 이러한 일감이 확인되지 않는다면 구성된 일감을 재 검토하거나 스프린트에 참여하는 담당자에게 독립적으로 진행 가능한 일감에 대하여 문의해 보도록 하자. 모든 업무가 선행 업무가 필요하다고 판단될 경우 기존 리소스(시스템 또는 디자인 리소스)를 활용할 수 있는 방안이나 선행 업무 이전에 처리해야 하는 R&D(Research and Development) 일감에 담당자를 배정할 수 있다.
※. Research and Development : 개발에 필요한 기초 연구와 응용화에 대한 뜻을 가지고 있지만 게임 개발에서는 기술적 완성 또는 실현 가능한 기술의 최적화 및 정규화 과정에 대한 기술 연구를 포함한다.

 

▶. 가장 빠르게 처리할 수 있는 업무인가?

업무 우선순위 선정에 있어 가장 많이 발생하는 실수 중 하나는 준비된 일감 중 가장 많은 시간을 투자해야 하는 항목에 담당자를 가장 빠르게 선정해야 한다는 생각이다. 일감 처리에 많은 시간이 투입되어야 한다는 이야기는 바꿔 생각하면 업무가 진행될 때 예상하지 못한 문제가 더 많이 발생할 수 있다는 뜻이기도 하다. 이러한 일감은 초기에 예상된 일정보다 더 많은 시간이 투입될 수 있는 잠재적 위험성을 가지고 있기 때문에 우선순위를 높여 처리하게 된다면 일정 지연으로 인하여 간단하게 처리할 수 있었던 일감 또한 빠듯한 일정에 처리해야 하는 문제를 발생시킬 수 있다.(아무리 간단한 일감이라 하더라도 시간에 쫓기다 보면 실수가 발생하거나 담당자에게 과도한 스트레스를 주기 마련이다.) 그래서 당신은 준비된 일감에서 가장 빠르고 간단하게 처리할 수 있는 업무를 우선 담당자에게 배정해야 한다. 이러한 일감이 당신의 예상 보다 더 빠르게 처리된다면 계획된 일정 보다 더 빠르게 목표를 달성할 수 있는 장점이 있지만 이를 뒤로 미뤘을 때는 언젠가 스크럼과 스프린트 전체의 발목을 잡는 치명적인 크랙(Crack)이 될 수 있다. 상식적으로 생각해 보자 우리는 일상생활에서 쉽고 간단하게 처리할 수 있는 일을 선호하면서 왜 일감을 처리할 때는 잠재적 위험이 가장 높은 순서로 처리하려 하는가?

 

■. 일감의 진행율(Progress)

스프린트와 일감 그리고 세부 항목까지 스크럼을 시작하기에 필요한 기본 준비는 완료되었다. 하지만 이 스크럼의 가장 큰 장점은 스케줄 관리의 유연성(일감과 세부 항목 관리를 통한 유연한 관리)과 업무가 진행됨에 따라 발생하는 다양한 이슈를 확인하기에 매우 유리하기 때문이다. 이러한 기능을 위해 우리는 일감(Task)과 세부 항목(Task Back Log)에 각 업무의 진행율과 이슈 정보를 등록할 수 있도록 하여 각 담당자의 업무 진척도와 문제점을 매번 확인할 수 있는 관리용 칼럼을 추가하도록 한다.

<Sprint Task를 통해 주요 항목에 대한 통합 진행율을 확인하고 각 Back Log별 진행 사항을 확인할 수 있다.>

 

Sprint Task 쪽 진행율(Progress)의 경우 Task의 통합 진행 사항을 확인하는 용도로 사용된다. Back Log의 Progress의 값을 모두 더한 후 Back Log 수량만큼 나눈 것을 백분율 값으로 변환한다. Back Log의 Progress는 앞으로 설명될 스크럼 회의를 통해 개별 담당자의 진행율을 표기하도록 한다.

 

이제 스크럼을 위한 기초적인 준비는 완료되었다. 프로젝트의 목표를 달성하기 위한 스프린트(Sprint) 구간과 이를 달성하기 위한 일감(Task)과 구체적인 세부 항목(Task Back Log) 그리고 진행 사항을 확인하고 이슈를 등록하고 체크할 수 있는 준비가 완료되었다면 본격적으로 프로젝트 오더(Project Order)를 달성하기 위한 팀원을 소집하고 내용을 공유하도록 하자.

■. 스크럼 회의

이제 스크럼을 시작하기 위한 모든 준비는 완료되었다. 이제 스프린트(또는 프로젝트 오더)를 달성하기 위해 필요한 담당자를 호출하고 한자리에 모아 회의를 진행하면 된다. 스크럼 회의는 가급적 매일 아침 업무가 시작되기 전에 시작하는 것이 일감에 대한 문제점과 진행사항 확인에 유리하다. 여기서 중요한 점은 매일 지정된 시간에 항상 스크럼 회의가 진행되어야 한다는 점이다. 그리고 일반적으로 첫 회의를 제외하고는 모두 비슷한 형식으로 진행된다.

 

▶. 첫 회의

첫 회의는 프로젝트 오더 수행을 위해 달성해야 하는 스프린트와 일감에 대한 정보를 공유하는 것으로 시작한다. 당신이 작성한 스프린트와 일감은 아직 실무를 진행하는 담당자와의 협의와 의견을 반영하지 않은 희망 사항과 같은 형태이다. 그렇기 때문에 처음 공개되는 당신의 계획은 거센 반발을 불러오는 것은 당연한 수순이다. 하지만 너무 겁먹지는 말자 당신은 오직 팀원(스크럼에 참여한 담당자)들과 함께 프로젝트 오더를 달성하기 위한 계획을 수립하고 이를 공유했을 뿐이다. 문제가 있거나 수정해야 할 부분이 있다면 의견을 반영하고 문서와 계획을 일부 수정하기만 하면 된다.(누가 봐도 쿨하게 말이다.) 하지만 모든 일은 계획대로 되지 않는 법이다. 그래서 스크럼을 진행하면서 경험한 몇 가지 사례를 설명하고 그에 대한 대응법에 대해서 이야기해 보도록 하자.

 

▷. 스크럼(회의)에 대한 불필요성 논의

스크럼 회의는 매일 정해진 시간에 항상 진행된다.(예를 들자면 업무 시작 30분 전이 가장 효과적이다.) 대부분의 개발진(기획, 프로그램, 아트)은 모두 회의에 대하여 부정적인 생각을 가지고 있다.(역설적이게도 불필요한 회의는 파트의 구분 없이 요구되기도 한다.) 스크럼은 매일 일감에 대한 진행 사항을 확인하고 업무 간 발생되는 이슈 확인하여 문제를 빠르게 해결하는 것에 그 목적이 있기 때문에 매일 이를 확인하기 위한 회의는 필수적이다. 대부분 회의에 대한 거부감이 있는 스크러머의 경우 매일 회의하는 것에 대하여 이유를 알 수 없는 부담감을 가지고 이에 반대하기 쉽다. 이런 상황이 발생한다면 당신은 침착하게 이 회의가 왜 필요하고 하루 30분의 회의가 목표 달성을 위해 얼마나 유익한 시간이 될 수 있는지에 대하여 설명할 수 있어야 한다.(어떠한 내용을 설명해야 할지 모르겠다면 지난 내용을 다시 한번 읽어 보도록 하자.) 기본적인 개발진은 사무직이다. 점심시간을 제외하고 하루 근무 시간은 기본 8시간으로 구성되어 있고 이 시간을 온전히 자신의 스케줄을 소화하기 위해 사용하는 사람은 나는 아직 단 한 명도 보지 못했다.(이것은 나조차 포함되지 못할 정도로 부정할 수 없는 사실이다.) 만약 하루 30분을 이 중요한 회의에 할애할 수 없을 정도로 바쁜 사람이라면 당연하게도 이 프로젝트 오더에 참여하는 것조차 허락되지 못할 정도의 핵심 개발진이거나 당신이 어찌할 수 없는 높은 위치의 상급자일 것이다. 이 두 가지에 포함되지 않음에도 일간 회의에 거부감을 가진다면 투명하게 관리되는 업무로 인하여 자신의 업무 역량이 공개되는 것을 두려워하는 무능력한 사람이거나 아직 스크럼에 대한 경험이 부족하여 이 프로세스에 대한 확신이 없는 사람 중 하나이다. 만약 전자라면 당연히 스크럼을 통해 개인 역량이 확인되고 자연스럽게 도태되는 과정을 겪을 것이며 후자일 경우 스크럼을 통한 새로운 경험이 개인의 업무 집중도를 올리고 협업을 통해 어떠한 성과를 낼 수 있는지에 대한 새로운 경험을 제공할 것이다.

 

▷. 일정에 대한 압박

초기부터 스크럼이 도입되고 일상적인 업무 프로세스로 자리 잡혀 있다면 문제가 없겠지만 개인적인 경험으로 스크럼이 도입되는 시점이라면 프로젝트의 상황이 그다지 희망적이지 않은 경우가 많다.(프로젝트 오더에 대한 전권을 이임받을 수 있다는 것은 그만큼 미래가 어둡다는 뜻이기도 하다.) 이러한 상황에서 대부분의 스크러머들은 당신과의 업무 외 다른 업무를 수행하고 있을 확률이 더 높다. 이러한 상황에서 체계적으로 분리된 일감을 마주하게 된다면 당연히 더 많은 업무를 처리해야 하는 부담감을 가질 수밖에 없다.(일감과 세부 항목은 대부분의 담당자가 무의식적으로 수행하는 과정을 단지 도표화 시켰을 뿐이지만 감각으로 느끼던 것을 실물로 확인하게 된다면 할 일이 더 많아 보이는 법이다. 어떻게 본다면 조삼모사(朝三暮四)와 같은 형국이다.) 이러한 상황에서 당신이 할 수 있는 선택은 대략적으로 두 가지이다. 하나는 과중한 업무 중 불필요한 일감을 줄이고 최선의 효율을 위해 선택과 집중을 위해 필요한 전략을 설명하는 것 아니면 당신이 만들어 놓은 일감에서 처리가 불가능하거나 어려운 일에 대한 항목을 제거(또는 유사 효과를 낼 수 있는 기능으로 대체)하는 것이다. 하지만 여전히 중요한 부분은 그 어떠한 선택이 되더라도 당신이 준비한 이 모든 것은 스크러머를 괴롭히기 위한 것이 아니라 그동안의 부당함을 해소하고 담당자가 보다 업무에 집중할 수 있는 환경을 만들어 주기 위함을 잊지 말자.

 

▷. 명령과 감시 상황에 대한 거부감

이 스크럼 과정의 가장 큰 문제점이며 이에 대한 갈등과 오해를 해결하지 못한다면 당신이 준비한 모든 것은 단순히 불필요한 것으로 전락하게 된다. 스프린트와 일감 그리고 세부 항목으로 구성된 도표는 각 담당자에게 창의성을 요구하기보다는 당신의 계획대로 움직여야 한다는 오해를 불러올 수 있다. 그리고 매일 진행되는 회의를 통해 당신에게 보고하고 당신의 질문에 대답하는 형태는 상급자와 하급자의 모습으로 받아들여질 수 있다. 당신은 이러한 오해를 충분히 불러올 수 있음을 인지하고 그에 대하여 해명할 수 있어야 한다. 스크럼에 사용되는 모든 내용은 오직 프로젝트 오더를 달성하기 위해 필요한 내용이며 스크러머를 압박하거나 감시하기 위함이 아님을 이야기해야 한다. 당신은 스크럼을 통해 그들이 달성한 결과물과 그 과정을 시각적으로 확인할 수 있도록 하며 오직 업무와 일감에 집중할 수 있는 환경을 제공하기 위해 희생하는(결과적으로 당신을 위한 것이기도 하다.) 동등한 위치의 팀원임을 설명하라.

 

▷. 진행율 체크에 대한 의문

세부 항목(Task Back Log)에 대한 진행율은 0% ~ 100%까지 일감을 담당한 개인의 의지에 따라 반영된다. 만약 애니메이션 작업을 진행하는데 파일만 생성한 상태일 경우 진행율은 어떻게 포함해야 할까? 그리고 오늘 진행해야 하는 상황을 반영해야 하는가? 아니면 어제까지 진행한 작업만을 진행율에 반영해야 하는가? 여러 고민이 있고 이에 대한 질문이 있겠지만 당신의 답변은 오직 하나이다.

“그 무엇이든 상관없다.”

진행율은 일감이 진행 중이거나 완료된 상태를 확인하기 위해 사용된다. 이는 진행율의 변화가 너무 적을 경우 지연되는 상황과 원인을 확인하기 위함이다. 당신은 지연되는 상황에 대하여 원인을 경청하고 이를 해결하기 위한 방법을 모색하면 된다. 또한 진행율은 일감(Task)과 스프린트(Sprint)의 진척도를 확인하고 각 담당자의 업무 처리 상황을 투명하게 확인할 수 있는 수단이 될 수 있다. 하지만 당신이 주의해야 할 사항을 강조하자면 스크럼은 담당자를 감시하기 위한 용도로 악용되어서는 안 된다는 점이다.

 

▶. 첫 회의 이후

첫 회의가 무사히 진행되었다면 이후 진행되는 회의는 보다 간결하게 진행할 수 있다. 스크럼의 회의는 어젠다(agenda)를 통해 결정을 위한 것이 아닌 각 담당자의 업무 진행 상황을 확인하기 위한 자리임을 잊지 말자. 이후 진행되는 회의에서 당신은 스크러머에게 물어보는 질문은 세 가지로 요약될 수 있다.

 

▷. 어제 한 일은 무엇인가?

당신은 스크러머에게 어제 했던 일이 무엇이고 스프린트와 일감 그리고 세부 항목에서 어느 정도 진척사항이 발생했는지를 확인해야 한다. 담당자의 어제 진행 업무 내역을 확인할 때 진행 사항이 부족하거나 문제 발생으로 인하여 업무가 지연되었다면 상세 항목(Task Back Log) 옆 문제(Issue) 란에 발생된 문제와 내용을 추가하도록 한다. 스크럼이 진행되는 동안 즉석에서 문제의 해결이 가능하다면 좋겠지만 상급자의 결정 또는 다른 업무와의 협업이 필요할 경우 문제를 인지하고 기록하는 것으로 마무리하는 것을 권장한다. 이와 관련된 논의가 진행된다면 진행 사항 확인과 이슈 파악에 대한 스크럼 회의의 본질을 잃어버릴 수 있다.

▷. 오늘 해야 할 일은 무엇인가?

어제 진행된 업무에 대한 진행율과 문제를 확인했다면 이제 오늘은 어떠한 일을 해야 하는지에 대한 계획을 확인한다. 오늘 해야 할 일을 확인하는 과정에서 선행 작업이 필요하거나 연관 작업자의 서포트가 필요한 경우 관련 문제를 정리하여 스크럼 참석 인원이 문제를 인지할 수 있도록 한다.

 

▷. 추가되어야 하는 업무가 있는가?

당신이 스프린트와 일감 그리고 세부 항목을 준비하고 다수의 인원과 협의를 통해 하나의 스프린트 문서가 완성되었다고 하더라도 그것이 완벽하다고 착각해서는 안된다. 개발이 진행되는 동안 예상하지 못했던 추가적인 일감 그리고 기존에 완성된 일감에 대한 고도화(Develop) 과정 또는 이미 종료되었으나 다른 일감과의 연결성으로 인하여 일부 수정 또는 재 작업이 필요한 사항은 얼마든지 발생할 수 있다. 이러한 일감이 스크럼회의 때 언급된다면 주저하지 말고 기존 문서에 일감을 추가하고 관리될 수 있도록 진행해야 한다.

 

구성원에 따라 차이가 있겠지만 가급적 스크럼 회의는 30분을 초과하지 않도록 주의해야 한다. 당신은 이 회의에 대한 전체적인 조율권한을 가지고 있기 때문에 불필요하다고 판단되는 내용 아니면 회의 이후 논의가 필요한 일감에 대해서는 과감하게 대화를 중지시켜야 한다. 스크럼 회의가 종료되었다고 진행 중인 스크럼이 종료되는 것이 아니다. 회의가 종료된 이후 아직 정리되지 않은 문제점들에 대하여 개별 스크러머를 찾아가 보다 세부적인 내용을 확인하거나 제시된 문제점들의 해결 방법을 모색할 수 있다. 초기 스크럼 회의가 진행되면 당신이 생각한 것보다 더 많은 문제와 직면할 수 있다. 초기 30분 회의 시간이 짧게 느껴질 정도로 많은 문제와 의견, 건의 사항 등이 발생하지는 이는 매우 자연스러운 상황이다. 기존에 확인되지 않은 문제 그리고 연관 작업자와 협의 커뮤니케이션 이슈 등이 수면 위로 올라왔을 뿐이다. 그리고 이러한 문제는 스크럼이 진행됨에 따라 자연스럽게 줄어들고 기존의 문제는 하나씩 해결되어 갈 것이기 때문에 당황하거나 걱정하지 않아도 괜찮다. 개인 적인 경험으로 첫 스크럼 회의는 약 60분 정도의 시간을 소비했지만 이후 마지막 스크럼 회의는 약 15분 만에 종료될 정도로 익숙해진다면 문제는 줄어들고 결과는 보다 빠르게 당신에게 보답할 것이다.

 

■. 이슈 추적(Issue Track)

스크럼 회의가 진행되고 다양한 문제점이 확인되면 이를 기록하고 해결될 때까지 관리될 수 있어야 한다. 스프린트를 달성을 완료할 때까지 당신은 예상하지 못한 많은 문제를 만나게 될 것이 분명하다. 하지만 당황하지 말자대부분의 문제는 당신과 스크럼 참여 인원을 통해 해결 가능한 문제이며 당신보다 상급자 또는 당신의 직접적인 결정을 요구하는 문제가 대부분이다.

 

이슈 추적을 위해서 당신이 해야 할 일은 문제를 기록하는 것으로부터 시작된다. 스크럼 문서에 기록된 문제는 그것이 해결되기 전까지 남아있기 때문에 문제의 발생 시점과 원인 그리고 해결을 통한 결과가 기록된다. 물론 문제를 해결하기 위한 과정에 당신의 영향력과 노력이 엄청나게 소비되겠지만 우리는 당신이 스프린트를 달성하기 위한 일대기를 기록하기 위한 것이 아니기 때문에 내용은 중요 항목만 간략하게 요약하여 작성하도록 하자.

 

이렇게 정리되는 문제점들은 다음 비슷한 유형의 스크럼이 필요하게 될 때 훌륭한 레퍼런스(Reference) 자료로 활용될 수 있다. 그리고 스크러머들은 자신에게 당면한 문제 해결을 통해 보다 업무에 집중할 수 있게 되며 문제가 줄어들게 된다면 당신이 목표한 일정보다 더욱 빠르게 스프린트가 가속화될 수 있다.

<이슈 추적의 기본은 발생 일자와 내용을 작성하고 이를 해결한 결과를 기록하는 것으로 관리된다.>

 

■. 일간 보고

스프린트를 준비하고 스크럼 회의를 끝냈지만 아직 당신이 해야 할 일은 끝나지 않았다. 매일 진행되는 회의 내용과 스프린트의 진행 사항을 정리하고 전체 개발팀 또는 당신의 상급자에게 보고해야 하는 의무가 있다. 스크럼을 진행할 때 이미 당신은 팀 또는 상급자로 하여금 어느 정도의 신뢰를 바탕으로 권한을 위임받았겠지만 그것은 결과를 나올 때까지 기다리겠다는 의미는 아니다. 상급자에게는 모든 프로젝트의 진행 사항을 확인하고 그보다 더 높은 상급자에게 보고해야 하는 의무가 있는 만큼 당신도 상급자에게 보고해야 하는 의무가 있다. 다소 귀찮고 일을 위한 일을 만드는 기분이 들지 모르겠지만 진행 사항을 알 수 없는 상태에서 오는 상급자의 피드백은 오히려 스프린트와 스크럼 전체에 악영향을 줄 수 있기 때문에 이를 사전에 방지하고자 하는 의미도 있다. 그리고 이러한 정보 공개는 스크럼 참여자를 독려하고 상급자의 신뢰를 얻어낼 수 있기 때문에 여러모로 당신의 목표 달성에 도움이 된다.

<스크럼 진행 이후 매일 공유된 진행 사항에 대한 예시로 정규 양식에 그날 스크럼 회의 내용을 정리한다.>

 

실제 스크럼에 사용된 일간 보고서 양식이기 때문에 내용을 공개할 수는 없지만 보고를 위한 양식은 회사 내부에 정규 양식이 있다면 이를 활용해도 좋고 아니면 당신이 자유롭게 작성해도 상관없다. 주요 진행된 일감에 대한 결과 지연 사유, 문제 및 대안 그리고 처리 형태에 대한 내용과 전체 프로젝트와 각 스프린트의 진행율을 공개하여 스크럼에 참여하지 않은 인원이 프로젝트의 진행 상황을 알 수 있도록 하면 된다.

 

■. 스크럼이 잘 이용되지 않는 이유

스크럼은 매우 유용하다. 하지만 초기 개발 단계에서부터 도입되어 활용되지 못하는 이유는 프로젝트 저마다의 이유가 있겠지만 내가 제안하는 방식은 정통적인 스크럼과는 다른 변형된 형태이며 스크럼을 주도하는 개인에게 상당히 높은 업무 집중도를 요구한다. 전체 내용을 통해 알 수 있는 부분은 단순 기획자의 제한된 업무 영역을 벗어나 PM(Project Manager)과 PD(Project Director)의 역할을 요구한다. 이렇듯 내가 제안하는 스크럼은 당신 스스로 막대한 업무에 몰아넣지만 그러한 노력에 대한 결실은 매우 흥미롭고 만족스러울 것이다.

 

기획자는 자신이 기획한 내용에 대하여 실행 가능한 제품(Shippable Product)을 얻지 못한다면 결과적으로 아무것도 얻을 수 없다. 스크럼은 비록 힘겨운 과정을 필요로 하지만 최종 결과물은 확실하게 당신의 손에 들어오게 만들어 준다. 그러니 만약 당신이 스크럼을 진행하게 되고 이 방식을 따르게 된다면 예상보다 많은 업무 분량에 힘들 때 언젠가는 당신 손에 들어올 실행 가능한 제품(Shippable Product)에 대한 보상을 기대하며 힘내기를 바란다.