스크럼, 이걸 왜 하나요?

뭔가 익숙하지 않나요?

프로듀서는 팀원들을 회의실에 불러 모아놓고 게임 개발의 시작을 선포합니다. 가장 먼저 하는 일은 화이트보드에 긴 화살표를 주욱 긋고 '5개월'이라는 글자를 적는 것입니다. 그리고 비장한 목소리로 이렇게 이야기합니다. "우리에겐 딱 이만큼의 시간이 있다". 이어서 각 팀원들에게 시간을 배분하며 스케줄을 그려봅니다.

전설의 GDD

"기획은 1개월 줄게. GDD도 병행해서 작성해. 나중에 퍼블리셔 잡을때 필요하니까 충분히 디테일 살려서 두껍게 만들어, 그 동안 디자인팀은 컨셉 그려두고 프로그램팀은 관련 기술 리서치 해. 2개월째부터는 바로 UI, 배경, 캐릭터, 프랍 모두 시안 작업 시작하는거야. 클라이언트팀은 캐릭터 작업과 파티클 병행해서 개발해보고, 서버팀은 기본 골격잡아. 봇은 처음부터 만들어서 성능 테스트 쉽게 할 수 있도록 하는거 잊지마. 3, 4개월째에는 크런치 모드로 갈 수 밖에 없을거야. 4개월째에는 끝을 내야하고 한달동안 테스트만 계속 돌려야 하니까. 다들 알겠지? 내가 말한대로 스케줄 표 작성해보자."

다음날, 일정대로 팀은 분주하게 움직입니다. 기획팀은 밤을 새가며 기획에 여념이 없습니다. 기획을 하는건지 책을 쓰는건지 구분이 잘 되지는 않지만 그래도 열심히 하고 있는 것 같습니다. 디자인팀은 상상의 나래를 펼치며 컨셉을 그려냅니다. 뭔가, 대단한 게임이 나올 것 같은 기대감이 생깁니다. 프로그램팀은 어제 바로 YES24에서 책 대여섯권을 주문했습니다.

하얗게 불태웠어...

그리고 시간은 흘러, 4개월째가 되었습니다. 뭔가 욕심대로 기능들을 추가한 탓에 개발 일정이 빡빡해서 두달여동안 햇빛을 거의 못 봤습니다. 어제 팀 내에서 마지막으로 함께 테스트하던 순간이 기억납니다. 아직도 버그 투성이라 게임중에 튕겨져 나가는 플레이어들이 계속 보입니다. 때로는 서버가 크래시 나는 바람에 정상화되기까지 한참을 앉은채로 대기해야 했습니다. 게다가 심각한건, 게임이 하나도 재미가 없다는 겁니다. 사실 2주 전에 알파가 만들어진 상황에서 게임이 재미가 없다는 사실은 인지했지만, 고작 2주로는 핵심 게임성을 바꾸는 것은 불가능한 일이었습니다. 팀내에는 실패할거라는 패배감이 만연해있어서 처음 시작하던 당시 여기저기서 들려오던 웃음소리는 사라진지 오래입니다. 오늘은, 퍼블리셔를 만나 게임을 시연해야 합니다. 하지만, 왠지 두 달 정도 시간을 더 달라고 말해야 할 것 같습니다.

뭐가 문제였을까요?

자신을 너무 믿지 마세요.

프로젝트가 시작될때만해도 부푼 기대를 안고 즐거운 마음으로 업무를 합니다. 열심히만 하면 일정을 채우고도 시간이 남을 것 같습니다. 하지만, 시간이 흐를수록 뭔가 문제가 생깁니다. 알쏭달쏭한 기획, 끈질기게 안풀리는 이슈, 늦는다고 채근하는 팀장. 자꾸 나만 뒤쳐지는 것 같습니다. 뭔가 하소연하고 싶어도 바삐 돌아가는 팀 안에서 내 이야기를 들어줄 사람조차 없습니다. 이제 마감일을 맞추지 못하는 것은 기정사실입니다.

