brunch

매거진 PM이 되고싶어요

라이킷 11 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 개복치 Oct 18. 2022

스프린트 실행 과정에서 PO의 역할은 무엇일까?

≪스크럼 가이드≫를 요약해보자

이번 포스팅에서는 ≪스크럼 가이드≫, Ken Schwaber & Jeff Sutherland 저 를 읽고 스크럼과 스프린트 실행 주기, 스프린트 실행 과정에서의 PM의 역할에 대해 간단히 요약해 보고자 합니다. 스크럼 가이드의 주요 내용을 요약하기 전에, 애자일과 스크럼에 대해 알아봅시다.

1. 애자일(Agile)과 스크럼(Scrum)

애자일(Agile)이란 무엇일까요? Agile 이라는 단어는 '민첩한'이라는 뜻을 가지고 있습니다. 단어의 뜻과 같이 애자일이란 소프트웨어 개발 방법론이자 철학 중 하나로, 개략적으로 요약해 본다면 요구사항이 끊임없이 변화하는 것을 전제로 두어 변화하는 상황에 맞추어 민첩하게 대응하는 프로덕트 개발 문화를 뜻한다고 볼 수 있습니다. 애자일은 반드시 지켜야 하는 절차가 있는 프레임워크라기보다, '변화에 대응하기 위해 유연하고 빠르게 일을 진행하자'라는 문화 내지 철학에 가깝습니다. 빠른 실행과 피드백으로 점진적으로 프로덕트를 발전시켜나가는 것이 애자일의 목표이기 때문에, 문서 커뮤니케이션보다는 대면 커뮤니케이션, 완벽한 프로덕트보다는 MVP를 선호합니다. 한 마디로, "빠르고 유연하게 일하자"는 것이기 때문에, 애자일의 핵심은 협력과 피드백이라 볼 수 있습니다.

이런 애자일 문화를 구체적으로 실행하기 위한 프레임워크와 방법론들이 있습니다. 대표적인 프레임워크(혹은 방법론)는 아래와 같습니다.

스크럼(Scrum)

칸반(KanBan)

XP(eXtream Progrmming)

LSD(Lean SW Development)

이 글에서는 많은 방법론 중 스크럼에 대해 다뤄보고자 합니다. 스크럼(Scrum)이란, 애자일 개발을 위한 프레임워크 중 하나로 '스프린트'라는 개발 주기를 가진다는 특징이 있습니다. '스프린트'라는 단어의 뜻에서 짐작할 수 있듯, 단거리를 전력질주하는 방식입니다. 즉, 스프린트는 최소 1주에서 최대 1달 가량의 짧은 프로덕트 개발 주기를 뜻하며, 스크럼 팀은 스프린트 주기동안 처리해야 할 백로그를 집중적으로 처리한 다음, 피드백을 거치고, 다음 스프린트를 계획하게 됩니다. 스크럼의 핵심 요소는 아래와 같습니다.

투명성 : 업무의 프로세스는 가시적이어야 한다

점검 : 잠재적인 문제를 발견하기 위해 스크럼 산출물과 목표에 대한 진척사항을 점검해야 한다. 점검 내용을 바탕으로 환경을 조정하고, 환경에 적응해야 한다.

적응 : 프로세스와 프로세스의 결과물에서 문제를 발견한 경우, 진행하고 있는 프로세스를 반드시, 빠르게 조정해야 한다.

이제 스크럼 팀과 스프린트 진행 과정, 그리고 PM의 역할에 대해 하나씩 살펴보도록 하겠습니다.

2. 스크럼 팀이란?

