스크럼(Scrum)의 스프린트(Sprint), XP의 스토리(Story)

스크럼의 스프린트와 XP의 스토리는 같은 의미로 사용되는 프로젝트의 세분화된 단위이다.
스프린트는 30일을 기준으로 백로그에서 우선순위가 높은 작업을 수행해야할 과업으로 나눈 것이고,
스토리는 2주 단위로 나누어서 우선적으로 해야할 작업을 수행 하는 것이다.

둘의 차이점은 없다. 둘다 지정된 기간내에 한 단위 작업을 성공적으로 이행하고, 그것을 시연함으로써 전체 과업을 달성하는 부담감을 줄이면서도, 고객과 기민하게 상호작용 하면서, 보다 고객이 원하는 방향으로 프로젝트를 성공으로 이끈다는 것이다.

처음 이 내용을 읽고서 엄청난 기대감과 자신감에 차 있었다.
과거 프로젝트 방법론 역시 업무를 나누고, 그것을 분배해서 결과를 내는것은 같은것이지만, 그 주기를 더 짧게 잡고, 문서나 말이 아닌 실행되는 프로그램으로 그것을 증명하는 것이었기에 과거에는 약속하지 못했던 수많은 일을 해 낼수가 있기 때문이었다.

하지만 한가지 의문이 생겼다.
이것을 SI 프로젝트에 이용하면 어떻까?
SI에 적용하면, 밑도 끝도없는 프로젝트 밤샘 작업을 좀 줄일수 있지 않을까?
그리고 최소한 릴리즈 날짜에 병이 날정도로 긴장을 하지 않고, 밤도새지 않을수 있지 않을까?

그런 생각으로 기존의 방법대로 업무를 분해하고, 나름대로 스토리를 작성했다.
그리고는 개발자들에게 각자 업무를 분장하고, 일일 체크 (사실 일일 스크럼 회의는 할수 없었다. 모두들 지쳐 있었고, 매일 회의실을 다른팀이 차지해 버려서, 일정하게 모일수 있는 장소를 마련하기가 녹녹치 않았다. 그래서 주단위 주 2회 회의를 잡고 주 시작인 월요일과 주 마지막인 금요일 오전에 회의를 했다.)를 수행했다.
회의의 핵심은 개발자 스스로 지정된 일정을 지켜서 일을 하고 있는지, 해야할 일을 하고 있는지와, 가장큰 것은 그들이 가지는 문제점이 무엇인지 편안한 분위기로 도출해 내는것과 가능하면 빠른 시일내에 문제를 해결해서 업무에 지장이 없도록 하는 것이었다.

직접 수행되는 내용을 기획 관리팀이 테스트 해보게 했고, 거기에 따른 변경사항도 나왔다.

문제는 여기서 부터 시작 되었다.

우리는 초기 프로젝트를 따기 위해서 제안서를 작성하고, 정해진 일정을 미리 잡아버린 상태였다.
대부분의 한국내에 이루어 지는 프로젝트가 그렇듯이 특별한일(사실 특별한 일은 항상 생긴다.)이 없는한 프로젝트 일정은 매우 짧게 정해지고, 이미 정해져서 수정이 불가하다고 못박아 버린다.

이런 환경에서 수정사항을 처리할 시간이 없었다. (수정사항은 항상 이렇게 발생한다. 기획을 해놓고 보니까. 저번주 회의에서 이렇게 하면 좀더 멋진 기능이 될꺼라면서, 어디서 이렇게 하는것을 봤다. 좋더라.. 하는 식으로 발생된다.) 왜냐하면 프로젝트 기간을 산정할때 지정된 시간내에 처리하기에도 개발자들은 하루에 주 60시간 이상을 일해도 정해진 일정을 맞추기에는 빠듯한 시간이었기 때문이었다.

여기에서 고객의 의견은 개발자들이 정시 퇴근을 포기하고 개발해야하는 업무의 증가로 다가 오는 것이었다.

