스크럼

스크럼(scrum)은 경기를 재개하기 위해 팀원이 서로 밀착하여 형성하는 전술 대형을 뜻하는 럭비 용어에서 유래된 것으로, 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중 하나이다. 소프트웨어 개발 프로젝트를 위해 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.

개요

특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크다. 스크럼은 30일을 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다. 일반적인 권장 기간은 30일이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주 정도의 유연성을 가진다. 주기가 너무 짧으면 개발 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로, 적용해보면서 조율이 필요한 경우 조율하는 것이 좋다. 스크럼 과정을 통해 개발 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해나가게 된다. 보통, 각 작업은 4시간에서 16시간 정도를 소요하도록 정한다. 물론, 작업을 정하고 할당하는 것은 팀 내에서 자율적으로 진행된다. 애자일 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화를 중요하게 여긴다. 다만 다른 프로세스들에 비해 무질서해 보이기 때문에 전통적인 프로세스 개선과 마찰이 있다. 비즈니스 요구를 충족시키는 데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 관리 프레임워크 기법이다. 사람들이 효과적으로 성취감을 충족하며 협업할 수 있게 하여, 복잡하고 정교한 제품을 생산하도록 한다.

특징

특정 언어나 방법론에 의존적이지 않고, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용범위의 개발 기법이다. 스크럼은 다음과 같은 특성을 가진다. 솔루션에 포함할 기능/ 개선점에 대한 우선순위를 부여한다. 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과와 적용할 기능이나 개선에 대한 목록을 제공해야 한다. 날마다 15분 정도 회의를 가지고, 항상 팀 단위라 생각해야 한다. 이때 주의할 것은 보고하는 자리가 아니라 공유하는 자리라는 것이다. 이 프로젝트와 관련되어 한 일, 또는 이슈들을 공유해야 한다. 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지해야 한다.

역사

스크럼 방법론을 창조한 것은 제프 서덜랜드와 켄 슈와버이지만, 스크럼이랑 용어가 처음 등장한 것은 노나카 이쿠지로와 타케우치 히로타카가 하버드 비즈니스 리뷰에 발표된 ‘새로운 신제품 개발 방식’이었다. 이 글에 큰 영감을 받은 서덜랜드와 슈와버가 스크럼의 개념을 실천 기법으로 개발, 발전시키게 된다. 노나카와 타케우치가 왜 럭비 용어인 스크럼을 사용했는지에 대한 언급은 없지만, 스크럼의 핵심인 주도적인 팀 수행을 묘사하기 위해 사용한 것으로 추측된다. 생산성과 혁신을 나타내는 제조업체의 특성을 바탕으로 기업이 팀 안에서 서로 공을 주고받으며 하나가 되어 필드를 나아가는 럭비 팀처럼 일체적 방법론을 사용한다고 비유하였다.

진행순서

제품 백로그 작성

제품 책임자가 사용자 스토리를 기반으로 제품 백로그(product backlog)를 작성한다. 이때 사용자 스토리는 사용자의 관점에서 작성이 되어야 한다. 제품 백로그는 이해 관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록을 말한다. 우선순위를 가지며, 위에 있을수록 우선순위가 높고 상세화되어 있다. 사용자 스토리란 고객이나 개발자 모두 이해할 수 있도록 고객이 작성하는 것이다. 카드(card), 대화(communication), 테스트(test) 세 가지를 이용하여 작성한다.

• 카드: 고객의 요구 사항을 문서화하기보다는 표현하기 위한 것으로 대화의 매개체 역할을 한다. 누가, 왜, 무엇을에 대한 정보가 다 포함되어 있어야 한다.
• 대화: 카드 내용의 세부사항을 구체화시킴으로서 인수 기준이 정해지고, 이해의 공유를 촉진시킨다.
• 테스트(Confirmation): 대화에서 논의한 인수 기준을 통해 스토리의 완료 여부를 판단한다. 인수 기준이 만족되었는지 여부를 확인하기 위해 긍정적인 테스트와 부정적인 테스트를 모두 사용해야 한다.

스프린트 계획 회의

