Agile 프로젝트 퀵가이드(14) : Execution & Control편-성과측정과 산출물관리

스크럼 가이드북에는 “성과 측정”이란 용어 대신 “진행상황 모니터링”이란 말을 사용합니다. “성과”라는 용어 자체가 과정 보다는 결과 중심적이며, 구성원간 상호 협력과 상생보다는 경쟁을 강조하는 측면이 있기에 필자 또한 스크럼 가이드북에서 사용하는 “진행상황 모니터링”이라는 용어 사용에 더 끌립니다.
그러나, 당사의 방법론에서는 “성과 측정”이란 단어를 사용하여 스프린트의 전체 공정 중 독립적인 프로세스로 정규화하였습니다. 아무래도 외부의 고객사와 계약을 통해 S/W 개발 프로젝트를 진행하는 SI 구조에서는 프로젝트의 과정 못지 않게 결과가 중요하며, 많은 이해관계자를 만족시키기 위한 지표 관리가 중요하겠지요.
애자일 프로젝트를 위한 다양한 성과 지표 관리 방법에 대해서는 CNAPS 2.0 애자일 방법론 본문을 참고하여 상세히 알 수 있습니다.

본 포스팅에서는 퀵가이드답게 애자일 프로젝트에서 주로 사용되는 몇가지 핵심 지표에 대해서 간략히 언급하겠습니다.

성과 측정 대상

스크럼 프로젝트에서 관리해야 하는 주요 성과 지표로써 “팀 속도”와 “번다운차트”가 있습니다다. 이에 대해서는 지난 Starting 퀵가이드 (7)- 의사소통 및 품질관리 계획에서도 소개한 바가 있습니다.

팀 속도

팀 속도는 한 팀이 단위 스프린트 기간 내에 완료시킨 스토리 포인트 총 합을 의미하며, 이 때, 완료기준의 정의는 고객과 사전에 정한 조건에 부합된 것이어야 합니다.(이에 대해 모든 팀원이 동일한 생각을 가져야 함)
스프린트 종료시 완료된 일감의 크기만을 대상으로 하며, 미완료 및 진행 중에 있는 일감은 제외시킵니다.
진행 중인 일감에 경우 이미 Effort가 투입되었을 수 있지만, 팀 속도는 투입된 Effort 크기를 보고자 하는 것이 아니며 순수하게 완료된 일의 크기만을 대상으로 합니다. 팀 속도는 얼핏 보기에는 팀 생산성과 비슷하지만 Effort가 아닌 완료된 일감의 크기이기 때문에 생산성이라고 보지 않습니다.

주의해야 할 것은, 팀의 속도를 측정하는 것이며 어느 한 개인의 속도를 평가하기 위함은 아닙니다.
팀 속도를 측정하는 이유는 다음과 같습니다.

• 팀 속도를 고려하여 다음 스프린트의 계획시 스프린트 목표 수립 및 스프린트 백로그를 선정할 수 있다.
• 속도가 더 개선(상승)될 여지가 있는지, 가까스로 최고 속도가 유지되고 있는지 등을 확인하고, 속도 개선을 위해 제거해야 할 장애물이 있는지를 검토한다.
• 팀 속도와 번다운 차트를 함께 관찰함으로써, 전체 스프린트 완료시 프로젝트 목표를 달성할 수 있는지 여부를 예상할 수 있다.
  
  

번다운 차트

번다운 챠트는 제품 출시를 위해 진행하기로 계획된 일감 크기의 총량의 변화를 보여준다. 세로축은 일감량을, 가로축은 시간을 사용합니다.
번다운 차트를 통해 시간이 지남에 따라 남아 있는 일감 총량이 감소하는 양상과 기울기를 모니터링함으로써, 팀의 속도에 비해 남아있는 일감 총량이 적정 수준인지–즉, 완료 가능한 수준인지-를 예상할 수 있고, 스프린트 회고 미팅에서 또는 다음 스프린트 계획 수립시 현재의 속도를 변화시키기 위한 프로세스 개선과 전략의 변화를 모색할 수 있게 됩니다.
팀 속도가 지속적으로 증가했음에도 불구하고 잔여 일감의 양이 크게 줄지 않는다면, 팀은 번아웃될 위기에 놓이게 됩니다. 이는 백로그가 지속적으로 늘어나고 있거나 또는 애초에 일감 크기가 잘못 산정되었다는 의미입니다.

