스크럼에 대한 설명 및 시작하는 방법

스크럼은 애자일의 핵심 원칙인 지속적 개선에 중점을 두기 때문에 스크럼과 애자일이 동일하게 여겨지는 경우가 많습니다. 그러나 스크럼은 작업 수행을 위한 프레임워크이며, 애자일은 철학입니다. 애자일 철학은 빈번한 소규모 릴리스를 통한 지속적이고 점진적인 개선에 중점을 두고 있습니다. 고객에게 가치를 제공하는 방식에 대한 팀의 사고방식을 바꾸는 데에는 팀 전체의 노력이 필요하므로, 단순히 '애자일로 전환'할 수는 없습니다. 하지만 스크럼과 같은 프레임워크를 사용하면 그러한 사고방식을 갖추고 일상적인 커뮤니케이션과 작업에 애자일 원칙을 실천하는 연습을 할 수 있습니다.

애자일 및 스크럼 정의의 차이는 스크럼 가이드와 애자일 매니페스토에서 확인할 수 있습니다. 애자일 매니페스토는 다음의 네 가지 가치를 간략하게 설명합니다.

• 프로세스 및 도구보다 개인 및 상호 작용

• 종합적 설명서보다 작동하는 소프트웨어

• 계약 협상보다 고객과의 협업

• 계획을 따르기보다는 변화에 대응

스크럼의 정의는 경험주의 및 린 사고를 기반으로 합니다. 경험주의는 경험을 통해 지식을 얻고 관찰한 것을 기반으로 결정을 내리는 것입니다. 린 사고는 불필요한 것을 줄이고 필수 사항에 집중하는 것을 말합니다. 스크럼 프레임워크는 체험을 중시하며, 지속적으로 학습하고 변동 요인을 조정하는 것을 기반으로 합니다. 또한 프로젝트가 시작될 때 팀이 모든 내용을 알고 있지 않으며 경험을 통해 진화해 나간다고 말합니다. 스크럼은 팀이 변화하는 조건과 사용자 요구 사항에 자연스럽게 적응할 수 있도록 구성되었으며, 팀이 지속해서 학습하고 개선할 수 있도록 프로세스에 대해 우선 순위를 재지정하고 릴리스 주기가 짧습니다.

스크럼은 구조화되어 있지만 완전히 경직된 것은 아닙니다. 스크럼의 실행은 모든 조직의 요구에 맞게 맞춤화할 수 있습니다. 스크럼 팀이 성공하기 위해 정확히 어떻게 작업해야 하는지에 대해서는 여러 이론이 있습니다. 하지만 Atlassian에서 10년 넘게 애자일 팀이 작업을 완료하도록 지원한 결과 어떤 프레임워크를 선택하든 그 중심에는 명확한 커뮤니케이션, 투명성 및 지속적 개선에 대한 노력이 있어야 한다는 점을 배웠습니다. 나머지는 사용자에게 달려 있습니다.

스크럼 프레임워크에서는 스크럼 팀이 제품 또는 서비스를 제공하기 위해 따르는 일련의 가치, 원칙 및 관행을 설명합니다. 스크럼 팀원과 팀원의 책임, 제품을 정의하고 제품을 '아티팩트' 및 스크럼 팀의 작업을 이끄는 스크럼 세레모니에 대해 자세히 설명합니다.

스크럼 팀은 제품 증분 목표를 달성하기 위해 노력하는 민첩한 소규모 팀입니다. 스크럼 팀 규모는 보통 10명 정도로 소규모이지만, 스프린트 한 번으로 상당한 양의 작업을 완료할 수 있을 만큼 큰일을 합니다. 스크럼 팀에는 제품 소유자, 스크럼 마스터 및 개발 팀이라는 세 가지 역할이 필요합니다. 스크럼 팀은 다기능 팀이기 때문에 이 개발팀에는 개발자뿐만 아니라 테스터, 디자이너, UX 전문가 및 운영 엔지니어가 포함됩니다.

스크럼 제품 소유자

제품 소유자는 해당 제품의 챔피언으로, 비즈니스, 고객 및 시장 요구 사항을 이해하고 그에 따라 엔지니어링 팀이 해야 할 작업의 우선 순위를 지정하는 데 중점을 둡니다. 유능한 제품 소유자는 다음과 같이 행동합니다.

• 제품 백로그를 만들고 관리합니다.

• 모두가 제품 백로그의 작업 항목을 이해할 수 있도록 비즈니스 및 팀과 긴밀하게 협력합니다.

• 팀에 다음에 제공할 기능을 명확하게 안내합니다.