제품 책임자, 스크럼 마스터, 개발팀이 참여하며 제품 백로그를 기반으로 스프린트 목표와 스프린트 백로그를 계획하는 회의이다. 스프린트 계획 파트 1과 스프린트 계획 파트 2로 나뉘는데, 스프린트 계획파트 1에서는 스프린트 동안 무엇을 할지 우선순위가 높은 아이템들을 검토하고 스프린트 목표를 정한다. 스프린트 계획 파트 2에서는 스프린트 계획 파트 1에서 결정한 무엇을 어떻게 실행할지에 대해 정한다. 스프린트 계획 회의가 끝날 때쯤, 개발팀은 각 스프린트가 끝날 때마다 어떤 결과물을 내놓을 것인지 대한 현실적인 목표를 정하는데 이것을 스프린트 약속이라고 한다. 전에 수행했던 스프린트의 경험을 바탕으로 학습한 내용이 반영되어야 한다는 것이 핵심이다.

스프린트 백로그 작성

제품 백로그에서 결정된 우선순위를 기반으로 스프린트 동안 해야 하는 일에 대한 리스트를 스프린트 백로그라고 한다. 스프린트 목표를 구현 가능하도록 각각의 요구사항을 task 단위로 나누어 개발자들이 나눠서 작업을 수행한다. 많은 팀들이 벽 크기의 업무 보드 형식의 스프린트 백로그를 만드는데 이것을 스크럼 보드(scrum board)라고 한다.

일일 스크럼 미팅

일일 스크럼 미팅은 개발원들이 늘어지는 것을 막기 방지하기 위해 늘어지는 것을 방지하기 위해 스탠드업 미팅 형식으로 진행된다. 제품 책임자의 참석은 옵션이고, 매일 정해진 시간에 정해진 장소에 모여서 15분~20분 동안 간단하고 빠르게 진행한다. 어제 했던 일과 오늘 할 일, 수행 중 문제점이나 장애 요인 등을 공유하며, 문제가 있을 경우 미팅 후 바로 해결한다. 일일 스크럼 미팅을 지속적으로 할 경우 프로젝트 후반부에 문제점이 갑자기 발생하는 것을 예방할 수 있다. 개발 팀원들은 매일 스프린트 백로그에 있는 현재 작업을 완료하기 위해 작업이 얼마나 남았는지 번 다운 차트를 통해 진척도를 추적한다.

실행 가능한 제품 개발

각 스프린트마다 목표는 실행 가능한 제품을 만들어서 배포하는 것이다. 매 스프린트의 결과로써 나오는 산출물을 잠재적으로 출시 가능한 제품 증분이라고 부른다.

스프린트 리뷰

스프린트가 종료되었을 때 개발팀이 스프린트 동안 개발한 증분의 기능을 고객을 포함한 이해 관리자들에게 보여주고 피드백을 받는 과정을 말한다. 고객은 자신이 요청한 요구사항이 해당 스프린트 동안 제품이 잘 반영되었는지 평가한 후 피드백을 하면 프로덕트 오너는 고객의 피드백이나 여러 사항들을 정리하여 다음 스프린트에 반영되도록 제품 백로그를 다시 갱신한다. 스프린트의 한주당 스프린트 리뷰 시간은 한 시간으로 제약되어 있으며 스프린트 리뷰를 준비하는데 30분을 넘지 않도록 해야 한다.

스프린트 회고

스프린트 리뷰 후 프로젝트를 진행하면서 좋았던 점이나 문제점, 미진한 점 등을 도출함으로써 다음 스프린트를 보다 더 나은 방향으로 개선할 수 있도록 하는 과정을 말한다. 스프린트 회고 과정에서 스크럼 마스터는 중재 및 조정 역할을 하는 퍼실리테이터(facilitator) 역할을 할 수 있다. 스프린트 회고 과정을 통해 이미 정해진 프로세스로만 프로젝트를 수행하는 것이 아니라 프로세스가 끊임없이 개선되도록 하여 변화하고 있는 환경에 더 능동적으로 적응할 수 있도록 한다.

다음 스프린트 시작

스프린트는 제품 책임자가 제품을 출시할 준비가 되었다고 판단할 때까지 계속된다. 스프린트가 회고가 끝나면 휴식 기간 없이 바로 다음 스프린트를 진행한다.