일정을 잡을 때 적당하다고 판단되는 기간보다 적어도 50%를 더 길게 잡으라고들 합니다. 그 이유는 생각지도 못했던 장애물들이 곳곳에서 튀어나올 것을 대비해야 하기 때문입니다. 자신의 업무 효율은 스스로 혹은 환경에 의해 점점 떨어지기 마련이고, 이를 혼자 이겨내는 것은 너무 힘든 싸움입니다. 결국 끊임없는 야근으로 일정을 가까스로 맞추거나 부득이하게 기한을 늦출 수 밖에 없습니다. 일정에 무리가 있을것으로 판단되어 미리 팀에 공지를 해준다면 그나마 다행이지만, 대부분의 경우 마지막까지 가슴속에 묻어두었다가 프로젝트 종료일 이틀쯤 전에 조용히 이야기를 꺼내는 것이 보통입니다.

자신을 너무 믿지 마세요. 팀원들의 도움을 받아야 합니다.

기획은 언제든지 바뀔 수 있습니다. 그래야만 합니다.

여기 에스칼레이터를 설치한다고 집값이 오르겠냐

마침내 게임을 완성했는데 재미가 없는 경우 보통 두 가지 방법 중 하나를 택합니다. 첫번째 방법은 재미있어 보이는 기획 요소들을 대거 집어넣는 것입니다. 여기서 재미있는 건, 안되면 또 만들어서 집어넣는다는 겁니다. 어떻게든 땜빵으로 해결해보려 하지만 결국 핵심 게임성은 흥행에 발목을 잡게 마련입니다. 두번째 방법은 재미가 떨어지는 핵심 요소를 제거하고 원점부터 다시 기획하는 것입니다. 하지만, 대부분의 영세한 개발사는 금전적인 부담으로 인해 이미 개발이 끝난 시점에서 핵심 게임성을 뒤집어 엎는 과감한 결정을 내리는 것은 상상하기 어렵습니다.

글의 서두에 들었던 사례는 폭포수 개발 방법론을 따르고 있습니다. 폭포수 방법론은 초기 기획부터 설계, 구현, 테스트, 출시가 하나의 흐름으로 진행되며, 선행 작업이 완료되어야 그 다음 작업으로 넘어갈 수 있다는 것이 특징입니다. 그래서 재미가 없다는 치명적인 사실을 발견한 시점은 이미 구현이 완료된 이후의 테스트 시점이 되는 것입니다. 눈여겨 볼 점은, 이러한 방식의 접근은 소프트웨어 개발이 아닌 제조업이나 건설업에 적합하다는 사실입니다. 건물은 마음에 들지 않는다고 쌓던 것을 무너뜨리고 다시 쌓는 것이 거의 불가능합니다. 하지만, 소프트웨어는 그에 비해 손쉽게 수정 작업을 진행 할 수 있습니다. 즉, 기획을 마치고 구현 중인 게임이라 할지라도 개발 중에 진행된 테스트에서 문제가 발견될 때, 특히 재미가 없을 때에는 얼마든지 기획을 변경하여 재수정을 할 수 있다는 것입니다.

이 것이 바로 재미없던 게임이 개발 과정중에 재미있어 질 수 있는 키워드입니다.

위험한 150% 보다 안정적인 100%가 낫습니다.

일정이 초과되는 이유는 생각보다 간단합니다. 팀의 능력에 비해 너무 많은 것을 시도했기 때문입니다. 일정이 진행되는 도중에 언제라도 약속된 시일을 맞출 수 없다는 판단이 선다면 즉각 협의를 거쳐 작업량을 줄여야 합니다. 그리고 예상한 스케줄이 터무니 없었다는 것을 깨달았다면, 다음에는 그에 비해 여러가지를 포기한 일정을 선택해야 합니다. 그렇게 점차 교정해 나간다면 이후에는 예측과 꽤 맞아 떨어지는 일정이 만들어지고, 그 것이 비로소 그 팀의 역량이 됩니다.