• 제공 주기를 확대하는 것을 목표로, 제품을 제공할 시기를 결정합니다.

제품 소유자가 항상 제품 매니저인 것은 아닙니다. 제품 소유자는 개발 팀이 비즈니스에 가장 큰 가치를 제공하도록 하는 데 중점을 둡니다. 또한 여러 제품 소유자로부터 엇갈린 안내를 받고 싶어 하는 개발 팀은 없으므로, 제품 소유자는 한 사람이어야 합니다.

스크럼 마스터

스크럼 마스터는 팀 내 스크럼 챔피언으로, 스크럼 프로세스에 대해 팀, 제품 소유자 및 비즈니스를 코칭하고 스크럼 관행을 상세 조정하는 방법을 모색합니다.

유능한 스크럼 마스터는 팀이 수행하는 작업을 깊이 있게 이해하며 팀이 투명성 및 제공 흐름을 최적화하는 데 도움을 줄 수 있습니다. 진행 책임자인 스크럼 마스터는 스프린트 계획, 스탠드업, 스프린트 검토 및 스프린트 회고에 필요한 리소스(인력 및 물류 모두)를 예약합니다.

스크럼 개발 팀

스크럼 팀은 골치 아픈 작업을 완료하며 지속 가능한 개발 관행을 책임지는 챔피언입니다. 가장 효과적인 스크럼 팀은 아주 긴밀하게 협업하고, 같은 곳에서 일하며, 보통 5~7명의 팀원으로 이루어져 있습니다. 팀의 규모를 정하는 한 가지 방법은 Amazon CEO인 Jeff Bezos가 만든 유명한 '피자 두 판 규칙'(팀은 피자 두 판을 나눠 먹을 수 있을 정도로 작아야 함)을 사용하는 것입니다.

팀원들은 서로 다른 기술 집합을 가지고 있으며, 아무도 작업 제공에 병목 현상을 일으키지 않도록 서로를 교육합니다. 강력한 스크럼 팀은 스스로 체계화하며 분명한 '팀 중심'의 태도를 가지고 프로젝트에 임합니다. 모든 팀원이 스프린트를 성공적으로 완료하기 위해 서로를 돕습니다.

이 스크럼 팀은 각 스프린트에 대한 계획을 추진하며, 과거의 속도를 가이드로 삼아 반복을 통해 작업을 얼마나 완료할 수 있을지 예측합니다. 반복 기간을 고정하면 개발 팀에 추정 및 제공 프로세스에 대한 중요한 피드백을 제공할 수 있으며, 시간이 지남에 따라 추정 정확도를 높일 수 있습니다.

스크럼 아티팩트는 스크럼 팀이 제품을 정의하고 제품을 만들기 위해 해야 할 작업을 정의하는 데 사용하는 중요한 정보입니다. 스크럼에는 제품 백로그, 스프린트 백로그, '완료'라고 정의하는 증분이라는 세 가지 아티팩트가 있습니다. 스크럼 팀이 스프린트 기간과 그 이후에도 되돌아봐야 할 세 가지 상수입니다.

• 제품 백로그란 제품 소유자 또는 제품 매니저가 유지 관리해야 하는 기본 작업의 목록으로, 스프린트 백로그에 입력되는 기능, 요구 사항, 개선 사항 및 수정 사항의 동적인 목록입니다. 기본적으로 팀의 "해야 할 일" 목록입니다. 더 알게 되거나 시장이 변화함에 따라 어떤 항목이 더 이상 관련성이 없어지거나 문제가 다른 방식으로 해결될 수 있으므로, 제품 소유자는 제품 백로그를 지속적으로 다시 검토하고 우선 순위를 다시 지정하며 유지 관리합니다.

• 스프린트 백로그는 현재 스프린트 주기에서 구현하기 위해 개발 팀이 선택한 항목, 사용자 스토리 또는 버그 수정의 목록입니다. 각 스프린트 전, 팀은 스프린트 계획 회의(이 문서의 뒷부분에서 다룰 예정) 중 제품 백로그에서 해당 스프린트 중 어떤 항목을 작업할 것인지 선택합니다. 스프린트 백로그는 유연성이 있어 스프린트 중에 변경 가능하지만, 기본 스프린트 목표(팀이 현재 스프린트에서 달성하고자 하는 것)는 바뀔 수 없습니다.

