How to 스크럼(Scrum): #스프린트 #PO (요약 ver.)

코드스테이츠| PMB 11/Daily 과제

How to 스크럼(Scrum): #스프린트 #PO (요약 ver.)_ 코드스테이츠 PMB 11기| W8D2

Sutella 2022. 5. 3. 20:02

728x90

오늘의 과제는 스크럼 가이드를 읽고, 제시한 과제 문항에 맞춰 내용을 요약하는 것이다. 제시된 과제는 다음과 같이 3개의 문항으로 구성되어 있다.

1. '프로덕트 오너' 파트를 읽고 프로덕트 매니저로서 스크럼을 관리하는 과정에 필요한 업무 요소를 요약 정리해 봅니다.
2. '스프린트' 파트를 읽고 실제 스프린트가 진행되는 과정에서 중요하게 생각해야 하는 점을 요약 정리해 봅니다.
3. 그 외의 파트들에 대해서도 상세하게 검토를 하고, 학습한 내용과 연결 지어 중요한 부분을 추출해 정리해 봅니다.

원문(스크럼 가이드) 자체도 그리 많은 분량이 아니기에, PO와 스프린트에 대한 파트의 원문과, 이를 간단하게 요약한 내용을 정리해 보았다. 해당 목차 내의 중요한 내용은 원문 자체에 표기(볼드체나 색깔 등)하였고, 과제에서 묻는 것에 대한 답반 별도로 정리하였음을 미리 알린다.

이번 글의 목차는 다음과 같이 구성된다.

프로덕트 오너 ⬅ 과제 1. 프로덕트 오너 파트
스프린트 ⬅ 과제 2. 스프린트 파트
추가 정리 ⬅ 스크럼의 정의, 백로그 (프로덕트 백로그, 스프린트 백로그)

[추가 정리]의 경우, 이번 과제의 근본이 되는 개념인 '스크럼'의 정의를 먼저 다룰 것이며, 어제의 과제에서 헷갈렸던 '백로그'에 대해서도 정리해 보았다. 백로그는 프로덕트 백로그와 스프린트 백로그로 나누어지며, 자세한 설명은 아래의 정리를 참고하길 바란다.

약간 읽기 자료를 스스로 만드는 느낌이지만...? 여하튼 과제 시작-

원문 자료(스크럼 가이드)

Download | Scrum Guides

scrumguides.org

프로덕트 오너

원문

프로덕트 오너는 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는다. 이 업무를 수행하는 방법은 조직, 스크럼 팀, 개인에 따라 다를 수 있다.

프로덕트 오너는 프로덕트 백로그를 효과적으로 관리하는 것에도 책임이 있는데, 다음 사항들을 포함한다:

프로덕트 목표를 세우고 명쾌하게 소통하는 것
프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
프로덕트 백로그 아이템을 우선순위에 따라 정렬
프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것

프로덕트 오너는 위에 나온 일을 직접 하거나 혹은 다른 사람들에게 그 책임을 위임한다. 어떤 식으로 하든지 최종 책임은 프로덕트 오너가 갖는다.

프로덕트 오너가 성공적으로 일을 하기 위해서는 조직 전체가 반드시 그의 결정을 존중해야 한다. 프로덕트 오너가 내린 결정들은 프로덕트 백로그의 내용과 우선순위에 따라 정렬한 것을 통해 확인할 수 있다. 또한 스프린트 리뷰 때에 점검 가능한 증가분을 통해서도 볼 수 있다.

프로덕트 오너는 한 사람이지 여럿으로 구성된 위원회가 아니다. 프로덕트 오너는 프로덕트 백로그와 연관된 많은 이해관계자들의 요구를 대표한다. 프로덕트 백로그를 변경하고 싶은 사람들은 프로덕트 오너를 설득하여야 한다.

✅ [요약] 스크럼 관리 과정에서의 필요 요소

책임

프로덕트 가치 극대화
백로그 관리
- 프로덕트 목표 설정
- 커뮤니케이션
- 프로덕트 아이템 생성
- 우선순위 정렬
- 가시적인 백로그 작성

조직 문화

조직 전체가 PO의 결정을 존중해야 하며, PO가 많은 이해관계자들의 요구를 대표함을 인지해야 한다.
만약 백로그 변경을 원할 때에는 PO를 설득해야 한다. (임의 변경 불가)

💡 나의 생각

스크럼 팀에서의 PO의 역할에 대해 알아보았다. 그렇다면 PM은 무엇을 할까? 이쯤에서 PM과 PO의 개념이 다시 헷갈려서 관련 자료를 통해 다시 정리해 보자면 다음과 같다. (출처: 브런치 RSH)