위 그림에서 빨간색 그래프가 잔여일감의 변화를 나타내고 있지만, 추가적으로 녹색과 파란색 그래프를 사용하여 전반적인 상황을 더 잘 보여줄 수 있습니다. Baseline는 초기 계획시 수립한 기준선으로 스크럼팀이 도달해야 할 목표입니다. 파란색 라인의 변화는 프로젝트 중도에 전체 일감량이 크게 증가된 양상을 나타내는데, 이에 따라 잔여일감의 양도 크게 증가하여 Baseline목표와 큰 Gap이 발생하고 있음을 알 수 있습니다. 물론스프린트 #4 이후에 catch-up 시도를 했겠지만, 그럼에도 불구하고 녹색과 빨간색의 기울기 차이는 몇 차례의 스프린트 수행 후에도 팀 속도가 목표를 따라잡지 못하고 있음을 시사합니다.
이런 상황에서는 스크럼 마스터와 프로젝트 의사 결정권자가 남은 2개의 스프린트 동안 목표에 도달할 수 있도록 특단의 조치를 취해야 할 것입니다.

이상에서 알 수 있듯이 스크럼 프로젝트의 진행상황을 모니터링하고 필요한 조치를 취하기 위해서는 번다운 차트를 주기적으로 업데이트되도록 관리하는 것이 중요합니다. 가장 이상적인 측정 주기는 매일매일 진행되는 일일 스크럼 미팅에서 공유된 일감의 완료 상태를 즉시 반영하는 것입니다. 그러나, 매일 업데이트하는 여건이 안될 경우에는 주별 또는 최소한으로 하더라도 스프린트 주기마다 번다운 차트가 업데이트될 수 있도록 해야 합니다.

산출물 관리

애자일 선언문에서는 “문서화된 산출물보다는 작동하는 S/W를 더 가치있게 여긴다”고 했으며, 스크럼 가이드북에서도 산출물에 대해서는 단 3가지 종류만 언급하고 있습니다. “제품 백로그”, “스프린트 백로그”, 그리고 “제품(증분)” 입니다.
제품의 feature에 해당하는 제품 백로그, 그 백로그를 구현하기 위한 Task와 완료조건 등의 작업명세에 해당하는 스프린트 백로그, 그리고 실제 세계에 구현된 제품 그 자체만이 산출물로써 가치 있다고 여기는 것은 어찌보면 극단적인 관점처럼 보일 수도 있습니다.
그러나 애자일 방식으로 S/W를 개발하기로 선택한 프로젝트라면 애자일 특성을 감안해야 합니다. 사실 매 스프린트마다 고객의 피드백을 우선적으로 고려하여 다음 릴리즈에서 해당되는 제품 기능을 구현해내느라 스크럼 팀이 전력질주하는 상황에서, 또다른 문서 산출물도 만들어 내라고 요구한다면 차라리 애자일을 하지 말고 전통적인 방법으로 돌아가자는 답변이 돌아올 것입니다.

이와 같이 애자일 방식에서는 문서 산출물을 강조하고 있지는 않지만, 우리나라의 SI 프로젝트 여건을 고려해 볼 때 고객에게 인도할 산출물이 무엇이 되어야 하는지는 프로젝트 관리 차원에서 명시적으로 선언할 필요는 있습니다.
즉, 애자일 프로젝트라 할 지라도 개발 산출물 각각에 대해 합리적인 수준에서 어떤 것들을 인도할지 또는 문서로 증적을 남겨두어야 할 대상이 무엇인지 미리 정의함으로써, 추후 산출물에 대한 고객과의 다툼 소지를 방지해야 합니다.


