프로젝트는 고객의 요구사항을 이행하기 위한 것입니다. 프로젝트의 결과물이 고객이 원하는 대로 잘 나와서 고객을 행복하게 해주었으면 하지만 실제로는 그렇게 만족스럽지 못한 경우가 많습니다. 고객의 요구사항은 애초에 불분명하게 정해지는 경우가 많기 때문에 진행중에 요구사항이 변경되는 경우가 빈번하고.. 프로젝트를 거의 완성시켜가는 단계에서 고객이 자신이 원한던 결과물이 나오지 않았다며 대대적인 수정을 요구하게 되는 경우가 발생합니다. 이 경우 프로젝트 기간은 연장되고 제품의 품질은 떨어지며 모두가 불행해지는 프로젝트 결과가 나올 수 있습니다.
어떻게 해야 모두가 만족하고 행복한 프로젝트를 수행할 수 있을까요? 애초에 고객의 원하는 것이 무엇인지 최대한 정확하게 규정이 되고, 고객의 요구에 따라 정확하게 프로젝트가 진행되고 있는지 중간점검이 이루어진다면 가능해질 것입니다. 모든 것을 초기에 계획해서 계획한대로 프로젝트를 진행시키는 워터폴 방식의 프로젝트 방법은 그런 면에서 어려움이 생길 여지가 많은 것이 사실입니다. 고객의 요구사항이 개략적으로 수집된 다음에 이것을 바탕으로 고객에게 바로 보여줄 수 있는 결과물을 보여주고, 몇번의 단계별로 완성되어 가고 있는 가시적인 결과물을 보여주고 고객의 요구사항을 반영하여, 고객이 만족하는 최종 결과물을 완성키는 방법이라면 가능하겠지요.. 이런 방법론을 스크럼이라고 합니다.
[그림] 점진적 (incremental) 방법과 반복적 (lterative)방법
출처: http://ktsysop.blogspot.kr/2012/06/blog-post_1366.html
처음에 요구사항을 완벽하게 정의하고 점진적으로 결과물을 부분적으로 만들다보면 중간에 수정하려면 큰 어려움이 따릅니다. 경우에 따라서는 완전히 새로 만들어야할 수 있습니다. 하지만 주기별로 고객이 볼 수 있는 중간 결과물을 설정하여 반복적으로 만들어가면 고객이 원하는 결과물을 좀더 정확하게 만들어 낼수 있는 것이지요.. 위에 보이는 반복적 방법을 이용한 프로젝트 방법이 바로 ‘스크럼’입니다.
위키피디아에 따르면 “스크럼은 애자일 소프트웨어 개발 과정의 하나로 단순하면서도 구체적인 실천법들을 정의해 놓은 넓은 응용범위의 개발방법론이다“라고 정의하고 있습니다.
아래는 스크럼을 이해하기 위한 중요 요소들입니다.
1) 제품 백로그: 개발할 제품에 대한 요구 사항 목록
2) 스프린트(Sprint): 30 일의 반복적인 개발 주기
3) 스프린트 계획 회의: 스프린트 목표와 스프린트 백로그를 계획하는 회의
4) 스프린트 백로그: 각 스프린트 목표에 도달하기 위해 필요한 작업 목록
5) 일일 스크럼 회의: 날마다 진행되는 진척 상황 미팅
6) 실행 가능한 제품 개발: 스프린트의 결과로써 나오는 실행 가능한 제품
민혁아빠 블로그에서 스크럼을 잘 정리해주고 있어서 여기에 소개합니다.
출처: http://chidoo74.blog.me/10099867456
스크럼 방식은 고객의 요구 사항이 개략적으로 수집된 다음에 이걸 바탕으로 바로 고객에게 보여줄 수 있는 프로그램을 단계적인 몇 번의 단계를 거쳐서 최종적인 것을 만들자는 데에 그 핵심이 있다. 여기에서 단계라는 것을 스프린트(Sprint)라고 이야기를 하는데 각 스프린트에서는 개발적인 관점에서 해야할 일이 뭔지를 개발자들이 고객의 관점에서 중요하다고 판단되는 항목을 중심으로 판단해서 개발하고 스프린트 기간의 마지막에 그 기간동안 만들어진 결과물을 고객과 이야기하고 어떤 부분들에 대해서 좀 더 힘을 써야할 것인지를 고민하게 된다.즉 의견을 듣고 보여주고 하는 과정을 2 ~ 6주 기간을 가지고 지속적으로 반복하기 때문에 고객(혹은 고객의 관점을 대표하는 사람)의 입장에서는 내가 원하는 것이 어떤 과정으로 만들어지는지 그리고 정말로 내가 원하는 기능들이 제대로 되어가고 있는지를 확인할 수 있다. 물론 잘못 이야기한 내용을 수정한다든지 아니면 산으로 가고 있는 개발자들이 언덕쯤에 있을 때 이야기를 해서 내려오라고 알려줄 수도 있으니 말이다.
한 단계의 스프린트는 다음의 3가지 과정을 통해서 진행된다.
1) Sprint 계획회의 – 준비단계는 말 그대로 업무를 시작하는 준비를 하는 시간으로 하루정도를 소비한다. 팀원들이 스프린트 기간에 작업할 수 있는 날들이 얼마나 될지를 고려한다. (total man days for sprint period). 시간을 정했으니 우선 순위에 따라서 그 시간을 투입해서 할 수 있는 일들을 backlog 혹은 backlog의 세분화를 통해서 확인한다. 다만 하나의 처리되어야 할 업무(혹은 개발 사항)는 테스트를 포함해서 최대 5일을 넘지 말아야 한다. 만약 5일이 넘으면 그 일은 반드시 5일 이하의 일로 세분화되어야 한다. 그 일이 5일 이하의 일이라고 확신하는 근거는… 이런 근거를 확신하기 위해서 모두의 경험치를 이용하는 방법이 Planning Poker라는 업무 시간을 계산할 수 있는 게임이다. 이 게임을 한번 해보면 모두가 동의하는 결과를 얻을 수 있지 않을까 한다.
2) Sprint 실행 – 계획을 세웠으면 바로 실행이다. 실행 과정에서는 주로 일별 미팅(Daily Scrum) 미팅을 통해 업무 공유가 이루어진다. 미팅에서는 전일 있었던 일과 다음에 할 일들을 정리하고 다른 팀원들의 문제점을 해결해주기 위해서 노력한다. 물론 전체 공정을 방해할 수 있는 일들이 있다면 이런 사항들을 스크럼 마스터 혹은 프로젝트 관리자를 통해 논의하고 해결될 방안을 모색하는 추가 미팅이 진행될 수 있다.
3) Sprint 종료 – 종료 단계의 핵심은 데모를 통해 결과를 사람들에게 자랑/소개하는 기회를 반드시 가져야 한다. 데모 후 전체 스프린트 기간에 발생됐던 여러 업무 내외의 문제들을 검토하고 잘된것이나 나중에 고쳐야 할 사항들을 정리한다. 데모 후에 가지는 이 미팅을 스프린트 회고(혹은 회고 미팅)라고 이야기를 한다.
스크럼은 에자일을 표방한다. 에자일에서 이야기하는 가장 좋은 모토는 4F라는 키워드이다.
1) Fail Fast – 우선 상세한 기능들을 하는게 아니라 우선 테스트 코드를 작성하고 이 코드를 실패로 만들어주는 코드부터 시작한다. 그럼 테스트 위주의 개발이 되고, 개발자의 입장에서는 집중해야 할 부분에 자신의 전력을 쏟을 수 있게 된다.
2) Fast Feedback – 결과물, 즉 움직이는 프로그램으로 사용자와 이야기를 한다. 요구하는 결과물을 빨리 보여주고 그것에 대한 피드백을 빨리 받게되면 결론적으로 고객이 진정으로 원하는 프로그램이 될 수 있도록 개발자가 만들어줄 수 있다는 것이다.
스크럼이 진행되는 프로세스를 아래의 도식을 보시면 더욱 쉽게 이해할 수 있습니다. 아래 도식은 김태형님의 논문에 게재된 [현재 스크럼 활동 흐름]을 인용한 것입니다.
출처: 김태형,”스크럼 기반의 프로젝트 관리 도구 설계”,2011, 5페이지