이쯤되면 개발 총괄인 내가 나타나서 한바탕 푸닥거리를 해야할 때가 된것이다.
기획팀에게 시간, 비용, 개발팀의 피로도를 이야기하면서 현업과 잘 이야기해서 쓸데없는 기능은 빼고, 핵심에 치중하자고 난리를 치게 된다. 그렇게 해야 개발팀 팀원들에게 원망을 사지 않기 때문이기도 하지만 사실 나도 너푸 피곤하기 때문이다.

본사에서 이런 상황을 알아서 도움을 주려는지 스크럼에서 말하는 백로그와 비슷(?)한 이슈관리툴인 맨티스라는 것을 들고 나왔다. 이쯤 되면 역시 내가 나서서.. 그딴거 잘못쓰면 마이너스이니 좀더 신중하게. 그리고 이슈 사항에 대해서 테스트와 기획팀에게 상세화 하는 교육을 충분히 하고나서 천천히 도입해라 하지만, 막무가내로 좋더라 식으로 밀어 붙인다.

하지만 늘 일은 기대했던것이, 이때다~ 하면서 일어난다.
테스트를 수행하는 사람은 어떤 상황에서 어떠한 문제가 발생했다고 절대 이야기 하지 않는다. 그들은 단지 "XXX오류 발생" 이라고만 쓴다. 그럼 우리는 각자의 상상력을 동원해서 그 오류를 찾으려고 몇시간을 헤메인다. (그시간에 코딩하면, 게시판 하나는 나온다.... 에효...)

그러면서 우리에게는 해야할 일에 수정해야할 일이 즉, 고정된 기간내에 해야할일은 1.5 ~ 2배로 증가하게 된다.

스크럼에서 말하는 스프린트와 스토리, 백로그등은 이런 모습을 바라는 것이 아닐 것이다.
하지만 현재 우리나라 SI에서는 스크럼 방법론을 적용하고자 하는 오픈마인드 부족인지, 실제 적용하고자 하는 기업과, 현업이 없다는 것이 참 안타까웠다.

스크럼을 현재 SI에서 성공적으로 적용한 프로젝트가 있다면 배우고 싶다. 어떻게 그것을 적용할수 있는지 말이다.
가령,
1. 백로그 리스트를 작성해보니, 초기에 산정한 기간을 오버하지 않으면 개발을 완료할수 없을때, 기간을 늘일수 있는 방법이 있는지...
2. 스프린트를 끝내고 고객의 요구사항이 바뀌어서, 다음 스프린트를 준비해야하는데 이전 스프린트의 변경작업을 해야할때, 백로그 우선순위와 개발 기간을 어떻게 재조정하고, 현업의 동의를 얻어낼지.
3. 업무가 스크럼 마스터를 통하지 않고, 바로 개발자에게로 들어갔을때, 업무 지시자와 부당함과 기간에 대한 이야기를 했을때, 이미 현업과 협의가 끝나버린 상태일경우라면 어떻게 백로그를 다시 지정할지..
4. 스프린트 작업이 단순히 우리 팀 내의 일이 아니라 외부 인터페이스를 통해서 작업 해야하지만, 아직 외부 인터페이스를 지원해줄 업체에서 작업이 마치지 않았을 경우에 어떻게 조정을 해야할지. - 사실 이 부분은 크게 문제가 되지 않았다. 일정 재 조정을 할수 있었으니 말이다. (한 프로젝트에서 고객과 일정 계약을 맺은 대형 벤더가 있었는데, 그들이 해야할일을 하지 못했다. 그렇게 해서 일정이 한달 지연이 되었지만, 고객은 그들에게는 상당히 관대했다. 우리에게는 일주일 지연이 크나큰 재앙처럼 부산을 떠는것에 비해서는 말이다....)
5. 현업이 기존 개발된 시스템을 보고 백로그 리스트 (맨티스, 트래커와 같은 이슈관리툴)에 계속해서 요구사항을 추가해 넣을때, 즉시 응대해지 않으면 기간내에 해야하는 업무가 되어 버린다면, 거기에 인력을 소진해야할지..
(백로그 관리는 내가 해야한다.. 하지만.. PM과 기획에서 공권역을 가한다.... 대부분이 내가 모르는 밀실 협약에 의해서 이미 백로그 리스트에 올라와 있다.. ㅜ,.ㅜ; 그때마다, 난 성깔 더러운 인간이 된다....)

