PO는 해당 제품에 대해 관련 있는 여러 사람들을 통해 요구사항 즉 사용자 스토리를 수집한다. 이 여러 사람 안에는 해당 제품을 사용한 End User는 당연히 포함이 되어야 하며, 제품과 연계되어 있는 임원들이나 관련 깊은 부서의 실무 담당자들, 그리고 스크럼 팀을 이루는 팀원들도 포함된다.

필자는 프로젝트 킥오프 시점에 제품과 관련된 모든 사람을 한 곳으로 모아서 워크숍을 수행하였다. 이름이 머였더라.. 'User Story 도출 워크숍' 정도 되었던 것 같다. 과제 수행원 전원과 End User 전원, 각 팀의 팀장 레벨까지 한 자리에 모여서 한 나절 동안 앞으로 만들 제품의 사용자 스토리를 수집하였다. 실은 무척 쉽지 않은 일이었다. End User 들은 대부분 소프트웨어 지식은 거의 없는 분들이었고, 연령층도 높은 편이었다. 하지만 제품을 사용할 사람들을 3가지 정도의 롤로 분리하고 각 롤마다 작은 소그룹을 형성하여 해당 롤의 핵심 유저를 배치하고 소프트웨어 인력들을 한두 명씩 배치하였다. 반나절 동안 텍스트 기반으로 사용자 스토리를 도출하고 오후에는 해당 사용자 스토리를 취합 한 다음, 전원의 투표로 우선순위화를 하였고, Top 3 에 대한 화면 와이어프레임(Wireframe, drawing 기반의 낮은 수준의 화면 프로토타입)을 작성하였다. 여기서 중요한 것은 사용자 스토리는 사용자의 관점에서 작성이 되어야 한다는 것이다. 소프트웨어 개발자들이 사용하는 용어들이 들어가서는 안된다. 가령, '데이터베이스 연결을 위한 최적 드라이버 선정 및 샘플 코드 작성'과 같은 것은 사용자 입장에서는 전혀 이해가 안 되는 사용자 스토리다. 실은 사용자 입장에서는 본인들이 사용하는 제품의 데이터베이스가 무엇인지 전혀 알 필요가 없는 것이다. 대신 이런 식으로 작성이 되어야 한다. '처음 접속한 사용자는 쉽게 사용자 등록 요청을 할 수 있다.'와 같이 말이다. 사용자 스토리를 작성하는 방법에 대해서 기술한 책들도 많다. 관심 있는 분들은 인사이트에서 출간한 번역서, '사용자 스토리' 나 O'reilly에서 출간한 원서, 'User Story Mapping' 등을 참고해보자. User Story Mapping의 내용은 정말 좋다. 아직 번역서는 출간되지 않았지만 한창 번역 중인 걸로 알고 있다.

스프린트 계획 미팅(Sprint Planning Meeting)

