스크럼 (애자일 개발 프로세스)
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
스크럼은 1986년 처음 소개된 제품 개발 프레임워크로, 럭비의 스크럼에서 유래하여 유연하고 자유로운 개발 방식을 특징으로 한다. 소프트웨어 개발을 위해 시작되었지만, 현재는 적응형 솔루션 및 제품 개발 전반에 적용된다. 스크럼 팀, 제품 백로그, 스프린트, 인크리먼트 등의 요소로 구성되며, 투명성, 검사, 적응을 통해 경험주의에 기반한 개발을 수행한다. 스크럼은 팀 내 역할 분담, 스프린트 계획, 일일 스크럼 회의, 스프린트 리뷰, 스프린트 회고 등을 통해 진행되며, 스크럼반, 스크럼 오브 스크럼, 대규모 스크럼과 같은 확장 및 변형된 형태도 존재한다.
더 읽어볼만한 페이지
- 애자일 소프트웨어 개발 - 유스 케이스
유스 케이스는 시스템과 액터 간 상호작용을 통해 시스템 목표 달성에 기여하는 동작들을 나타내는 요구 사항 캡처, 모델링, 명세 기법으로, 객체 지향 소프트웨어 공학에서 기능 요구 사항을 캡처하는 데 중요한 역할을 하며 다양한 분야에서 활용된다. - 애자일 소프트웨어 개발 - 페어 프로그래밍
페어 프로그래밍은 두 명의 프로그래머가 한 컴퓨터로 코드를 함께 작성하며, 드라이버와 네비게이터 역할을 번갈아 수행하여 지식 공유, 실시간 코드 검토, 문제 해결 능력 향상 등의 이점을 제공하는 소프트웨어 개발 방법이다. - 소프트웨어 공학 - 통합 개발 환경
통합 개발 환경(IDE)은 코드 편집, 빌드, 디버깅 등 소프트웨어 개발에 필요한 여러 기능을 통합적으로 제공하는 응용 프로그램이다. - 소프트웨어 공학 - 소프트웨어 개발
소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다. - 표시 이름과 문서 제목이 같은 위키공용분류 - 라우토카
라우토카는 피지 비치레부섬 서부에 위치한 피지에서 두 번째로 큰 도시이자 서부 지방의 행정 중심지로, 사탕수수 산업이 발달하여 "설탕 도시"로 알려져 있으며, 인도에서 온 계약 노동자들의 거주와 미 해군 기지 건설의 역사를 가지고 있고, 피지 산업 생산의 상당 부분을 담당하는 주요 기관들이 위치해 있다. - 표시 이름과 문서 제목이 같은 위키공용분류 - 코코넛
코코넛은 코코넛 야자나무의 열매로 식용 및 유지로 사용되며, 조리되지 않은 과육은 100g당 354kcal의 열량을 내는 다양한 영양 성분으로 구성되어 있고, 코코넛 파우더의 식이섬유는 대부분 불용성 식이섬유인 셀룰로오스이며, 태국 일부 지역에서는 코코넛 수확에 훈련된 원숭이를 이용하는 동물 학대 문제가 있다.
| 스크럼 (애자일 개발 프로세스) | |
|---|---|
| 소프트웨어 개발 정보 | |
| 종류 | 관리 프레임워크 |
| 분야 | 소프트웨어 개발 |
| 개요 | |
| 정의 | 스크럼은 소프트웨어 개발, 제품 개발, 프로젝트 관리, 운영 및 조직 일반을 위한 애자일 방법론을 구현하는 데 사용될 수 있는 프레임워크이다. |
| 특징 | 가볍고 이해하기 쉽고 구현하기 어렵다. |
| 핵심 요소 | |
| 역할 | 제품 책임자 스크럼 마스터 개발팀 |
| 이벤트 | 스프린트 스프린트 계획 회의 일일 스크럼 스프린트 리뷰 스프린트 회고 |
| 산출물 | 제품 백로그 스프린트 백로그 증분 |
| 관련 방법론 | |
| 애자일 방법론 | 익스트림 프로그래밍 사용자 기능 중심 개발 린 소프트웨어 개발 칸반 |
| 기타 | |
| 참고 자료 | 애자일 개발 소프트웨어 개발 프로세스 |
2. 역사
스크럼의 역사는 1986년 하버드 비즈니스 리뷰에 실린 다케우치 히로타카와 노나카 이쿠지로의 논문 "새로운 신제품 개발 게임"에서 시작되었다.[5] 이 논문에서 럭비의 스크럼 방식을 차용하여 팀이 협력하여 목표를 달성하는 새로운 제품 개발 방식을 제시하였다.
1993년 제프 서덜랜드와 동료들은 소프트웨어 개발에 스크럼 방식을 도입하였고, 1995년 켄 슈와버와 함께 스크럼을 공식화하여 발표하였다.[8] 이후 스크럼은 애자일 소프트웨어 개발 선언의 기반이 되었으며,[9] 2002년에는 스크럼 얼라이언스(Scrum Alliance)가 설립되어 스크럼 관련 인증 체계가 구축되었다.[10]
2009년 이후, 켄 슈와버와 제프 서덜랜드는 "스크럼 가이드"를 통해 스크럼의 정의와 해설을 제공하고 있으며, 지속적인 개선을 통해 스크럼은 발전하고 있다.[12] 스크럼은 현재 소프트웨어 개발뿐만 아니라 다양한 분야에서 활용되고 있다.[65]
2. 1. 기원
이 방법은 일본 히토쓰바시 대학의 노나카 이쿠지로와 다케우치 히로타카가 1986년 1~2월 Harvard Business Review에 올린 "The New New Product Developement Game"The New New Product Developement Game|더 뉴 뉴 프로덕트 디벨롭먼트 게임영어[127]에서 시작된다. 1991년 디그라스(DeGrace)와 슈탈(Stahl)은 "Wicked Problems, Righteous Solutions"Wicked Problems, Righteous Solutions|위키드 프라블럼스, 라이처스 솔루션스영어[128]에서 스크럼을 처음 언급했다. 처음 노나카와 타케우치가 스크럼을 만들때의 목표는 공업품의 개발이었으나, 1995년 켄 슈와버가 이 방법을 Advanced Development Method라는 이름으로 자신의 회사에서 사용하였다. 비슷한 때에 제프 서덜랜드, 존 스컴니오테일스(John Scumniotales), 그리고 제프 맥케나(Jeff McKenna)는 Easel 사에서 이와 비슷한 방법을 개발하고, 스크럼이라고 처음 불렀다.1986년 하버드 비즈니스 리뷰에 실린 다케우치 히로타카와 노나카 이쿠지로의 논문 "새로운 신제품 개발 게임"The New New Product Development Game|더 뉴 뉴 프로덕트 디벨롭먼트 게임영어에서 소프트웨어 개발에 "스크럼"이라는 용어를 사용하기 시작했다. 자동차, 복사기, 프린터 산업의 제조 회사 사례 연구를 바탕으로, 저자들은 속도와 유연성을 높이기 위한 새로운 제품 개발 방식을 제시했다. 그들은 이 방식을 럭비 방식이라고 불렀는데, 이는 이 프로세스가 팀이 "단위로 거리를 이동하려고 노력하며 공을 주고받는" 여러 겹치는 단계를 거쳐 작동하는 단일 교차 기능 팀을 포함하기 때문이다.[5] 저자들은 나중에 그들의 저서 ''지식 창조 기업''The Knowledge-Creating Company|더 날리지 크리에이팅 컴퍼니영어에서 스크럼을 발전시켰다.[6]
1990년대 초, 켄 슈와버는 자신의 회사인 어드밴스드 개발 메소드(Advanced Development Methods)에서 스크럼이 될 방식을 사용했다. 제프 서덜랜드, 존 스컴니오테일스, 제프 맥케나는 Easel Corporation에서 비슷한 방식을 개발했으며, 이 방식을 "스크럼"이라는 용어로 지칭했다.[7] 서덜랜드와 슈와버는 나중에 그들의 아이디어를 스크럼으로 공식적으로 알려진 단일 프레임워크로 통합하기 위해 함께 일했다. 1995년에 슈와버와 서덜랜드는 스크럼을 테스트하고 지속적으로 개선하여 연구 논문을 발표했고,[8] 2001년에는 애자일 소프트웨어 개발 선언을 발표했다.[9] 슈와버는 또한 듀폰 연구소와 델라웨어 대학교에서 바바툰데 오구나이케와 협력하여 스크럼을 개발했다. 오구나이케는 제품 관리가 경험적 실천에 기반하지 않으면 초기 조건이 변경될 때 소프트웨어 개발 프로젝트가 종종 실패할 수 있다고 믿었다.[2]
2002년, 슈와버는 다른 사람들과 함께 스크럼 얼라이언스(Scrum Alliance)를 설립하고 ''Certified Scrum''Certified Scrum|서티파이드 스크럼영어 인증 시리즈를 구축했다.[10] 2009년 말에 슈와버는 스크럼 얼라이언스를 떠났고, 이후 병행하는 ''Professional Scrum''Professional Scrum|프로페셔널 스크럼영어 인증 시리즈를 감독하는 Scrum.org을 설립했다.[11] 2009년 이후, ''스크럼 가이드''(The Scrum Guide)The Scrum Guide|더 스크럼 가이드영어[12]라는 공개 문서가 슈와버와 서덜랜드에 의해 출판되고 업데이트되었다. 이 문서는 여섯 번 개정되었으며, 가장 최근 버전은 2020년 11월에 출판되었다.
2. 2. 소프트웨어 개발 방법론으로의 발전
이 방법은 일본 히토쓰바시 대학의 노나카 이쿠지로와 다케우치 히로타카가 1986년 1~2월 ''Harvard Business Review''에 올린 〈The New New Product Developement Game〉[127]에서 시작된다. 그 후 1991년 디그라스(DeGrace)와 슈탈(Stahl)은 〈Wicked Problems, Righteous Solutions〉[128]에서 스크럼을 처음 언급했다. 처음 노나카와 타케우치가 스크럼을 만들 때의 목표는 공업품의 개발이었으나, 1995년 켄 슈와버(Ken Schwaber)가 이 방법을 Advanced Development Method라는 이름으로 자신의 회사에서 사용하였다. 비슷한 때에 제프 서덜랜드(Jeff Sutherland), 존 스컴니오테일스(John Scumniotales), 그리고 제프 맥케나(Jeff McKenna)는 Easel 사에서 이와 비슷한 방법을 개발하고, 스크럼이라고 처음 불렀다.소프트웨어 개발에서 "스크럼"이라는 용어의 사용은 1986년 하버드 비즈니스 리뷰에 실린 다케우치 히로타카와 노나카 이쿠지로의 〈새로운 신제품 개발 게임〉이라는 논문에서 비롯되었다. 자동차, 복사기, 프린터 산업의 제조 회사 사례 연구를 바탕으로 저자들은 속도와 유연성을 높이기 위한 새로운 제품 개발 방식을 제시했다. 그들은 이 방식을 럭비 방식이라고 불렀는데, 이는 이 프로세스가 팀이 "단위로 거리를 이동하려고 노력하며 공을 주고받는" 여러 겹치는 단계를 거쳐 작동하는 단일 교차 기능 팀을 포함하기 때문이다.[5] 저자들은 나중에 그들의 저서 《지식 창조 기업》에서 스크럼을 발전시켰다.[6]
1990년대 초, 켄 슈와버는 자신의 회사인 어드밴스드 개발 메소드(Advanced Development Methods)에서 스크럼이 될 방식을 사용했다. 제프 서덜랜드, 존 스컴니오테일스, 그리고 제프 맥케나는 Easel Corporation에서 비슷한 방식을 개발했으며, 이 방식을 "스크럼"이라는 용어로 지칭했다.[7] 서덜랜드와 슈와버는 나중에 그들의 아이디어를 스크럼으로 공식적으로 알려진 단일 프레임워크로 통합하기 위해 함께 일했다. 슈와버와 서덜랜드는 스크럼을 테스트하고 지속적으로 개선하여 1995년에 연구 논문을 발표했고,[8] 2001년에는 애자일 소프트웨어 개발 선언을 발표했다.[9] 슈와버는 또한 듀폰 연구소와 델라웨어 대학교에서 바바툰데 오구나이케와 협력하여 스크럼을 개발했다. 오구나이케는 제품 관리가 경험적 실천에 기반하지 않으면 초기 조건이 변경될 때 소프트웨어 개발 프로젝트가 종종 실패할 수 있다고 믿었다.[2]
2002년, 슈와버는 다른 사람들과 함께 스크럼 얼라이언스(Scrum Alliance)를 설립하고 ''Certified Scrum'' 인증 시리즈를 구축했다.[10] 슈와버는 2009년 말에 스크럼 얼라이언스를 떠났고, 이후 병행하는 ''Professional Scrum'' 인증 시리즈를 감독하는 Scrum.org을 설립했다.[11] 2009년 이후, 《스크럼 가이드》(The Scrum Guide)[12]라는 공개 문서가 슈와버와 서덜랜드에 의해 출판되고 업데이트되었다. 이 문서는 여섯 번 개정되었으며, 가장 최근 버전은 2020년 11월에 출판되었다.
3. 스크럼의 특징
스크럼은 특정 언어나 방법론에 의존하지 않고, 넓은 응용 범위를 가진 개발 기법이다. 애자일 소프트웨어 개발 과정의 하나로 다음과 같은 특징을 갖는다.
- 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
- 개발 주기는 30일 정도로 조절하고, 개발 주기마다 실제 동작할 수 있는 결과를 제공한다.
- 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공한다.
- 날마다 15분 정도 회의를 갖는다.
- 항상 팀 단위로 생각한다.
- 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지한다.
스크럼은 복잡한 문제에 대한 완벽한 솔루션을 한 번에 실현하는 것은 어렵다는 인식에서 출발한다. 불완전한 솔루션을 빠르게 제시하고, 이를 통해 학습하고 개선하는 적응형 솔루션(adaptive solutions영어) 접근 방식을 취한다. 스크럼은 솔루션 개발 프레임워크이므로, 그 목적은 개발된 솔루션을 통해 가치를 창출하는 것이다.[58]
스크럼의 핵심 기본 원칙은 프로젝트 개발 과정에서 고객이 요구 사항이나 필요 사항을 변경할 수 있다는 인식이다. 예상치 못한 변경 사항에 대해 계획에 기반한 방식으로 대처하는 것은 쉽지 않다. 따라서 스크럼은 경험에 기반한 접근 방식을 채택한다. 문제를 충분히 이해하거나 정의할 수 없으므로, 나타나는 요구 사항에 신속하게 대응하기 위한 팀의 능력을 극대화하는 데 집중한다.
스크럼은 팀이 자발적으로 조직적으로 행동하도록 한다. 이러한 자기 조직화를 실현하기 위해서는 모든 팀원이 물리적으로 같은 장소에 있거나, 긴밀한 온라인 공동 작업을 통해 매일 직접 만나 서로 소통하고, 프로젝트의 규율을 지켜야 한다.
스크럼은 최소한의 가볍고 간결한 공정의 틀(프로세스 프레임워크)만 제공한다.[59] 즉, 스크럼은 개발 흐름, 핵심 이벤트만을 정의한다.[60] 실제 솔루션 개발에서는 스크럼 프레임워크에 따라 전체적인 구체적인 절차를 구축한다.
스크럼은 경험주의에 기반한다. 스크럼은 작은 실천을 반복하여 경험을 창출하고, 그 경험에 기반하여 판단하고 지식을 얻음으로써 제품의 미래를 더욱 정확하게 예측하고 불확실성을 제어할 수 있다는 철학을 가지고 있다.[66]
이러한 철학을 실현하기 위해 스크럼에는 세 가지 기둥이 있다.[67]
- 투명성(transparency영어)
- 검사(inspection영어)
- 적응(adaptation영어)
스크럼에서는 투명성을 통해 팀 전체에 현 상황이 올바르게 공유되고, 제품이 빈번하게 검사되어 이상이 빠르게 발견되며, 이에 적응하여 제품 및 프로세스가 수정되기를 기대한다.
4. 스크럼 팀
스크럼 팀은 스크럼의 기본 단위가 되는 작은 팀이다.[71] 스크럼 팀은 제품 책임자, 개발자, 스크럼 마스터의 세 가지 역할로 구성된다.[13]
스크럼 팀은 스포츠 팀처럼 기능한다. 각 구성원은 높은 전문성을 가지면서 자신의 포지션에 얽매이지 않고, 하나의 목표를 향해 모든 구성원이 하나의 팀으로서 협력한다. 즉, 매니지먼트, 엔지니어링, 디자인 등 다양한 전문 분야를 가진 전문가가 분야에 구애받지 않고, 하나의 제품 목표에 초점을 맞춰 제품 개발을 수행하는 팀이 스크럼 팀이다.[72]
스크럼 팀은 제품 목표 달성에 필요한 모든 활동에 대한 책임과 권한을 가진다.[73] 개발에 있어서 어떤 구성원이 무엇을, 언제, 어떻게 수행할지는 스크럼 팀 자신이 결정하고 자기 관리한다.[74] 가치 있는 결과물(제품 목표 달성)을 만들어내는 것에 관해 팀으로서 이해 관계자에게 설명 책임을 진다.[75][76]
스크럼 팀은 적응형 제품을 개발하므로, 적응에 필요한 속도를 확보하기 위해 1개 팀당 10명 이하가 권장된다.[77]
스크럼은 복잡한 문제에 대한 완벽한 솔루션을 한 번에 실현하는 것은 어렵다는 인식에서 출발한다. 스크럼의 핵심 기본 원칙은 프로젝트 개발 과정에서 고객이 요구 사항이나 필요 사항을 변경할 수 있다는 인식이다. 따라서 스크럼은 경험에 기반한 접근 방식을 채택하여, 문제를 충분히 이해하거나 정의할 수 없을때 나타나는 요구 사항에 신속하게 대응하기 위한 팀의 능력을 극대화하는 데 집중한다.
스크럼은 팀이 자발적으로 조직적으로 행동하도록 한다. 이러한 자기 조직화를 실현하기 위해서는 모든 팀원이 물리적으로 같은 장소에 있거나, 긴밀한 온라인 공동 작업을 통해 모든 팀원이 매일 직접 만나 서로 소통하고, 프로젝트의 규율을 지켜야 한다.
4. 1. 제품 책임자 (Product Owner)
각 스크럼 팀에는 한 명의 제품 책임자(Product Owner)가 있다.[15] 제품 책임자는 제품 개발의 비즈니스 측면에 집중하며, 이해 관계자 및 팀과의 연락에 대부분의 시간을 할애한다. 이 역할은 주로 제품의 이해 관계자, 고객의 목소리, 또는 위원회의 요구 사항을 나타내며 비즈니스 결과 전달에 대한 책임을 진다.[16][17][18][19] 제품 책임자는 제품 백로그를 관리하며, 팀이 제공하는 가치를 최대화할 책임이 있다.[17] 그들은 팀의 기술적 해결책을 지시하지 않지만, 대신 팀 구성원 간의 합의를 구하려고 시도할 수 있다.[20][21]스크럼 팀과 이해 관계자 간의 주요 연락 담당자로서, 제품 책임자는 발표, 프로젝트 정의 및 진행 상황, RIDA(위험, 장애물, 의존성 및 가정), 자금 조달 및 일정 변경, 제품 백로그 및 프로젝트 거버넌스 등을 포함한 다양한 책임을 수행한다.[22] 제품 책임자는 필요한 경우, 팀 구성원의 의견 없이 스프린트를 취소할 수도 있다.[12]
프로덕트 오너(Product Owner|프로덕트 오너영어)는 제품의 총책임자이다. 고객의 의사를 대표하는 역할을 맡는다. 비즈니스 관점(ROI 등)에서 프로젝트에 문제가 없음을 보장하는 역할을 한다. 고객의 요구 사항을 제품 백로그에 우선순위를 정하여 반영한다.
4. 2. 스크럼 마스터 (Scrum Master)
스크럼은 스크럼 마스터에 의해 촉진되며, 스크럼 마스터의 역할은 스크럼 이론과 실천에 대해 팀을 교육하고 코칭하는 것이다.[24] 스크럼 마스터는 전통적인 팀 리더 또는 프로젝트 매니저와는 다른 역할과 책임을 갖는다. 스크럼 마스터의 책임에는 코칭, 목표 설정, 문제 해결, 감독, 계획, 백로그 관리 및 의사 소통 촉진 등이 있다. 반면에, 전통적인 프로젝트 매니저는 종종 관리와 관련된 책임을 갖지만 스크럼 마스터는 그렇지 않다. 스크럼 팀은 프로젝트 매니저를 포함하지 않아 개발자 간의 자기 조직화를 극대화한다.[25]스크럼 팀(Scrum Team영어)은 스크럼의 기본 단위가 되는 작은 팀이다.[71]
스크럼 마스터(Scrum Master영어)는 스크럼 프레임워크가 올바르게 적용되도록 보장하는 역할을 한다. 주요 업무는 팀 내부 및 외부 조직 간 조율(퍼실리테이션)과 외부 방해 요소를 해결하는 것이다. 기존의 프로젝트 매니저가 이 역할을 수행하는 경우가 많지만, 프로젝트 자체를 관리하지는 않는다.
4. 3. 개발자 (Developers)
스크럼에서 "개발자" 또는 "팀원"이라는 용어는 연구원, 설계자, 디자이너, 프로그래머 등 제품 개발 및 지원에 역할을 하는 모든 사람을 지칭한다.[12][23]스크럼 팀(Scrum Team영어)은 스크럼의 기본 단위가 되는 작은 팀이다.[71] 스크럼 팀은 스포츠 팀처럼 각 구성원이 높은 전문성을 가지면서도 자신의 포지션에 얽매이지 않고, 하나의 목표를 향해 모든 구성원이 하나의 팀으로서 협력하는 것을 의미한다. 즉, 매니지먼트, 엔지니어링, 디자인 등 다양한 전문 분야를 가진 전문가들이 분야에 구애받지 않고, 하나의 제품 목표에 초점을 맞춰 제품 개발을 수행하는 팀이 스크럼 팀이다.[72]
스크럼 팀은 제품 목표 달성에 필요한 모든 활동에 대한 책임과 권한을 가진다.[73] 즉, 개발에 있어서 어떤 구성원이 무엇을, 언제, 어떻게 수행할지는 스크럼 팀 자신이 결정하고 자기 관리한다.[74] 가치 있는 결과물(제품 목표 달성)을 만들어내는 것에 관해 팀으로서 이해 관계자에게 설명 책임을 진다.[75][76]
스크럼 팀은 적응형 제품을 개발하므로, 적응에 필요한 속도를 확보하기 위해 1개 팀당 10명 이하의 크기가 권장된다.[77]
스크럼 팀에는 다음과 같은 3가지 명확한 역할과 책임이 정의된다. 개발자(Developer영어)는 각 [스프린트]에서 활용 가능한 [인크리먼트]의 모든 측면을 생성하는 역할을 담당한다. 개발자에게 필요한 특정 기술은 광범위하며, 작업 영역에 따라 달라진다.
5. 스크럼의 진행 (워크플로우)
스크럼은 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시간 정도 걸리도록 정한다. 작업을 정하고 할당하는 데는 고객이나 제품 책임자와는 상관없이 팀원 자율로 진행된다. 이와 같은 자율적인 행위를 통해서 팀원들은 의사를 활발하게 주고받게 되고, 끈끈한 협업 체계를 가지게 된다.
스크럼은 복잡한 문제에 대한 완벽한 솔루션을 한 번에 실현하기 어렵다는 인식에서 출발한다. 대안적인 접근 방식은 불완전한 솔루션을 빠르게 제시하고, 이를 통해 학습하고 개선하는 적응형 솔루션이다. 스크럼은 솔루션 개발 프레임워크이므로, 개발된 솔루션을 통해 가치를 창출하는 것이 목적이다.
스크럼은 "문제에 대한 해결책 열거", "우선순위가 높은 해결책을 일정 기간 동안 팀에서 실행", "결과 검사에 기반한 조정", "그 반복"을 실현할 수 있는 환경을 만든다.[55] 스크럼의 핵심 기본 원칙은 프로젝트 개발 과정에서 고객의 요구 사항이나 필요 사항을 변경할 수 있다는 인식이다. 예상치 못한 변경 사항에 대해 계획에 기반한 방식으로 대처하는 것은 쉽지 않다. 따라서 스크럼은 경험에 기반한 접근 방식을 채택한다. 즉, 문제를 충분히 이해하거나 정의할 수 없으므로, 나타나는 요구 사항에 신속하게 대응하기 위한 팀의 능력을 극대화하는 데 집중한다.
스크럼은 팀이 자발적으로 조직적으로 행동하도록 한다. 이러한 자기 조직화를 실현하기 위해서는 모든 팀원이 물리적으로 같은 장소에 있거나, 긴밀한 온라인 공동 작업을 통해 모든 팀원이 매일 직접 만나 서로 소통하고, 프로젝트의 규율을 지켜야 한다.
스크럼은 경험주의(투명성, 검사, 적응)를 실현하기 위해 산출물과 이벤트를 정의한다.[78] 이러한 프레임워크를 따름으로써 팀과 제품의 투명성이 향상되고, 올바른 검사가 정기적으로 이루어지며,[79] 빠른 적응이 일어나 좋은 제품이 만들어진다.
| 이벤트/빈도 | 빈도 | 검사 대상 | 확약/검사 기준 | 적응 반영처 |
|---|---|---|---|---|
| 데일리 스크럼 | 일일[80] | 일일 진척 상황[81] | 스프린트 목표[82] | 스프린트 백로그[83] |
| 스프린트 검토 | n주 | 스프린트 성과[84] (인크리먼트) | 제품 목표[85] | 제품 백로그[86] |
스크럼의 산출물은 '''확약'''을 갖는다. 목표가 되는 확약을 명시함으로써 진척 측정이 가능해진다.[87] 제품 백로그의 제품 목표, 스프린트 백로그의 스프린트 목표, 인크리먼트의 완료의 정의가 확약이다.[88] 확약은 제품의 이상적인 상태를 나타내며, 개발자에게 달성을 요구한다(검사 대상). 제품 상태를 검사 대상으로 함으로써, 스크럼은 개발 과정의 큰 자유도를 개발자에게 제공한다[89] (미션 명령).
5. 1. 스프린트 (Sprint)
스크럼에서 스프린트(Sprint)는 팀 구성원들이 특정 목표를 달성하기 위해 작업하는 고정된 기간을 의미한다. 각 스프린트는 일반적으로 1주에서 4주 사이이며, 2주가 가장 일반적이다.[2] 스프린트의 결과는 기능적인 결과물, 즉 증분 방식으로 개발이 이루어진 제품이다.각 스프린트는 스프린트 목표가 정의되는 스프린트 계획 이벤트로 시작하며, 다음 두 가지 이벤트로 종료된다.[7]
- 스프린트 검토: 이해 관계자에게 피드백을 얻기 위해 진행 상황을 보여준다.
- 스프린트 회고: 다음 스프린트에 대한 교훈과 개선 사항을 식별한다.
만약 스프린트가 비정상적으로 종료되면, 종료 이유를 검토하는 새로운 스프린트 계획을 수행한다.
스크럼은 복잡한 문제에 대한 완벽한 솔루션을 한 번에 실현하기 어렵다는 인식에서 출발한다. 따라서 불완전한 솔루션을 빠르게 제시하고, 이를 통해 학습하고 개선하는 적응형 솔루션 개발 방식을 택한다. 이러한 적응형 솔루션을 팀에서 개발하기 위한 규칙과 프레임워크가 바로 스크럼이다. 스크럼은 솔루션 개발 프레임워크이므로, 개발된 솔루션을 통해 가치를 창출하는 것이 목적이다.
스크럼은 "문제에 대한 해결책 열거", "우선순위가 높은 해결책을 일정 기간 동안 팀에서 실행", "결과 검사에 기반한 조정", "그 반복"을 실현할 수 있는 환경을 만든다.[55] 스크럼의 핵심은 프로젝트 개발 과정에서 고객의 요구 사항 변경을 당연하게 여기는 것이다. 예상치 못한 변경에 대해 계획에 기반한 방식으로 대처하기 어렵기 때문에, 스크럼은 경험에 기반한 접근 방식을 채택한다. 즉, 문제를 충분히 이해하거나 정의할 수 없으므로, 나타나는 요구 사항에 신속하게 대응하기 위한 팀의 능력을 극대화하는 데 집중한다.
스크럼은 팀이 자발적으로 조직적으로 행동하도록 한다. 이를 위해 모든 팀원이 물리적으로 같은 장소에 있거나, 긴밀한 온라인 공동 작업을 통해 매일 직접 만나 소통하고, 프로젝트의 규율을 지켜야 한다.
스크럼은 경험주의(투명성, 검사, 적응)를 실현하기 위해 산출물과 이벤트를 정의한다.[78] 이러한 프레임워크를 통해 팀과 제품의 투명성이 향상되고, 올바른 검사가 정기적으로 이루어지며,[79] 빠른 적응이 일어나 좋은 제품이 만들어진다.
스프린트 목표(Sprint Goal)는 스프린트가 제품 개선을 통해 제공하는 가치의 목표이다.[118][119] 스프린트의 목적은 스프린트 목표 그 자체이다.[120] 만들어지는 제품(what)이나 제품 개발 절차(how)뿐만 아니라, 창출하고 싶은 성과 즉 가치(why)에 주목하기 위해 스프린트 목표가 설정된다.[121] 상황 변화로 설정된 스프린트 목표가 더 이상 쓸모 없게 된 경우, 해당 스프린트는 중단된다.[122]
5. 1. 1. 스프린트 계획 (Sprint Planning)
스크럼에서 스프린트는 반복적인 개발 주기를 의미하며, 일반적으로 1주에서 4주 사이의 기간을 가진다. 스프린트 계획 회의는 각 스프린트의 시작 시점에 열리며, 이 회의를 통해 해당 스프린트의 목표와 스프린트 백로그를 계획한다.스프린트 계획 회의는 다음과 같은 순서로 진행된다.
# 제품 책임자(PO)가 제품 백로그의 우선순위를 설명하고, 개발팀과 함께 이번 스프린트에서 어디까지 작업할지 조율한다. 이때 선정된 제품 백로그 항목들이 이번 스프린트의 목표가 된다.
# 스프린트 목표를 달성하기 위해 필요한 구체적인 작업 목록(스프린트 백로그)을 팀에서 작성하고, 각 팀원에게 작업을 할당한다.
스프린트 백로그의 각 작업은 보통 4시간에서 16시간 정도 소요되도록 정하며, 고객이나 제품 책임자와는 상관없이 팀원 자율로 진행된다. 이러한 과정을 통해 팀원들은 활발하게 의사를 교환하고 협업 체계를 강화한다.
| 이벤트/빈도 | 빈도 | 검사 대상 | 확약/검사 기준 | 적응 반영처 |
|---|---|---|---|---|
| 데일리 스크럼 | 일일[80] | 일일 진척 상황[81] | 스프린트 목표[82] | 스프린트 백로그[83] |
| 스프린트 검토 | n주 | 스프린트 성과[84] (인크리먼트) | 제품 목표[85] | 제품 백로그[86] |
5. 1. 2. 일일 스크럼 (Daily Scrum)
스프린트 기간 동안 개발자들은 매일 서서 진행하는 데일리 스크럼을 진행하며, 스크럼 마스터가 진행할 수 있다.[2][26] 데일리 스크럼 회의는 15분 이내로 제한되며, 매일 같은 시간과 장소에서 열린다.[27] 회의의 목적은 스프린트 목표 달성 상황과 문제점을 발표하는 것이다. 상세한 논의는 하지 않는다. 회의가 끝나면 개별 구성원들은 심층 토론과 협업을 위해 '브레이크아웃 세션' 또는 '애프터 파티'를 가질 수 있다.[27] 스크럼 마스터는 팀원들이 데일리 스크럼을 효과적으로 활용하도록 돕거나, 대안을 제공할 책임이 있다.[28][29]
'''검사'''는 현상 파악, 즉 목표와 현상의 비교·평가이다. 검사를 통해 개발 진행에 따른 변화·문제를 감지한다.[68] 검사의 목적은 적절한 방향으로 적응하는 것이다.[69] 목표가 없으면 비교 대상이 없어 검사가 어렵다(예: 문제는 검사할 수 있어도 방향 불일치는 감지 불가). 따라서 목표의 투명성이 중요하다.[70] PDCA 사이클의 ''Check'' 단계에 해당한다.
스크럼은 경험주의(투명성·검사·적응)를 실현하기 위해 다음과 같은 산출물과 이벤트를 정의한다.[78] 이러한 프레임워크를 통해 팀과 제품의 투명성이 향상되고, 올바른 검사가 정기적으로 이루어지며,[79] 빠른 적응으로 좋은 제품이 만들어진다.
| 이벤트/빈도 | 빈도 | 검사 대상 | 확약/검사 기준 | 적응 반영처 |
|---|---|---|---|---|
| 데일리 스크럼 | 일일[80] | 일일 진척 상황[81] | 스프린트 목표[82] | 스프린트 백로그[83] |
| 스프린트 검토 | n주 | 스프린트 성과[84] (인크리먼트) | 제품 목표[85] | 제품 백로그[86] |
스크럼의 산출물은 '''확약'''을 갖는다. 목표가 되는 확약을 명시함으로써 진척 측정이 가능해진다.[87] 제품 백로그의 제품 목표, 스프린트 백로그의 스프린트 목표, 인크리먼트의 완료의 정의가 확약이다.[88] 확약은 제품의 이상적인 상태를 나타내며, 개발자에게 달성을 요구한다(검사 대상). 제품 상태를 검사 대상으로 함으로써, 스크럼은 개발 과정의 큰 자유도를 개발자에게 제공한다[89] (미션 명령).
5. 1. 3. 스프린트 리뷰 (Sprint Review)
스프린트 리뷰는 팀이 완료한 작업을 이해관계자들과 공유하고, 피드백, 기대치, 향후 계획에 대해 협의하는 회의이다. 스프린트 리뷰에서는 완료된 결과물을 이해관계자들에게 시연한다. 스프린트 리뷰의 권장 시간은 스프린트 1주일에 1시간이다.[12]스프린트 검토는 n주(스프린트 주기)마다 이루어지며, 스프린트 성과(인크리먼트)를 검사 대상으로 한다. 이때 제품 목표를 확약/검사 기준으로 삼아 제품 백로그에 적응 반영한다.[84][85][86]
| 이벤트/빈도 | 빈도 | 검사 대상 | 확약/검사 기준 | 적응 반영처 |
|---|---|---|---|---|
| 스프린트 검토 | n주 | 스프린트 성과(인크리먼트) | 제품 목표 | 제품 백로그 |
5. 1. 4. 스프린트 회고 (Sprint Retrospective)
스크럼 팀 구성원들이 스프린트의 강점과 약점, 향후 개선 분야, 그리고 지속적 프로세스 개선 활동을 내부적으로 분석하는 별도의 회의이다.[30]5. 2. 백로그 정비 (Backlog Refinement)
백로그 정비는 팀 구성원들이 향후 스프린트를 위해 백로그를 수정하고 우선순위를 정하는 과정이다. 이는 새로운 스프린트 시작 전에 별도의 단계로 수행되거나, 팀 구성원이 스스로 진행하는 지속적인 과정으로 수행될 수 있다. 백로그 정비에는 큰 작업을 더 작고 명확한 작업으로 세분화하고, 성공 기준을 명확히 하며, 변화하는 우선순위와 반환값을 수정하는 작업이 포함될 수 있다.6. 스크럼 산출물 (Artifacts)
스크럼 팀은 프로젝트를 진행하며 수행한 작업을 문서화하여 제품 개발을 관리하는데, 이러한 수단을 아티팩트라고 부른다. 스크럼 아티팩트는 총 7가지가 있지만, 가장 일반적인 3가지는 제품 백로그, 스프린트 백로그, 인크리먼트이다.[31]
스크럼은 복잡한 문제에 대한 완벽한 솔루션을 한 번에 만들기 어렵다는 인식에서 출발한다. 대신, 불완전한 솔루션을 빠르게 제시하고, 이를 통해 학습하고 개선하는 적응형 솔루션 방식을 사용한다. 스크럼은 이러한 적응형 솔루션을 개발하기 위한 가벼운 프레임워크이며, 개발된 솔루션을 통해 가치를 창출하는 것을 목표로 한다.
6. 1. 제품 백로그 (Product Backlog)
제품 백로그는 수행해야 할 작업의 세분화된 목록이며, 팀이 제품을 위해 유지 관리하는 요구 사항(예: 소프트웨어 기능, 버그 수정 및 비기능적 요구 사항)의 정렬된 목록을 포함한다. 제품 백로그의 순서는 작업의 긴급성에 해당한다. 백로그 항목의 일반적인 형식에는 사용자 스토리와 유스 케이스가 포함된다.[25] 제품 백로그에는 또한 제품 소유자의 비즈니스 가치 평가와 팀의 제품 노력 또는 복잡성에 대한 평가가 포함될 수 있으며, 이는 반올림된 피보나치 수열을 사용하는 플래닝 포커의 스토리 포인트로 표현될 수 있다. 이러한 추정치는 제품 소유자가 타임라인을 측정하는 데 도움을 주며, 제품 백로그 항목의 순서에 영향을 미칠 수 있다.[32]제품 소유자는 위험, 비즈니스 가치, 종속성, 규모 및 타이밍과 같은 고려 사항을 기반으로 제품 백로그 항목을 유지 관리하고 우선 순위를 정한다. 백로그 상단의 우선 순위가 높은 항목은 개발자가 작업할 수 있도록 더 자세하게 세분화되는 반면, 백로그 아래쪽의 작업은 더 모호할 수 있다.[2]
프로덕트 골(Product Goal)은 프로덕트의 미래 상태이며,[90][91] 미래의 프로덕트 사용이 창출해야 할 가치이다. 골은 평가 가능하며, 모두에게 공유되고, 한 번에 하나만 설정된다.
프로덕트 골은 프로덕트의 목표이다. 이를 통해 스크럼 팀은 프로덕트 골의 실현을 목표로 계획을 수립할 수 있다.[92] 프로덕트 골은 평가 가능하며,[93] 이를 통해 프로덕트의 진척 상황을 ''검토''할 수 있으며, 프로덕트가 적응할 수 있다.[94] 프로덕트 골은 팀과 이해관계자에게 공유된다.[95] 이를 통해 팀은 제공해야 할 가치를 파악하고 "왜(why) 이것을 개발하는가"를 이해하며, 목적 의식을 가진 자율적인 개발이 가능해진다.[96] 프로덕트 골은 한 번에 하나만 설정된다. 이를 통해 팀은 단일 골에 집중할 수 있다.[97]
예를 들어, 택시 서비스가 내걸는 "고객은 평균 7분 안에 택시를 잡을 수 있다"는 정량적으로 평가 가능한 사용자 경험이며, 프로덕트 골에 적합하다.
프로덕트 백로그(Product Backlog영어)는 프로덕트가 지향하는 모습과 그렇게 되기 위한 요소의 목록이다. 프로덕트 백로그는 프로덕트 골과 '''프로덕트 백로그 항목'''으로 구성된다[98]。
프로덕트 백로그 항목(PBI)은 프로덕트 골을 달성하기 위한 "무언가(what)"의 정의이며, 이상적인 형태에 필요한 요소를 나타낸다. PBI는 비용과 고객 가치가 추정되고 우선순위를 가진다. 프로덕트에 대한 요구사항은 항상 변화한다. 예를 들어 변화를 일으키는 요소로는 프로덕트의 사용 및 성장, 시장의 피드백, 비즈니스 요구사항 및 환경 변화, 기술의 등장 등이 있다.[99][100] 프로덕트에 대한 요구사항의 변화에 대응하여 프로덕트 백로그는 "적응"한다. 즉, 프로덕트 백로그의 항목은 요구사항의 변화에 응답하여 변화한다. 프로덕트 백로그를 업데이트함으로써, 제품은 항상 적절하고 경쟁력을 가지며 편리한 방향으로 개발된다.[101]
프로덕트 백로그의 최종 결정과 책임은 프로덕트 오너에게 있으며 존중된다. 프로덕트 백로그에 접근하는 방식(오너 주도 또는 팀 협업)은 프로젝트에 따라 다르다.[92] 또한 PBI가 가져야 할 구체적인 항목은 각 프로젝트마다 정의된다(스크럼은 어디까지나 프레임워크이다).[98]
'''프로덕트 백로그 리파인먼트''' 스프린트 기간 동안 팀은 프로덕트 백로그의 건전성을 유지하기 위한 회의를 연다. 프로덕트 백로그의 건전성을 나타내는 지표로, INVEST가 자주 사용된다.
스크럼은 제품 목표 달성을 유일한 목적으로 삼아 훌륭한 솔루션/제품 개발을 가능하게 한다. 하지만 그 전제로서 제품 목표, 즉 제공하는 가치의 질이 모든 것을 좌우한다. 가치가 없는 제품 목표(무가치한 가치)를 달성하는 완벽한 제품이 완성되어도, 그것은 가치를 창출하지 못한다.[124] 따라서 좋은 제품 목표를 설계하는 다양한 기법이 스크럼 프레임워크와 함께 채택될 수 있다.
제품 목표는 종종 제품의 '''비전'''(Vision영어)에서 연역된다. 제품의 비전은 기업이 내세우는 이상적인 모습이다. 제품은 점차 개선되면서 비전을 향해 나아가기 때문에, 여러 상태를 거치게 된다. 제품 목표는 그 하나하나의 상태에 대응한다.[125]
제공해야 할 가치가 불확실한 단계에서는 제품 목표 자체를 탐색할 필요가 있다(참고: 제품 개발). 그 경우, 적응적인 가치 탐색을 수행한다. 소프트웨어 프로토타이핑을 통해 MVP를 만들고 가치를 탐색한다. 린 스타트업은 그것을 실현하는 방법론 중 하나이다. 제품 관리는 가치 탐색에서 개발까지를 포함한 관리이다.
제품 목표가 불확실한 경우, 제품 목표를 설정하는 것 자체가 의미를 갖는다. 왜냐하면 제품 목표가 갖는 특성(장기 목표·단일·측정 가능·공개)은 구체적이며, 이해 관계자와의 논의를 내용 있는 것으로 만들기 때문이다.[126]
제품 목표의 최종 결정은 제품 책임자의 책임이다. 그 과정에서 스크럼 팀을 참여시키는 것은 현장의 감각·지혜를 끌어내고 또한 팀의 더욱더 자기 관리를 촉진한다는 의미에서 유의미하다. 목표는 달성해야 할 목표이지만, 실제로 사용자가 손에 넣는 것은 개발된 증분 전체인 제품이다.
6. 2. 스프린트 백로그 (Sprint Backlog)
스프린트 백로그는 개발자가 특정 스프린트에서 처리하도록 의도된 제품 백로그의 하위 집합이다.[33] 개발자는 과거 성과를 사용하여 각 스프린트 역량을 평가하고, 스프린트를 채우기에 적절하다고 판단되는 작업으로 이 백로그를 채운다. 스크럼 접근 방식은 특정 개인이나 리더가 개발자에게 할당하지 않은 작업을 스프린트 백로그에 포함한다. 팀원은 백로그 우선순위와 자신의 능력 및 역량에 따라 필요에 따라 작업을 가져와 자체적으로 조직한다.[34]스프린트 백로그는 스프린트 계획이다.[114] 여기에는 이 스프린트에서 실현하고자 하는 성과 (스프린트 목표), 이를 위해 필요한 PBI, PBI를 생성하는 절차 계획이 포함된다.[115] 스프린트 백로그는 데일리 스크럼에서 진척 상황을 검사할 수 있을 정도로 상세해야 한다.[116] 스프린트 백로그는 스프린트 계획 회의에서 생성되며, 상황 변화에 따라 적응한다.[117]
6. 3. 인크리먼트 (Increment)
인크리먼트(Increment|인크리먼트영어)는 스프린트 목표를 충족하는, 잠재적으로 릴리스 가능한 스프린트 결과물이다. 인크리먼트는 완료된 모든 스프린트 백로그 항목으로 구성되며, 이전 모든 스프린트의 작업과 통합된다.인크리먼트는 제품 목표를 향한 구체적인 성과물이다.[102] 인크리먼트를 쌓아 올려 이상적인 형태의 제품이 실현된다. 인크리먼트의 원료는 PBI(제품 백로그 항목)이다. 즉, 아이디어인 PBI를 개발자가 구현하여 인크리먼트가 된다. 작업 중인 중간 산출물은 인크리먼트가 아니며, "완료의 정의"를 충족해야 인크리먼트가 된다.[103] 인크리먼트는 릴리스 가능해야 한다.[104]
완료의 정의(Definition of Done|완료의 정의영어)는 PBI 완성품이 충족해야 하는 품질 기준이다.
7. 스크럼의 확장 및 변형
스크럼은 다양한 목표를 달성하기 위해 여러 상황에 맞춰 자주 조정되거나 적용된다.[40] 스크럼은 전체 제품 개발 생명 주기를 다루지 않기 때문에, 다른 소프트웨어 개발 방법론과 결합하여 사용하기도 한다.[41] 또한, 여러 스크럼 실무자들은 특정 문제나 조직에 스크럼을 적용하거나 조정하는 방법에 대한 더 자세한 기술을 제안해 왔으며, 이러한 기술을 건축 및 소프트웨어의 디자인 패턴과 유사하게 '패턴'이라고 부르기도 한다.[42][43]
7. 1. 스크럼반 (Scrumban)
스크럼반은 스크럼과 칸반을 기반으로 하는 소프트웨어 생산 모델이다. 각 작업 단계를 설명하기 위해, 같은 공간에서 작업하는 팀은 종종 포스트잇이나 큰 화이트보드를 사용한다.[44] 칸반 모델을 통해 팀은 작업 단계와 제한 사항을 시각화할 수 있다.[45]7. 2. 스크럼 오브 스크럼 (Scrum of Scrums)
스크럼 오브 스크럼은 동일한 제품에 대해 조정하는 여러 팀을 위해 스크럼을 확장하여 운영하는 기술이다. 스크럼 오브 스크럼 데일리 스크럼 회의에는 각 개별 팀에서 선택된 대표자가 참여하며, 이들은 개발자 또는 스크럼 마스터일 수 있다. 조정 도구로서 스크럼 오브 스크럼은 팀이 팀 전체의 위험, 방해 요소, 종속성 및 가정(RIDA)을 집단적으로 처리할 수 있도록 하며, 이는 자체 백로그에서 추적될 수 있다.7. 3. 대규모 스크럼 (Large-Scale Scrum, LeSS)
크레이그 래먼과 바스 보드가 개발한 대규모 스크럼(Large-Scale Scrum, LeSS)은 다양한 규칙과 지침을 통해 스크럼을 확장하는 제품 개발 프레임워크이다.[48][49] 이 프레임워크는 두 단계로 구성된다. 첫 번째 단계는 최대 8개 팀을 위해 설계되었으며, 두 번째 단계인 'LeSS Huge'는 수백 명의 개발자가 참여하는 개발을 수용할 수 있다.[50]8. 비판
일부에서는 매일 스크럼과 스크럼 검토와 같은 스크럼 이벤트가 생산성을 저해하고 실제 생산적인 작업에 더 잘 사용될 수 있는 시간을 낭비한다고 주장해 왔다.[36][37] 스크럼은 파트타임 또는 지리적으로 떨어진 팀, 혼자 또는 작업 그룹에서 일하는 것이 더 나은 고도로 전문화된 구성원을 가진 팀, 점진적이고 개발 테스트에 적합하지 않은 팀에게 어려움을 야기하는 것으로도 관찰되었다.[38][39] 체계적 검토 결과, 분산 소프트웨어 개발에서 "분산 스크럼은 전반적인 프로젝트 성공에 긍정적이든 부정적이든 아무런 영향을 미치지 않는다"는 사실이 밝혀졌다.[51]
마틴 파울러는 애자일 소프트웨어 개발 선언의 저자 중 한 명으로, "애자일의 가치와 원칙을 무시하는" "가짜 애자일" 관행[52]과 "프로세스와 도구보다 개인과 상호 작용"을 중시하고 작업 수행자가 작업 방식을 결정하고 필요에 따라 프로세스를 변경할 수 있도록 하는 애자일 원칙에 반하는 "애자일 산업 복합체"의 방법 강요를 비판했다.[9]
2016년 9월, 애자일 소프트웨어 개발 선언의 서명자인 론 제프리스는[9] "다크 스크럼"이라고 칭하며 "스크럼은 프로그래머에게 매우 위험할 수 있다"고 말했다.[53]
참조
[1]
웹사이트
What Is A Scrum Master? Everything You Need To Know – Forbes Advisor
https://www.forbes.c[...]
2023-11-16
[2]
서적
Agile Project Management with Scrum
https://archive.org/[...]
Microsoft Press
2004-02-01
[3]
웹사이트
What is Scrum?
https://www.scrumall[...]
Scrum Alliance
2016-02-24
[4]
간행물
Quantitative assessment of the software maintenance process and requirements volatility
ACM Conference on Computer Science
1993
[5]
학술지
The New New Product Development Game
https://cb.hbsp.harv[...]
2010-06-09
[6]
서적
The Knowledge Creating Company
https://books.google[...]
Oxford University Press
2013-03-12
[7]
웹사이트
Agile Development: Lessons learned from the first Scrum
https://www.scrumall[...]
2008-09-26
[8]
서적
Business object design and implementation: OOPSLA '95 workshop proceedings
The University of Michigan
[9]
웹사이트
Manifesto for Agile Software Development
https://agilemanifes[...]
2019-10-17
[10]
서적
The Scrum Culture: Introducing Agile Methods in Organizations
https://books.google[...]
Springer
2016-08-25
[11]
웹사이트
Home
https://www.scrum.or[...]
2020-01-06
[12]
웹사이트
Scrum Guides
http://www.scrumguid[...]
ScrumGuides.org
2023-06-15
[13]
서적
Scrum: an ideal framework for agile projects
In Easy Steps
[14]
서적
The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach
John Wiley & Sons
2015
[15]
서적
Succeeding with Agile: Software Development Using Scrum
Addison-Wesley
2010
[16]
Citation
Essential Scrum. A Practical Guide to the Most Popular Agile Process
Addison-Wesley
2013
[17]
서적
The Professional Product Owner: Leveraging Scrum as a Competitive Advantage
https://books.google[...]
Addison-Wesley Professional
2018-06-04
[18]
서적
Agile Product Management with Scrum: Creating Products that Customers Love
Addison-Wesley Professional
2010-03-11
[19]
웹사이트
The Product Owner Role: A Stakeholder Proxy for Agile Teams
http://agilemodeling[...]
agilemodeling.com
2016-07-22
[20]
웹사이트
The Scrum Guide
https://scrumguides.[...]
Scrum.org
2023-06-15
[21]
웹사이트
The Role of the Product Owner
https://resources.sc[...]
Scrum Alliance
2018-05-26
[22]
웹사이트
The Product Owner Role
http://scrum-master.[...]
2017-02-03
[23]
서적
Agile Scrum Foundation Courseware, Second Edition
Van Haren
2018
[24]
웹사이트
The Scrum Guide
https://scrumguides.[...]
Scrum.org
2023-06-15
[25]
웹사이트
The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum (Version 2.0)
http://www.infoq.com[...]
InfoQ
2012-12-17
[26]
웹사이트
What is a Daily Scrum?
https://www.scrum.or[...]
2020-01-06
[27]
서적
The Agile Developer's Handbook: Get more value from your software development: get the best out of the Agile methodology
Packt Publishing Ltd
2018
[28]
서적
The Art of Scrum: How Scrum Masters Bind Dev Teams and Unleash Agility
CA Press
2016
[29]
서적
Lean Mobile App Development: Apply Lean startup methodologies to develop successful iOS and Android apps
Packt Publishing Ltd
2017
[30]
Citation
Essential Scrum. A Practical Guide to the Most Popular Agile Process
Addison-Wesley
[31]
웹사이트
What are Scrum Artifacts? ! The Ultimate Guide ! Miro
https://miro.com/agi[...]
2024-11-29
[32]
웹사이트
Authoring Requirements in an Agile World
http://www.batimes.c[...]
BA Times
2009-03-31
[33]
서적
Project Management ToolBox: Tools and Techniques for the Practicing Project Manager
https://books.google[...]
Wiley
2016-01-05
[34]
웹사이트
The Scrum Guide
http://www.scrumguid[...]
Scrum.org
2018-05-25
[35]
서적
The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach
https://books.google[...]
John Wiley & Sons
2015-01-27
[36]
웹사이트
Meetings: The productivity killer for developers
https://www.tandemse[...]
2019-03-08
[37]
간행물
Not all developers like agile, and here are 5 reasons why
https://www.bmmagazi[...]
2019-12-04
[38]
논문
Limitations of Agile Software Processes
[39]
논문
Issues and Challenges in Scrum Implementation
http://www.ijser.org[...]
2012-08
[40]
논문
Why and how is Scrum being adapted in practice: A systematic review
https://www.scienced[...]
2022-01-01
[41]
논문
Scrum in practice: an overview of Scrum adaptations
http://pure.au.dk/po[...]
2018-01
[42]
웹사이트
Scrum as Organizational Patterns
https://sites.google[...]
Gertrude & Cope
2008-06-21
[43]
웹사이트
Scrum Pattern Community
http://www.scrumplop[...]
2016-07-22
[44]
웹사이트
scrum-ban
http://leansoftwaree[...]
Lean Software Engineering
2012-09-13
[45]
웹사이트
Kanban and Scrum – Making the most of both
https://www.infoq.co[...]
InfoQ
2016-07-22
[46]
웹사이트
Risk Management – How to Stop Risks from Screwing Up Your Projects!
http://www.allabouta[...]
Kelly Waters
[47]
웹사이트
Scrum of Scrums
http://guide.agileal[...]
Agile Alliance
2015-12-17
[48]
웹사이트
Large-Scale Scrum (LeSS)
http://less.works
[49]
웹사이트
Descaling organisation with LeSS (Blog)
https://leanarch.eu/[...]
[50]
간행물
Scaling Agile Development
http://www.crosstalk[...]
2013-05
[51]
논문
Distributed Scrum: A Case Meta-Analysis
2023-10-05
[52]
웹사이트
The State of Agile Software in 2018
https://martinfowler[...]
2018-08-25
[53]
웹사이트
Dark Scrum
https://ronjeffries.[...]
2016-09-08
[54]
문서
"スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。"
scrum guide 2020 JP
[55]
문서
"スクラムとは次の環境を促進するため ... 1. ... 問題に対応するための作業をプロダクトバックログに並べる。 2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。 3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。 4. 繰り返す。 スクラムはシンプルである。"
scrum guide 2020 JP
[56]
문서
"プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。"
https://scrumguides.[...]
スクラムガイド
2020
[57]
문서
"スクラムとは、複雑な問題に対応する適応型のソリューションを通じて … 軽量級フレームワークである。"
scrum guide 2020 JP
[58]
문서
"スクラムとは ... 価値を⽣み出すための軽量級フレームワークである。"
https://scrumguides.[...]
スクラムガイド
2020
[59]
문서
Scrum '''is a process framework''' that has been used to manage work on complex products since the early 1990s. Scrum '''is not a process, technique, or definitive method'''.
https://www.scrumgui[...]
SCRUM GUIDES 2017
[60]
문서
"スクラムフレー ムワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。... スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。"
scrum guide 2020 JP
[61]
논문
New New Product Development Game
https://cb.hbsp.harv[...]
1986-01-01
[62]
웹사이트
"「実践知リーダーシップとアジャイル／スクラム」－野中郁次郎氏が国内最大のスクラムイベントで講演"
http://enterprisezin[...]
EnterpriseZine（翔泳社）
2013-02-01
[63]
웹사이트
스크럼 제창자로부터 배우는, 팀의 불행을 줄이는 단 2개의 방법 (1/2)
https://atmarkit.itm[...]
ITmedia
2011-04-13
[64]
문서
Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum.
https://www.scrumgui[...]
SCRUM GUIDES
2020-08-16
[65]
문서
"スクラムが誕⽣したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採⽤されている。"
scrum guide 2020 JP
[66]
문서
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
https://www.scrumgui[...]
SCRUM GUIDES 2017
[67]
문서
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
https://www.scrumgui[...]
SCRUM GUIDES 2017
[68]
문서
"これは、潜在的に望ましくない変化や問題を検知するためである。"
scrum guide 2020 JP
[69]
문서
"検査によって適応が可能になる。適応のない検査は意味がないとされる。"
scrum guide 2020 JP
[70]
문서
"Transparency enables inspection. Inspection without transparency is misleading and wasteful."
Scrum Guide 2020
[71]
문서
スクラムの基本単位は、スクラムチームという⼩さなチームである。
scrum guide 2020 JP
[72]
문서
⼀度にひとつの⽬的（プロダクトゴール）に集中している専⾨家が集まった単位である。... スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。
scrum guide 2020 JP
[73]
문서
The Scrum Team is responsible for all product-related activities
scrum guide 2020
[74]
문서
⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。... 2020 年版ではスクラムチームの⾃⼰管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できる
scrum guide 2020 JP
[75]
문서
例えば完成したプロダクトが売れなかった場合、そうなった経緯を社長へ正しく報告する責任がある。チームの失敗はチームとして責任を負う。
[76]
문서
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
scrum guide 2020
[77]
문서
スクラムチームは、敏捷性を維持するための⼗分な⼩ささ ... があり、通常は 10 ⼈以下である。
[78]
문서
Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required.
Scrum Guide 2020
[79]
문서
Events are used in Scrum to create regularity
Scrum Guide 2020
[80]
문서
The Daily Scrum ... is held ... every working day of the Sprint.
Scrum Guide 2020
[81]
문서
Daily Scrum ... inspect '''progress'''
Scrum Guide 2020
[82]
문서
Daily Scrum ... inspect progress toward the '''Sprint Goal'''
Scrum Guide 2020
[83]
문서
Daily Scrum ... adapt the '''Sprint Backlog'''
Scrum Guide 2020
[84]
문서
Sprint Review ... inspect the '''outcome of the Sprint'''
Scrum Guide 2020
[85]
문서
Sprint Review ... progress '''toward the Product Goal''' is discussed.
Scrum Guide 2020
[86]
문서
Sprint Review ... The '''Product Backlog''' may also be adjusted to meet new opportunities.
Scrum Guide 2020
[87]
문서
Scrum Artifacts ... contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured ... These commitments exist to reinforce empiricism
Scrum guide 2020
[88]
문서
Each artifact contains a commitment ... : For the Product Backlog ...
Scrum Guide 2020
[89]
문서
Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.
Scrum Guide 2020
[90]
문서
プロダクトゴールは、プロダクトの将来の状態を表している。
scrum guide 2020 JP
[91]
문서
The Product Goal describes a future state of the product
scrum guide 2020
[92]
문서
プロダクトゴールは、スクラムチームの⻑期的な⽬標である。... プロダクトを全体的なプロダクトゴールに近づける
scrum guide 2020, JP
[93]
간행물
優れたプロダクトゴールは、達成に努めるものであり、測定可能であり
https://www.infoq.co[...]
InfoQ
2020
[94]
문서
スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。… 各作成物には、透明性と集中を⾼める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。・プロダクトバックログのためのプロダクトゴール … プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり
scrum guide 2020 JP
[95]
간행물
優れたプロダクトゴールは…スクラムチームとそのステークホルダに可視化されます。
https://www.infoq.co[...]
InfoQ
2020
[96]
간행물
プロダクトゴールは、プロダクトバックログのコンテキストを提供します。これは、プロダクトバックログが存在する「なぜ (Why)」と、スクラムチームが作業を行っているなぜ (Why) と考えることができます。… なぜチームにバックログを与えているのかについてのビジョンがないプロダクトオーナに大きな問題があると言いました。これは、チームにとって重要な意欲を削ぐものです。
https://www.infoq.co[...]
InfoQ
2020
[97]
문서
スクラムチームは ... ⼀度にひとつの⽬的（プロダクトゴール）に集中している
scrum guide 2020 JP
[98]
문서
プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。
scrum guide 2020, JP
[99]
웹사이트
As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list.
https://www.scrumgui[...]
2017
[100]
웹사이트
Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
https://www.scrumgui[...]
2017
[101]
웹사이트
Requirements never stop changing, so a Product Backlog is a living artifact. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.
https://www.scrumgui[...]
2017
[102]
문서
An Increment is a concrete stepping stone toward the Product Goal.
scrum guide 2020
[103]
문서
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。... 完成の定義を満たさない限り、作業をインクリメントの⼀部と⾒なすことはできない。
scrum guide 2020 JP
[104]
문서
スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。 ... プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。
scrum guide 2020 JP
[105]
문서
スプリントはスクラムにおける⼼臓の⿎動であり、スプリントにおいてアイデアが価値に変わる。
scrum guide 2020 JP
[106]
인용
スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり、予測可能性が⾼まる。
scrum guide 2020 JP
[107]
인용
スプリントは 1 か⽉以内の決まった⻑さとする。
scrum guide 2020 JP
[108]
인용
スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。
scrum guide 2020 JP
[109]
인용
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog
Scrum Guide 2020
[110]
인용
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.
Scrum Guide 2020
[111]
인용
プロダクトバックログアイテムが完成の定義を満たしていない場 合 ... スプリントレビューで提⽰することもできない。
scrum guide 2020 JP
[112]
인용
スプリ ント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。
scrum guide 2020 JP
[113]
인용
スプリントレビューのことを価値をリリースするための関⾨と⾒なすべきではない。
scrum guide 2020 JP
[114]
인용
スプリントの計画（スプリントバックログ）
scrum guide 2020 JP
[115]
인용
スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。
scrum guide 2020 JP
[116]
인용
スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。
scrum guide 2020 JP
[117]
인용
スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。... 作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。
scrum guide 2020 JP
[118]
인용
プロダクトの価値と有⽤性を今回のスプリントでどのように⾼める ... そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。
scrum guide 2020 JP
[119]
인용
スプリントゴール（なぜ）
scrum guide 2020 JP
[120]
인용
スプリントゴールはスプリントの唯⼀の⽬的である。
scrum guide 2020 JP
[121]
인용
これまでのスプリントプランニングのトピックである「What」と「How」に加えて、スクラム ガイド 2020 年版では、3 つ⽬のトピック「Why」に重点を置いた。これはスプリントゴールで ⾔及されている。
scrum guide 2020 JP
[122]
인용
スプリントゴールがもはや役に⽴たなくなった場合、スプリントは中⽌されることになるだろう。
scrum guide 2020 JP
[123]
인용
スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。... スクラムを利⽤していると、本⽂書で説明しているスクラムフレームワークと適合するようなパターン、プロセス、インサイトを発⾒・適⽤・考案することもあるだろう。
scrum guide 2020 JP
[124]
간행물
誤解を恐れずに言えば、アジャイルでは「正しく」ソフトウェアを作っても、それがリーン・スタートアップが目指す「正しい」ソフトウェアにならないことが起こり得るということになります。
新規事業のイノベーションを加速するリーン・スタートアップ適用とアジャイル開発. PROVISION No.87, 2015.
[125]
웹사이트
いくつものプロダクトゴールを積み上げていくことで、プロダクトビジョンに到達する、という考えです。
https://speakerdeck.[...]
2021
[126]
웹사이트
Involving Stakeholders to build consensus using your Product Goal
https://www.scrum.or[...]
2021-09-03
[127]
논문
The New New Product Development Game
http://hbr.org/produ[...]
2010-06-09
[128]
서적
Wicked problems, righteous solutions
https://archive.org/[...]
Prentice Hall
1990-10-01
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com