PM: 일정 기간동안 수행하는 업무를 관리하는 사람

PO: 제품을 총괄하는 역할을 하는 사람

만약 PM의 역할 중 '일정 기간'에 초점을 맞춘다면, PM을 '하나의 스크럼 팀의 책임자'라 볼 수 있을까? 만약 이 정의가 맞다면, 위의 본문에서 '프로덕트 오너는 위에 나온 일을 직접 하거나 혹은 다른 사람들에게 그 책임을 위임한다.'는 문장의 '다른 사람'은 PM이 된다. 하나의 스크럼 팀은 PM을 중심으로 스프린트를 진행하고, 여러 스크럼 팀을 총괄하는 사람을 PO로 명명할 수 있을 것이다.

스프린트

원문

스프린트는 아이디어를 가치로 만들어 내는 이벤트로 마치 스크럼의 심장 박동과 같다.

스프린트는 꾸준함을 갖기 위해 한달 또는 그보다 짧은 기간으로 고정된 길이의 이벤트이다. 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작한다.

스프린트 동안 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 프로덕트 목표를 달성하기 위해 필요한 모든 업무를 수행한다.

스프린트 기간 동안에는:

스프린트 목표 달성을 저해하는 변경을 해서는 안된다.
품질을 떨어뜨려서는 안된다.
필요한 수준까지 프로덕트 백로그를 정제해야 한다.
범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.

스프린트를 진행하게 되면 적어도 한 달에 한 번은 프로덕트 목표 대비 진척을 점검하고 조정을 할 수 있기 때문에 프로젝트 진척에 대한 예측 정확도를 높일 수 있다. 스프린트 기간을 너무 길게 잡으면, 스프린트 목표가 효력이 없어지거나 복잡도가 늘어나고 리스크가 높아질 수 있다. 더 짧은 스프린트 기간일수록 더 많은 학습 기회를 가질 수 있고, 짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있다. 각 스프린트는 짧은 프로젝트와 같이 여겨질 수 있다.

진척을 예측하는 데에는 번 다운(Burn-downs) 차트, 번 업(Burn-ups) 차트, 누적 흐름도(Cumulative flows)와 같은 다양한 방식이 있다. 이러한 방식이 유용하기는 하지만, 경험주의의 중요성을 대체하지는 못한다. 복잡한 환경에서는 어떤 일이 일어날지 알 수가 없다. 단지 지금까지 무엇이 발생했는지를 토대로 앞으로의 결정을 내릴 수 있다.

스프린트 목표가 효력이 없게 되면, 스프린트를 취소할 수 있다. 오직 프로덕트 오너만이 스프린트를 취소할 결정권을 갖는다.

✅ [요약] 실제 스프린트 과정 중 중요하게 생각해야 할 점

스프린트는 한 달 이하의 기간을 가짐
직전의 스프린트가 끝나면, 새로운 스프린트를 즉시 시작한다.
➡ 짧은 스프린트 기간일수록 더 많은 학습 기회, 리소스 절약, 리스크 한정 가능

유의 사항

목표 달성을 저해하는 변경 금지
품질 저하 주의
필요 수준까지 백로그 정제
범위 재정의가 필요한 경우 PO와 다시 협상
스프린트 기간은 짧을수록 효과적

단, 스프린트 취소는 PO만이 결정할 수 있다.

💡 나의 생각

스프린트는 한 달 이내의 짧은 기간으로 진행되는 일종의 미니 프로젝트로 볼 수 있으며, 하나의 스프린트가 끝나면 회고를 통해 곧장 다음 스프린트를 시작한다고 나와있다.
하지만 여기서 약간의 의문점이 생긴다. 개발자들은 컴퓨터가 아닌 사람이기에, 이러한 스프린트가 반복되다 보면 지치는 순간이 필연적으로 다가올 것이다. 그렇다면 PO는 그 주기(?)를 어떻게 설정해야 할까? 스프린트 반복 횟수를 어떻게 설정하면 좋을까? 물론 회사나 부서, 팀마다 환경은 다르겠지만, 이와 관련된 기준이 있다면 좋을 것 같다. 몰아치며 일하는 것은 좋지만, 이것도 몇 번 반복되다 보면 효율을 잃을 것 같은데... 이와 관련된 연구 결과가 있는지 궁금하다. (구글에 잠깐 검색해 봤을 때는 스포츠계의 스프린트만 나와서^^... 금방 자료를 찾기는 어려울 것 같다.)
+ 한 편으로는 PO의 위치에 도달하는 사람은 대부분 10년 이상의 경력자가 많기에, 그정도는 별도의 기준이 없어도 스스로 판단 가능한 위치의 사람이라는 생각이 든다. 회사, 부서, 팀 그리고 산업 환경에 따라 다르기 때문일까? (최근에는 IT가 쓰이지 않는 시장이 없기에;;) 또 나의 대뇌 망상을 추가해 본다.