역할

• 제품 책임자(Product Owner): 약자로 PO라고도 하며, 제품 백로그를 관리, 작성하고 이해 관리자로부터 요구사항을 추출하여 제품 백로그에 반영하는 일을 한다. 고객 밑 조직 가치에 기반하여 제품 백로그 항목들의 우선순위를 매기고 각 스프린트마다 결과를 검토하여 우선순위를 관리, 조정한다. 단 한 명이어야 한다. 팀에 소속되어 있지만, 팀 밖에 있는 고객, 사용자 등 여러 이해관계 당사자들과 대화를 하는 유일한 사람이어야 하고, 팀에 들어오는 압력을 컨트롤할 수 있는 유일한 사람이어야 한다. 소프트웨어 개발 역량이 꼭 필요한 것이 아니기 때문에 개발 영역에 있는 사람이 아닌, 제품을 사용할 고객 또는 비즈니스 요구사항을 정의할 수 있는 사람에게 맡기는 경우도 있다.

• 스크럼 마스터(servant leader): 일반적인 프로젝트 관리자들과는 다르게 업무 지시, 통제를 하는 것이 아니라, 개발 팀원들을 코칭하고 개발팀이 프로젝트 진행 중 문제가 생겼을 때 잘 해결할 수 있도록 도와주는 역할을 한다. 개발팀원들이나 스크럼에 참여하는 사람들이 스크럼을 제대로 알고 수행하고 있는지에 대한 책임을 가지며 스크럼의 이론, 규칙들을 잘 따르도록 보장해야 한다. 일일 스크럼 회의를 주관하여 팀의 진척도를 모니터링하고, 팀의 생산성에 악영향을 미치는 정책, 절차, 구조를 공론화하는 역할을 한다.

• 개발팀: 스크럼 팀(scrum team) 또는 DT(Development Team)이라고도 부르며 고객으로부터 받은 요구사항을 가지고 제품을 개발, 테스트하는, 앞의 2 역할을 제외한 모든 팀원을 뜻하며 주로 5~7명 정도로 이루어진다. 프로젝트 수행에 필요한 모든 역량을 갖춘 팀으로 이를 위해 관련된 모든 부서로부터 팀원이 구성되며, 팀원은 자신의 전문 영역에 고정되지 않고 다 같이 팀 과제를 수행한다. 자율 관리 조직으로 따로 리더가 정해져 있지 않으며, 팀 스스로가 외부의 명령 없이 스프린트 목표를 달성하기 위해 업무 분량, 목표, 달성 방안을 결정하고, 최상의 방법을 결정한다.

추구 가치

• 용기: 팀원 간 갈등과 도전을 위한 용기를 가져야 한다. 해당 기능이 이해가 안 되거나 문제가 있는 경우 일을 더 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득시킬 용기가 있어야 한다.
• 집중(전념): 한 번에 하나씩 일을 마무리하고, 업무에 집중할 수 있도록 불필요한 회의 참석은 지양해야 하며, 주기적인 반복 작업은 제거하거나 자동화해야 한다.
• 헌신/책임: 팀의 목표 달성을 위해 개개인이 공약한 목표를 달성하도록 팀에 헌신하고, 필요한 모든 권한을 부여해야 한다. 개인보다 팀과 공동 목표 달성이 우선이고, 가치 있는 소프트웨어를 개발할 수 있도록 최대한의 지원과 권한이 필요하다.
• 존중: 개개인별로 장단점이 있을 것이고, 그 사람이 그렇게 할 수밖에 없는 이유가 있을 것이다. 팀원 서로를 존중할 필요가 있다.
• 투명성/개방성(정직): 프로젝트에 대한 모든 내용을 투명하게 공개해야 한다. 제품백로그, 스크럼회의, 스프린트 리뷰 등을 통해 공유되어야 하며, 자신에게 불리해도 숨기지 않고 도움을 청해야 한다.

주요 용어

