SW정보 이동 SW칼럼 이동

[전문가 칼럼]도대체 애자일이 뭐지? - 스크럼 편

SW중심사회 2017-11-20 6817명 읽음

 

'스크럼'이라는 용어를 들어 본 적이 있나? 애자일을 접한 사람이라면 한 번쯤은 들어 봤을 수 있다.
스크럼(Scrum)은 럭비에서 유래된 용어이다. 공수가 불분명할 때, 팀원들이 어깨동무를 하고 상대편과 원을 이루고 어깨를 맞닿은 상태에서 중앙에 럭비공을 놓아서 경쟁하는 것을 말한다. 아마도 팀원들과 협업하여 소프트웨어를 개발하는 모습이 럭비의 스크럼과 모양새가 비슷(?) 한  듯하여 지어진 이름이 아닐까 싶다.

 

 

스크럼은 애자일의 여러 가지 실천 도구 중 하나이다. 이 또한 하나의 방법론이다. 간혹 애자일에 의해서 스크럼이  도출된 것으로  생각할 수 있는데, 스크럼이나 칸반, XP(eXtreme Programming), 린 SW 개발 등은 애자일이라는 용어가 나오기  전부터 여러 형태로 이미 존재하는 녀석들이었다. 다만, 2001년 애자일 선언문이  발표되면서 이러한 방법들을 통칭하는 용어인 애자일이 등장하였고, 이러한 개발 방법론들이 자연스릅게 애자일 범주안에 들어온 것이다. 여하튼 이런 방식들은 기존에 사용하던 폭포수 방식의 개발과는 사뭇 다른 형태를 띄우고 있다는 공통점이 있다.  그중에서도 스크럼은 애자일을 접하지 않는 사람들도 쉽게 애자일을  실천할 수 있는 정형화된 프로세스(절차, 일하는 방식)를 제공해주고 있다. 그럼 이러한 프로세스들을 하나씩  살펴보도록 하자.

 

 