만약 폭포수 개발 방법론을 채택한 팀이라면 초기에 전체 일정을 계획합니다. 이 때 팀의 능력을 과대평가한 일정을 산출했다면 그 부작용은 아마도 스케줄의 중반부가 넘어가서야 나타나기 시작 할 것입니다. 하지만, 이미 그 때는 자연스럽게 일정을 조정하기란 거의 불가능합니다. 결국 일정을 늘리거나 인력을 충원하는 등의 진행이 불가피합니다.

팀의 역량을 조기에 판단하고 그에 맞게 작업량을 책정하는 것이 실패없는 일정 수행에 매우 중요한 요소입니다.

도대체 스크럼은 이런 문제를 어떻게 해결하나요?

반복개발이 답입니다.

이제 게임 개발에 있어서 반복개발은 더 이상 선진적인 일부 개발자들만 사용하는 비주류 방법론이 아닙니다. 위에서 사례를 보았 듯, 개발 시간 단위가 길어질수록 문제가 뒤늦게 파악 될 가능성이 크고, 파악되더라도 해결에 필요한 노력이 너무 커집니다. 해답은, 전체 일정을 잘게 쪼개서, 보다 자주 뒤를 돌아보며 올바른 길을 걷고 있는지 확인하는 것입니다.

스크럼은 이 단위를 '스프린트'라고 부릅니다. 스프린트의 사전적 의미는 '단거리 경주, 전속력으로 달리다'의 뜻으로, 대략 2주에서 1개월의 짧은 시간을 책정하여 집중력있게 개발에 임하는 시간 단위를 가리킵니다. 또 한가지 중요한 컨셉 중 하나는 매 스프린트가 완료 될 때마다 실행 가능한 결과물이 제작되어야 한다는 것입니다. 반복개발에서 가장 중요한 요소는 바로 '테스트'입니다. 테스트가 불가능한 결과물은 아무런 가치가 없다고 해도 과언이 아닙니다. 게임이 재미있는지 여부를 확인하기 위해서 반드시 실행 가능한 결과물이 제작되어야 합니다.

팀원들에게 즐겁게 개발 할 수 있는 동기 부여를 해주는 것 역시 중요합니다. 20% 완성, 캐릭터 5마리 완성과 같은 몸으로 느껴지지 않는 목표들은 언제나 개발자의 의욕를 떨어뜨립니다. 스프린트를 진행하는 동안 게임이 점차 완성되어 가는 모습을 보면서 동기를 부여하고, 완료후에는 의도한대로 재미있는 게임이 되었는지를 확인하는 절차가 꼭 필요합니다.

피드백을 좀더 일찍, 좀더 자주, 좀더 많이, 좀더 지속적으로!

그거 아니야

원활한 개발을 방해하는 요소들은 셀 수 없이 많습니다. 하지만, 그런 방해 요소들을 적극적으로 해결하고자 하는 노력은 그에 비해 턱없이 부족합니다. 늦어지는 기획, 너무 잦은 회의, 본부장의 잦은 간섭, 협업 요청에 대한 동료의 무응답, 작업을 더디게하는 수많은 요소들은 오늘도 우리 주위에 산재해 있습니다. 하지만, 이런 것들에 문제를 제기하면 왠지 분위기가 어색해질 것 같고 눈치가 보여서 포기하고 맙니다. 결국 시간이 갈수록 즐겁게 개발 할 수 있는 환경은 사라져갑니다. 스크럼은 목표를 달성하는데 방해가 되는 요소들을 그 즉시 해결해야 한다고 이야기합니다.

