스크럼(Scrum)

2012. 02. Technical Talk & Seminar - 스크럼(Scrum)

스크럼(Scrum)은 애자일 방법론(Agile Methodology)을 철학적 기반으로 하는 소프트웨어 개발방법론 중 하나로, 경험을 바탕으로 위임과 자기조직화에 큰 비중을 두고 창의성과 업무환경을 개선해 가는 개발방법론이다.

애자일 방법론은 2001년 Agile Menifesto를 통해 프로세스와 도구보다 개인과 상호작용이 우선, 포괄적인 문서보다 동작하는 소프트웨어가 우선, 계약 협상보다 고객과의 협력이 우선, 계획을 따르는 것보다 변화에 대응하는 것이 우선이라는 내용으로 발표되었다.

그 바탕의 원칙들을 살펴보면…

  1. 작동하는 소프트웨어를 수 주에서 수 개월의 주기로 자주, 가능한 더 짧은 기간에 인도한다.

  2. 개발 후반이라고 해도 요구사항의 변경을 환영한다.

  3. 동기부여 된 개인을 중심으로 프로젝트를 구축하며, 그들에게 필요한 환경과 지원을 제공하고

      업무를 완수할 것이라 믿는다.

  4. 개발팀에게 그리고 팀 내에서 정보를 전파하는 가장 효율적이고도 효과적인 방법은 얼굴을 

      직접 보고 대화하는 것이다.

  5. 최고의 아키택처 와 요구사항과 설계는 자기조직화 된 팀에서 나온다.

스크럼(Scrum)

 

일본 히토츠바시 대학의 노나카이쿠지로와 타케우지 히로시고가1986년 Harvard Business Review에 올린 "TheNew New Product Developement Game"에서 시작

like scrum in rugby. "tries to go to the distance as a unit, passing the ball back and forth".

[출처] [Technical Talk & Seminar] 스크럼(Scrum)|작성자 NTS Story

1991년 디그라스(DeGrace)와 슈탈(Stahl)이, "Wicked Problems, Righteous Solutions"에서 스크럼을 처음 언급했다. 처음 노나카와 타케우지가 스크럼을 만들 때의 목표는 공업품의 개발이었으나, 1995년 Ken Schwaber가 이 방법을 Advanced Development Method라는 이름으로 자신의 회사에서 사용하였다. 비슷한 때에 Jeff Sutherland, John Scumniotales, 그리고 Jeff McKenna는Easel 사에서 이와 비슷한 방법을 개발하고, 스크럼이라고 처음 불리게 되었다.

스크럼은 경험주의적 접근법(경험주의적 공정제어 모델, 불완전한 정의, 빈번한 감사, 적응, 자기조직화(자발적, 능동적, 적극적인 참여, 팀워크, 행위자(Agent) 기반), 실천(가능한 것을 하라)는 키워드를 기반으로 다음과 같은 흐름으로 진행된다. 

 

스크럼에서는, 30일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시키며, 스크럼 진행 시 나타나는 중요 요소들은 다음과 같다.

  - 제품 백로그(Product Backlog) : 개발할 제품에 대한 요구 사항 목록

  - 스프린트(Sprint) : 30일의 반복적인 개발 주기

  - 스프린트 계획 회의(Sprint Planning Meeting) : 스프린트 목표 및 백로그를 계획하는 회의

  - 스프린트 백로그(Sprint Backlog) : 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

  - 일일 스크럼 회의(Daily Scrum Meeting) : 날마다 진행되는 진척 상황 미팅

  - 실행 가능한 제품(shippable product) 개발 : 스프린트의 결과로써 나오는 실행 가능한 제품

 

상기 요소들을 아래와 같은 순서에 따라 사용하여 스크럼을 진행시킨다.

1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.
2. 제품 백로그로부터 스프린트를 통해 구현되어야 할 목표를 선택한다.
3. 스프린트 목표를 보다 상세한 작업으로 모듈화한 스프린트 백로그를 작성한 뒤 작업을 
    할당한다.
4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 
    회의를 가진다.
5. 매회의 스프린트가 종료할 때마다, 스크럼 리뷰 미팅을 가지고, 개발된 제품을 평가한다.

이후의 스프린트에 대비하여 제품 백로그의 내용과 우선순위를 재검토 한다이러한 진행 방식과 더불어, 개발 팀원 이외에 아래와 같은 직책이 정의되어 있다. 

 

제품 책임자(Product Owner)는 스프린트 목표와 제품 백 로그 등을 정의하여 우선순위를 결정하는 상위 관리자로, 독단적으로 목표를 결정하지 않고, 고객과 관리자 및 팀원들이 모여서 목표를 결정하는 할 수 있도록 하는 역할을 한다.

 

스크럼 마스터(Scrum Master)는 프로젝트 관리자(코치)로서, 일반적인 관리를 수행하는 프로젝트 관리자들과는 달리 팀원을 코칭하고 프로젝트의 문제 상황을 해결한다.

 

이런 과정을 거친 뒤, 개발 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해 나가게 된다. 보통, 각 작업들은 4시간에서 16시간 정도 걸리도록 정한다. 물론, 작업을 정하고 할당하는 데는 고객이나 제품 책임자와는 상관 없이 팀원 자율로 진행된다. 이와 같은 자율적인 행위를 통해서 팀원들은 의사를 활발하게 주고 받게 되고, 끈끈한 협업체계를 가지게 된다.

 

스크럼의 효과를 살펴보면 스크럼은 가시성을 극대화(개방성, 리스크 관리 및 예측), 커뮤니케이션 능력 강화(능동적 참여, 자발적인 헌신, 타인에 대한 존중), 빠른 대응, 유연성 극대화, 명확한 관리와 책임 및 집중할 수 있는 환경을 제공한다.

[출처] [Technical Talk & Seminar] 스크럼(Scrum)|작성자 NTS Story

출처 - NTS : http://nts_story.blog.me/50139142464