• 제품 백로그: 제품 완성에 필요한 특성, 기능, 개선점 등 제품의 모든 요구사항(사용자 스토리)을 우선순위에 따라 나열한 목록이다. 사업 환경이나 변화에 따라 지속적으로 업데이트되며 우선순위가 높은 백로그는 낮은 백로그보다 더 명확하고 상세하게 기술된다.
• 완료 기준(Definition of Done), 인수 기준(Acceptance Criteria): 사용자 스토리를 완료시키기 위한 조건 명세다.
• 스프린트: 실제 개발 작업을 진행하는 것으로, 계획, 개발, 리뷰 작업 등 최소 단위의 주기다. 보통 1~4주 단위에서 선택할 수 있다. 스프린트를 진행하는 동안 기간, 과제 가감 등의 변경은 불가능하다.
• 잠재적 출시 가능 제품, 최소 실행 가능 제품: 팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품이다.
• 스프린트 계획 회의: 제품 백로그를 기반으로 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립한다. 요구사항을 태스크로 분할한 후 개발자별로 스프린트 백로그를 작성한다.
• 스프린트 백로그: 1개의 스프린트에서 개발할 백로그들을 스프린트를 의미한다.
• 칸반 보드: 작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판이다.
• 일일 스크럼 회의: 매일 어제 한 일, 오늘 할 일, 해결해야 할 장애 또는 문제 요소를 공유하는 회의로 매일 15분 정도 수행한다. 장애 요소는 화이트 보도에 적어놓고 지속적으로 해결한다. 스크림 마스터가 주관하여 해결 요소를 처리한다.
• 스프린트 검토 회의: 한 주당 한 시간 정도 부분 또는 전체 제품이 요구사항에 맞는지 확인하고, 개선 사항을 피드백하여 제품 백로그를 업데이트 하는 과정이다.
• 스프린트 회고: 스프린트 주기를 회고하여 규칙 준수, 개선 점을 확인하고 기록한다. 스프린트 마지막 날 또는 일정 주기로 수행하여 개발자가 개발한 내용을 Stakeholder, 고객, 제품 책임자에게 시연하고 검토한다.

참고자료

• 〈스크럼(애자일 개발 프로세스)〉, 《위키피디아》
• 민현기, 〈애자일 Scrum(스크럼) 이해하기〉, 《미디엄》, 2019-01-26
• 양민경, 〈애자일 방법론⓵: 스크럼(scrum)〉, 《뉴스레터》, 2018-06-19
• 황선영, 〈스크럼의 진행 과정〉, 《미디엄》, 2019-07-17
• 도전적인 HarimKang, 〈스크럼(Scrum) 이란?〉, 《티스토리》, 2020-02-04

같이 보기

• 애자일
• 스프린트
• 프레임워크
• 방법론

이 스크럼 문서는 프로그래밍에 관한 토막글입니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 이 문서의 내용을 채워주세요.

