SCRUM에서 백로그에 대한 통제와 작업 수행

SCRUM에서 SCRUM Master는 일반적인 프로젝트의 PM/PL과 유사하게 생각할 수도 있지만, 가장 주요한 역할은 작업(구현할 기능)에 대한 통제입니다. 또한, 한팀은 5 ~ 7명으로 구성된 특정 전문성에 특화되지 않으며, 모든 SW 관련 작업에 대해 일정 수준의 전문화를 갖춘 구성원들이어야 합니다.(cross functional team)

이에 대한 원칙은 무엇보다도 SW 관련 작업에 대한 특수성에서 기인합니다. 우선, 제품 백로그(product backlog)는 SW 제품이 최종적으로 완성되었을 때에 해당 제품이 가지는 기능의 목록입니다. (비기능 목록 포함) SCRUM에서는 일반적으로 말하는 기능(function, feature)이라는 단어 대신에 backlog라는 단어를 명시적으로 사용하고 있습니다. 이는 기능이라고 말할 때에 비기능적인 특징들에 대해서 포함되지 않는다는 개념이 이미 들어가 있고, 이전부터 사용되는 단어이기 때문에 새로운 용어인 backlog를 사용하고 있습니다. backlog는 작업에 대한 queue이며, 여기에 들어오는 모든 작업들은 SCRUM Master에 의해서 통제되어야 합니다.

SCRUM에서의 이러한 SCRUM Master에 의한 backlog 관리는 일반적인 queueing 이론에 근거합니다. Queueing 이론은 서버와 클라이언트로 구성원이 형성되며, 서비스를 받고자 하는 클라이언트가 도달하는 순간(arrival time)부터 서버로부터 서비스를 받고 그 목적하는 바를 달성해서 떠나는 순간(departure time)을 어떻게 효율적으로 관리할 것인가에 대한 것입니다. 이때 특정 순간에 서비스를 받고자 하는 클라이언트의 수가 서비스를 제공하려는 서버보다 많게 되는 경우, 대기열이 발생되며 이를 queue라고 말합니다. 즉, 이 queue에 남아있는 클라이언트의 수를 일정한 적정 수준으로 유지하거나 최소화시켜서 전체적인 성능(performance)를 최대화시키는 것이 목적입니다. 즉, 전체적인 성능을 극대화시키기 위해서는 queue에 있는 클라이언트의 수와 서비스를 제공하는 서버의 수를 어떻게 조화롭게 구성할 것인가가 관건이 됩니다.

 

