스크럼 (애자일 개발 프로세스)

파일:Scrum process.svg

스크럼 프로세스

소프트웨어 개발 프로세스
활동과 단계
요구사항 분석 · 기능 명세 구조 · 설계 구현 · 테스팅 배치 · 유지보수
개발 모형
애자일 소프트웨어 개발 · 클린룸 DSDM · 순차점증적 개발 · 반복형 개발 RAD · RUP · 나선 모형 폭포수 모델 · 익스트림 프로그래밍 스크럼 · V 모델 · TDD
지원 활동
구성 관리 · 문서화 품질보증 · 프로젝트 관리 사용자 경험 설계
도구
컴파일러 · 디버거 · 프로파일러 GUI 디자이너 · 통합 개발 환경

스크럼(scrum)은 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중의 하나이다. 소프트웨어 개발 프로젝트를 위하여 고안되었지만 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.

역사

이 방법은 일본 히토쓰바시 대학의 노나카 이쿠지로와 다케우치 히로타카가 1986년 1~2월 Harvard Business Review에 올린 "The New New Product Developement Game"에서 시작된다. 그 후 1991년 디그라스(DeGrace)와 슈탈(Stahl)이, "Wicked Problems, Righteous Solutions"에서 스크럼을 처음 언급했다. 처음 노나카와 타케우지가 스크럼을 만들때의 목표는 공업품의 개발이었으나, 1995년 Ken Schwaber가 이 방법을 Advanced Development Method라는 이름으로 자신의 회사에서 사용하였다. 비슷한 때에 Jeff Sutherland, John Scumniotales, 그리고 Jeff McKenna는 Easel 사에서 이와 비슷한 방법을 개발하고, 스크럼이라고 처음 불리게 되었다.

스크럼의 특성

스크럼은 특정 언어나 방법론에 의존적이지 않으며, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용 범위의 개발 기법이다. 스크럼은 애자일 소프트웨어 개발 과정의 하나로 다음과 같은 특성을 가지고 있다.

• 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
• 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
• 날마다 15분 정도 회의를 가져라.
• 항상 팀 단위로 생각하라.
• 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.

스크럼의 기반

스크럼은, "지식창조기업(知識創造企業)"이라는 이름으로 소개된 일본의 조직론에 이론적 기반을 두고 있다. 지식창조기업에서는, 가정용 제빵기나 저가 복사기등을 획기적으로 개발한 일본 기업의 조직론을 소개하고 있다. 이 지식창조기업에서는, 암묵지와 형식지를 상호 변환할 수 있는 프로세스를 가지고 그에 따라 새로운 지식을 창출해 내고 있다.

지식 창조 프로세스를 촉진시키는 5가지 요소

조직의 의도

지식 창조의 목표나 팀을 지탱하는 축

자율성

팀의 멤버에게 자유로운 행동을 인정하는 열린 환경(시스템)

역동적이고 창조적인 카오스

조직 내 외부 간의 역동적인 상호작용을 통한 지식창조 환경

잉여성

의도적으로 조직에 넘쳐나는 여분의 정보

최소 유효 다양성

복잡하고 다양한 환경에 기민하게 대응하기 위해서는 조직 구성원이 가져야 하는 다양성

Ken Schwaber는 스크럼의 가치와 개발 프로세스가, 지식창조기업에서 이야기 하는 지식 창조 프로세스와 그것을 촉진하는 5가지 요소들을 충족시켜 프로젝트를 성공적으로 이끌게 된다고 이야기 하고 있다.

스크럼이 추구하는 가치

스크럼은 다음의 5가지 가치에 중점을 두어 진행된다.

확약

약속한 것을 확실히 실현하는 것

전념

확약한 것의 실현에 전념하는 것

정직

어떤 것이 자신에게 불리해도 숨기지 않는 것

존중

자신과 다른 사람에게 경의를 표하는 것

용기

팀 구성원 은 자신이 옳은 일을 할 수 있도록 팀원간 갈등과 도전을 통해 작업 할 수 있는 용기

