과제 ) 스크럼 가이드 학습하기
- 필수 읽기자료에 있는 '스크럼 가이드' 내 '프로덕트 오너' 파트를 읽고 프로덕트 매니저로서 스크럼을 관리하는 과정에 필요한 업무 요소를 요약 정리해 봅니다.
- 필수 읽기자료에 있는 '스크럼 가이드' 내 '스프린트' 파트를 읽고 실제 스프린트가 진행되는 과정에서 중요하게 생각해야 하는 점을 요약 정리해 봅니다.
- 그 외의 파트들에 대해서도 상세하게 검토를 하고, 학습한 내용과 연결지어 중요한 부분을 추출해 정리해 봅니다.
| 제시한 스크럼 가이드를 읽고 과제를 작성하였는가? |
| 프로덕트 오너의 역할에 대해 제시된 자료를 바탕으로 스스로 의견을 정리하였는가? |
| 스크럼 내에서의 프로덕트 오너(프로덕트 매니저)의 역할을 나누어 사고하였는가? |
| 실제 스크럼을 관리하는 과정에서 발생할 수 있는 일들을 바탕으로 의견을 작성하였는가? |
| 프로덕트 오너로서 스프린트를 구체적으로 진행하게 될 경우를 바탕으로 의견을 작성하였는가? |
| 스프린트의 목적과 방향에 대해 제시된 자료를 바탕으로 스스로 의견을 정리하였는가? |
⊙ 과제의 핵심 용어(또는 이론)
스크럼 프레임워크
애자일 업무 구조 중 하나다.
짧은 기간 동안 계획-업무-평가-회고 단계를 반복하면서 목표를 이루어나가는데 이를 스프린트라고 한다. 자세한 건 아래에서 확인하자.
스크럼 업무 과정을 도와주는 직무를 스크럼 마스터라고 한다.
스크럼 조직에 들어간 PM이 맡아야 하는 직무가 스크럼 팀 PO다.
당연히 스프린트도 PM이 운영해야 하기 때문에 알아둬야 한다.
참고) Product Owner(PO) vs Product Manager(PM)
PO는 애자일 팀에서 제품을 관리하는 데 중점을 둠 / 애자일
PM은 제품을 만드는 방향을 결정함 / 제품 비전
- 제품 팀을 운영한다는 측면에서 유사함. 국내에서는 혼용해서 씀.
- 스크럼 프레임워크를 쓰는 조직에서 스크럼 마스터가 없으면 PO가 다 한다.
따라서 스프린트와 PO, 이 두 가지 개념을 공식 가이드를 읽어 파악하는 것이 오늘 과제의 핵심이다.
스크럼 가이드
스크럼 창시자들이 프레임워크 잘 쓰라고 무료로 인터넷에 가이드를 공개하고 있다.
위 링크가 안열린다면, 아래 링크로 들어가자.
PDF 버전이라고 되어있는 탭을 쭉 내리다보면 한글 버전이 있다. 이걸 누르면 한국어판 스크럼 가이드 2020 버전이 열린다.
| 스크럼 가이드를 읽고 요약
[요약]
po: '자 우리는 이 기간 동안 이걸 하면 돼!'라고 해주는 관리자 → 자자 파이팅 합시다!를 잘하는 게 중요
스프린트: 위에서 말하는 '이 기간' → 목표를 항상 염두에 두고, 피드백을 뜯어내고, 돌이켜보는 게 중요
그 외 스크럼 팀, 스프린트 진행 과정을 정리하였음.
⊙ '프로덕트 오너' 의 업무 요소를 요약
스크럼 가이드에서 '프로덕트 오너'가 설명된 부분이다.
-
스크럼 팀에 관여하는 프로덕트 오너(PO)는
고객, 투자자, 팀원, 사장님 등 여러 사람이 원하는 바(피드백)를 잘 수집해서 백로그에 정리한다.
(백로그란 현재 하고 있는 일 뒤편에 쌓아둔 일을 말한다.)
우리가 해야 하는 커다란 목표 아래를 정하고, 단기간에 해야 할 일들만 모아 우선순위를 정리한다.
스크럼 팀이 일에만 집중할 수 있도록(=만들고 있는 걸 더 잘 만들게 하도록) 챙겨주면서
뭐든 도맡아 결정한 다음 이해하기 쉽게 알려주는 사람이다.
-
한마디로 하면 PO는 (이해관계자로부터 받은) 피드백을 정리하고 팀원을 챙기고 일정과 목표를 관리&결정하는 사람이다.
- 내 의견을 내보자
어쩌면 PO가 내 성향에 잘 맞는지도 모르겠다.
나는 다른 사람들이 열심히 해서 목표를 완수하도록 돕는 걸 선호하는 것 같다. PO의 본질은 이런 거 아닐까~
다르게 표현하면 너희는 집중해서 개발하고 디자인해라, 나는 너희가 신경 쓸 필요 없게 일정 관리 등을 모두 처리하겠다, 물론 너희 의견을 존중하고 반영해줄테니 개선점이나 문제점 빨리 말해봐라.
어떤 분들은 계속 말하는 것도 지친다며 그냥 내가 하고 말지라고 하시는데 나는 아무리 말해도 지치지 않는다. 그래서 내가 그래도 되는 위치에 있음을 다들 납득한다면, '자자 파이팅합시다, 더 열심히 합시다.' 외치며 목표 달성을 촉구할 것이다. 내가 그래도 되는 위치가 아니라서 말하지 못해 힘든 적은 있었다.
오늘 강의에서 워터폴 방식과 애자일 방식에서 PM 역할의 미묘한 차이를 배웠다.
워터폴 - 클라이언트의 요구사항을 잘 이해하고 기획을 꼼꼼히 잘 하는 것
애자일 - 임기응변, "자자 파이팅 합시다!"
신입일 적에는 워터폴에서 산출물 및 꼼꼼한 기획을 배우고(책임도 덜 지니까 부담이 덜할 거 같다)
좀 숙련된 다음에는 애자일 방식에 적응해보면서 트렌드에 맞춰 수정하는 법, 팀과 상호작용하며 목표를 향해 나아가는 법 등 여러 능력을 키우는 게 어떨까 하는 생각이 들었다.
둘다 해보면 나한테 뭐가 더 잘맞는지 알 수 있을텐데 워터폴 해본 다음 애자일을 하는 거지.
다양하고 부수적인 요소를 처리하며 작업환경을 깨끗이 하는 것이 뿌듯할 듯 싶다. 세부적으로 PO이 협업툴에 남겨진 기록을 정리하고 피드백을 주는 고객을 응대하며, 상담을 요청하는 팀원의 이야기를 들어주겠지? 다 내가 잘하거나 할 수 있는 거 아닌지? 실제로 협업툴 쓰게 되면 엄청나게 깔짝거린다. 이거 기록해야 되는 거 아니에요?라고 말한다.
실제로 스크럼을 관리하는 과정에서 여러 사건이 발생할 것이다. 목표를 완수하지 못해 배포 기간을 놓치는 일도 허다할 거고. 작업량이 이상적 기준과 거리가 멀다고 팀원들에게 윽박 지르면 안된다고 배웠다. 대부분의 돌발 사태는 머리 한번 긁적이고 '아유 어쩔 수 없죠, 왜 그럴까요? 다음에 이렇게 해볼까요? 어떠세요?'라고 하면 되는 거겠지. 어렵지 않다. 타박은 문제해결에 도움이 안되니 어떻게 수습할지 고민하는 편이다.
탑-다운 방식인 워터풀에 비해 애자일은 수평적 구조에 가깝다고 한다. 그렇다는 건 PM이거나 기획자 역할일 내가 팀원이나 외부 인원들에게 마음껏 '이거 어떠세요?'라고 물어볼 수 있다는 뜻이다. 워터풀에 비해 의사결정권이 많아서 책임도 더 많이 지겠지만, 그만큼 다른 사람의 의견을 많이 물어보고 결정하면 되지 않을까. 책임을 분산해서 회피한다! 나 그런 거 잘하고 좋아한다. 내가 리드해야 하는 일인 경우 거의 모든 사람의 의견을 물어보거나 투표를 받아 결정하는 일이 많았다. 이 방식에는 경험 부족을 보완하기 위해 많은 소통이 중요하다고 배웠다.
규모가 큰 사이드 프로젝트에서도 스프린트 방식이 적절한 거 같다.
워터폴처럼 기획과 디자인이 끝날 때까지 개발자들을 마냥 기다리게 할순 없고, 토이 프로젝트니까 내가 시키는대로 하면 개발자들이 억울할테고, 처음부터 같이 만들길 바랄 것이다. 내가 만들고 싶은 집단지성 플랫폼을 언젠가 만들 수 있게 된다면 팀 내에 스프린트 방식을 적용해야지.
요컨대 이렇다.
- 나 PO 잘 맞을지도 몰라.
- 자자 파이팅 합시다! 이렇게 격려하는 역할 선호함
- 부수적이고 잡다한 일을 도맡아 하며 지원하는 거 은근히 즐기지 않을까? : 협업툴 정리 등에 익숙함
- 타박하기 보단 수습을 고민하는 편
- 팀원의 의견을 물어보고 결정하기, 나 그런 거 잘해!
- 조금이라도 규모가 있는 토이 프로젝트에 적합한 방식 아닐까
- 워터폴 방식을 거쳐본 다음에 애자일식 업무를 해보는 게 좋을듯.
⊙ '스프린트' 파트를 읽고 과정 중 중요하게 생각해야 하는 점을 요약
스크럼 가이드에서 '스프린트'가 설명된 부분이다.
- 전체 요약
스프린트란, PO가 모은 백로그 업무 중에서 '이 정도'는 '이 기간' 안에 완료하겠다는 목표를 향해 달려가는 단기 프로젝트다. 기간을 짧게, 많이 가져야 학습 기회를 많이 가질 수 있다. 하나의 스프린트는 계획(어떻게 할지 계획하기), 데일리 스크럼(업무를 진행하기), 리뷰(고객들한테 보여주고 피드백 받기), 회고(프로젝트 자체에 대해 돌이켜보기) 단계를 거친다. 이것이 끝나면 바로 다음 스프린트가 시작되며, 이들이 모여 하나의 프로젝트를 이룬다.
프로젝트 목표에 얼만큼 진행되었는지 점검하고 조정할 수 있다는 장점이 있다. 진행도를 점검할 때는 누적 흐름도 등 여러 도구가 있지만 역시 경험이 짱이다. 만일 스프린트를 할 필요가 없어지면 PO가 취소를 결정한다.
-
한마디로, 스프린트란 효율을 높이기 위해 업무와 기한을 잘게 나눠 전체 프로젝트 기간 동안 반복하여 완수하는 것이다.
- '스프린트가 진행되는 과정에서 중요하게 생각해야 하는 점'을 정리하자면?
1) 목표 그 자체
스크럼은 복잡한 문제에 적응하도록 돕는 경량 프레임워크이며 무엇을 만들어야 가장 성공적일지 확실히 알 수 없는 상황에서 최대한 성과를 보기 위해 적용하는 업무 프로세스다. 스프린트는 스크럼을 채택한 조직에서 프로젝트 기간을 쪼개 반복하는 단기 이벤트다. 이 힘든 마라톤을 선택한 건 프로젝트 목표를 달성하고 제품의 품질을 향상시키기 위해서이다. 헛되지 않도록 지금 스프린트로 완수하고 싶은 목표가 무엇인지 계속 염두해두자.
2) 리뷰를 통해 고객 반응 받고 백로그에 정리하기
스크럼의 핵심이자 스프린트의 특이점은 스프린트 리뷰 과정을 통해 고객의 반응을 자주 접한다는 점이다. 부랴부랴 만들어낸 신기능을 고객한테 짠 하고 보여주고 빨리 평가 받자. 이해관계자가 피드백을 주도록 멱살을 탈탈 털자. 반응이 많든 적든, 날 서있든 온화하든 모아서 백로그에 넣어두자. 다음 스프린트에는 이 백로그에 들어간 반응을 고려해서 수정한다. 완벽한 제품이 될 때까지!
3) 회고하기
이번 달리기 동안 우리 팀이 잘했는지 못했는지 뭐가 문제인지 고민하는 과정을 꼭 거쳐야 한다. 모든 일이 생각대로 흐르지 않으니 단기간에 많은 걸 완수해야 하는 스프린트도 마찬가지다.
예를 들어보자. 이번에 성과가 떨어졌다. 다들 열심히 했는데 왜 그럴까? 팀원들로부터 의견을 수집해보니 힘들어요, 번아웃 와요, 사고 나서 병원에 입원해야 돼요라는 반응들이 나왔다. 병가를 낸 인원이 생겨 인력 자원이 적어졌고 남은 인원끼리 모든 업무를 처리하기 버거워진 것이다. 그렇다면 인력 자원을 더 투입하거나 CAPA(팀이 하나의 스프린트 기간 동안 완수할 수 있는 작업량)를 조정해야 한다. 만약 회고를 건너뛰고 다음 스프린트를 바로 시작했다면 몇 명은 퇴사하고 몇 명은 골병 들었을 것이다.
⊙ 다른 파트 읽어보기
요약이 필요하면 줄 그은 것만 보시오.
스크럼 팀
a scrum master, a product owner, team members(engineers)로 구성된 최소 단위팀이며 4~9명 정도다. 팀마다 프로덕트 목표와 백로그가 있다. 하부 구조가 없고 목표를 향해 독립적으로 움직인다. (이해관계자와의 협력, 검증, 유지보수, 운영, 실험, 연구개발과 같이 필요한 모든 것을 책임지고 알아서 한다.) 매 스프린트마다 고정된 작업량(capacity)으로 일하며 결과물을 내야 한다.
▶ 스크럼 마스터 : 스크럼 가이드에 정의된 대로 일하도록 돕는 사람들.
이론과 실천법을 이해하도록 사람들을 교육하고 조언한다. 팀원들이 자율관리를 하도록, 기한 안에 일을 끝내도록 돕는다. 이해관계자와 스크럼 팀 간의 협업을 유도한다. 그동안의 경험을 중심으로 PO이 목표를 세우고 백로그를 관리하는 걸 돕는다.
▶ 개발자(팀원) : 업무 달성에 전념하는 사람들.
전문가의 긍지를 가지고 매일 개인 작업량을 조정하며 성취해나간다.
스프린트 과정
▶ 스프린트 계획 : 팀 전체가 참여해서 이번에는 무얼 할지 목표와 백로그 아이템을 정한다. 이번 스프린트가 왜 꼭 필요한지, 어떤 기준으로 완료할지를 정해야 한다. 하루 작업량을 정하는 건 개발자의 재량이므로 참견하지 말아야 한다.
▶ 데일리 스크럼 : 실무자들이 매일 15분 가량 진행 상황을 확인하고 조정하는 회의다. 복잡성을 줄이기 위해 같은 시각, 같은 장소에서 모든 근무일 마다 수행한다. 팀의 자율관리 능력을 키우고 불필요한 회의 시간, 소통 오류를 줄여준다.
▶ 스프린트 리뷰 : 고객을 비롯한 이해관계자들에게 결과물과 목표 대비 진척도를 보여주고 피드백을 받는다. 발표만 하고 끝내지 말고 백로그를 수정하거나 다음에 뭐할지 논의하자. 1주 당 1시간을 넘지 않도록 하자. (4주면 최대 4시간, 짧게)
▶ 스프린트 회고 : 해왔던 과정을 전체적으로 훑어본다. (팀원 간 상호작용, 툴, 완료라고 여겼던 기준, 어떤 문제를 어떻게 풀었는지(또는 풀지 못했는지)와 그 이유) 개선책을 찾아 우선적인 걸 다음 백로그에 추가한다. 리뷰 시간보다 더 짧게 진행한다.
스프린트 산출물
▶ 프로덕트 백로그 : 프로젝트의 전체 할 일 목록이다. 스프린트에서 할 일을 여기서 (계획 단계 동안) 선택한다. 바로바로 일할 수 있도록 백로그 아이템을 Task 단위로 잘게 쪼갠다. 설명 붙이기, 우선순위에 따라 정렬하기는 PO가 하며 개발자들이 업무의 크기를 계산한다. 팀의 장기적인 목표인 프로덕트 목표와 연관이 있다.
▶ 스프린트 백로그 : 무슨 아이템들을 어떤 실행 계획을 가지고 어떤 스프린트 목표(기간 중에 다룰 목표)로 일하는지 정해진 계획이다. 스프린트 동안 완수할 업무를 시각화한다. 데일리 스크럼 때 진척을 확인할 수 있어야 한다.
▶ 증가분 : (스프린트는 제품의 가치를 높이기 위해 하는 거라는 측면에서) 가치의 증가분 = 스프린트 성과물
증가분은 스프린트의 종료 전에 이해관계자에게 전달될 수 있으므로, 스프린트 리뷰를 가치의 증가분을 배포하기 위한 관문으로 여겨서는 안된다. 완료한 업무만 증가분으로 쳐준다. 모이면 경험이 된다.
- 중요한 부분은 ?
경험주의를 되게 강조하는데 시간이 그냥 흘러가는 게 아니라 적절한 이력으로 남으려면 회고가 몹시 중요헌 거 같다.
겪었던 일을 상세하게 기록하는 게 필요하겠다. 감정, 피로도 등 세세하게!
나중 되면 다 잊으니까 업무를 방해하지 않으면서 수시로 적어둘 방법을 고안할 필요가 있어 보인다. 따로 메모하려고 각 잡으면 메모 프로그램을 찾아서 키는데만 반나절이고, 막상 뭘 적어야 할지 떠올리는데 사나흘 걸린다.
내 경우에는 PC에 메모 앱을 2개 깔아서 수시로 켜놓고 있다. 캡쳐 프로그램 2개(칼무리, 캡쳐 도구)를 깔아서 필요에 따라 사용한다. 컴퓨터 책상 옆에는 종이 메모와 볼펜을 둬서 한눈 팔 때 메모하도록 해놓았다. 아직 부족하다. 좀 더 빠르고 쉽게 메모를 할 수 있는 환경이 필요해... 내가 가진 포스트잇은 접착력이 죄다 낮아서 컴퓨터 책상에 붙어있지 않았다. 접착력이 낮은 이유는 내가 메모에 집착하지 않아서인지?
실제로 업무를 진행할 때는 효율적으로 메모할 수 있는 환경이 더 중요할 것 같다. 고민해보자.
경험을 유의미하게 쌓기 위해서는 기록을 어떻게 정리해서 인사이트를 낼지도 중요하다. 관련 아티클을 많이 찾아보고 매일~주중 근무일 단위로 작게라도 KPT 회고를 퇴근 전에 하는 게 어떨까. 당신들 금주 KPT 내기 전에 퇴근 못해!! 이렇게 엄포를 놓는거지...
기록을 어떻게 정리하는 게 효과적일까? 이건 겪었던 문제 중심으로 하는 게 좋을듯 싶다. 바쁜 일정에 쫓겨 팀원끼리 으르렁 거려서 힘들었다, 업무가 너무 많아서 카파시티를 조정해야 했다는 식으로 문제 단위를 설정한다. 문제 범위랑 세부 문제는 알아서 경험적으로 구분 짓는다. 개선책 쓰고... ㅊ
여담
스프린트 방향이 몰가
스프린트의 목적과 방향를 구체적으로 진행하게 될 경우를 생각해라는데 어케 더 덧붙여야 될가
어제 과제도 그랬지만 같은 말만 반복하는 것 같다... 나도 알아!
하루를 넘겨 과제 보충을 했다..
의문
가이드에서는
개발자들은 프로덕트 백로그 아이템의 크기를 결정하는 데에 책임을 진다. 프로덕트 오너는 개발자들이 절충안 trade-offs 을 이해하고 선택하도록 도움을 줄 수 있다.
라고 되어있지만
애자일 개발 과정에서 PM이 하는 역할 중에 가장 중요한 것은 이 스코프(범위)를 잘게 쪼개는 것입니다. 핵심 기능 위주로 빠르게 개발할 수 있는 형태로 최대한 잘게 쪼개고 실제로 구축될 수 있도록 하는 것입니다. 그 외는 워터폴 PM과 비슷하게 적재적소에 일정을 배치하는 겁니다. 라고 설명해주었는디 강의에서는
또다른 의문
증가분은 스프린트의 종료 전에 이해관계자에게 전달될 수 있으므로, 스프린트 리뷰를 가치의 증가분을 배포하기 위한 관문으로 여겨서는 안된다.
도대체 무슨 상황에서 전달된다는 거지 리뷰 외에
분석 참고 글
W8D2 [코드스테이츠 PMB 16기] 과제
스크럼 가이드
'PM 부트캠프(22.12.12~23.03.15) > 과제' 카테고리의 다른 글
| Jira 둘러보시라 (W8D4) (0) | 2023.02.06 |
|---|---|
| 고객 외 이해관계자는 어떻게 대응해야 할까? (W8D3) (0) | 2023.02.03 |
| 티스토리 불편해요 유저 스토리 (W8D1) (2) | 2023.02.02 |
| Flow Chart를 Technical Flow Chart로 승진시켜보자 (W7D4) (0) | 2023.01.31 |
| 오픈 API 탐색 - 카카오 로그인 API (W7D3) (0) | 2023.01.28 |