제품 백로그가 나왔으면, 해당 스크럼 팀에서 수행할 스프린트 기간에 개발할 백로그를 선정하고, 각 백로그에 들어갈 공수를 산정(Estimation)하는 미팅을 수행한다. 이 미팅은 매번 스프린트가 시작될 때 수행하며, 기간에 따라 소요되는 시간이 조금 유동적일 수 있다. 처음 수행할 때는 시간이 많이 걸린다. 이렇게 해서 나온 백로그의 집합이 바로, 스프린트 백로그이다. 중요한 건 스크럼 팀원 전체가 모여서 함께 계획을 수립한다는 것이다. 그리고 바로 전에 수행한 스프린트의 경험을 바탕으로 학습한 내용이 반영이 되어야 하는 것이 핵심이다. 이 것을 통하여 지난 스프린트에서 백로그의 크기를 잘못 산정하여 지나치게 많은 일을 할당받았거나, (반대인 경우는 거의 없다.) 고객의 요구사항을 잘 못 이해하고 있어서 방향을 틀어야 한다거나, 하다 못해 근무환경이 너무 좋지 않아 개발을 하기 어렵다는 것 따위의 많은 것들이 반영이 되어야 한다. 스프린트 내에서 개발해야 하는 백로그를 추출하고 각 백로그에 대한 크기를 산정하는 작업에 대한 방법은 보통 플래닝 포커(Planning pocker) 게임을 활용한다. 팀원들이 모두 모여서, 스프린트 백로그 중 하나를 선택 한 뒤, 동시에 각자가 생각하는 공수가 적힌 카드를 제출한다. 카드에 적힌 숫자는 보통 추상적인 시간을 의미한다. 시간과 매핑하는 곳도 있고, 일자나 회사에서 일하는 상황에 맞게 설정하게 된다. 필자는 일의 버퍼를 감안한 시간을 사용하고, 3일(24)을 넘지 않게 사용하고 있다. 이렇게 각자 카드를 내고 나면, 의견이 일치하는 경우도 있지만, 굉장히 차이가 벌어지는 경우도 있다. 이는 팀원들의 경험과 내공, 그리고 백로그에 대한 이해도의 차이에 의해서 생기는 괴리다. 이 부분은 그 자리에서 SM이 주도하여 서로의 차이점에 대한 이유를 공유하고, 서로 합의하면서 너무 낮거나 높은 숫자를 조정한다. 이 과정 역시 무척 중요하다. 필자 같은 경우도 프런트엔드 경험이 없는 개발자는 화면을 그리는 시간을 다소 오버 측정하는 반면, 프런트엔드 경험이 많은 사람은 다소 짧게 측정을 하는 경우를 많이 보았다. 결국, 두 숫자의 중간쯤이 항상 의미 있는 숫자임을 나중에 알게 되었고, 서로의 관점과 소견에 대한 이해를 바탕으로 한 팀 전체의 생산성 측정에 큰 도움이 된다. 이렇게 각 백로그에 적힌 숫자를 스크럼에서는 스토리 포인트(Story point)라고 부른다.

한 가지 더 공유하고 싶은 내용이 있다. 일반적으로 스크럼팀은 특정 제품을 개발하는 사람으로 구성이 되어 있고, 한 가지 일에만 집중해야 하는 것이 옳다고 본다. 해서 백로그 측정 시 모수 즉 전체 팀원이 스프린트 내에서 수행할 수 있는 전체 스토리 포인트가 계산이 될 것이다. 가령, 5명의 팀원이 2주 동안 스프린트를 수행하고, 스프린트 포인트는 물리적인 시간과 1:1로 매핑한다고 가정하였을 때, 전체 팀 생산성은 8시간 X 5명 X 10일 = 400 스토리 포인트가 될 것이다. 하지만! 필자의 회사인 경우, 한 사람이 하나의 프로젝트만 할 수 있는 상황이 아니었다. 필자를 비롯한 팀원들이 대부분 다른 일도 병행하고 있었다. 해서 필자는 각 스프린트 계획을 세울 때 각자가 스크럼 프로젝트에 기여할 수 있는 기여도를 % 로 산정하여 모수에 반영하였다. 가령, 전원이 동시에 2가지 일을 병행하고 있고, 스크럼 프로젝트에 50% 정도 일을 할 수 있다고 가정하였을 때, 전체 모수는 200 스토리 포인트가 될 것이고, 자연스럽게 할 수 있는 백로그의 양은 절반으로 줄어드는 개념이다. 그리고 계획을 세울 때 야근이나 휴일 근로까지 계산해서 측정하는 것은 절대 금물이다. 이는 처음부터 팀원들의 고유 시간을 침범하겠다는 의도로 밖에 보이지 않는다. 반드시 이 과정은 팀원들을 쪼는(?) 채찍질의 도구로 사용되서는 안된다. 정확하게 팀원들의 생산성을 판단하고, reasonable 한 양의 일을 좋은 품질을 통해 제공하겠다는 것이 주요 목표이다. 잊지 말자.