• 증분(또는 스프린트 목표)은 스프린트에서 사용할 수 있는 최종 제품입니다. Atlassian에서는 일반적으로 팀은 스프린트에서 완료된 내용을 보여주는 스프린트 종료 데모 중에 "증분"을 시연합니다. 실제로 "증분"이라는 단어를 듣지 못할 수도 있습니다. 팀이 "완료"를 마일스톤, 스프린트 목표 또는 정식 버전 또는 제공된 에픽이라고 정의하는 경우가 많기 때문입니다. 팀에서 "완료"를 정의하는 방법 및 스프린트 목표를 정의하는 방법에 따라 달라집니다. 예를 들어, 어떤 팀은 모든 스프린트가 끝날 때 고객에게 무언가를 릴리스하기로 선택합니다. 따라서 "완료"에 대한 이 팀의 정의는 '제공'일 것입니다. 그러나 다른 유형의 팀에서는 이 정의가 현실적이지 않을 수 있습니다. 한 분기에 한 번만 고객에게 제공할 수 있는 서버 기반 제품에 대해 작업하는 경우를 가정해 보겠습니다. 그러한 경우에도 2주 스프린트에서 작업하도록 선택할 수 있지만, "완료"에 대한 정의는 함께 제공하려는 더 큰 버전의 일부를 마무리하는 것일 수 있습니다. 물론 소프트웨어를 릴리스하는 데 시간이 오래 걸릴수록 소프트웨어가 결과를 달성하지 못할 위험이 높아집니다.

아티팩트 내에서도 팀에서 정의하기로 선택할 수 있는 다양한 변형이 있습니다. 따라서 아티팩트를 유지하는 방법을 진화시키는 데 개방적인 태도를 유지하는 것이 중요합니다. "완료"에 대한 정의가 팀에 과도한 스트레스를 줄 수 있으며, 다시 돌아가서 새로운 정의를 선택해야 할 수도 있습니다.

스크럼 프레임워크는 스크럼 팀이 정기적으로 수행하는 스크럼 관행, 세레모니 및 미팅으로 구성됩니다. 애자일 세레모니는 팀마다 가장 차이가 많은 부분입니다. 예를 들어 어떤 팀에서는 모든 세레모니를 번거롭고 반복적이라고 여기지만 어떤 팀에서는 세레모니를 꼭 필요한 체크인으로 사용합니다. 저희의 조언은 두 개의 스프린트에 대해 모든 세레모니를 사용하고 어떻게 생각되는지 관찰하는 것입니다. 그런 다음 빠른 회고를 수행하면 어떤 부분을 조정할지 확인할 수 있습니다.

다음은 스크럼 팀이 참여할 수 있는 모든 주요 세레모니의 목록입니다.

1. 백로그 구성: 백로그 그루밍이라고도 하는 이 이벤트는 제품 소유자의 책임입니다. 제품 소유자의 주요 업무는 제품 비전에 따라 제품을 추진하고 시장 및 고객에 대한 최신 정보를 파악하는 것입니다. 제품 소유자는 사용자 및 개발 팀의 피드백을 바탕으로 이 목록을 유지하고 지속적으로 이 목록을 정리하고 언제든지 사용할 수 있도록 준비합니다. 양호한 백로그 유지에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

2. 스프린트 계획: 이 미팅에서 전체 개발 팀은 현재 스프린트 중에 수행할 작업(범위)을 계획합니다. 이 미팅은 스크럼 마스터가 주도하며 팀이 함께 스프린트 목표를 결정합니다. 그런 다음 제품 백로그에서 특정 사용자 스토리를 스프린트에 추가합니다.  이 스토리는 항상 목표와 정렬되며 스프린트 중에 구현할 수 있도록 스크럼 팀의 합의를 거칩니다.

   이 계획 미팅을 마칠 때 모든 스크럼 구성원은 스프린트에서 제공할 수 있는 사항 및 증분을 달성하는 방법을 명확히 알고 있어야 합니다.

3. 스프린트: 스프린트는 스크럼 팀이 함께 작업하여 증분을 완료하는 실제 기간입니다. 스프린트의 일반적인 기간은 2주이지만 어떤 팀은 범위를 지정하는 데 일주일 또는 중요한 증분을 제공하는 데 1개월이 더 편하다고 느낄 수 있습니다. Scrum.org의 Dave West는 작업이 복잡하고 알 수 없는 부분이 많을수록 스프린트가 짧아야 한다고 조언합니다. 하지만 이는 실제로 팀의 선택에 달려 있으며 잘 맞지 않는다면 과감하게 바꿔야 합니다. 이 기간에 필요에 따라 제품 소유자 및 개발 팀 간에 범위를 다시 논의할 수 있습니다. 이것이 스크럼의 경험적 특성을 가장 잘 보여 주는 부분입니다.

   계획부터 회고에 이르는 모든 이벤트는 스프린트 중에 발생합니다. 스프린트의 시간 간격이 수립되면 개발 기간에 걸쳐 일관성을 유지해야 합니다. 그러면 팀은 과거의 경험으로부터 배우고 그 인사이트를 이후의 스프린트에 적용할 수 있습니다.