스크럼에는 데일리 스크럼 회의라는 것이 있습니다. 이 회의는 업무를 시작하기 전에 함께 모여서 최대 15분 정도로 짧게 진행하는 것으로서 스크럼의 꽃이라고 할 수 있습니다. 많은 사람들이 스크럼을 이야기 할 때 가장 먼저 떠올리는 것 역시 바로 이 데일리 스크럼 회의입니다. 그만큼 데일리 스크럼 회의는 스크럼의 핵심적인 가치를 잘 드러내는 매우 중요한 절차입니다. 하지만, 스크럼을 도입한 많은 회사들은 이 회의를 왜 해야 하는것인지, 어떻게 하는 것인지 정확하게 모른채 실시하고 있습니다. 결국 아침에 잠깐 모여서 내가 지금 무슨 일을 하고 있는지 보고하는 정도에서 크게 벗어나지 않습니다. 데일리 스크럼 회의는 보다 더 중요한 목적을 가지고 있습니다.

그런데 왠지 못해내면 제거 될 분위기

이 회의의 가장 큰 목표는 바로 위에서 언급한 장애물들을 제거하는 것입니다. 보다 쾌적한 개발이 가능하도록 보다 자주, 보다 많이, 보다 지속적으로 피드백을 주고 받아야합니다. 스크럼 회의에서 항상 언급되어야 하는 세 가지 필수 요소가 있습니다. 그것은 바로 <어제 한 일>과 <오늘 할 일>, 그리고 원활한 작업을 방해하는 <장애 요소>입니다. 내가 하고 있는 일을 공유하여 스프린트의 어느 위치를 달리고 있는지 팀원들에게 알리고 만약 일정에 차질이 발생한다면 그 원인은 무엇인지를 공유하는 것입니다.

일정은 반드시 지켜내야 한다. 그것이 스크럼의 존재 이유.

스크럼은 일정을 정확하게 지키기 위한 고민에서 탄생한 개발 방식입니다. 우리는 보통, 프로젝트 초기에 수립한 일정은 반드시 지켜야 하는 것이라고 이해합니다. 하지만, 불행하게도 일정에 포함된 작업량은 변함이 없습니다. 만약 일정 수립에 문제가 있었다는 것이 뒤늦게 발견되더라도 숱한 야근으로 정해진 목표를 정해진 일정안에 완수해야 합니다. 

하지만, 스크럼이 접근하는 방식은 다릅니다. 수립된 일정은 지키되 작업량은 언제든 변경 될 수 있다고 가정합니다. 혹시 팀원들이 전력을 다하는 상황에서도 목표를 달성하지 못할때는 우선순위가 낮은 작업을 일정에서 과감하게 제외시킵니다. 그럼에도 개발이 효율적일 수 있는 이유는 팀원들이 스프린트, 즉 전력을 다한다는 가정이 있기 때문입니다. 짧은 시간동안 전력을 다하여 최고의 효율을 만들어내는 것이 바로 스크럼이 추구하는 방식이고 그럼에도 불구하고 불가능한 것들은, 어쩔 수 없이 포기해야 하는 몫으로 판단합니다.

그렇다면, 이처럼 전력을 다하는 개발 환경을 만들어주는 방법은 무엇이 있을까요? 

일정은 디테일하게, 퍼블릭하게

팀원들끼리 게임하듯이 작업 소요 시간을 예측하는 '플래닝 포커 게임'