기타 이러한 일 이외에도, 다양한 문제가 발생하게 되는데 이러한 사항에 대한 적용 방법이 정말 알고 싶었다.

프로젝트 방법론의 공통적인 내용은 대부분, 프로젝트 목표를 설정하고, 그 목표를 달성하기 위해서 해야할 업무를 잘게 나누고, 그것을 지정된 시간내에 이룰수 있도록 지원하는 다양하고 유용한 방법론을 제시하는 것이다.

잘게 나눈 작업들이 스프린트이고 스토리가 되며, 매일 혹은 주간 회의를 통해서 개발자들 사이에 작업 진척도를 체크하고, 프로젝트 진행에 발생하는 장애물을 제거하는 작업을 수행한다. 그리고 테스트 기간이 되면, 단위 테스트에서 통합테스트에 이르기까지 테스트를 수행하고, 마지막 산출물을 내놓게 된다.

스크럼이나 XP에서는 그 주기가 상당히 짧다. 과거에 고객이나, PMO, 개발자들까지도 나와봐야 알던 결과를, 프로젝트 중간중간에 확인하고 변경해 나갈수가 있다는 장점이 있다.

하지만 이것역시 방법론중에서 소프트웨어, 경험적인 비용산정과 프로젝트 관리라는 측면에 모두 사용될 수 는 없을 것이다.
개발 환경에 맞추어 적절하게 적용하는 것이 필요할 것이며, 백로그 관리를 하는것은 좋지만, 전체 일정에 차질을 주는 작업은 어떻게 하든 막든지, 추가해주는 대신 기간을 연장하든지 해야 현실적인 프로젝트 관리 방법론이 될 것이다.

다음에 프로젝트를 따기위해서 무리한 서비스 차원에서 백로그에 작업이 추가되고, 그것을 기간내에 반드시 해야할 작업으로 남게 된다면....

Never ending Project.... 가 된다. 그것은 확실하다. (작은 변경, 글자하나 변경하고, 이미지 하나 변경하는 작업에도, 반드시 인력과 시간이 들어간다... 우리는 그 작은 시간들이 모이면 얼마나 큰 시간이 되며, 맨먼스가 되는지 분명히 깨닫고 있어야 한다.)

적절한 방법론.. 그것은 틀에박힌것, 성공모델을 읽고 그것을 실천하는 것이 아니다.
내가 직접 느끼고, 다양한 방법론의 장점을 어떻게 하면 프로젝트에 적용해서 효과를 볼 수 있을지 끊임없이 고민하고, 노력해야하는 것이다.

지금까지 틀에 박힌 방법론, 그리고 산출물 (지금은 정보공학적 방법론의 그 방대한 산출물이 주를 이루었다.)이 만들어내는 쓰레기들을 버리고 프로젝트에 맞는 방법론과 산출물을 통해서 프로젝트에 도움을 줄수 있도록 하는 노력이 필요할 것이다.

PS 1.
혹 SI에서 스크럼을 사용해서 성공을 한 프로젝트가 있으면 정말고 알고 싶다.
이는 스크럼을 부정하는 것이 아니라. 스크럼의 어떠한 면을 프로젝트에 어떻게 적용하는 것이 좋은지 배워보고 싶은 간절함이다.

PS 2.
XP와 스크럼은 지금까지 나와있는 가장 가시적이면서도, 현실성 있는 방법론이다.
Agile 진영은 이런 실천적인 방법론, 좀더 현실적인 대응책을 주로 이야기한다. 그것은 우리같은 전산쟁이들의 삶을 조금이나마 윤택하게 할수 있도록 해주는 선배들의 노력의 산물일 것이다.
앞으로도 이런 좋은 사례들과 실천적 방법론들이 좀더 다양한 분야에 다양하게 적용될수 있도록 발전되고, 많이 나왔으면 하는 바램이다.