4. 매일 스크럼 또는 스탠드업: 같은 시간(보통 아침)에 간단히 진행하는 아주 짧은 미팅입니다. 많은 팀에서는 15분 만에 미팅을 완료하려고 하지만 이것은 가이드라인일 뿐입니다. 이 미팅은 빠르게 진행되어야 한다는 점을 강조하여 '매일 스탠드업'이라고도 합니다. 매일 스크럼의 목표는 모든 팀원이 같은 정보를 공유하고 스프린트 목표에 정렬 상태를 유지하고 다음 24시간 동안의 계획을 세우는 것입니다.

   스탠드업은 스프린트 목표를 달성하는 데 나타나는 우려 사항 또는 블로커에 대해 알리는 시간입니다.

   스탠드업을 진행하는 일반적인 방법은 스프린트 목표 달성의 맥락에서 모든 팀원이 세 가지 질문에 답하는 것입니다.
   
   • 어제 무엇을 했습니까?
   • 오늘 무엇을 할 계획입니까?
   • 장애물이 있습니까?
   
   하지만 이 미팅은 어제의 일정을 보고 다음 날 일정을 확인하는 모임으로 빠르게 변질되는 경우가 많습니다. 스탠드업의 기반이 되는 이론은 매일 모임에 방해가 되는 잡담을 일일 미팅으로 전환하여 팀이 하루 중 나머지 시간 동안 작업에 집중할 수 있도록 하는 것입니다.  따라서 미팅이 매일 일정을 읽는 시간으로 바뀐다면 여기에 변화를 주고 창의력을 발휘하는 것을 두려워하지 마세요.

5. 스프린트 검토: 스프린트가 끝나면 팀이 함께 모여 비공식 세션을 통해 증분의 데모를 보거나 증분을 검사합니다. 개발 팀은 피드백을 얻기 위해 현재 '완료'된 백로그 항목을 이해 관계자와 팀원에게 보여 줍니다. 대부분의 경우 증분을 릴리스하지만 제품 소유자는 증분을 릴리스할지 여부를 결정할 수 있습니다.

   이 검토 미팅에서는 또한 제품 소유자가 다음 스프린트 계획 세션에 반영할 제품 백로그를 현재 스프린트를 기반으로 다시 작업하기도 합니다. 기간이 1개월인 스프린트의 경우 스프린트 검토를 최대 4시간으로 한정하는 것을 고려하세요.

6. 스프린트 회고: 회고란 팀이 함께 모여 스프린트, 프로젝트, 사용자 또는 관계, 도구 또는 특정 세레모니에서 잘 진행되었던 부분과 잘 진행되지 않았던 부분을 기록하고 논의하는 단계입니다. 그 목적은 팀이 잘 진행되지 않았던 부분보다는 잘 진행된 부분과 다음번에 개선해야 할 사항에 집중할 기회를 제공하는 것입니다.

2016년에는 스크럼 가이드에 다섯 가지 스크럼 가치가 추가되었습니다. 스크럼 가치는 스크럼 팀의 업무, 작업 및 행동에 대한 방향을 제시하며 스크럼 팀의 성공에 필수 요소로 간주됩니다.

이행 약속

스크럼 팀은 규모가 작고 민첩하므로 각 팀원이 팀의 성공에 중요한 역할을 합니다. 따라서 각 팀원은 무리하지 않고 완료할 수 있는 작업을 수행하는 데 동의해야 합니다. 보통 스탠드업에서 업무 진행률에 대해 자주 소통해야 합니다.

용기

스크럼 팀의 용기란 성공을 방해하는 모든 요소와 현상에 의문을 제기하는 용기를 말합니다. 스크럼 팀원은 새로운 것을 시도할 용기가 있어야 하고 그렇게 하는 것을 편안하게 느껴야 합니다. 스크럼 팀은 장애물, 프로젝트 진행률, 지연 등을 투명하게 공개할 용기가 있어야 하고 그렇게 하는 것을 편안하게 느껴야 합니다.

집중 영역

스크럼 팀 워크플로의 중심에는 스프린트가 있습니다. 스프린트는 팀이 정해진 양의 작업을 정해진 시간에 집중하는 것입니다. 스프린트는 구조를 제공하는 것은 물론 계획된 작업량을 완료하는 데 집중합니다.

개방성