첫번째는 상세한 일정 수립입니다. 스프린트 회의에서 가장 먼저 해야 하는 일은 이번 개발을 통해 어떤 기능 혹은 디자인을 추가 할 것인지를 결정하는 것입니다. 그렇게 결정된 기능들은 백로그(backlog)라고 부르며, 스케줄 선정에 필요한 기초 자료가 됩니다. 다음은 그 기능을 구현하는데 필요한 작업을 목록으로 만드는 것입니다. 이를 태스크(task)라고 부릅니다. 태스크에는 구현의 난이도가 설정됩니다. 가장 구현이 쉬운 태스크에 1의 난이도를 부여하고 가장 어려운 난이도에 5를 부여 합니다. 난이도의 설정이 완료되면 프로젝트의 성격, 전체 시간, 팀 혹은 담당자의 능력에 따라 난이도 수치를 작업 시간으로 변환합니다. 보통은 하나의 태스크에 할당하는 시간으로 4시간, 8시간, 16시간 24시간 등을 사용하며 최대 3일내에 해결 가능하게 구성합니다. 마침내 스프린트 회의가 끝날 때에는 이번 스프린트에 필요한 모든 태스크들이 예상 작업 시간과 함께 산출됩니다. 마지막으로 해야 할 일은 태스크들을 각각 하나씩 포스트잇에 기록하는 것입니다.

두번째는 '해야 할 일'과 '완료 한 일'을 구분하여 관리하는 것입니다. 회사내의 벽면이나 화이트 보드에 크게 사각형을 그려놓고 TODO(할일) 라고 적습니다. 그리고 바로 옆에 똑같은 사각형을 하나 더 그리고 DONE(한일) 이라고 적어둡니다. 이제 스프린트 회의에서 만들어진 많은 포스트잇들은 TODO 영역에 모두 붙입니다. 이제 우리의 목표는 TODO 영역에 있는 모든 포스트잇을 DONE 영역으로 옮기는 것입니다. 필요에 따라서 TODO와 DONE 사이에 DOING 항목을 조그맣게 만들어서 각 개발자가 현재 작업중인 태스크를 붙여 두는 방법도 있습니다. 이런 방법을 이용하면 누구나 어떤 작업이 완료되었고 어떤 작업이 현재 진행되고 있는지 쉽게 파악 할 수 있습니다.

두 번의 작업 축소, 한번의 작업 추가가 있었던 스프린트

세번째는 작업의 진척도를 한 눈에 확인 할 수 있도록 하는 것입니다. 스크럼에서는 이런 요구에 부응하기 위해 '번다운 차트(Burn-down chart)' 를 활용합니다. 이번 스프린트에서 해야 할 모든 태스크들은 이미 스프린트 회의에서 결정되었습니다. 게다가 각 태스크들마다 예상 작업 시간이 산출되었기 때문에 모든 태스크들의 작업 시간을 더하면 이번 스프린트에 완료해야 할 총 작업 시간을 구할 수 있습니다. 이렇게 얻은 총 예상 작업 시간을 Y축으로 놓고 스프린트 종료 일까지의 날짜수를 X축으로 놓아서 그래프를 그립니다. 예를 들어, 스프린트가 30일이라면 X축에 30개의 칸을 그리고 총 예상 작업 시간이 6000시간이라면 Y축으로 대략 8000을 표현 할 수 있는 칸을 그립니다. 자, 이제부터 매일 스크럼 회의가 끝날 때마다 전날 작업이 완료된 태스크들의 작업 시간만큼을 뺀 수치로 그래프에 선을 잇습니다. 선분은 6000에서 시작하여 30일이 흐르는 동안 0으로 수렴하는 그래프가 가장 이상적일 것입니다. 하지만, 실제로 그렇게 예쁜 그래프가 그려진다면 뭔가 의심해봐야 할 것 같기도 합니다. 팀원들이 혹시 외계인이 아닌지...

스크럼을 해볼까요?

제품 백로그의 예

팀원들은 제작에 들어가기에 앞서 새로 제작 할 게임이 어떤 매력으로 사람들을 유혹하고 붙잡아둘지에 대해 폭넓게 논의했습니다. 기획팀은 그 수많은 의견들을 정리하여 필요한 것들을 간추립니다. 이 목록을 우리는 '제품 백로그(Product Backlog)'라고 부릅니다. 제품 백로그는 게임이 갖추어야 할 기능과 요소들로 구성되며, 개발자가 아닌 사용자의 관점으로 작성하는 것이 중요합니다. 이 시기는 아직 개발자가 개입하는 단계가 아닌, 사용자의 요구사항을 취합하는 단계이니까요. 또한 나중에도 필요에 따라 얼마든지 새롭게 추가되고 제거 될 수 있습니다.