또한 개발 외에 관리 영역에서도 산출물이 필요할 수 있습니다. 이 부분은 애자일 방법론의 영역이 아닌 프로젝트 관리의 영역에 속하는 부분입니다. 주로 PMBOK에서 이야기하는 범위관리, 예산관리, 품질관리, 위험/이슈관리, 구매관리 등의 영역을 말합니다. 수행사가 법적으로 책임을 져야 하는 외부 프로젝트, 특히 공공 프로젝트를 수행하는 경우에는 외부 감리를 감안하여 이러한 영역의 관리는 매우 중요합니다. 문서로 된 증적이 반드시 필요하며, 요구사항 변경이나 설계 변경시마다 이를 위한 근거 자료, 문서 산출물이 수반되어야 합니다. 이는 애자일 방법론에서 말하는 가치 지향적인 빠른 개발과는 충돌이 날 수 있습니다.
퀵가이드 Starting-프로젝트 수행준비 및 소통&품질 편에서도 언급하였고, 거듭 강조하건대 이러한 문서 산출물을 반드시 제출해야 하는 프로젝트인 경우에는 애자일 방법론을 추천하지 않습니다. 굳이 애자일 방법론을 적용해야 한다면 계약 단계에서부터 관리 산출물, 고객 인도 산출물의 범위에 대해서 사전 조율을 거쳐 적정 수준으로 관리될 수 있도록 해야 명시해야 할 것입니다.

맺음말

이상으로 퀵가이드 Overview & Starting 각 9편, 그리고 Execution & Control 각 5편에 걸친 내용을 마무리하고자 합니다. 애자일/스크럼 프로젝트를 시작하려는 프로젝트 관리자들에게 무거운 방법론보다 쉽고 빠르게 읽히기 위한 목적으로 시작하였는데, 꼭 필요한 내용만을 골라 쓴다고 하였는데도 생각보다 양이 많아졌네요.
흔히 갖는 애자일에 대한 가장 큰 오해는 “빠르게” 무언가를 해낼 수 있다는 부분일 것입니다. 아마도 “Agile”이라는 용어가 “민첩함”이란 뜻을 갖고 있는 데에서 기인한 것이겠지요. 그러하기에 애자일로 프로젝트를 하게 되면 모든 진행도 빠르게 만들어낼 수 있고, 결과도 빨리 만들어낼 뿐 아니라 “애자일 방법론” 그 자체도 조직이 빠르게 순응하여 적용할 수 있다는 식의 오해가 퍼져 있는 듯 합니다. 물론 애자일 방법이 조직에 내재화되어 개발팀 및 제품 책임자를 포함한 조직 전반의 구성원들이 모두 숙달된다면, 또한 애자일에서 말하는 Self-Organized & Cross-Functional한 조직이 된다면 기존 방법론보다 훨씬 빠르게 결과물을 만들어내리라는 것은 믿어 의심치 않습니다.
하지만, 새롭게 도입된 프로세스, 시스템, 문화와 같은 것이 구성원 모두에게 숙련되고, 조직 내에서 동일한 수준의 이해와 방법으로 실행하기까지에는 오랜 시간이 걸리는 법입니다. 부디 그 시기가 도래할 때까지 인내심을 가지고, 실천을 반복하시기를 바라마지 않습니다.
마지막으로… 프로젝트 현장에 나가 코칭을 하게 되면 말로 전달하는 사항들은 아무리 강조를 하여도 바쁘게 돌아가는 현장 특성상 공중에 흩어지는 느낌을 받을 때가 많습니다. 이제라도 활자화된 본 가이드를 읽어보면서 애자일 방식에 대한 이해를 조금이나마 늘릴 수 있다면 필자로서 더 바랄 나위가 없을 것 같습니다.
여기까지 읽어주신 분들에게 감사를 드립니다.

< EOF >