매일 스탠드업을 진행하면서 팀이 진행 중인 작업 및 블로커에 대해 공개적으로 이야기를 나누는 열린 문화를 조성할 수 있습니다. Atlassian에서는 종종 스크럼 팀이 다음과 같은 질문에 답하도록 합니다.

• 어제 어떤 작업을 했습니까?

• 오늘 무슨 일을 하고 있습니까?

• 어떤 이슈가 나를 방해합니까?

이렇게 하면 진행률을 강조하고 블로커를 식별할 수 있습니다. 모두가 진행률을 공유하면 팀의 역량을 강화할 수도 있습니다.

존중

애자일 팀의 강점은 공동 작업, 그리고 각 팀원이 스프린트에서 작업에 기여한다는 것을 인식하는 데 있습니다. 서로의 성과를 축하하는 것은 물론 서로를 존중하고 제품 소유자, 이해 관계자 및 스크럼 마스터를 존중합니다.

스크럼은 매우 인기 있는 애자일 프레임워크이므로 스크럼과 애자일을 같은 의미로 잘못 이해하는 경우가 많습니다. 하지만 많이 사용되는 대안인 칸반과 같은 다른 프레임워크도 있습니다. 일부 회사에서는 스크럼 및 칸반의 하이브리드 모델을 따르기도 하는데 이 모델은 'scrumban' 또는 백로그가 있는 칸반인 'kanplan'이라는 이름으로 알려져 있습니다.

스크럼 및 칸반 모두 스크럼 보드 또는 칸반 보드와 같은 시각적 방법을 사용하여 작업 진행률을 추적합니다. 둘 다 효율성을 강조하고 복잡한 작업을 관리하기 쉬운 작은 작업으로 나누는 것을 강조하지만 그 목표에 대한 접근 방식은 다릅니다.

스크럼은 시간이 고정된 더 작은 반복에 중점을 둡니다. 스프린트 기간이 확정되면 이 스프린트 주기에 구현할 수 있는 스토리 또는 제품 백로그 항목이 결정됩니다. 하지만 칸반에서는 현재 주기에 구현할 작업 수 또는 진행 중인 작업(WIP 제한)이 처음에 고정되어 있습니다. 그런 다음 이 기능을 구현하는 데 걸린 시간을 역으로 계산합니다.

칸반은 스크럼만큼 구조화되어 있지 않습니다. WIP 제한을 제외하고는 해석의 여지가 상당히 많습니다. 그러나 스크럼에는 스프린트 검토, 회고, 매일 스크럼 등과 같이 구현의 일부로 적용되는 몇 가지 단정적인 개념이 있습니다. 또한 스크럼 팀이 목표를 달성하기 위해 외부 구성원에게 의존하지 않는 능력인 교차 기능성을 강조합니다. 교차 기능 팀을 구성하는 것은 간단하지 않습니다. 그런 의미에서 칸반은 적응하기 쉬운 반면 스크럼은 개발 팀의 사고 과정 및 기능에 근본적인 변화를 가져온다고 볼 수 있습니다.

스크럼 프레임워크 자체는 간단합니다. 규칙, 아티팩트, 이벤트 및 역할은 이해하기 쉽습니다. 스크럼 프레임워크의 반쯤 규범적인 접근 방식은 실제로 개발 프로세스의 모호성을 없애는 데 도움이 되며 회사가 개별적인 특성을 적용할 수 있는 충분한 여력을 제공합니다.

어려운 프로젝트에서 복잡한 작업을 관리 가능한 사용자 스토리로 구성하는 것은 이상적인 일입니다. 또한 역할 및 계획된 이벤트의 명확한 구분은 개발 주기 전반에 걸쳐 투명성 및 집단적 책임 의식을 보장해 줍니다. 빠른 릴리스를 통해 짧은 시간 내에 진행 상황을 확인할 수 있으므로 팀에 동기가 부여되고 사용자가 만족합니다.

그러나 특히 개발 팀이 전형적인 워터폴 모델에 익숙한 경우, 스크럼을 완전히 이해하는 데 시간이 걸릴 수 있습니다. 더 작은 반복, 매일 스크럼 미팅, 스프린트 검토 및 스크럼 마스터 식별이라는 개념은 새로운 팀에게는 어려운 문화적 변화일 수 있습니다.

그러나 장기적인 이익은 초기의 학습 곡선보다 훨씬 큽니다. 스크럼은 다양한 산업 및 업종에 걸쳐 복잡한 하드웨어 및 소프트웨어 제품을 개발하는 데 성공적인 결과를 제공하고 있으므로, 조직에서 채택할 만한 매력적인 프레임워크입니다.

Jira에서의 스크럼에 대해 알아보려면 이 자습서를 확인하세요.