제품 백로그가 갖추어지면 본격적으로 첫번째 스프린트를 준비합니다. 스프린트 회의에서는 먼저 제품 백로그에서 우선순위가 높은 것들을 대상으로 이번 스프린트에 추가 할 기능을 선정합니다. 그리고 선정된 각각의 기능을 구현하기 위해서 필요한 작업 즉, '태스크(Task)'를 얻어냅니다. 이 절차가 완료되면 이번 스프린트에 해야 할 모든 작업들이 목록으로 추출됩니다. 이 목록을 우리는 '스프린트 백로그(Sprint Backlog)'라고 부릅니다. 태스크로 분리하고 작업 시간을 할당하는 것은 해당 작업과 연관 된 팀원들이 맡아서 해주어야 합니다. 드디어, 스프린트에 해야 할 일들과 대략적인 스케줄이 확정되었습니다. 스프린트 회의의 마지막 절차로 방금 확정된 태스크들을 포스트잇에 옮겨 적습니다. 포스트잇에는 작업명, 작업자, 작업시간을 반드시 적습니다. 그리고, 화이트보드에 미리 그려놓은 TODO 사각형 안에 모두 옮겨 붙입니다.

누가, 무엇을, 얼마동안

본격적으로 개발이 시작되었습니다. 아침에 출근하고 작업 채비가 갖추어지면, 모든 팀원이 모여 스크럼 회의를 진행합니다. 한명씩 돌아가면서 어제 한 일, 오늘 할 일, 그리고 일정에 문제가 생기다면 그 이유를 이야기합니다. 오늘 할 일이 새로 할당되면, TODO 영역에 있던 포스트잇을 뜯어서 DOING 영역으로 옮깁니다. 어제 한 일로 하나의 태스크가 완료되었다면 DOING 영역에 있던 포스트잇을 DONE 영역으로 옮깁니다. 이렇게 TODO, DOING, DONE 영역에 골고루 포스트잇을 붙여가며 작업의 처리를 구분합니다.

작업을 하다보면 포스트잇에 적어둔 작업일수를 초과할 수 있으며 팀은 그것에 구속받아서는 안됩니다. 산정한 작업 시간은 단지 개발 전에 추정한 예상 시간일 뿐이며, 여러가지 이유로 정확히 맞아떨어지지 않을 수 있습니다. 작업을 너무 간단하게 생각했다거나, 뜬금없이 옛날에 진행한 작업에 수정 요청이 들어왔다거나, 갑작스러운 연차 휴가를 내었을 수도 있습니다. 반면 너무 어렵게 생각했지만, 매우 쉽게 개발 된 반대 사례도 있을 수 있습니다. 언제나 중요한 것은 일정이 예측과 달랐던 원인을 파악하고 함께 공유해야 한다는 것입니다. 

스크럼 회의가 끝나면 팀 리더는 번다운차트를 업데이트 합니다. 어제 마지막으로 점을 찍은 위치에서 오늘 작업 완료된 시간만큼 아래쪽에 점을 찍어 선을 이어주면 할 일이 끝납니다. 스프린트 도중에 새로운 태스크가 추가되거나 삭제되는 경우에도 그에 상응하여 남은 작업 시간을 계산하면 됩니다. 팀원 모두는 번다운차트로 팀이 순항중인지 문제를 겪고 있는지를 파악 할 수 있습니다.

스크럼 대시보드 예