스크럼 팀은 스크럼 조직의 기본 단위입니다. 일반적으로 스크럼 팀은 한 명의 스크럼 마스터와 PO(Product Owner), 개발자들로 구성됩니다. 하나의 스크럼 팀은 하나의 프로덕트 목표에 집중합니다. 일반적으로 스크럼 팀은 자율관리팀이며, 매 스프린트마다 프로덕트에 가치를 더하는 데 필요한 모든 기술을 가지고 있습니다. 스크럼 팀은 민첩하게 움직일 수 있도록 규모가 작아야 하지만, 동시에 프로덕트에 가치를 더하기 위해, 즉 한 스프린트(기간) 내에 의미 있는 결과물을 도출할 수 있을 정도의 규모여야 합니다. 스크럼 팀은 이해관계자와의 협력, 검증, 유지보수, 운영, 실험, 연구개발 등 프로덕트와 관련한 모든 활동에 책임을 집니다. 이제 스크럼 팀을 구성하는 각각의 역할에 대해 조금 더 자세히 알아봅시다.

1) 개발자들

스크럼 팀의 개발자들은 매 스프린트마다 프로덕트에 증가분(새로운 가치를 더하는 결과물)을 더하기 위해 개발을 진행하는 사람들입니다. 개발자들의 책임과 역할은 아래와 같습니다.

스프린트 동안의 개발 계획(스프린트 백로그) 작성

프로덕트의 품질을 높이는 것( +QA)

스프린트 목표를 달성하기 위해 계획을 매일 조정하는 것

개발 전문가로서 책임을 지는 것

2) 프로덕트 오너(PO)

프로덕트 오너(PO)는 스크럼 팀의 결과물인 '프로덕트의 가치'를 극대화하는 책임을 지는 사람입니다. 조직의 구성과 스크럼 팀의 크기 등 환경에 따라 PO의 역할이 조금씩 달라질 수 있습니다. 프로덕트 오너는 아래와 같은 사항을 고려해 프로덕트 백로그를 효율적으로 관리하는 책임을 집니다.

프로덕트 목표를 세우고 명확하게 소통

프로덕트 백로그 생성하고 공유

프로덕트 백로그에 우선순위 부여, 정렬

프로덕트 백로그를 반드시 투명하고, 가시적이며 이해가 잘 되도록 만들어야 함

3) 스크럼 마스터

스크럼 마스터는 스크럼 가이드대로 스크럼을 확립하는 것을 책임지는 사람이며, 스크럼 팀 구성원 모두가 스크럼 이론과 실천법을 이해하도록 도와야 합니다. 스크럼 마스터의 역할은 아래와 같습니다.

팀원들이 자율적으로 일정을 관리하고, 교차기능적인 팀이 되도록 코칭하는 것

스크럼 팀이 높은 가치를 갖는 증가분(결과물)을 만드는데 집중할 수 있도록 돕는 것

스크럼 팀의 작업 진행에 방해가 되는 장애물을 제거

모든 스크럼 이벤트들이 생산적으로 이루어지며, 정해진 스프린트 안에 작업이 완료될 수 있도록 돕는 것

얼핏 스크럼 마스터와 프로덕트 오너의 역할에 대해 혼란스러울 수 있는데요, 프로덕트 오너가 제품의 목표를 정의하고 백로그의 우선순위를 정하는 역할이라면, 스크럼 마스터는 프로덕트 오너를 돕기 위해 목표 정의와 백로그 관리를 위한 기술을 찾는 것을 돕거나, 팀원들이 간결한 백로그의 필요성을 이해하도록 돕는 등 스크럼 팀이 '스크럼 가이드'를 따라 일할 수 있도록, 팀원들과 이해관계자들이 '스크럼'이라는 방법의 필요성을 깨닫고 체화시킬 수 있도록 돕는 역할입니다.

3. 스프린트 진행 과정과 PM의 역할

지금까지 애자일, 스크럼, 스프린트가 무엇인지, 또 스크럼 조직을 구성하는 최소단위인 스크럼 팀과 구성원에 대해 알아보았습니다. 스프린트가 단위 기간이라고 했으니, 스크럼 팀이 일하는 과정은 곧 스프린트가 진행돠는 과정이라 볼 수 있겠죠. 이제 스프린트가 어떻게 진행되는지, 그 과정에서 PM은 어떤 역할을 해야 하는지 알아봅시다.

스프린트는 일반적으로 아래와 같은 절차대로 진행됩니다.