위 그림은 스크럼의 전체 프로세스를 도식화 한 그림이다. (출처 : http://www.agileforall.com/intro-to-agile/)  하나하나씩  살펴보자.

 

Product Owner(PO)
제품 책임자, 제품에 대한 요구사항 즉 백로그(Backlog)를 작성하는 주체다. 팀이 개발할 소프트웨어에 대한 모든 요구사항에 대한 오너쉽을 가진다. 또한 백로그가 준비가 되었으면, 어떤 백로그부터 개발을 해야 할지 우선순위를 정하는 유일한 사람이다. PO는 팀에 소속되어 있지만, 팀 밖에 있는 여러  이해관계 당사자들(Stakeholders, 고객, 사용자 등)과의 대화를 하는 유일한 사람이 되어야 하며, 팀에 들어오는 외압(?)을  컨트롤할 수 있는 유일한 사람이 되어야 한다. (외압의 예: 갑자기 지나가던 임원 왈,  '이것부터 해야 되는 거 아니야?', '이게 더 중요하지.' 하는 것 따위.. 아무것도 아닐 수 있지만 팀의 생산성과 사기를 떨어뜨리는 주범임..) 보통 이 역할은 소프트웨어 개발 영역에 있는 사람보다는 제품을 사용할 고객이 직접 하거나 비즈니스 요구사항을 정의할 수 있는 사람이 좋다. 소프트웨어 개발 역량은 없어도 된다. 필자 역시 현재 개발하고 있는 제품의 내부 고객에게 해당 역할을 위임한 상태이다.

 

Scrum Master(SM)
스크럼 마스터, 스크럼 팀의 스크럼이 잘  수행될 수 있도록 도와주는 역할이다. 간혹, 스크럼 마스터가 과제 리더와 같이 모든 의사결정을 내리는 주체라고  생각할 수 있는데, 그렇지 않다. 스크럼 마스터는 최대한 객관적인 시각에서 스크럼에 정해진 원칙들이 팀에 잘  적용될 수 있도록 도와주고, 문제가 생겼을 때 해결하는 역할을 한다. 여기서 말하는 문제란, 팀 구성원 간의 오해나 이해의 부족으로 인해 생기는 여러 가지 분쟁이나, 하는 일에 대한 우선순위 선정, 일이 끝났을 때 정말로 일이 잘 끝났는 지 내려진 정의를  확인해 보고 투명하게 의사결정을 할 수 있게 가이드하는 역할을 한다. SM은 스크럼을 잘 아는 사람이 하는 것도 좋지만, 스크럼 팀마다 가지고 있는 성향이나 개성, 일하는 방식이 모두 다르기 때문에 해당 팀에서 애자일, 스크럼 적용에 열려있고 스스로 현재 작업 문화를 개선하고자 하는 의지가 강하다면, 누구나 돼도  상관없겠다. (물론, 하기 싫은 사람 시키면 잘 될 리 없다.)

 

Team Member
팀 구성원, 위 두 역할을 제외한 모든 팀원들을 말한다. 일반적으로 스크럼 팀은 Cross-functional 한 롤을 가진 사람들로 이루어져야 한다. 여기서 말하는  Cross-functional이라 함은 제품이 만들어지기 위해서 필요한 모든 인력,  개발자뿐만이 아니라 디자이너와 테스터, 제품을 만들기 위해 참여하는 모든 사람들을 뜻한다. 필자가 본 해외의 한 스크럼팀은 기획자나 예산을 담당하거나 결정할 수 있는 사람도 포함되어 있는 경우를 보았으나, 이는 조금 오버인  듯하다. 제품 개발에 참여하는 모든 사람을  집어넣는 것이 좋겠다. 실은, 이렇게 팀을 구성하는 것도 쉬운 일은 아니다. 필자는 필자가 프로젝트 리더로 있는 프로젝트의 소프트웨어 개발에 참여하는 자사 엔지니어와 협력 업체 엔지니어 전원이 스크럼 팀원에 들어와 있고, 비즈니스 영역의 인력 중 제품의 오너쉽이 있는 부서를 제외한 타 부서들은 제품에 대한 영향력이 많지 않아 팀 안에  배치하지 않았다. 또한, 이런 인력들은 물리적으로 떨어져 있기 때문에 함께 스크럼 팀을 이끌어가기에는 제약 사항이 많다. 꼭 필요한 PO를 제외하고는 스크럼을 함께 하지 않고, 월간으로 진척 현황 리뷰 및 이슈가 있을  때마다 협의하고 있다.

 

이렇게 구성된 스크럼팀의 크기는 제각각 일 수 있으나, 일반적으로 2개의 피자를 한 끼 식사에 먹을 수 있는 인원(Two-pizza team)인 7~8명을 넘지 않는 것이 좋다. 그리고 필자 생각에는 아무리 인원이 적어도 3명 이상이라면 스크럼을 하는 것이 좋다고 본다. (2명은 스크럼을 짜기엔 적은 인원이다) 필자의 현재 스크럼팀은 현재 PO 1명, SM 1명, 팀원 3명이며, 2~3 명 정도의 개발자가  추가될 예정이다.

 

스크럼에는 이렇게 3가지 롤만이 존재한다. 우리가 흔히들 아는 프로젝트 매니저(PM)나 프로젝트 리더(PL)는 존재하지 않는다. 실은 여기서도 기존의 조직과의 괴리가 느껴지는 곳이기도 하다. 필자는 현재 회사에서 수행하는 작은 프로젝트의 리더이다. 처음 스크럼을  시작하였을 때는 모두 스크럼이 낯설었고, 그나마 경험해본 사람이 필자 밖에 없었기 때문에 PO 및  SM을 프로젝트 리더인 필자가 수행하였으나, 실은 두 역할 모두 스크럼이 아닌 일반적인 프로젝트의 리더가 수행하는 그것과는 차이가 많다. 특히, 함께 하면 문제가 많다.

 

일단, 프로젝트 매니저나 리더는 과제의 일정을 수립하고 예산에 대한 결정을 내리고 이슈나 리스크가 있으면 핸들링을 하는 다소 '강압적인 존재'이다. 책임도 많고 의사 결정해야 할 사항들도 많다. 팀원들의 의견을 듣는 건 실은 옵션이다. 굳이 들을 필요 없이 혼자서 독단적으로 결정해도  상관없고, 실은 일부 팀원들은 본인의 의견을  내세우기보다는 위에서 빨리 결정해서 하향식(Top-down)으로 일을 수행하는 것을 편하게 생각하는 사람도 있다.

 

PO는 제품에 대한 오너쉽을 가지는 사람이다. 일정이나 리스크/이슈 등에도 관심이 있어야 하겠지만, 가장 중요한 것은 지금 만들어지는 제품이 어떤 순서로 개발이 되어야 하는지 결정을 내리는 것이 가장 중요한 역할이다. 그럼 SM은 어떨까? SM은 항상 팀원들의 목소리에 귀를 기울여야 하는 사람이다. 이들이 어떤 문제나 이슈를 만났을 때 해결을 하는 주체가 되어야 한다. 한 가지 예를 들어 보겠다. PO가 화면을 리뷰하다가 이 것 만큼은 당장  고쳐야겠다는 의견을 주었다고 해보자. SM는 해당 의견에 대해 팀원들과 이야기를 할 것이다. 팀원들은 이 의견에 대해 크게 두 가지 반응을 보일 것이다. 지금 하는 일에 집중하는 것이 좋을지, 아니면 바로 PO의 의견을  받아들일지다. 어떤 것이 좋을지는 전체 팀원이 함께 정한다. 무슨 결정을 하더라도 잘못된 결정은 없다. 제품의 기능이 딜리버리 되는 시점만 다를 것이다. 만약, 팀원들이 지금 당장은 할 수 없고 현재 정해진 일에 집중해야 한다고 한다면, SM은 그 사실을 다시  PO에게 전달하여 서로 이해할 수 있는 환경을 만들어줘야 한다. PO 역시 제품의 오너쉽을 가지고 있지만, 팀 외부에 많은  이해관계 당사자들의 피드백을  필터링하는 역할을 하고 있다. 만약, 해당 건이 정말 급한 건이라면, 팀의 개발 우선순위를 바꾸되, 해당 기간에 개발하기로 한 건은 뒤로 미루는 등의 타협이 필요할 것이다.

 

이렇듯, PO와 SM의 역할은 큰 차이가 있으며 스크럼 내에서 해야 할 일이 다르다. 상호 보완적인 존재라고나 할까. 그리고 일반적은 프로젝트의 리더와도 괴리가 있다. 해서 필자는 처음 스크럼 도입시 PO와 SM을 함께 수행하였으나, 6개월이 지난 지금, PO는 내부고객에 할 수 있도록 하였고, SM은 팀원 중 한 명이 할 수 있게 하였다. 필자는 회사에서는 프로젝트 리더이지만 스크럼 팀에서는 팀원으로 역할을 조정하여 진행해 보고 있다. 필자에게는 다소 답답한 마음도 없지 않아 있지만, 팀원들 입장에서 보았을 때는 본인들의 의사결정 사항에 따라 스스로 할 일들을 선택하고 일이 진행이 되니, 오히려 더 생동감 있고 동기부여 측면에서도 더 좋은 영향을 미치고 있는 것으로 보인다. 그리고 필자에게는 다른 일에 더  집중할 수 있는 여유(?)가 생겼다. (여기서 말하는 다른 일은 프로젝트 수행을 하기 위해 필요한 스크럼 이외의 미팅들이나 보고서 준비, 보고 등 개발자들이 일반적으로  선호하지 않는 일들을 말한다.)

 

 

주요 용어

자, 이제 주요 프로세스들을 살펴보기 전에 위에서 스크럼에서 사용하는 용어들을 살펴보자.

 

백로그(Backlog)
요구사항 리스트, 제품의 개발 대상  목록쯤으로 이해하자. 애자일에서는 요구사항을 User  Story라고 부른다.

 

스프린트(Sprint)
애자일은 짧은 기간 동안에 동작하는 SW를 사용자에게 제공하면서 피드백을 받아서 고쳐 나간다고 하였다. 이 '짧은 기간'을 일반적으로 이터레이션(Iteration)이라고 하며, 스크럼에서는 스프린트(Sprint)라고 한다. 보통 1주~4주의 기간을 상황과 조직에 맞게 선정한다.

 

제품 백로그(Product Backlog)
전체 기간 동안 개발할 백로그를 제품 백로그라고 한다.

 

스프린트 백로그(Sprint Backlog)
1개 스프린트에서 개발할 백로그들을 스프린트 백로그라고 한다.

 

나머지 용어들은 프로세스 설명에 포함되어 있으니 넘어가도록 하겠다.

 

※전문가 칼럼의 내용은 SW중심사회의 편집 방향과 다를 수 있음을 밝힙니다

홈페이지 만족도

콘텐츠 내용에 만족하십니까? 현재 페이지의 만족도를 평가해 주십시요. 의견을 수렴하여 빠른 시일 내에 반영하겠습니다.

등록