개발 : 프로그래밍 □■⊕, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인 프로그래밍 언어 ASP • C 언어 • C++ • C# • CSS • D 언어 • HTML • HTML5 • JSP • PHP • R • XHTML • XML • XSLT • 고(Go) • 고급언어 • 기계어 • 델파이 • 러스트 • 루비 • 루아 • 리액트 • 리퀴디티 • 무브 • 미켈슨 • 베이직 • 브이비스크립트 • 비주얼 C++ • 비주얼베이직(VB) • 비주얼베이직닷넷(VB.NET) • 솔리디티 • 스몰토크 • 스위프트 언어 • 스칼라 • 스크립트 언어 • 알골 • 어셈블리 • 언리얼스크립트 • 얼랭 • 에이잭스(Ajax) • 엠에프씨(MFC) • 오브젝티브-C • 오브젝트 파스칼 • 오카멜 • 웹어셈블리(WASM) • 이와즘(eWASM) • 자바 • 자바스크립트 • 저급언어 • 제이슨(JSON) • 제이쿼리(jQuery) • 카멜 • 코볼 • 코틀린 • 콜드퓨전 • 타입스크립트 • 파스칼 • 파워스크립트 • 파이썬 • 펄(Perl) • 포트란 • 프로씨(Pro-C) • 피엘에스큐엘(PL/SQL) • 피엘원(PL/I) • 하스켈 개발방법론 CBD 개발방법론 • EA • 구조적 개발방법론 • 객체지향 개발방법론 • 라이브러리 • 람다 아키텍처 • 모듈 • 모듈화 • 벤치마킹 • 소프트웨어 개발방법론 • 스크럼 • 스프린트 • 아키텍처 • 아키텍트 • 애자일 • 웹개발방법론 • 정보공학 개발방법론 • 컴포넌트 • 테일러링 • 템플릿 • 폭포수 모델 • 프로젝트 • 프로토타입 • 피드백 코딩 EUC-KR • UTF-8 • 값 • 글루웨어 • 디버깅 • 디코딩 • 마크업 • 버그 • 부트스트랩 • 세이브포인트 • 소스코드 • 시큐어코딩 • 아스키 • 액티브엑스 • 오픈소스 • 유니코드 • 인코딩 • 재컴파일 • 주석 • 컴파일 • 컴퓨터 프로그램 • 코드 • 코딩 • 태그 • 테스트 • 테이블 • 텍스트 • 파싱 • 퍼블리싱 • 퓨니코드 • 하드코딩 • 하이퍼링크 • 하이퍼텍스트 프로그래밍 C 명령어 • 객체 • 객체지향 • 객체지향 프로그래밍 • 거짓 • 관계연산자 • 기본형 변수 • 널 • 논리 • 논리연산 • 논리연산자 • 다중상속 • 다형성 • 대입 • 대입문 • 대입연산자 • 더블 • 도스 명령어 • 디폴트 • 레지스터변수 • 루프 • 리눅스 명령어 • 리턴 • 메모리 주소 • 메소드 • 멤버 • 명령문 • 명령어 • 무한루프 • 문자 • 문자열 • 바이트 • 반복문 • 배열 • 변수 • 분기 • 분기문 • 불린 • 브레이크 • 비교연산자 • 비트연산자 • 산술연산자 • 상속 • 상수 • 생성자 • 선언 • 선언문 • 설정자 • 속성 • 스위치 • 스태틱 • 시프트연산자 • 실행 • 실행문 • 어노테이션 • 에코 • 역참조 • 연산 • 연산문 • 연산자 • 오버로딩 • 오버라이딩 • 외부변수 • 윈도우 명령어 • 유닉스 명령어 • 인스턴스 • 인스트럭션 • 인클루드 • 인터페이스 • 임포트 • 입력 • 입력문 • 입출력 • 입출력문 • 자료형(데이터 타입) • 자바 명령어 • 자바 예약어 • 자바 컬렉션 • 전역변수 • 접근자 • 접근제어자 • 정보은닉 • 정수형 • 정적변수 • 제어 • 제어문 • 제어자 • 조건 • 조건문 • 조건연산자 • 주소 • 증감연산자 • 지역변수 • 참 • 참조 • 참조변수 • 초기화 • 추상메소드 • 추상클래스 • 추상화 • 출력 • 출력문 • 캡슐화 • 케이스 • 클래스 • 파라미터(매개변수) • 파이널 • 패키지 • 퍼블릭 • 포인터 • 프라이빗 • 프로텍티드 • 필드(멤버변수) • 함수 • 환경변수 명령어 abstract • array • boolean • break • byte • case • char • continue • default • double • do while • echo • elif • else • else if • false • final • float • for • gosub • goto • if • if else • import • include • int • join • long • long long • null • print • printf • println • private • protected • public • return • scanf • short • stdio.h • static • string • switch • temp • then • true • unsigned • void • while 디자인패턴 구조패턴 • 동시성패턴 • 동시실행패턴 • 모델-뷰-컨트롤러 패턴 • 상태패턴 • 생성패턴 • 싱글톤패턴 • 아키텍처패턴 • 전략패턴 • 커맨드패턴 • 행동패턴 프로그래밍 인물 귀도 반 로썸 • 그레이스 머레이 호퍼 • 니클라우스 비르트 • 댄 브릭클린 • 더그 커팅 • 데니스 리치 • 리누스 토르발스 • 리처드 그린블라트 • 마거릿 해밀턴 • 마크 앤드리슨 • 빈트 서프 • 빌 게이츠 • 빌 조이 • 스티브 잡스 • 에이다 러브레이스 • 제임스 고슬링 • 척 벤턴 • 켄 톰슨 • 팀 패터슨 위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반