먼저 스프린트 진행 과정에 대해 간략하게 알아보도록 하겠습니다. 스크럼의 비전이란, 3년에서 5년 단위의 목표를 뜻합니다. '비전'이라는 말에서 알 수 있듯이, 당장 생각하기에는 조금 불가능 할 것 같다 싶은 목표이지만 프로덕트의 방향성을 나타내는 목표를 설정합니다. 프로덕트의 비전을 설정했다면, 이를 실행하기 위한 구체적인 1년 단위, 분기별 플랜을 작성하는데 이를 로드맵이라 합니다. 프로덕트 백로그는, 이 로드맵을 실행하기 위한 구체적인 할 일 목록, 보통 3개월 간의 할일 목록을 뜻합니다.

스프린트 플래닝이란, 최소 일주일에서 최대 한달 간 집중해서 일하는 기간(스프린트)동안 어떻게 일을 할지, 모든 팀원들이 모여 의견을 공유하는 시간을 의미합니다. 스프린트 플래닝을 통해 스프린트 동안 무엇을, 어떻게 할 것인지 정했다면 스프린트 기간 동안 해야 할 일의 목록인 스프린트 백로그를 작성하게 됩니다. 스프린트 백로그까지 작성했다면, 본격적으로 증가분(결과물)을 도출하기 위해 스프린트가 진행됩니다.

스프린트 기간 동안 하루 업무를 시작하기 전 일의 진척도와 이슈를 공유하는 자리를 가지는데요, 이를 데일리 스크럼이라 합니다. 데일리 스크럼을 통해 이슈를 파악하고, 변화에 대응하며 스프린트 기간동안 증가분(결과물)을 완성했다면, 이제 스크럼 팀원들과 이해관계자들이 완성된 결과물을 평가하고, 향후 계획에 대해 논의하게 되는데 이를 스프린트 리뷰라고 합니다. 또한, 이해관계자를 제외하고 스크럼 팀원들만을 대상으로 하는 회고도 진행되는데요, 스프린트 기간 동안 무엇을 느꼈는지, 일하는 방식을 어떻게 발전시키면 좋을지 등 스프린트 기간을 회고하고 의견을 공유하는 자리를 바로 스프린트 회고라고 합니다. 스프린트 회고가 끝났다면 무엇을 할까요? 바로 새로운 스프린트를 다시 계획, 즉 스프린트 플래닝을 시작하는 것이죠.

이제 스프린트 진행 과정에서의 PM(PO)의 역할에 대해 알아봅시다.

프로덕트 백로그

: (일반적으로) 3개월 동안의 프로덕트 로드맵을 달성하기 위한 할일목록

PO의 역할

프로덕트 백로그에 우선순위 부여

백로그 아이템을 구체적으로, 명확하고 투명하게 정의하여 세부 계획으로 쉽게 나눌 수 있도록 함

개발자들은 백로그 아이템의 크기를 결정하며, PO는 개발자들이 절충안을 이해하고 선택할 수 있도록 도와야 함

스프린트 계획

: 최소 1주일 ~ 최대 1달 간 집중해서 일하는 기간을 스프린트라고 함, 스프린트 플래닝은 1주일~1달이라는 단위기간동안 어떻게 일을 할지, 모든 팀원이 모여 이야기하는 시간을 말함

PO의 역할

팀원들과 함께 스프린트 목표 정의 시, 이 스프린트가 이해관계자들에게 왜 중요한지 이유를 녹여낼 수 있어야 함

스프린트가 왜 가치있는지에 대해 이해관계자들에게 설명할 수 있어야 함

개발자들과 함께 스프린트에 포함할 백로그 아이템 선정

(주의) 프로덕트 백로그 아이템을 어떻게 증가분(결과물)로 만들어 낼 것인지에 대해서는 온전히 개발자들의 재량

데일리 스크럼

: 하루 업무를 시작하기 전 일의 진척도와 이슈를 공유하는 자리

PO의 역할

일반적으로 팀의 개발자들만 참여, PO가 스프린트 백로그 아이템에 깊이 관여하고 있다면 데일리 스크럼의 일원으로 참가