➕ 추가 정리

스크럼의 정의

스크럼이란 복잡한 문제에 대해 적응할 수 있는 해법을 활용하여 가치 창출을 도와주는 경량 프레임워크
스크럼 마스터가 환경을 조성하는 것

환경

PO는 복잡한 문제 해결을 위해 업무를 우선순위에 따라 프로덕트 백로그에 정렬

스크럼 팀은 선택한 업무를 스프린트 동안 가치의 증가분으로 제작

스크럼 팀&이해관계자: 결과물 점검 및 다음 스프린트를 위한 조정

반복

스크럼은 의도적으로 불완전하며, 오직 스크럼 이론을 구현하는데 필요한 부분만 정의

스크럼 이론

경험과 관찰을 기반으로 한 의사 결정으로부터 지식을 얻는 경험주의와 낭비를 줄이고 본질에 초점을 맞추는 린 씽킹을 기초로 한다

예측 최적화와 리스크 통제를 위해 반복적이고 점진적인 방법 사용

점검과 적응을 위해 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고가 하나의 스프린트 안에 포함

✅ 정리
스크럼은 프레임워크 / 스프린트는 짧은 기간으로 고정된 길이의 이벤트 / 스프린트는 또다시 여러 개의 이벤트로 구성

백로그

프로덕트 백로그

프로덕트 백로그는 프로덕트를 향상하기 위한 것으로 발생하는 업무를 우선순위에 따라 정렬한 목록이다. 프로덕트 백로그는 스크럼 팀이 실행하는 업무를 제공하는 유일한 출처(single source)이다.

프로덕트 백로그 아이템은 스프린트 계획 이벤트 때에 선택할 수 있도록 준비된 것으로 스크럼 팀이 한 스프린트 안에 완료할 수 있는 것이다. 보통 할 일들을 정제한 이후에 스프린트 계획을 할 수 있는 수준의 투명성을 확보할 수 있다. 프로덕트 백로그 정제는 프로덕트 백로그 아이템을 구체적으로 정의하여 보다 명확하게 일을 작은 단위로 나누는 것이며, 설명, 우선순위에 따른 정렬, 크기와 같은 세부 사항들을 지속적으로 추가하는 활동이다. 속성 항목들은 주로 업무 영역에 따라 다를 수 있다.

개발자들은 프로덕트 백로그 아이템의 크기를 결정하는 데에 책임을 진다. 프로덕트 오너는 개발자들이 절충안(trade-offs)을 이해하고 선택하도록 도움을 줄 수 있다.

스프린트 백로그

스프린트 백로그는 스프린트 목표(왜), 스프린트를 위해 선택된 프로덕트 백로그 아이템들의 모음(무엇을), 증가분을 전달하기 위한 실행할 수 있는 계획(어떻게)으로 구성되어 있다.

스프린트 백로그는 개발자들에 의한 개발자들을 위한 계획이다. 매우 가시적이며, 개발자들이 스프린트 목표를 달성하기 위해 스프린트 동안 완수하기로 계획한 업무를 실시간으로 보여주는 그림이다. 따라서 스프린트 백로그는 스프린트 기간 동안 더 알게 된 것만큼 업데이트된다. 스프린트 백로그는 데일리 스크럼 때 진척을 확인할 수 있을 만큼 세부 내용이 충분해야 한다.

✅ 요약

프로덕트 > 프로덕트 백로그 > 스프린트 백로그
프로덕트 백로그
- 프로덕트의 향상을 위해 발생하는 업무를 우선순위에 따라 정렬한 목록
- 스크럼팀은 프로덕트 백로그에 적힌 업무 실행 (스크럼팀의 업무를 제공하는 유일한 출처)
- 아이템 크기 결정은 개발자들의 영역이며, PO는 개발자들이 절충안을 이해하고 선택하도록 돕는 역할을 수행한다.
스프린트 백로그
- 개발자들에 의한, 개발자들을 위한 계획
- 스프린트 동안 완수하기로 계획한 업무를 실시간으로 보여주는 그림
- 데일리 스크럼 때 진척을 확인할 수 있을만큼 세부 내용이 충분해야 함
- 스프린트 백로그 = 목표(Why) + 프로덕트 아이템들의 모음(What) + 증가분 전달을 위한 계획(How)