스프린트 플래닝 미팅을 통해 전체 팀원들이 할 일이 정해졌다. 한 개의 백로그에 대한 태스크들의 담당자는 미리 정할 수도 있고, 자발적으로 선택하여 그때 그때 할당할 수도 있다. 아직 성숙하지 않은 단계라면 플래닝 시에 담당자까지 정하여 백로그가 적힌 포스트잇 하단에 이름을 적도록 하자. 그리고 담당자 이름 우측에 함께 협의한 스토리 포인트를 적는 것도 잊지 말자.

이렇게 적힌 포스트잇들은 팀원들이 함께 일하는 장소에 가장 잘 보이는 벽에 붙이도록 하자. 필자는 일반적으로 사용하는 TO-DO, In-Progress, Done 이 적힌 큰 보드를 벽에 붙이고, 포스트잇을 활용하여 현황을 추적하고 있다. 이게 어느 정도 익숙해지면 시스템으로 넘어갈 생각이다. 이를 도와주는 시스템은 여러 가지가 있으나, 트렐로(Trello)와 같이 가볍게 사용해도 좋고, 아틀라시안 지라(Atlattian Jira)나 피보탈 트래커(Pivotal Tracker)등과 같은 상용 솔루션도 널리 사용이 되고 있다.

일일 스크럼 미팅(Daily Scrum Meeting)

스프린트가 시작되었으면, 매일 오전에 일일 스크럼 미팅을 수행한다. 약속한 시간에 스크럼 팀원 전원이 모여서 스탠드업으로 수행한다. 이때 PO의 참석은 옵션이다. 스탠드업으로 수행하는 이유는 늘어지지 않게 하기 위함이다. 크게 3가지를 다룬다. 각자 돌아가면서 어제 한일, 오늘 할 일, 이슈 사항에 대해 공유한다. 이슈사항에서는 본인이 해야 할 일이 예상대로 잘 진행이 되지 않는 어떤 것이든 상관없다. 생각보다 너무 어렵다라던지, 양이 너무 방대하다던지, 혼자서는 해결을 못 하겠다와 같은 일적인 것도 있겠지만, 건강상태나 신변 관련된 일도 포함될 수 있다. 가령, 내가 몸이 아프거나 집 계약 때문에 골치 아픈 일에 휘말려 있다고 가정해보자. 제대로 된 코딩을 할 수 있을까? 우리는 사람이다. 소프트웨어는 단순 노동이 아닌 지식 집약적 작품을 만들어내는 예술과도 같은 작업이다. (적어도 필자는 그렇게 생각한다.) 이런 작품을 만들어내는 데 정신이 혼미한 상태에서는 제대로 된 작품을 만들 수 없을 것이다. 해서 필자는 항상 일일 스크럼 미팅의 본인 차례가 왔을 때 체크인(Check-in)을 먼저 한다. 체크인은 마치 일을 시작하기 위하여 문을 여는 것과 같은 개념이다. 보통 본인의 컨디션을 짧게 얘기한다. 말하기 싫은 사람도 있을 것이다. 이런 경우에는 'Pass~'를 외치고 넘어 갈 수도 있다. 최소한 이런 경우에는 해당 인력에게 심적으로 부담감이 있다는 것을 감지할 수 있을 것이고, 다른 구성원들이 조금이라도 관심을 가지게 될 수 있다. 'Pass~'를 외친 구성원은 그날 말 한마디 안 하려고 마음먹었지만, 본인의 목소리를 팀원에게 들려준 것만으로도 서로에게 도움이 된다. SM은 일일 스크럼 미팅을 주관하고 도출된 이슈나 리스크들을 어떤 방식으로든 해결해줘야 한다. 일일 스크럼 미팅은 무척 중요하긴 하지만, 너무 목 메일 필요는 없다. 가령, 특정 인원이 출근을 하지 못 하는 상황이라던지, 해당 시간에 부재라고 한다면 시간을 유연하게 옮길 수도 있고, skip 하는 경우도 있을 수 있다. 가급적이면 정해진 시간에 수행하고, 불가피한 상황에는 유두리 있게 수행해야 할 필요도 있다. 그리고 너무 길어지면 안 된다. 얘기를 하다 보면 길게 얘기하거나 세미나 형태로 어떤 정보를 공유하는 것도 보일 것이다. 이럴 때는 SM이 적어 놓았다가 미팅이 끝나고 진행이 될 수 있도록 유도해야 한다. 그리고, 미팅 중에 나온 이슈나 리스크는 작업 현황 판에 빨간색 포스트잇처럼 튀는 색의 포스트잇에 적은 다음, 현재 진행을 방해하고 있는 백로그에 위에 붙이도록 하자. 이 빨간색 포스트잇을 떼기 전까지는 해당 백로그는 다음 단계로 넘어가지 못 한다.