스크럼의 진행

스크럼에서는, 30일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다. 아래는 스크럼 진행시 나타나는 중요 요소이다.

1. 일반적인 권장기간은 30일이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주의 유연성을 가진다.

제품 백로그(Product Backlog)

개발할 제품에 대한 요구 사항 목록

스프린트(Sprint)

반복적인 개발 주기 (회사에서 정하는 이터레이션이 개발 주기가 된다. 계획 회의부터 제품 리뷰가 진행되는 날짜 까지의 기간이 1스프린트 이다)

스프린트 계획 회의(Sprint Planning Meeting)

스프린트 목표와 스프린트 백로그를 계획하는 회의

스프린트 백로그(Sprint Backlog)

각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

일일 스크럼 회의(Daily Scrum Meeting)

날마다 진행되는 미팅 (어제 한일, 오늘 할일, 장애 현상 등을 공유)

실행 가능한 제품(shippable product) 개발

스프린트의 결과로써 나오는 실행 가능한 제품

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

1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.
2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다. 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 된다.
3. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
5. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해 한다.
6. 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 갖는다.
7. 스프린트 기간 중 다음 스프린트를 준비 하기 위해 PO와 필요 인원이 모여 백로그를 준비하는 시간을 갖는다.

이러한 진행 방식과 더불어, 개발 팀원 이외에 아래와 같은 직책(역할)이 정의되어 있다.

제품 책임자(Product Owner)

제품 백 로그를 정의하여 우선순위를 정해 준다.

스크럼 마스터(Scrum Master)

프로젝트 관리자(코치)

스크럼 마스터는, 일반적인 관리를 수행하는 프로젝트 관리자들과는 달리 팀원을 코칭하고 프로젝트의 문제 상황을 해결하는 역할을 하며, 제품 책임자는 스프린트 목표와 백로그등의 결정에 있어 중심이 되는 상위 관리자로, 제품 책임자가 독단적으로 목표를 결정하지 않고, 고객과 관리자 및 팀원들이 모여서 목표를 정한다.

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

애자일 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화를 중요하게 여기고 있다. 하지만, 이러한 부분과 더불어 애자일 프로세스는 무질서해 보이기 때문에 전통적인 프로세스 개선과 마찰이 생기게 된다.

같이 보기

• 카이젠
• 동적 시스템 개발 방법
• 익스트림 프로그래밍 (XP)

참고 및 관련 문헌

• N.S. Janoff & L. Rising (2000년 1월). “The Scrum Software Development Process for Small Teams” (PDF). 2007년 2월 17일에 원본 문서 (PDF)에서 보존된 문서. 2020년 8월 19일에 확인함. 
• Deemer, Pete; Gabrielle Benefield, Craig Larman, Bas Vodde (2009년 2월). “The Scrum Primer”. 2009년 6월 3일에 원본 문서에서 보존된 문서. 2009년 6월 1일에 확인함.  CS1 관리 - 여러 이름 (링크)
• Kniberg, Henrik. 《Scrum and XP from the Trenches》. 2010년 8월 9일에 확인함. 

외부 링크

• 위키미디어 공용에 [{{fullurl:Commons:|uselang=ko}} 스크럼] 관련 미디어 분류가 있습니다.
• Scrum dot Org (ken Schwaber's home for Scrum)
• Scrum Alliance
• Agile Alliance’s Scrum library
• A Scrum Process Asset Library
• A Scrum Process Description by the Eclipse Process Framework (EPF) Project
• BPMN process diagram of Scrum

동영상

• Jeff Sutherland. 《Scrum Tuning: Lessons learned from Scrum implementation at Google》. 2014년 3월 21일에 확인함. 
• Jeff Sutherland. 《Hyperproductive Distributed Scrum Teams》. 
• Hamid Shojaee. 《Scrum in 10 Minutes》. 
• Jeff Sutherland. 《Self-Organization: The Secret Sauce for Improving your Scrum team》. 
• 《Scrum at Large: Managing 100 People and More》.