AGILE Framework - 스크럼(SCRUM) Basics (1)
Updated:
미리 일러두는 말: 본 포스팅은 LinkedIn 에서 제공하는 [Agile Methodology] Scrum 과정을 참고하여 정리한 내용임을 알려드립니다.
AGILE을 내 손에 거머쥐는 방법 - AGILE Framework 세우기
Agile 방법론은 기존의 소프트웨어 개발 방법론에 대한 반성이자 변화무쌍한 시장의 요구에 효과적으로 대응하기 위해 제안된 새로운 ‘개발 방법론’, 소프트웨어 개발을 위한 ‘일하는 방식’의 혁신입니다. 다시 말해 Agile 방법론은 소프트웨어 공학 분야 ‘구루(Guru)’들의 경험과 통찰에 기초하여 제안된 새로운 소프트웨어 개발 ‘문화(Culture)’이자 ‘운동(Movement)’라고도 할 수 있습니다.(‘Agile 프로젝트 개발자들에게 요구되는 역량’ 편 참조 https://engineering-skcc.github.io/culture/agileability/)
그런데 ‘문화’, ‘운동’이란 개념적 용어를 소프트웨어 공학에 적용 하기에는 어딘지 모르게 모호합니다. 그저 “뜬 구름 잡는 소리 아냐?” 라고 느껴질만큼 말이죠.
그저 ‘모호함’의 영역에 머무를지도 모를(?) Agile 문화 혹은 운동을 실제 활용이 가능한 ‘실용의 영역’으로 구현하는 것은 소위 말하는 Framework, 즉 ‘틀’ 혹은 ‘형태’를 세우는 작업을 통해 이루어 집니다. 우리는 이를 Agile Framework라 부르고 이를 구체화하는 모델(프로젝트 수행 방법론)에는 스크럼(Scrum), XP(Extreme Programming), 칸반(Kanban) 등이 포함됩니다. 나아가 이런 Framework 모델들과 더불어 Agile 개발 방식인 Extreme Programming 과 대형 Agile 프로젝트 관리 방법론인 DAD와 SAFe 등을 포함하여 ‘Agile 문화’를 이루고 있는 일종의 생태계, Agile Umbrella를 아래의 그림과 같이 표현할 수 있습니다.
앞으로 3차례의 연작 포스팅을 통해 Agile 생태계를 이루는 AGILE Framework 모델 중 가장 많이 활용되는 ‘스크럼(Scrum)’에 대해 자세히 살펴보도록 하겠습니다. 특히 이번 스크럼(Scrum) Basics (1)편에서는 스크럼의 유래와 의미를 알아보는 동시에 기본 정신을 익혀보고 이를 활용한 프로젝트를 수행하기 위한 준비로써 스크럼의 기본 구성요소와 이를 진행하는 팀 구성 방안에 대해 알아보겠습니다. 이어지는 Basics (2)편에서는 스크럼 프로젝트를 수행하기 위한 계획을 포함한 준비 작업을 다룰 예정이고 마지막 Basics (3)편에서는 실제 수행하는 방안을 차례로 알아보도록 하겠습니다.
논의에 들어가기 전에 한가지 당부를 드리자면 이번 스크럼 Basics 시리즈는 아직 AGILE에 익숙치 않은 Agile Beginner를 위한 기본적인 사항을 중점적으로 다룰 예정이니 읽으시는 분께서는 자신의 Agile 레벨을 잘 감안하셔서 포스팅을 읽어 주시기 바랍니다.
스크럼에서 우리 팀이 하는 일 엿보기
그럼 스크럼(Scrum) Basics 첫걸음으로 스크럼이 하는 일을 간략히 정리해 보겠습니다. 간단한 말로 표현되어 있지만 아래의 여섯 문장에 스크럼이 강조하는 핵심가치가 모두 포함되어 있으니 잘 기억해 두시면 앞으로의 스크럼 학습에 도움이 되리라 생각합니다.
- 팀원 중 하나인 Product Owner는 최우선 시 되어야 할 일감(백로그)을 결정한다.
- 팀은 스스로 향후 2주 간 어떤 일을 할 수 있는지를 결정한다.
- 팀은 일감에 대한 솔루션이 완료(Done)될 때까지 개발하고 테스트한다.
- 팀은 완료된 일감을 시연한다.
- 팀은 자신의 생산성을 어떻게 향상시킬지 회고한다.
- 이와 같은 과정을 프로젝트 성공 시까지 반복한다.
잘 읽어 보셨나요? 아직은 제가 무엇을 말하려는 건지 잘 와닿지 않을 수 있습니다. 이제부터 이어지는 논의들을 통해 위의 여섯 문장이 의미하는 바가 무엇인지 그리고 이 문장들이 스크럼을 어떻게 대표할 수 있는지 알아보고, 나아가 스크럼이 어떻게 Agile 방법론을 구체화 시킬 수 있는지에 대해서도 알아보도록 하겠습니다.
스크럼의 유래와 의미
스크럼에 대해 자세히 알아보기 전에 스크럼이 어디서 온 말인지 그리고 그것이 의미하는 바가 무엇인지 먼저 알아보는게 좋겠지요?
스크럼을 짜라!
스크럼(Scrum)이라는 단어는 사실 럭비(Rugby)에서 사용하는 ‘스크럼을 짜다’라는 뜻인 ‘scrummage’에서 따 왔습니다. 다들 잘 아시다시피, 럭비는 마치 미국 서부개척 시대를 연상시키듯 팀원이 협심하여 상대방의 진영을 점차 점령하면서 궁극적으로 그라운드의 가장 안쪽에 다다르면(Touch Down) 득점을 하게됩니다. 그리고 Touch Down 후 ‘Kick’을 잘 차면 추가 득점도 얻을 수 있지요. 당연히 Touch Down을 많이 할수록 많은 점수를 얻게되어 승리합니다. 아래 그림을 보시죠.
스크럼은 럭비와 같이 팀이 하나가 되어 상대방이 버티고 있는 혹은 미지의 적진 깊숙한 곳(=프로젝트 비전)을 향해 차츰 전진(=스프린트 수행)한 후 끝에 다다르는(=스프린트 결과물 리뷰) 행위를 ‘반복’함으로써 궁극적으로 승리(=프로젝트 성공)하는 게임의 룰을 차용한 것입니다. 다시 말하자면 ‘스프린트(Sprint)’라 불리는 업무 단위를 ‘반복’하며 전체 프로젝트의 일감을 수행함으로써 궁극적으로는 ‘프로젝트를 완성’한다는 개념으로 이해하시면 되겠습니다.
빨리 실패하고 빨리 배우자.
주지했듯이 스크럼은 Agile 생태계에 포함된 Framework 모델 중 가장 널리 활용되는 모델입니다. 이 것의 가장 기본적인 모토는 ‘빨리 실패함으로써 빨리 배우자(Fast fail, fast learn)!’ 로 정리할 수 있습니다. 즉, 가이드 포스트로써, 그리고 탄력적인 Framework로써의 Agile 원칙에 기반하여 프로젝트를 성공시키기 위하여 개발 작업을 짧은 기간안에 반복적으로 수행함을 의미합니다.
Scrum Essentials
이제 스크럼을 구성하는 기본 요소와 스크럼 팀의 Key Role에 대해 알아보겠습니다. 우선 스크럼은 기본적으로 아래 간단한 그림과 같이 ‘유연한(Flexible) 범위(Scope)’와 ‘고정(Fixed)된 비용(Cost)과 시간(Time)’으로 구성됩니다.
다들 잘 아시다시피 프로젝트는 ‘기간(period of development)’이 정해져 있고 책정된 ‘예산(budget)’을 변경하기 어렵습니다(물론 두 요소 모두 늘어나는 경우도 있습니다만…^^;). 반면 개발 범위는 애자일 방법론의 특성 상 프로젝트 계획 단계에서 명확한 그림을 그릴 수 없습니다. 다시말해 스크럼은 수행기간과 비용은 이미 정해져 있지만 수행해야할 일감의 양이 명확하지 않은 애자일 프로젝트의 특징을 잘 반영하고 있습니다.
기본 구성요소
그럼 스크럼을 이루고 있는 기본 구성요소에 대해 알아보겠습니다.
-
제한된 시간: 스크럼은 반드시 전체 프로젝트 기간을 제한된 시간으로 구분하여 각 차수마다 결과물을 반복적으로 만들어 내는데, 여기서 언급된 ‘제한된 시간’은 ‘스프린트(Sprint)’라는 이름으로 부르고 각 스프린트는 통상적으로 2~4주의 기간으로 설정합니다.
-
간소한 공유 미팅: 스크럼은 투명하게 공유됨으로써 하나의 유기적인 협업 프로세스를 표방하는데, 이는 매일 아침 15분 정도의 Daily Stand-Up Meeting을 통해 팀원 각자 전 날의 업무 사항과 요청사항 등을 공유함으로써 구현됩니다.
-
반추를 통한 개선: 스크럼 팀은 개별 ‘스프린트’를 마친 이후 ‘회고(Retrospective)’라는 세션을 통해 금번 스프린트의 계획과 개발 등 진행 전반에 대해 반추해 보고 어떤 부분을 배웠는지, 어떤 부분을 개선하면 더욱 효과적이고 생산적인 개발 작업을 할 수 있을지 공유합니다.
스크럼 팀 내 Key Roles
스크럼을 진행하는 팀원의 역할은 프로젝트를 통해 도출되는 ‘제품’의 책임자인 Product Owner, 스크럼 팀의 facilitator인 Scrum Master, 그리고 Developer(Designer 포함)로 나눠지며 5~9명의 인원으로 구성됩니다. 이 중 Product Owner(이하 PO)와 Scrum Master를 스크럼 팀의 Key Role이라 일컫습니다. 간단하게 PO는 “팀원으로 참여하는 비지니스 대표자”로 표현할 수 있고, Scrum Master는 “팀원을 대변하며 그들의 업무 완수와 역량 성장을 이끌어내는 조력자”라고 표현할 수 있습니다.
-
01 Product Owner Product Owner는 스크럼 팀에 Full-time 으로 참여하는 Biz. 대표자로서, 각 스프린트를 거쳐 도출된 팀 결과물의 완료 여부를 결정합니다. 더불어 프로젝트 오너들과 팀원을 연결하는 커뮤니케이션을 담당해야하고 무엇보다 팀원 전체가 수행해야하는 일감(백로그)를 정의하고 관리하며 우선순위를 조정함으로써 팀을 위해 Product Vision을 흔들림없이 유지하고 제시해야 합니다.
-
02 Scrum Master 다음으로 Scrum Master는 스크럼 프로세스가 유지되도록 가이드해야 하고, 팀원들이 자기들의 업무를 꾸준히 수행할 수 있도록 돕습니다. 팀원들의 업무를 방해하는 장애물을 사전에 제거하고 그들의 생산성을 높이고 성장을 이끌어내기 위한 팀원의 대변인 역할을 담당해야 합니다. 더불어 Product Owner가 팀 전체를 신뢰하도록 이끌어야 합니다.
스크럼 팀 구성하기
스크럼 팀은 7명을 기준으로 2명 내외를 빼거나 더할 수 할 수 있습니다. 이는 업무를 진행하는데 필요한 역량 분야를 충분히 확보하면서도 가장 원활한 소통과 협업을 가능케할 팀원의 수가 7명 내외이기 때문입니다. 따라서 팀원이 5명이 안될 경우에는 다른 팀과 합치는 것을, 반대로 9명을 넘을 경우엔 두개의 팀으로 나눌 것을 추천합니다.
팀을 구성하는 각 팀원 특히 개발자는 복합적인 역량을 갖춘 인재로 구성하는 것이 좋습니다. 이러한 인재를 쉽게 T자형(T-Shaped) 인재라고 하는데 아래 이미지와 같이 표현합니다.
예를 들어, 전문분야는 자바 개발이지만 데이터베이스에 대한 기본적인 지식도 갖춤으로써 Multi-tasking이 가능한 인재를 생각해 볼 수 있습니다. 이러한 인재는 자바 개발을 담당하면서 DB 지식을 활용하여 팀 내 DB 전문가와 원활한 의사소통과 협업의 가능성을 가질 수 있는 것이죠. 이렇게 복합 역량을 가진 인재들로 팀을 구성함으로써 팀 전체의 원활한 협력을 이끌어 낼 수 있다는 장점을 가질 수 있습니다.
물론 좋은 스크럼 팀을 구성하기 위해서는 팀원의 역량 요소 외에 팀원들의 마음가짐 등 다른 사항들도 고려해야 합니다. 기존에 작성된 “Agile 프로젝트의 조직 구성에 대해 알아봅시다.” 포스팅에서 자세히 다루고 있으니 이에 대해 더 알고 싶은 분께서는 해당 포스팅을 참고해 주세요.(참고: https://engineering-skcc.github.io/culture/agileorganiztion/)
팀 공간
스크럼 팀은 같은 장소에 모여서 일하는 것이 좋습니다. 같은 공간에서 함께 일을 하면서 매일 아침의 데일리 스탠드업 뿐아니라 수시로 협의하고 논의하면서 생산성을 높일 수 있기 때문입니다. 만약 지리적인 여건이나 비용, 시간적인 여건으로 인해 팀원들이 같은 장소에서 일 할 수 없을 경우에는 비디오 컨퍼런스나 컨퍼런스 콜, 채팅 공간 등을 적극적으로 활용하여 수시로 커뮤니케이션하는 것을 추천합니다.
팀 규범(Norm) 세우기
또한 스크럼 팀은 자기들만의 업무 ‘규범’을 세우는 것이 좋습니다. 스크럼 역시 프로젝트를 진행하는 하나의 모델로써 다수의 구성원이 팀을 이루어 공통의 업무를 진행하는 과정에 갈등 요소는 언제든지 발생할 수 있습니다. 따라서 사전에 팀원들 간 협의를 거쳐 1) 팀원 간 관계를 돈독히하고 2) 갈등 해소방안을 세우며, 3) 합의를 위한 기준을 마련한다는 의미에서 ‘팀 규범(Team Norm)’을 세우는 것이 좋습니다.
마무리 및 이어나가는 글
지금까지 스크럼이 어떻게 생겨났는지, 그리고 그 것이 의미하는 바는 무엇인지 알아보고, 앞으로 프로젝트 수행을 위해 어떠한 것들을 준비하고 팀을 어떻게 구성해야하는지에 대해 살펴보았습니다. 글을 일으시면서 느끼셨을 지 모르겠습니다만, 스크럼 나아가 Agile 방법론은 ‘어떻게 해야 수행하는 팀원들의 협업을 안정적으로 이끌어 낼 수 있는 지’에 집중하고 있습니다. 그만큼 스크럼과 Agile 방법론은 팀이 협업을 통해 보여줄 수 있는 시너지 효과를 극대화시킬 것을 특히 강조하고 있다해도 과언이 아닙니다. 다음 시리즈 포스팅에서는 이러한 팀의 협업을 충분히 이끌어 내기 위하여 어떻게 프로젝트를 준비 해야 하는 지 자세히 알아보도록 하겠습니다.
그럼 다음 포스팅에서 뵙겠습니다 :)
P.S. 포스팅을 읽으시면서 수정이 필요하거나 보충이 필요하다고 느끼시는 부분이 있다면 아래 댓글로 알려주시기 바랍니다. 여러분의 댓글이 더 나은 그리고 더 풍성한 포스팅의 밑거름이 될 수 있습니다.
관련 글
AGILE Framework - 스크럼(SCRUM) Basics (2) https://engineering-skcc.github.io/culture/scrumbasics2/
AGILE Framework - 스크럼(SCRUM) Basics (3) https://engineering-skcc.github.io/culture/scrumbasics3/