소멸 차트 (Burn-down Chart)

스크럼에서 작업 현황을 추적하기 위해서 일반적으로 사용하는 차트가 바로 소멸 차트(Burn-down Chart)가 있다. 이는 스프린트 수행 시 초기에 세운 계획대로 잘 흘러가고 있는 지 쉽게 확인할 수 있다. 위키피디아에 있는 그림을 함께 살펴보자.

소멸 차트 (출처 : https://en.wikipedia.org/wiki/Burn_down_chart)

파란 선이 처음에 계획했던 스프린트의 스토리 포인트들의 합이 이상적으로 줄어드는 것을 말한다. 이상적인 모습이나 보통 일이 저리 계획대로 되진 않는다. 빨간 선이 실제 스토리 포인트가 소멸되고 있는 모습을 보여주고 있다. 백로그가 Done 상태로 넘어가면 숫자가 점점 줄어드는 개념이다. 초반에 7일 정도는 빨간색 선이 파란 선 보다 위쪽에 위치하고 있다. 계획보다 조금 늦어지고 있다는 뜻이다. 일일 스크럼 미팅 시에 해당 그래프를 팀원들과 함께 확인하고, SM은 일이 늦어지는 이유를 찾아내서 이슈를 해결해줘야 한다. 7일째가 넘어가니 계획보다 오히려 빠르게 일이 진행되고 있는 것을 볼 수 있다. 15일쯤 되니 다시 속도가 더뎌졌지만 마지막 날에는 원하는 스토리 포인트를 모두 소멸시킨 것을 확인할 수 있다.

여기서도 주의할 것이 있다. 물론, 정해진 계획대로 일을 수행하는 것이 중요하지만, 그렇지 않을 경우 비난을 하기 위한 척도로 사용되서는 절대 안된다. 예상대로 소멸이 다 되지 않은 경우는 여러 가지가 있지만 보통 팀원이 일을 열심히 하지 않아서 못 하는 경우는 거의 없다. 초반에 계획 수립시 스토리 포인트 산정을 잘 못 했을 수도 있고, 처음에는 예상하지 못 했으나 다른 일로 인해 방해를 받았을 수도 있다. 아니면 해당 인원이 아이를 출산하여 출산휴가를 갔거나, 경조사로 인하여 자리를 비웠을 수도 있다. 극단적으로는 개인적인 상황이나 주변 환경 때문에 일을 집중하지 못 할 가능성도 존재한다. 절대 채찍질의 도구로 활용해서는 안된다.

스프린트 리뷰(Sprint Review)

스프린트가 종료하는 시점에 팀원 전체가 모여서 각자가 한 일을 리뷰한다. 필자는 중요한 소스 코드 리뷰까지 이때 진행한다. 중요한 건 모두가 한 일을 모두를 대상으로 자세하게 공유해야 한다는 것이다. 생각보다 우리 사회는 본인들이 한 일을 공유하지 않는 것이 관습화 되어 있다. 오히려 부끄러워하거나, 부정적으로 보기도 한다. 하지만 이때 굉장히 많은 아이디어와 각자 작업에 대한 이해 및 존경(?)이 생기게 마련이다. 필자의 경우, 소프트웨어 개발에 대한 지식이 없는 팀원으로부터 굉장히 많은 화면 개선 사항을 받을 수가 있었다. 오히려 어떤 과정으로 개발이 되는지 모를수록 다양한 의견을 개진하기가 더 쉬울 수도 있다. (얼마나 고통스러운지 알면 미안해서 말도 안 한다.ㅡㅡ) 이 시간에는 상대방이 한 일에 대해 냉소적으로 트집을 잡거나 하는 행위를 하면 안 된다. 말 그대로 팀이 만든 산출물을 모두 함께 모여서 살펴보는 행위이다.

스프린트 회고(Sprint Retrospective)

스프린트에서 만들어낸 산출물을 살펴보는 것이 리뷰라 하면, 스프린트 회고는 스프린트 기간 동안에 팀 내부에서 발생한 여러 가지 일들을 되돌아보고 잘한 것, 개선할 것, 새로 시작할 것을 도출해내는 과정이다. 필자는 이 것이 스프린트의 하이라이트라고 생각한다. 팀 워크를 극대화할 수 있는 중요한 태스크이다. 이때, 본인은 생각지도 못한 작은 행위로 인하여 상대방이 상처를 받거나 오해를 불러 일으키는 경우도 찾아낼 수 있고, 반대로 작은 행위가 누군가에게는 큰 도움이 되어 감사를 받게도 된다. 그리고 다음 스프린트에서 새로 시작할 것들을 도출함으로써, 한 단계 발전된 팀으로 다음 스프린트를 수행할 준비를 하게 된다. 이 또한, 일에 관련된 내용만 있는 것이 아니다. 본인이 체력 증가를 하기 위해 운동을 시작해보겠다라던가, 정신 집중을 하기 위해 술을 줄이겠다(?)는 의견, 관심 있는 책을 읽어 보겠다와 같은 것들도 상관없다. 필자와 같은 경우에는 필자가 아무런 악의 없이 뱉어내는 언어들이 다소 공격적이다라는 피드백을 받은 적이 있다. 실은 많이 당황했었다. 무덤덤하게 모르는 것을 질문하듯이 뱉어내는 말들이 듣는 사람에게는 상처가 될 수도 있었던 것이다. 필자는 팀에게 사과를 했고, 지금도 쓸데없이 그런 행위로 인하여 특정 팀원의 사기를 떨어뜨리는 일은 피하려고 하고 있다. 당연히, 그래야 한다고 생각한다.

회고는 팀원들이 평소에는 쉽게 하지 못 하는 이야기들을 끄집어내야 하는 과정이기 때문에 SM의 역할이 무척 중요하다. 자칫하면 팀원들의 감정이 폭발할 수도 있다. 이럴 때 적절하게 상황을 제어할 수 있는 능력이 필요하다. 그리고, 회고를 위한 다양한 기법들이 존재하는데, 이 기법들은 실은 Facilitator 들을 양성하는 과정에서 많이들 사용하는 기법들을 다루고 있다. 인사이트에서 출간한 번역서인 '애자일 회고'를 추천한다. 필자는 스크럼 팀의 회고뿐만이 아니라 반기에 수행하는 소속 센터의 반기 회고에도 해당 기법을 활용하고 있다. 예전에는 신입사원들의 스터디 진행에도 활용했었다. 스크럼뿐만이 아니라 회사에서 수행되는 다양한 미팅이나 워크숍에서도 활용할 수 있으니, 참고하기 바란다.

스크럼에 대해서 모든 것을 상세히 다루지는 않았지만, 실제로 적용하기 위해서 필요한 대부분의 지식들은 언급이 된 것으로 보인다. 혹시 더 추가할 것이 있다면, 필자에게 댓글로 알려주면 반영하도록 하겠다.

스크럼에 대해서 조금 더 깊이 사례 기반으로 공부를 하고 싶다면 아래 링크를 참고해보자. 위에서 설명한 주요 프로세스들을 만화와 함께 재미있게 보여주고 있다. 각 역할들의 대응 방식도 눈여겨보자.

http://scrumtrainingseries.com/

Scrum Training Series: Free Scrum Master Training

There is no Scrum methodology, no Agile methodology. Online tutorials teach the Scrum framework, Ag

scrumtrainingseries.com

그리고 필자는 개인적으로 PO 역할이 굉장히 중요하다고 생각하고 있지만, 실제로 애자일 적용 사례들을 보면 PO의 역할을 제대로 수행하고 있는 스크럼 팀을 찾기가 쉽지 않다. 특히 고객이 수행하는 것이 좋지만, 현실적으로 불가능한 경우가 많다. 아래 링크는 PO 관점에서 스크럼을 이해할 수 있는 동영상이다. PO 뿐만이 아니라 스크럼 전체가 어떻게 흘러가야 하는지 집약적으로 보여준 동영상이니 꼭 한번 보기 바란다.

https://youtu.be/502ILHjX9EE

Agile Product Ownership in a Nutshell

전 글에서도 언급하였지만, 애자일은 프로세스들을 모은 일종의 도구이다. 애자일의 사상을 잘 따를 수 있게 하는 절차들을 모아 놓은 것 중 하나가 바로 스크럼이다. 하지만 이는 팀원들을 쪼는 채찍질로 활용이 되어서는 안된다. 관리자 입장에서는 지금 무엇을 개발하고 얼마나 걸릴 것이고 언제까지 끝날 것인지 알아야 한다. 하지만, 그 어떤 방식으로도 변덕이 심한 고객의 요구사항 변경과 다양한 리스크로 인한 변화를 예상할 수 있는 방법은 이 세상에 존재하지 않는다. 현재 가지고 있는 다소 추상적이고 모호한 수준의 End-image로 들어갈 리소스를 산정한 다음 팀을 꾸리면, 해당 목표에 도달하기 위해 팀원들과 함께 추상적이고 모호한 수준의 End-image를 점점 구체적인 소프트웨어로 만들어가면서 고객도 만족하고, 팀원들도 행복하게 일을 할 수 있게 한다면 그것만큼 좋은 것은 없을 것이다.

스크럼은 장점도 많지만, 실은 단점도 많다. 하지만 처음 애자일을 접하는 조직이라면, 하나하나씩 따라 하다 보면 자연스럽게 애자일에 익숙해질 수 있을 것이며, 어느 정도 성숙도가 올라가면 다양한 형태로 커스터마이징 할 수도 있다. 아니면 스크럼이 아닌 다른 도구들을 택할 수도 있을 것이다. 필자는 다음번 애자일 관련 글은 XP(eXtreme Programming)을 주제로 다뤄 볼까 한다. 이는 프로세스보다는 일하는 문화(지속적 배포, 짝 프로그래밍, 테스트 주도 개발 등)에 관련된 내용이 주이니, 재미있을 것이다.

마지막으로 애자일을 처음 적용하는 분들께 한 가지 당부하고 싶은 것이 있다. 아무리 좋은 음식도 급하게 먹으면 체한다. 모든 것을 한꺼번에 적용하려고 하지 말자. '이거 안 하면 스크럼이 아니고 애자일이 아니에요.'라는 것은 말도 안 된다고 생각한다. 천천히 하나하나씩 팀에 필요한 것을 적용해 보도록 하자. 애자일, 스크럼이라는 용어도 사용하지 말자. 필자가 제일 처음 쓴 기법은 '회고'였다. 그것도 6개월에 한번, 20명이 되는 인원들에게 반나절 워크숍 때 활용했었다. 스크럼 없이 '일일 미팅'만 하는 것도 좋다. 10분~15분 내에 일일 미팅을 통해 각 구성원들의 컨디션이나 기분을 확인해 보고, 일이 잘 진행되고 있는 지 공유해보자. 리스크가 있다면 두 팔 걷고 해결해주자. 이런 식의 점진적인 방식이 시간이 오래 걸릴 수는 있겠지만 효과적으로 애자일에 물들어 갈 수 있는 방법이 될 수 있다. 윗사람과의 align은 덤이다.

그럼 오늘도 더 좋은 소프트웨어 개발 문화 만들기에 한 발자국 나아갔기를 바란다.

Reference :

https://en.wikipedia.org/wiki/Scrum_(software_development)

https://www.brandwatch.com/2014/01/why-agile-and-scrum-is-good-for-your-business/

http://www.agileforall.com/intro-to-agile/

keyword