개발 관리 측면으로써의 스크럼
SI에서의 애자일 적용기 #2
SI 개발 프로젝트는 보통 폭포수 개발 방식으로 진행된다. 특히 정부나 연구원에서 발주된 과제는 더욱 그렇다. 고객에게 전달해야 하는 산출물과 일정이 정해져 있기 때문에 과제 기간 동안 자체적으로 다른 개발 방법론을 적용하기도 어렵다. 게다가 "SI에서 스크럼을 적용하기 어려운 이유"들로 인해 프로젝트에 스크럼을 적용할 생각을 하지 못했다.
그러던 중 책 소프트웨어 개발과 테스트 - 조대협의 서버 사이드에서 소개하는 빅엄브렐라 개발 방법론을 보고 깨달음을 얻었다. 그것은 스크럼을 완전한 형태로 프로젝트에 도입할 필요가 없다는 명쾌한 통찰이었다. 빅엄브렐라 개발 방법론은 전통적인 방법론(폭포수 개발)을 우산처럼 감싸고 세부 단계에서 애자일 방법론을 적용하는 방식이다. 즉, 폭포수 개발의 단계인 분석->설계->개발->테스팅의 각 단계을 진행하면서 반복적으로 분석->설계->개발->테스팅을 수행하겠다는 것이다. 이 방법이 얼마나 유용할 지 구체적으로 어떻게 적용해야 할지는 알 수 없었지만 필자는 이미 필요한 부분만 프로젝트에 뽑아 넣으면 되겠다는 생각이 자라났다. 가장 먼저 떠오른 것은 개발 관리 측면의 스크럼이었다.
폭포수 개발에서는 특별히 프로젝트의 진행을 관리하는 도구나 방법이 없다. PM(프로젝트 매니저)이나 PL(프로젝트 리더)이 알아서 자신만의 노하우로 관리해야 한다. 그러다보니 폭포수 개발에서는 프로젝트 진행 관리에 대한 리더의 역할이 매우 중요하다. 리더의 능력이 뛰어나면 프로젝트가 물 흐르듯 흘러가고 PM의 능력이 부족하면 프로젝트가 꽉 막혀 나아가질 않는다. 예를 들어 프로젝트를 진행하면서 구성원들이 항상 집중하여 작업을 진행할 수는 없으니 PM이 상황을 파악하며 적절하게 조이기도 하고 풀어주기도 해야 한다. 필자는 프로젝트에서 PL의 역할을 수행하고 있으나 이런 능력이 매우 부족한 편이다. 진행 상황 파악이 쉽지 않았고, 언제 격려를 해야 할 지 언제 쉴 수 있게 해야 할 지 알 수가 없었다. 작업 시간 추정도 무척 어려웠다. 언제나 작업 시간은 예상을 빗나갔고 대체로 추정 시간보다 오래 걸렸다.(프로젝트 구성원에게 작업의 예상 시간을 직접 추정하도록 하기도 해봤다. 추정을 잘 하는 사람도 있지만 대부분은 작업 예측을 잘 하지 못한다.)
그래서 프로젝트의 개발 진행에 스크럼을 적용했다. 전체적인 개발 방법은 고객이 원하는 폭포수 방법을 따르되 개발 관리 프로세스로 스크럼을 적용하는 것이다. 즉, 분석 -> 설계 -> 개발 -> 테스팅 단계를 수행하면서도 일정 주기로 스프린트를 진행한다. 이 때의 스프린트는 애자일에서 말하는 개발 방법으로써의 스프린트와 조금 다르다. 애자일에서는 스프린트를 통해 실행 가능한 소프트웨어를 구현하고 이를 리뷰하며 모두와 공유한다. 하지만 폭포수에서는 개발 단계가 아닌 다른 단계에서 실행 가능한 소프트웨어를 구현하기는 힘들다. 따라서 요구사항 분석서 초안 완료, 기본 설계 초안 완료 등 일정한 목표를 가진 스프린트를 진행하는 것이다.
프로젝트에 스크럼을 적용하여 개발 진행을 관리 함으로써 개인적으로 원하던 결과를 얻을 수 있었다. 프로젝트 진행 상황을 파악하려고 크게 노력하지 않아도 번다운 차트를 통해 스프린트 기간 내의 작업의 진행 상황을 한눈에 파악할 수 있었다. 게다가 작업이 지체 되는 경우 이런 상황이 시각화 되어 모두에게 공유함으로써 리더가 굳이 독려를 하지 않아도 구성원들이 스스로 느끼며 자연스럽게 작업 속도를 조절했다. 게다가 스프린트 리뷰, 회고를 통해 스프린트를 돌아보고 학습함으로써 작업 예상 시간 추정 오차가 조금씩 줄어들기 시작했다. 즉, SI 프로젝트에 개발 진행 관리를 위한 변형된 스크럼을 적용하여 큰 도움을 얻었다. 다음에는 어떻게 스크럼을 변형하여 적용했는지 얘기해 보겠다.