PO는 데일리 스크럼을 통해 작업 진척도를 파악하고 이슈를 해결하는 역할을 해야 함

스프린트 리뷰

: 스크럼 팀원 뿐만 아니라 이해관계자들이 모여 진행. 스프린트 결과물에 대한 평가 및 향후 계획에 대한 논의

PO의 역할

리뷰를 통해 다음 스프린트에서 진행해야 할 일 파악

리뷰 결과를 바탕으로 제품 백로그 조정

이후 새로운 스프린트 플래닝 시 팀원들과 위의 조정 사항에 대해 공유

스프린트 회고

: 이해관계자 제외한 팀원들간의 회고. 스프린트 기간동안 느낀 점, 앞으로의 일하는 방식에 대한 고민 등

PO의 역할

스프린트 회고 시 팀원들이 서로를 탓하거나 비난하지 않도록 중간자 역할, 퍼실리테이터의 역할을 해야 함

팀이 잘못된 방향으로 가게 된 원인, 잘 진행된 일의 원인을 찾을 수 있도록 팀원들을 독려

위의 과정을 통해 팀원들의 효율을 향상시킬 수 있는, 가장 영향이 큰 개선책을 고려하고 다음 스프린트에 수행할 수 있도록 백로그를 조정

4. 마치며

지금까지의 내용을 간략하게 정리해보면 아래와 같습니다.

스크럼의 비전 : 3년에서 5년짜리의 목표

로드맵 : 1년 단위의 목표(분기별)

프로덕트 백로그 : 3개월동안의 할일목록

스프린트 플래닝 : 최소 1주일 ~ 최대 1달 간 집중해서 일하는 기간을 스프린트라고 함, 스프린트 플래닝은 1주일~1달이라는 단위기간동안 어떻게 일을 할지, 모든 팀원이 모여 이야기하는 시간을 말함

스프린트 백로그 : 스프린트 기간동안 해야 할 일의 목록

스프린트 시작 : 정해둔 스프린트 기간 동안 집중해서 일하기

데일리스크럼 : 하루 업무를 시작하기 전 일의 진척도와 이슈를 공유하는 자리

프로덕트 증가분(Product Increment) : 스프린트 기간동안 완성된 결과물

스프린트 리뷰 : 스크럼 팀원 뿐만 아니라 이해관계자들이 모여 진행. 스프린트 결과물에 대한 평가 및 향후 계획에 대한 논의

스프린트 회고 : 이해관계자 제외한 팀원들간의 회고. 스프린트 기간동안 느낀 점, 앞으로의 일하는 방식에 대한 고민 등

다시 스프린트 플래닝 시작

위의 스프린트 과정에서 PO/PM이 어떤 역할을 수행하는지에 대해 살펴보며 가장 크게 느꼈던 점은, PM은 '확고한 방향성을 가지고 끊임없이 타협해야 하는 사람'이라는 것이었습니다. 프로덕트에 새로운 가치를 더하기 이전에 왜 그 가치를 더해야 하는지를 누구보다 잘 이해할 수 있어야 하고, 그를 현실적인 실행안으로 정립하기 위해 개발자, 디자이너, 이해관계자들과 끊임없이 커뮤니케이션하며 절충안을 찾아야 하기 때문입니다. 프로덕트를 개발하는 데 있어 개발자 분들이 '어떻게'를 담당한다면, PM은 '왜'와 '무엇'을 담당하는 사람이라는 생각이 들었습니다. 이상과 현실을 적절하게 운용해야 하는 직군이 바로 PM 아닐까요.

개발 가능성, 내/외부 리소스, 여러 이해관계 등 현실적인 요소를 무시한 채 이상을 향해 질주하는 것도, 현실적인 문제에 매몰되어 프로덕트가 전하고자 하는 본래의 가치를 잊어버리는 것도 경계해야 할 것 같습니다. 그를 위해 가장 중요한 것이 바로 팀원들과의 소통, 신뢰가 아닐까라는 생각이 들었습니다.

*참고사이트

https://medium.com/dtevangelist/scrum-dfc6523a3604

https://brunch.co.kr/@ogaa2143/33

keyword