스크럼
최고의 스크럼으로 진행하는 방법 알아보기
스크럼이란?
스크럼은 팀이 함께 작업할 수 있도록 지원하는 프레임워크입니다. 중요한 경기를 위해 훈련하는 럭비 팀(여기에서 스크럼이라는 이름이 유래)처럼, 스크럼은 팀이 경험을 통해 배우고, 문제를 해결하면서 스스로 구성하고, 얻은 것과 잃은 것을 되돌아보며 지속적으로 개선하도록 유도합니다.
여기에서 말하는 스크럼은 소프트웨어 개발 팀에서 가장 자주 사용하지만, 그 원칙과 배운 점은 모든 종류의 팀워크에 적용할 수 있습니다. 이것이 스크럼이 인기 있는 이유 중 하나입니다. 종종 애자일 프로젝트 관리 프레임워크라고 생각되는 스크럼은 팀이 작업을 구성하고 관리하는 데 도움이 되는 일련의 회의, 도구 및 역할을 설명합니다.
이 문서에서는 스크럼 가이드와 Scrum.org의 CEO인 David West의 도움으로 전통적인 스크럼 프레임워크가 어떻게 구성되는지 설명합니다. 또한 고객이 특정한 요구 사항에 맞도록 이러한 기본 사항에서 벗어나는 것에 대한 예도 포함합니다. 이를 위해 Jira Software의 그룹 제품 관리자인 Megan Cook 및 전 애자일 코치가 애자일 코치 비디오 시리즈에서 팁과 요령을 알려줍니다.
스크럼 문서
Jira Software 소프트웨어로 스크럼 배우기
스크럼 프로젝트를 추진하고, 백로그를 우선 순위를 지정하여 스프린트로 구성하고, 스크럼 세레모니를 실행하기 등 모두를 Jira에서 수행하는 방법에 관한 단계별 가이드입니다.
이 튜토리얼 읽어보기프레임워크
스크럼은 애자일의 핵심 원칙인 지속적인 개선에 중점을 두기 때문에 스크럼과 애자일이 동일하게 여겨지는 경우가 많습니다. 그러나 스크럼은 작업 수행을 위한 프레임워크이며 애자일은 사고 방식입니다. 고객에게 가치를 제공하는 데 대한 팀의 사고 방식을 바꾸는 데 팀 전체의 노력이 필요하므로 단순히 '애자일로 전환'할 수는 없습니다. 그러나 스크럼과 같은 프레임워크를 사용하여 그러한 방식으로 생각하기 시작하고 일상적인 의사 소통과 작업에 애자일 원칙을 구축하는 연습을 할 수 있습니다.
스크럼 프레임워크는 체험적으로, 지속적인 학습과 변동 요인에 대한 조정을 기반으로 합니다. 프로젝트가 시작될 때 팀이 모든 것을 알고 있지 않으며 경험을 통해 진화한다는 점을 인정합니다. 스크럼은 팀이 변화하는 조건과 사용자 요구 사항에 자연스럽게 적응할 수 있도록 구성되었으며, 팀이 지속적으로 학습하고 개선할 수 있도록 프로세스에 우선 순위 재지정을 기본적으로 제공하고 릴리스 주기가 짧습니다.
스크럼은 구조화되어 있지만 완전히 경직된 것은 아닙니다. 스크럼의 실행은 모든 조직의 요구에 맞게 사용자 지정할 수 있습니다. 스크럼 팀이 성공하기 위해 정확히 어떻게 해야 하는지에 대해서는 여러 이론이 있습니다. 하지만 Atlassian에서 10년 넘게 애자일 팀이 작업을 완료하도록 지원한 후에 어떤 프레임워크를 선택하든 그 중심에는 명확한 의사 소통, 투명성 및 지속적인 개선에 대한 노력이 있어야 한다는 점을 배웠습니다. 나머지는 사용자에게 달려 있습니다.
스크럼 아티팩트
스크럼에서 세 가지 아티팩트를 식별하는 것부터 시작해 보겠습니다. 아티팩트는 문제를 해결하는 도구처럼 우리가 만드는 것입니다. 스크럼에서 이러한 세 가지 아티팩트는 제품 백로그, 스프린트 백로그 및 '완료'라는 정의에 대한 증분입니다. 이는 시간이 지남에 따라 계속해서 다시 방문하고 투자하게 될 스크럼 팀의 세 가지 상수입니다.
- 제품 백로그란 제품 소유자 또는 제품 관리자가 유지 관리해야 하는 기본 작업의 목록으로, 스프린트 백로그에 입력되는 기능, 요구 사항, 개선 사항 및 수정 사항의 동적인 목록입니다. 기본적으로 팀의 '해야 할 일' 목록입니다. 더 알게되거나 시장이 변화함에 따라 어떤 항목이 더 이상 관련성이 없어지거나 문제가 다른 방식으로 해결될 수 있으므로, 제품 소유자는 제품 백로그를 지속적으로 다시 검토하고 우선 순위를 다시 지정하며 유지 관리합니다.
- 스프린트 백로그는 현재 스프린트 주기에서 구현하기 위해 개발 팀이 선택한 항목, 사용자 스토리 또는 버그 수정의 목록입니다. 각 스프린트 전, 팀은 스프린트 계획 회의(이 기사의 뒷부분에서 다룰 예정) 중에 제품 백로그에서 스프린트에 대해 어떤 항목에 대해 작업할 것인지 선택합니다. 스프린트 백로그는 유연할 수 있으며 스프린트 중에 변경 가능하지만, 기본 스프린트 목표(팀이 현재 스프린트에서 달성하고자 하는 것)는 바뀔 수 없습니다.
- 증분(또는 스프린트 목표)은 스프린트에서 사용할 수 있는 최종 제품입니다. Atlassian에서는 일반적으로 팀은 스프린트에서 완료된 내용을 보여주는 스프린트 종료 데모 중에 '증분'을 시연합니다. 증분은 '완료'에 대한 팀의 정의, 마일스톤, 스프린트 목표 또는 정식 버전 또는 출시된 에픽이라고도 자주 불리기 때문에, 실제로 '증분'이라는 단어를 듣게 되지는 않을 수도 있습니다. 팀에서 '완료'를 정의하는 방법 및 스프린트 목표를 정의하는 방법에 따라 달라집니다. 예를 들어, 어떤 팀은 모든 스프린트가 끝날 때 고객에게 무언가를 릴리스하기로 선택합니다. 따라서 '완료'에 대한 이 팀의 정의는 '출시'일 것입니다. 그러나 다른 유형의 팀에서는 이러한 정의가 현실적이지 않을 수 있습니다. 한 분기에 한 번만 고객에게 출시할 수 있는 서버 기반 제품에 대해 작업하는 경우를 가정해 보겠습니다. 그러한 경우에도 2주 스프린트에서 작업하도록 선택할 수 있지만, '완료'에 대한 정의는 함께 출시하려는 더 큰 버전의 일부를 마무리하는 것일 수 있습니다. 물론 소프트웨어를 릴리스하는 데 시간이 오래 걸릴수록 소프트웨어가 결과를 달성하지 못할 위험이 높아집니다.
아티팩트 내에서도 팀에서 정의하기로 선택할 수 있는 다양한 변형이 있습니다. 따라서 아티팩트를 유지하는 방법을 진화시키는 데 개방적인 태도를 유지하는 것이 중요합니다. '완료'에 대한 정의가 팀에 과도한 스트레스를 줄 수 있으며, 다시 돌아가서 새로운 정의를 선택해야 할 수도 있습니다.
제품과 마찬가지로 프레임워크에서도 애자일해야 합니다. 필요한 시간을 내어 상황이 어떻게 진행되는지 확인하고, 필요한 경우 조정하고, 오로지 일관성을 위해 무언가를 강요하지 마세요.
스크럼 세레모니 또는 이벤트
스크럼 프레임워크의 더 잘 알려진 구성 요소 중 몇 가지는 스크럼 팀이 정기적으로 수행하는 순차적 이벤트, 세레모니 또는 회의입니다. 세레모니에서 팀의 가장 많은 변형을 볼 수 있습니다. 예를 들어, 어떤 팀에서는 이러한 모든 세레모니를 번거롭고 반복적인 방법으로 수행하는 반면, 다른 팀에서는 세레모니를 꼭 필요한 체크인으로서 사용합니다. 저희의 조언은 두 스프린트에 대해 모든 세레모니를 사용하고 어떻게 생각되는지 확인하세요. 그런 다음 빠른 회고를 수행하고 어떤 부분을 조정할지 확인할 수 있습니다.
다음은 스크럼 팀이 참여할 수 있는 모든 주요 세레모니의 목록입니다.
-
백로그 구성: 백로그 그루밍이라고도 하는 이 이벤트는 제품 소유자의 책임입니다. 제품 소유자의 주요 업무는 제품 비전을 향해 제품을 유도하고 시장과 고객에 대한 최신 정보를 파악하는 것입니다. 그렇게 해서 제품 소유자는 사용자 및 개발 팀의 피드백을 사용하여 이 목록을 유지하여 이 목록을 정돈된 상태로 유지하고 언제든지 작업할 준비가 되도록 돕습니다. 양호한 백로그 유지에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
-
스프린트 계획: 이 회의에서 전체 개발 팀이 현재 스프린트 중에 수행할 작업(범위)을 계획합니다. 이 회의는 스크럼 마스터가 주도하며 팀이 스프린트 목표를 결정합니다. 그런 다음 제품 백로그에서 특정 사용 스토리를 스프린트에 추가합니다. 이 스토리는 항상 목표와 정렬되며 스프린트 중에 구현할 수 있도록 스크럼 팀의 합의를 거칩니다.
계획 회의를 마칠 때 모든 스크럼 멤버는 스프린트에서 제공할 수 있는 사항 및 점점 더 많이 제공하는 방법에 대해 명확히 알고 있어야 합니다. -
스프린트: 스프린트는 스크럼 팀이 함께 작업하여 증분을 완료하는 실제 기간입니다. 스프린트에서 일반적인 기간은 2주지만, 어떤 팀은 범위를 지정하는 데 1주일, 또는 중요한 증분을 제공하는 데 1달이 더 쉽다고 느낄 수 있습니다. Scrum.org의 Dave West는 작업이 복잡하고 알 수 없는 부분이 많을수록 스프린트가 짧아야 한다고 조언합니다. 하지만 실제로 이는 팀의 선택에 달려 있으며, 잘 맞지 않는다면 바꿔야 합니다. 이 기간 동안 필요에 따라 제품 소유자와 개발 팀 간에 범위를 다시 논의할 수 있습니다. 이것이 스크럼의 경험적 성격을 나타내는 가장 중요한 부분입니다.
계획부터 회고에 이르는 모든 이벤트는 스프린트 중에 발생합니다. 스프린트에 대한 특정한 시간 간격이 수립되면 개발 기간 동안 일관성을 유지해야 합니다. 이를 통해 팀은 과거의 경험으로부터 배우고 그 통찰력을 이후의 스프린트에 적용할 수 있습니다. -
일일 스크럼 또는 스탠드업: 같은 시간(보통 아침)에 진행하는 아주 짧은 회의이며 일을 간단하게 유지하는 데 도움을 줍니다. 많은 팀에서는 15분 만에 회의를 완료하려고 하지만, 이는 지침일 뿐입니다. 이 회의는 빠른 회의여야 한다는 것을 강조하여 '일일 스탠드업'이라고도 합니다. 일일 스크럼의 목표는 모든 팀원이 같은 정보를 공유하고, 스프린트 목표를 이해하고, 다음 24시간 동안의 계획을 세우는 것입니다.
스탠드업은 스프린트 목표를 충족하는 데 우려 사항 또는 방해 요소에 대해 알리는 시간입니다.
스탠드업을 수행하는 일반적인 방법은 스프린트 목표 달성의 맥락에서 모든 팀원이 세 가지 질문에 답하는 것입니다.
• 어제 무엇을 했습니까?
• 오늘 무엇을 할 계획입니까?
• 장애물이 있습니까?
하지만 이러한 회의는 어제의 자신의 일정을 읽고 다음 날 이를 반복하는 의미 없는 모임으로 빠르게 변하는 경우가 많습니다. 스탠드업의 기반이 되는 이론은, 매일 모임에 방해가 되는 잡담을 일일 회의로 전환하여 팀이 하루 중 나머지 시간 동안 작업에 집중할 수 있도록 하는 것입니다. 따라서 회의가 매일의 일정을 읽는 시간으로 바뀌면 여기에 변화를 주고 창의력을 발휘하는 것을 두려워하지 마세요. -
스프린트 검토: 스프린트가 끝나면 팀이 함께 모여 비공식 세션을 통해 증분의 데모를 보거나 검사합니다. 개발 팀은 피드백을 얻기 위해 현재 '완료'된 백로그 항목을 이해 관계자와 팀원에게 보여줍니다. 대부분의 경우 증분을 릴리스하지만, 제품 소유자는 증분을 릴리스할지 여부를 결정할 수 있습니다.
제품 소유자가 현재 스프린트를 기반으로 다음 스프린트 계획 세션에 반영할 제품 백로그를 다시 작업하는 경우도 이러한 검토 회의가 됩니다. 기간이 1달인 스프린트의 경우 스프린트 검토를 최대 4시간으로 한정하는 것을 고려하세요. -
스프린트 회고: 회고란 팀이 함께 모여 스프린트, 프로젝트, 사용자 또는 관계, 도구 또는 특정 세레모니에서 효과가 있었던 부분과 잘 되지 않았던 부분을 기록하고 논의하는 단계입니다. 그 목적은 팀이 잘못 진행된 부분보다는 다음번에 개선해야 할 사항에 집중할 수 있는 장소를 만드는 것입니다.
스크럼 성공을 위한 세 가지 필수 역할
스크럼 팀에는 제품 소유자, 스크럼 마스터 및 개발 팀이라는 세 가지 구체적인 역할이 필요합니다. 스크럼 팀은 다양한 기능을 갖추고 있기 때문에 개발팀에는 개발자뿐 아니라 테스터, 디자이너, UX 전문가 및 운영 엔지니어가 포함됩니다.
스크럼 제품 소유자
제품 소유자는 해당 제품의 챔피언으로, 비즈니스, 고객 및 시장 요구 사항을 이해하고 그에 따라 엔지니어링 팀이 해야 할 작업의 우선 순위를 정하는 데 중점을 둡니다. 효과적인 제품 소유자는 다음과 같습니다.
- 제품 백로그를 만들고 관리합니다.
- 모두가 제품 백로그의 작업 항목을 이해할 수 있도록 비즈니스 및 팀과 긴밀하게 협력합니다.
- 다음에 제공할 기능에 대한 명확한 지침을 팀에 제공합니다.
-
더 자주 제공하는 방향으로 나아가도록, 제품을 출시할 시기를 결정합니다.
제품 소유자가 항상 제품 관리자인 것은 아닙니다. 제품 소유자는 개발 팀이 비즈니스에 가장 큰 가치를 제공하도록 보장하는 데 중점을 둡니다. 또한 여러 제품 소유자로부터 엇갈린 지침을 받고 싶어 하는 개발 팀은 없으므로, 제품 소유자는 한 개인이어야 합니다.
스크럼 마스터
스크럼 마스터는 팀 내에 스크럼의 챔피언으로, 스크럼 프로세스에 대해 팀, 제품 소유자 및 비즈니스에게 코칭하고 그 프로세스의 실행을 미세 조정하는 방법을 모색합니다.
효과적인 스크럼 마스터는 팀이 수행하는 작업을 깊이 있게 이해하며 팀이 투명성과 전달 흐름을 최적화하는 데 도움을 줄 수 있습니다. 스크럼 마스터는 진행 책임자로서 스프린트 계획, 스탠드업, 스프린트 검토 및 스프린트 회고에 필요한 리소스(인력 및 물류 모두)를 예약합니다.
스크럼 개발 팀
스크럼 팀은 작업을 완료하며 지속 가능한 개발 관행의 챔피언입니다. 가장 효과적인 스크럼 팀은 아주 긴밀하고 같은 곳에 배치되며 보통 5~7명의 팀원으로 이루어져 있습니다. 팀의 규모를 정하는 한 가지 방법은 Amazon의 CEO인 Jeff Bezos가 만든 유명한 '피자 두 판 규칙'(팀은 피자 두 판을 나눠 먹을 수 있을 정도로 작아야 함)을 사용하는 것입니다.
팀원들은 서로 다른 기술 집합을 가지고 있으며, 아무도 작업 전달에 병목 현상을 일으키지 않도록 서로를 교육합니다. 강력한 스크럼 팀은 자체적으로 구성되며 분명한 '팀 중심의' 태도를 가지고 프로젝트에 접근합니다. 모든 팀원이 스프린트를 성공적으로 완료하기 위해 서로를 돕습니다.
스크럼 팀은 각 스프린트에 대한 계획을 추진하며, 과거의 속도를 가이드로 삼아 반복을 통해 작업을 얼마나 완료할 수 있을지 예측합니다. 반복의 길이를 고정하면 개발 팀에 추정 및 전달 프로세스에 대한 중요한 피드백을 제공하게 되므로 시간이 지남에 따라 추정의 정확도가 높아집니다.
스크럼, 칸반, 애자일
스크럼은 아주 인기 있는 애자일 프레임워크여서 스크럼과 애자일은 종종 같은 것으로 오해받기도 합니다. 그러나 인기 있는 대안인 칸반 등의 다른 프레임워크도 있습니다. 어떤 회사에서는 '스크럼반'이라는 이름이 붙여진 스크럼과 칸반의 하이브리드 모델 또는 백로그가 있는 칸반인 '칸플랜'을 선택합니다.
스크럼과 칸반 모두 스크럼 보드 또는 칸반 보드와 같은 시각적 방법을 사용하여 작업 진행 상황을 추적합니다. 둘 다 효율성을 강조하고 복잡한 작업을 관리 가능한 작은 작업으로 나누지만 그 목표에 대한 접근 방식은 다릅니다.
스크럼은 시간이 고정된 더 작은 반복에 중점을 둡니다. 스프린트의 기간이 마무리되면 이 스프린트 주기 동안 구현할 수 있는 스토리 또는 제품 백로그 항목이 결정됩니다. 그러나 칸반에서는 현재 주기에서 구현할 작업 또는 진행 중인 작업(WIP 제한)의 수가 처음에 고정됩니다. 그런 다음, 이러한 기능을 구현하는 데 걸리는 시간을 역으로 계산합니다.
칸반은 스크럼만큼 구조화되어 있지 않습니다. WIP 제한 외에는 상당히 개방적인 해석이 가능합니다. 하지만 스크럼은 스프린트 검토, 회고, 일일 스크럼과 같이 구현의 일부로 시행되는 몇 가지 범주형 개념을 가지고 있으며 스크럼 팀이 목표를 달성하기 위해 외부 구성원에 의존하지 않는 교차 기능성을 내세웁니다. 교차 기능 팀을 모으기란 간단한 일이 아닙니다. 이러한 면에서 칸반은 적응하기 더 쉽지만 스크럼은 개발 팀의 사고 과정과 기능의 근본적인 변화로 간주될 수 있습니다.
왜 스크럼을 사용합니까?
스크럼 프레임워크 자체는 간단합니다. 규칙, 아티팩트, 이벤트 및 역할은 이해하기 쉽습니다. 스크럼 프레임워크의 반쯤 규범적인 접근 방식은 실제로 개발 프로세스의 모호성을 없애는 데 도움이 되며 회사가 개별적인 특성을 적용할 수 있는 충분한 여력을 제공합니다.
어려운 프로젝트에서 복잡한 작업을 관리 가능한 사용자 스토리로 구성하는 것은 이상적인 일입니다. 또한 역할과 계획된 이벤트의 명확한 구분은 개발 주기 전반에 걸쳐 투명성과 집단적 소유권을 보장해줍니다. 빠른 릴리스를 통해 짧은 시간 내에 진전을 확인할 수 있으므로 팀에 동기가 부여되고 사용자가 만족합니다.
그러나 특히 개발 팀이 전형적인 워터폴 모델에 익숙한 경우, 스크럼을 완전히 이해하는 데 시간이 걸릴 수 있습니다. 더 작은 반복, 일일 스크럼 회의, 스프린트 검토 및 스크럼 마스터 식별이라는 개념은 새로운 팀에게는 어려운 문화적 변화일 수 있습니다.
그러나 장기적인 이익은 초기의 학습 곡선보다 훨씬 큽니다. 다양한 산업 및 업종에 걸쳐 복잡한 하드웨어 및 소프트웨어 제품을 개발하는 데 성공한 스크럼은 조직에서 채택할 만한 매력적인 프레임워크입니다.