용어

아이템: 스프린트 안에 완료할 수 있는 업무로, 스프린트 계획 때 선택할 수 있도록 준비된 것
백로그 정제: 아이템을 구체적으로 정의하여 보다 일을 보다 명확하게 작은 단위로 나누는 것. 우선순위 정렬, 업무 크기 등의 세부사항을 지속적으로 추가하는 활동
증가분: 스크럼 팀이 스프린트 동안 완료한 업무. 기존 프로덕트에 새로 더해지는 부분 의미. 수행한 업무가 완료의 정의를 충족하지 않으면 증가분에 포함 불가

"스크럼" 요약를 마치며

학창 시절 시험 며칠 전, 벼락치기로 공부할 때 최대의 집중력을 발휘하는 것처럼, 스프린트도 이러한 데드라인의 압박을 이용한 프레임워크이다. 스크럼은 하나의 목표 달성을 위해 문제를 정의하고, 이를 해결하기 위한 솔루션을 설정하여 목적에 도달하기 위해 팀원들에게 업무를 배분한다. 다들 쫓기듯이 업무에 참여하여 증가분을 만들어 내고, 이것들이 모여 스프린트의 목적 달성으로 이루어진다. 하나의 스프린트가 끝나면 스프린트 리뷰와 회고가 이루어지며, 이를 반영하여 곧바로 다음 스프린트를 시작한다.

만약 내가 현업에서 스크럼 방식으로 일을 한다면, 나는 오히려 이를 선호할 것 같다. (가끔 게을러지기는 하지만) 가만히 쉬고 늘어지는 것보다 바쁘게 할 일이 쌓여있고, 이를 끊임없이 해결하는 것이 더 좋기 때문이다. 나의 경우 오히려 몰아칠 때 잡생각을 떨쳐내고 아이디어가 샘솟기도 하며, 일의 효율성도 가장 높았다. 그래서 오늘 학습한 '스크럼'이 그렇게 낯설지 않고, 오히려 현업에서 이 방식으로 일하고 싶다-는 생각이 들기도 한다.

다만 위의 스크럼 가이드에서 간과한 부분이 있는 것 같아 아쉽다. 앞서 언급하기도 했지만, 그래서 스크럼의 끝은 어디인가? 스크럼 가이드와 스프린트의 정의, 유의 사항에 따르면 하나의 스프린트가 끝나면 곧장 다음 스프린트가 시작된다. 몇 번 정도는 나태해졌던 나 자신을 채찍질하며 최고의 효율을 낼 수 있겠지만, 이것이 계속 지속되기는 어렵다. 다만 이 때에도 스크럼과 스프린트를 정지할 수 있는 권한은 오직 PO에게 있기에, 그의 산하에 있는 팀원들은 PO에게 제발 죽여달라고... 소리치지 않을까...? PO는 팀원들의 상태를 살피고 능력에 맞는 task를 배분하겠지만, 결국 모든 책임은 PO에게 있기에 목표 달성을 위해 그들을 몰아세워야 한다. 만약 이 과정에서 한 번 지친 경험이 있는 팀원들이라면, 스크럼 문화 자체에 회의감과 반감을 가져, 이후부터는 비협조적인 태도를 보일 가능성도 있다.

결국 스크럼에서 중요한 것은 PO라는 생각이 든다. 개발자 팀원들이 적절한 task를 나눠가질 수 있도록 조율하는 역할과 함께 목표 달성을 해 내야 하기 때문이다. 그렇기 때문에 PO는 개발 지식이 필수적으로 요구될 것으로 보이며, 스프린트의 정지 포인트 결정, 팀원들의 역량 및 증가분 관리 등 많은 부분에 있어서 신경을 써야 할 것이다.

어... 오늘 과제 이게 끝이 맞ㄴ...? 이전의 과제들과 다르게 내 생각이 들어갔다기보다, 기존의 자료들을 짜집기+요약한 느낌이라 왠지 찝찝하다;; 그래도 어제까지 헷갈렸던 '백로그'에 대해서 좀 더 정리가 되었고, 학습 과정에서 두루뭉술했던 개념들을 명확히 정의 내린 것 같다. 나름 나만의 생각을 덧붙여 보기도 했으니...? 일단 오늘의 과제 끝?!

fin.

728x90

저작자표시