스프린트를 진행하는 동안 여러 시행착오를 겪습니다. 욕심을 부려 산정해놓았던 몇몇 기능들이 결국 팀 회의를 통해 이번에 완성하기는 불가능하다는 결론을 내리고 다음 스프린트로 미뤄지는 아픔도 겪고, 팀원들간의 아름다운 협업으로 예상보다 훨씬 빨리 끝나서 즐거웠던 기억도 생깁니다.결국 팀은 플레이가 가능한 데모 버전을 하나 얻어냅니다. 예상치 못하게 여러 기능들이 빠진 데모 버전이 만들어졌을지도 모르지만, 좋은 경험이 될 수 있을 것입니다.

어느 회사의 스프린트 리뷰 회의

이제 스프린트를 돌아보는 시간입니다. 스프린트 리뷰 회의는 지난 스프린트에서 완료해낸 작업과 실패한 작업을 되돌아봅니다. 그리고 완성된 데모 버전을 공개합니다. 데모 버전은 팀원들 뿐만이 아니라 사내의 다른 직원들에게 널리 플레이됩니다. 그리고, 그들로부터 얻은 가치있는 피드백들은 다음 스프린트의 방향을 잡는데 큰 도움이 될 수 있습니다. 물론 가장 중요한 것은 게임을 플레이 해본 사람들이 진심으로 즐거워하는지 유심히 살펴보는 일일 것입니다.

마지막으로 회고(Retrospective)라는 절차가 남아있습니다. 모든 팀원들은 지난 스프린트에서 있었던 일들에 대해 다시한번 돌아보는 시간을 갖습니다. 하지만, 되돌아보는 것으로 끝나지 않고 더 향상시키려는 노력이 반드시 필요합니다. 그래서 회고 시간에는 두 가지 질문에 대한 답변이 꼭 필요합니다. 첫번째는 '이번 스프린트에서 어떤 점이 좋았는가', 두번째는 '다음 스프린트에서는 어떤 점을 향상시킬 것인가'

이로서 한 스프린트가 완전히 완료되었습니다. 다음 스프린트는 이번보다 더 즐겁고 보람있기를 바래봅니다.

스크럼은 충분히 가치가 있습니다.

스크럼을 도입하여 진행된 프로젝트에서 느낀 것은, 이전의 개발 프로세스가 대단히 느슨한 방식이라는 점입니다. 느슨한 시스템에서 효과적인 업무 성과를 내기 위해서는 프로젝트 구성원의 자율적 노력이 반드시 필요합니다. 하지만, 차고 창업자(Garage startup)와 같은 열정적인 도전자들이 아닌 이상, 자율적 노력에는 한계가 있습니다. 이런 문제를 해결하는데 검증된 알맞은 도구가 스크럼입니다. 스크럼은 일정을 준수하고 의미있는 결과물을 만들어내기 위해 꽤 강력한 시스템을 요구합니다. 매일 작업 내용을 체크하고 일정을 비교하며 진행 상황을 공유합니다. 대신 쓸데없는 관행, 사소한 참견, 소통의 부재 등 개발을 더디게 하는 외부 방해 요소들을 막아줍니다.

한 눈에 보는 스크럼

스크럼은 기존의 방식에 익숙한 사람들에게 무척 생소한 개발 방식입니다. 그래서 이를 도입하려는 임원진의 적극적인 의지가 없다면 팀과의 의견 충돌이 생겨납니다. 스크럼에 대한 참여자의 올바른 이해가 없으면 이를 통해 얻어지는 업무 향상 역시 거의 없습니다. 스크럼을 적용하면 순식간에 문제점들이 많아집니다. 하지만 이 것들은 스크럼이 만든 문제가 아닙니다. 다만 이제까지 땅속에 묻어두었던 문제들입니다. 그럼에도 불구하고 이런 허들을 뛰어넘어 스크럼을 성공적으로  도입한다면 분명 기대한 것 이상의 효과를 얻을 수 있을 것입니다.

아래는 사내 발표 용으로 제작한 프리젠테이션 자료입니다:

스크럼, 이걸 왜 하나요 from Reid Lee