People or Ants? by boliston 이를 SCRUM에 적용해보면, queue에 있는 클라이언트는 SW 관련 작업이 됩니다. 그리고, 서버는 작업자(팀원)가 되고, queue에 있는 작업을 관리하는 역할자가 SCRUM Master가 됩니다. 작업자(팀원)의 수를 늘리게 되면, 많은 작업을 처리할 수 있겠지만, 어느 순간에는 작업을 처리하지 않는 idle 작업자가 생기게 됩니다. 이는 불필요한 잉여 비용이 발생되는 것과 같습니다. 즉, 많은 수의 팀원을 갖는 것이 효율적이라고 볼 수는 없습니다. (또한, 프로젝트 내 예산이 한정되어 있기 때문에 충분한 인력을 갖는다는 것은 불가능합니다.) 따라서, 적정 수준의 작업자가 처리하도록 해야 합니다.  또한, queue 상에 있는 작업이 이를 처리할 수 있는 작업자보다 과도하게 많이 남아있게 되면, 이는 작업 처리에 대한 부하가 적정수준으로 유지되는 queue보다 상당히 증가합니다. 이러한 예는 고속도로 매표소를 생각하면 됩니다. 만일 일정하게 속도가 유지되는 고속도로 매표소 근처의 queue는 거의 순서를 대기하지 않고도 바로 통과가 가능합니다. 하지만, 통행량이 너무나 많은 출퇴근이나 명절에는 queue에서의 대기 시간이 큰 폭으로(보통 기하급수적으로) 늘어납니다. 이때, 매표소에서 작업을 처리하는 사람은 이전에 한산한 상태에서나 그렇지 않은 상태나 동일한 시간으로 처리함에도 불구하고, 대기 시간이 엄청나게 차이가 발생하는 것을 느꼈을 겁니다. queue는 바로 이러한 특징이 있습니다. 즉, 작업을 처리하는 작업자가 평균의 시간으로 작업한다고 하더라도 queue에 남아있는 작업의 수가 일정 수준이 높아지면, 상당한 지연이 발생한다는 것입니다. 따라서, SCRUM Master는 이러한 queue에 있는 작업의 수를 일정하게 유지하도록 하는데 그 책임이 있습니다. 그리고, 프로젝트를 진행하는 시간 간격이 상당히 많기 때문에 일정 주기로 이를 반복적으로 수행할 수 있게 하여 일을 좀 더 효율적으로 만들게 합니다. 즉, 제품 백로그보다는 반복 주기인 sprint에 대한 backlog를 더 신경써서 관리해야 합니다. 따라서, 반복을 짧게 가지고 가고 queue에 들어온 backlog에 대해서는 일단 결정이 되면, 가급적 변화를 주지 않는 것이 필요합니다. 하지만, 작업자가 특정 기술에만 숙련되어 있어서 (예를 들어, 배포만을 담당하는 작업자나 형상관리만 담당하는 작업자, 혹은 설계만을 담당하는 작업자) 작업 유형별로 처리하는 작업자가 별도로 존재한다고 한다면 이는 queue에 있는 작업이 특정 작업자에게만 할당이 되어서 결국은 queue를 만들어놓고 제대로 사용하지 못하는 결과를 초래하게 됩니다. 다시 말하면, 특정 작업자에게는 일이 몰리고, 다른 작업자는 일이 없어서 idle 상태를 유지하는 결과가 발생됩니다. 이는 공항에서 티켓팅을 하는 형태나 화장실에서 일렬로 서서 대기하는 형태를 생각해보면 쉽게 이해가 갑니다. 여러 줄(queue)을 만들어 놓고 서비스를 수행하는 경우에는 다른 줄이 더 빨리 처리되는 결과가 발생되거나 또 다른 줄에서는 더디게 처리되는 결과가 발생되어서 전체적인 성능이 다시 안좋아지는 결과가 나타납니다. 따라서, queue에 있는 작업에 대해서는 모든 작업자가 처리할 수 있는 능력을 가져야 된다는 것입니다. 축구로 비유하자면, 마치 토탈 사커와 같은 형태입니다. 수비자가 공격도 하고, 때로는 공격수가 수비도 할 수 있는 능력이 있어야 되는 것입니다. 추가적으로, queue에 있는 작업을 어떤 수준으로 나눌 것인가도 하나의 변수가 됩니다. 즉, 해당 작업을 처리했는데, 나중에 이를 다시 처리해야 한다고 하면 이는 해당 작업이 완료된 상태가 아니기 때문에 이는 기존 처리 작업이 완료되었다고 볼 수 없습니다. SCRUM에서 작업은 명확하게 완료를 증명할 수 있는 형태로 나뉘어야 되며, 짧은 반복을 고려해서 대략 2 ~ 3일 정도의 작업 분량으로 나뉘어야 합니다. 위에서 말했듯이 해당 작업을 시작하는 것이 중요한 게 아니라, 작업을 완료하는게 더 중요합니다. (완료의 기준이 명확해야 합니다.) 이와 같은 전제 조건이 만족되면 SCRUM은 가시적인 형태로 관리가 가능하며, 작업 역시 통제가 가능합니다. 보통 프로젝트/품질 관리는 측정되고 계량화되어야 의미있는 통제가 가능합니다. 꼭 SCRUM이 아니더라도, SW 개발에서 queueing 이론을 잘 살펴보면, 너무나 많은 변이(variation)로 인해 예상하지 못하는 일들이 발생되는 것을 최소화시킬 수 있을 것입니다. 문제는 이러한 변이들을 어떻게 통제하고, 어떤 방법으로 표준화시킬 것인지가 관건이 됩니다.