by
Jan 31. 2016
애자일을 어떻게 실천하나요? - 스크럼편 (1/2)
더 나은 SW 개발 문화를 위한 이야기
본 글은 애자일 관련한 두 번째 글이며, 애자일의 개념에 대해 생소하다면 앞서 기고한 아래 링크의 글을 먼저 읽어 보기 바란다.
https://brunch.co.kr/@insuk/5
필자는 앞서 애자일에 대한 개념을 출판 과정과 빗대어 설명하였다. 필자의 의도대로 작성이 되었다면, 애자일에 대한 개념을 조금이나마 이해가 되지 않았을까 싶다. 하지만 모든 기술들이 그러하듯이, 실천 방식이나 실 적용 사례를 접하기 전에는 개념을 온전히 이해하기에는 쉽지 않다. 그리고 앞 글의 댓글에서도 애자일의 실천 방식에 대한 질문들이 나온 것을 보았을 때, 실천 방식에 대해서도 많은 분들이 궁금해할 것이라는 생각이 들었다.
실은 앞 글을 작성한 뒤 주위의 지인분들을 통해 여러 피드백을 받았었다. 경력이 없거나 짧은 주니어 분들에게는 도움이 되겠다는 의견이 많았으나, 또 한편으로는 필자의 의도와는 상관없이 오해할 소지들도 분명 있지 않나라는 피드백도 있었다. 실은 글이라는 것이 필자의 의도대로 읽히는 것도 쉽지 않은 듯하다. 특히, 애자일과 같이 '방법론'과 같은 이야기를 할 때는 더욱 그러하다. 아래 내용은 가능한 한 객관적인 지식 정보 전달 형태로 기술 한 다음, 필자의 실 적용사례(경험담)를 바탕으로 필자의 개인적인 생각을 기록하는 형태로 진행해 보겠다. 분명, 견해의 차이는 있을 수 있다. 필자와 나누고자 하는 이야기가 있다면 긍정적이든 부정적이든 상관없이 댓글에 남겨주면, 감사한 마음으로 함께 이야기하고 본 글에도 반영하였으면 한다. 주저하지 말고 꼭 댓글을 달아주기 바란다.
그럼 애자일 하면 가장 흔하게 접하는 도구인 '스크럼'에 대해서 이야기해 보자.
'스크럼'이라는 용어를 들어 본 적이 있나? 애자일을 접한 사람이라면 한 번쯤은 들어 봤을 수 있다.
스크럼(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은 팀원 중 한 명이 할 수 있게 하였다. 필자는 회사에서는 프로젝트 리더이지만 스크럼 팀에서는 팀원으로 역할을 조정하여 진행해 보고 있다. 필자에게는 다소 답답한 마음도 없지 않아 있지만, 팀원들 입장에서 보았을 때는 본인들의 의사결정 사항에 따라 스스로 할 일들을 선택하고 일이 진행이 되니, 오히려 더 생동감 있고 동기부여 측면에서도 더 좋은 영향을 미치고 있는 것으로 보인다. 그리고 필자에게는 다른 일에 더 집중할 수 있는 여유(?)가 생겼다. (여기서 말하는 다른 일은 프로젝트 수행을 하기 위해 필요한 스크럼 이외의 미팅들이나 보고서 준비, 보고 등 개발자들이 일반적으로 선호하지 않는 일들을 말한다. ㅜ.ㅜ)
주요 용어
