첫주차부터 들었던 '애자일'에 대해서 본격적으로 알아보는 한 주이다.
오늘은 스크럼 프레임워크와 칸반에 대해서 배워봤고, 스크럼에 대해 정리해보려고 한다.
오늘 강의와 아래 문서를 바탕으로 이해한 바를 정리하였다.
[ 이 글의 많은 부분은 해당 문서에서 발췌되었습니다._ 스크럼 가이드 ]
스크럼?
스크럼은 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법 을 활용하여 가치를 창출하도록 도와주는 경량 프레임워크라고 한다.
애자일 방법론은 여러 요구사항에 민첩하게 대처하기 위한 방식으로, 작은 문제들을 해결하고 테스트하는 과정을 반복하여 발전해나가는 것이 목적이다. 이 방법론을 팀에 적용시키기 위한 프레임워크가 '스크럼'이라고 할 수 있다.
아래 자료가 스크럼 프레임워크인데, 한 스프린트를 진행할 때 얼마 동안 어떤 순서로 진행되는 지 볼 수 있다.
간단하게 순서를 정리해보았다. 사용자 요구사항을 정리한 프로덕트 백로그를 스프린트에 반영하여, 한 스프린트를 시작부터 회고하는 단계까지 볼 수 있다.
그렇다면 PM은 스크럼에서 어떤 역할을 맡고 있을까?
PM이 스크럼을 관리하는 과정
스크럼팀은 적은 수의 인원으로 구성되며, 스크럼 마스터, 프로덕트 오너, 개발자들로 구성된다. 그 중 프로덕트 오너(PO)는 스크럼팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 가지며 그 방법은 조직마다 다를 수 있다.
PO = PM?
잠깐 짚고 가자면, 기업에 따라 이 둘을 혼용하여 사용하기도 하고 정의가 다르기도 하다. 오늘 참고한 '스크럼 가이드' 문서에서 말하는 PO의 역할은 스크럼에서 PM의 역할과 같아서, 이 글에서는 PM과 PO가 같다고 보고 이야기하였다.
백로그 관리
스크럼팀은 백로그를 해결하기 위해서 스프린트 주기에 따라 결과물을 산출하는데, 이때 PO의 주요역할은 백로그를 효과적으로 관리하는 것이다.
- 프로덕트 목표를 세우고 명쾌하게 소통하는 것
- 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
- 프로덕트 백로그 아이템을 우선순위에 따라 정렬
- 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것.
백로그를 어떻게 작성하고, 어떻게 우선순위를 세우느냐에 따라 스크럼팀의 방향이 달라질 수 있다.
백로그는 여러 이해관계자들의 요구를 모으는 것이고, PO는 그 요구들을 대표하고, 위에 나타낸 일에 대한 최종 책임을 갖는다.
추가 자료
스크럼 가이드에서 PM이 아닌 PO라고 지칭하는 이유와 PO와 PM의 차이가 궁금해서 애자일 조직에서 PM(Product Manager)의 역할에 대해 더 찾아보았다. 그렇게 찾게된 PO를 더욱 정확히 이해할 수 있는 글을 하나 소개하고 싶다.
[SW 개발 프로젝트에서 PM의 달라진 역할_ 그 많던 PM들은 다 어디로 갔을까요?]
달라진 PM(Project Manager)의 역할에 대한 글이다. 글에서 말하는 PM이 프로덕트 매니저가 아님을 알고 글을 읽어야 헷갈리지 않는다. 아래는 글의 주요 내용을 정리하고, 인사이트를 적어보았다.
- PM(Project Manager) → SM + PO
애자일 방식을 도입하는 기업이 많아지고, 스크럼 조직에서는 PM(Project Manager)의 역할을 SM(Scrum Master)과 PO(Product Owner)가 대신하게 되었다. SM은 프로세스를 관리하고, PO는 고객의 가치를 고려하여 의사결정을 하는 역할을 한다. 풀어 말하면 PO는 고객, 이해관계자와 소통하여 요구사항을 정리하고 빠른 결정을 내리는 역할이다.
- PdM(Product Manager)
"프로덕트의 규모에 맞춰 과거에 PO가 없을 때 프로덕트를 담당했던 PdM(Product Manager)의 역할이 다시 중요해지기 시작했습니다. (중략) PO가 제품의 비전, 유관 부서의 커뮤니케이션 관리를 맡으면서 PdM이 데브옵스팀과 스크럼을 수행하며 산출물을 만드는 역할에 더 집중할 수 있도록 했습니다."
내가 하려는 PM, Product Manager에 대한 언급도 있었다. PdM이라 지칭하며 PO가 커뮤니케이션 관리를 맡을 때 PdM이 산출물을 만드는 역할에 집중한다고 하는데, 이는 조직마다 PO와 PM으로 나누어 진행될 수도, PO 혹은 PM이 전부 진행할 수도 있을 것 같았다. 실제로 채용공고를 보면 PO와 PM의 JD와 정의가 기업마다 다르다.
- 조직의 변화
"과거 프로젝트 중심의 PMO(Project Management Office) 조직도 변화하고 있습니다. PMO를 먼저 꾸리고 프로젝트 조직을 구성하던 방식에서 대형 스크럼 조직을 운영하기 위한 SoS(Scrum of Scrums), 프로덕트를 중심으로 한 PPO(Product and Portfolio Office), 고객 가치 중심의 VMO(Value Management Office) 조직이 등장하고 있습니다. 역할은 비슷하지만 어디에 더 무게 중심을 두는지에 따라 운영해야 할 팀과 그에 따른 역할이 달라집니다."
조직의 변화에 따라 이 역할들이 변해온 점이 흥미로웠다.
지금 국내에는 IT기업을 제외하고 PM이, PO가 무엇인 지 생소하다. PM 부트캠프를 수강중이라고 하면 PM에 대해서 한번 더 설명해야하니까 말이다. 그 이유를 빠르게 변화하는 조직 구조에서 생겨난 직무이기 때문이라고 이해했다.
👉 이 글을 통해서 조직의 변화로부터 스크럼과 직무들을 이해할 수 있어서, 직무들의 의미와 역할에 대한 개념을 명확히 잡을 수 있었다.
스프린트
스프린트는 아이디어를 가치로 만들어 내는 이벤트로 마치 스크럼의 심장 박동과 같다.
'스크럼 가이드'에서는 스프린트를 이렇게 표현하고 있다. 스프린트는 일정 기간의 이벤트, 반복적인 개발 주기를 의미한다. 직역하면 '전력질주'를 뜻하며, 보통 1~4주로 정해진 기간동안 맡은 과제의 결과물을 도출해야한다.
프레임워크로 보면 아래와 같고, 스프린트 계획 회의 부터 회고까지 목표를 달성하기 위한 모든 과정을 포함한다. 스프린트를 진행하면서 적어도 한 달에 한 번은 프로덕트 목표 대비 진척도를 파악해야 하는데, 이 때 번 다운 Burn-downs 차트, 번 업 Burn-ups 차트, 누적 흐름도 Cumulative flows 와 같은 다양한 방식을 사용한다.
각 단계들을 간단히 살펴보자.
스프린트 계획 회의
스크럼팀 전체가 참여하여, 해당 스프린트 동안 수행할 업무를 선정하기 위해 아래 주제로 회의한다. 시간이 정해진 이벤트로 1개월의 스프린트의 경우 계획회의가 8시간을 넘지 않도록 하며 기간이 짧은 경우 계획 시간도 더 짧게 한다. 이 때 계획한 것이 스프린트 백로그가 된다.
1) 이 스프린트가 왜 가치가 있는가?
2) 이 스프린트의 완료는 무엇인가?
3) 선정한 일을 어떻게 완료할 것인가?
데일리 스크럼
스크럼팀의 개발자들만 참여하는 15분 길이의 이벤트이다. 스프린트 목표 대비 진척을 점검하고 필요에 따라 스프린트 백로그를 조정할 수 있는 시간이다.
스프린트 리뷰
이해관계자들에게 스프린트의 결과물과 진척도를 보여주는 시간이다. 1개월의 스프린트의 경우 4시간을 넘지 않도록 한다.
스프린트 회고
품질과 효율을 높이기 위한 방법들을 계획하기 위해서 스크럼 팀 전체가 지난 스프린트가 어떻게 진행되었는 지 점검한다. 잘못 진행된 것의 원인을 찾아내고, 잘 진행된 것과 해결한 문제에 대해 의견을 나눈다. 가장 영향이 큰 개선책을 도출하고 다음 스프린트에 적용할 수 있다.
주의사항
- 스프린트 목표 달성을 저해하는 변경을 해서는 안된다.
스크럼은 '빠르게'보다 '효율적'으로 일하는 프레임워크이기 때문에, 스프린트는 해당 스프린트의 목표에 맞춰 진행되어야 한다. 스프린트 시작 후 티켓 추가를 하거나 태스크를 추가하면 정작 해당 스프린트의 목표 달성이 어려울 수 있다. 급한 이슈가 있을 때는 PO와 SM의 협의 하에 결정할 수 있다.
- 품질을 떨어뜨려서는 안된다.
위에서 말했듯이, 빠르게만 중요한 것이 아니라 문제를 해결하는 것이 중요하다. 기간 내에 일을 처리하기 위해 품질을 떨어뜨리면 안된다.
- 필요한 수준까지 프로덕트 백로그를 정제해야 한다.
우선순위를 잘 세워야한다는 것으로 이해했다. 프로덕트 백로그가 정리되어야 스프린트 백로그데도 꼭 필요한 일만 담길 수 있기에 PO가 백로그를 효율적으로 관리하는 것이 필요하다.
- 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.
가장 첫번째 주의사항에서 언급했듯이, 필요한 경우 PO와 협의할 수 있다.
실제 사례
마침 오늘 토론에서 마켓컬리의 애자일 문화에 대해 이야기하였다. 마켓 컬리의 기술블로그에서 개발팀이 스크럼을 적용하고 있는 것을 알 수 있었고 실제 어떻게 활용하고 느끼는 지 볼 수 있었다.
[스크럼, 입고팀이 애자일하게 일하는 법 1부/ 2부]
애자일과 스크럼에 대한 설명, 프로세스, 스크럼에서 주의할 점 등이 담긴 글이었고, 실제 느낀 점만 요약해보았다.
스크럼을 진행하며 좋았던 점
- 커뮤니케이션 비용의 절약 → 스프린트 보드의 활용으로, 팀원들의 업무 진척도를 한 눈에 볼 수 있었다.
- 개발자, 기획자, QA 모두 공통의 목표를 향해 화목하게 일할 수 있다. → 목표가 얼라인되어 소통이 원활하다.
- 회고를 통한 피드백 시스템 정착 → 시간이 정해진 피드백으로 스프린트 동안에는 목표에만 집중, 피드백 정리 가능
- 개발팀원 전체의 도메인 이해도 증가
- 개발자가 주도적으로 업무의 일정을 산정할 수 있다.
👉 스크럼을 통해 편한 방식대로 일하며 과제 해결에만 집중할 수 있었다고 한다.
내가 PM이라면?
오늘 '스크럼 가이드'를 읽으면서 PO가 마치 CEO처럼 묘사되어 있다고 생각했다. PO가 백로그를 결정하고 최종 책임을 지기 때문에 스프린트 목표 설정과 백로그 설정에 대해서 PO의 결정에 따라야 한다는 것은 자칫 PO의 역할을 최종결정자로 생각하게 할 수 있다.
내가 PMB에서 배우고 있는 PM의 역할은 소통하고 조율하는 사람이다. 결정해야 할 부분은 결정해야겠지만, 독단적으로 판단하는 것이 아닌 여러 이해관계자들의 의견을 듣고 데이터를 바탕으로 한 논리를 가지고 결정해야 하고, 그 결정사항을 설득하는 것까지가 PM의 몫이라고 생각한다.
스크럼 팀에서 PM은 팀 내에서의 소통뿐만 아니라, 외부와 팀의 소통도 담당해야 한다. 스프린트 목표가 프로덕트 목표 방향과 일치하는 지, '지금 무슨 일을, 왜 하고 있는 지' 안으로 밖으로 말해주는 사람이 되어야할 것 같다.
내가 이해한 PM은 혼자 할 수 있는 일이 없다. 해야하는 일 자체가 '함께 할 수 있도록' 하는 것이기 때문이다. 팀원 모두가 한 목표에 얼라인되어 각자의 일을 할 수 있도록 돕는 것이 PM이고, 돕는 일에 결정, 조율, 설득이 모두 포함되는 것 같다.
'결정'만이 PM의 역할이라고 생각하지 않도록 주의해야할 것 같다.
[참고 자료]
https://hanseul-lee.github.io/2020/11/29/20-11-29-Agile/
https://brunch.co.kr/@insuk/13
https://www.samsungsds.com/kr/insights/sw_pm.html
https://helloworld.kurly.com/blog/inbound-squad-sprint-1/
https://helloworld.kurly.com/blog/inbound-squad-sprint-2/
PM을 설명하지 않아도 되는 날이 올까..? 조직이 변화하면서 직무가 생겨나고 달라지는 것도 흥미롭지만, 내가 가질 직업을 모두가 알았으면 하는 마음도 있다. 내가 현업에서 일하면서도 이 개념이 달라질 수 있겠다고 생각했다. 그래서 직무의 이름에 초점을 맞추기보다 해야하는 일과 조직에서의 역할을 잘 파악하고 있어야겠다.
'PMB Daily' 카테고리의 다른 글
| 어서와 'Jira'는 처음이지 [코드스테이츠 PMB 14기] (0) | 2022.10.19 |
|---|---|
| PM과 이해관계자 [코드스테이츠 PMB 14기] (0) | 2022.10.18 |
| 내 주머니에선 사라진 "포켓CU" [코드스테이츠 PMB 14기] (0) | 2022.10.14 |
| 2주 후 달라진 플로우차트?_케이크 과제 회고 [코드스테이츠 PMB 14기] (0) | 2022.10.12 |
| 카카오 푸시알림 API 알아보기 [코드스테이츠 PMB 14기] (1) | 2022.10.11 |
