[코드스테이츠 PMB 13기] | 스크럼&스프린트 탐구
어제에 이어서 애자일(Agile) 방법론, 그중에서도 대표적인 프레임워크인 스크럼(Scrum)에 대해 학습했다. 스크럼은 팀이 중심이 되어 개발의 효율성을 높인다는 의미로, 팀원 스스로 팀을 구성하는 `Self-organizing`, 개발 작업에 관한 모든 것을 스스로 결정하고 해결하는 `Cross-functional`한 특징을 가진다.
오늘은 PM으로서 스크럼을 관리하는 과정에 필요한 요소, 그리고 스크럼을 구성하는 대표적인 이벤트인 `스프린트` 과정에서 중점적으로 생각해봐야 할 부분에 대해 작성해보겠다.
스크럼이란 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법을 활용하여 가치를 창출하도록 도와주는 프레임워크이다. 간단히 스크럼의 프로세스를 간단히 살펴보면 다음과 같다.
1. 프로덕트 오너는 복잡한 문제를 해결하기 위한 업무를 우선순위에 따라 프로덕트 백로그에 정렬한다.
2. 스크럼 팀은 선택한 업무를 스프린트 동안 *가치의 증가분으로 만들어 낸다.
3. 스크럼 팀과 이해관계자들은 결과물을 점검하고 다음 스프린트를 위하여 조정을 한다.
4. 반복한다
*가치의 증가분(Increment of value) : 스크럼 팀이 스프린트 동안 완료한 업무로서, 기존 프로덕트에 새로 더해지는 프로덕트의 새로운 부분을 의미한다.
스크럼 가이드에 따르면, 스크럼 팀에서 PM/PO의 역할 중 하나는 프로덕트 백로그를 효과적으로 관리하는 것이다. 효과적인 관리라 함은 다음 항목을 포함한다.
프로덕트 목표를 세우고 명쾌하게 소통하는 것
프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
프로덕트 백로그 아이템을 우선순위에 따라 정렬
프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것
PM/PO는 위 과정을 모두 직접 담당하지는 않는다. 상황에 따라 다른 사람들에게 그 책임을 위임하기도 하지만, 결국 최종적인 책임 소재는 PM/PO에게 있다.
이는 결국 스크럼 팀의 결과물인 프로덕트의 가치를 극대화해야 하는 PM의 궁극적인 목표 달성을 위함이다. 쉽게 말해 제품 백로그에서 결정된 우선 순위를 기반으로, '스프린트 동안 해야 할 일'을 명확히 설정해 스크럼 팀이 올바른 방향으로 프로젝트를 진행할 수 있도록 해야 한다. 이를 위해 조직 전체가 PM이 내린 결정을 존중해야 하며, 백로그를 변경하고 싶은 구성원은 PM을 설득하여야 한다.
스프린트(Sprint)란 아이디어를 가치로 만들어 내는 이벤트다. 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고 등 세부 이벤트를 포함해 결국 프로덕트의 목표 달성을 위해 필요한 모든 업무를 수행하는 행위를 말한다. 꾸준함을 위해 한 달 이하의 기간으로 고정하는 것이 일반적이며, 원활한 스프린트 진행을 위해 다음과 같은 사항을 유념해야 한다.
스프린트 목표 달성을 저해하는 변경을 해서는 안된다
품질을 떨어뜨려서는 안된다
필요한 수준까지 프로덕트 백로그를 정제해야 한다
범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다
스프린트를 진행하게 되면, 적어도 한 달에 한 번은 프로덕트 목표 대비 진척을 점검하고 조정하기 때문에 프로젝트 진척에 대한 예측 정확도를 높일 수 있다. 진척을 예측하는 데 번 다운/번 업 차트, 누적 흐름도 등 다양한 방식을 활용할 수 있다.
번 다운 차트는 잔여 시간과 잔여 작업량을 기준으로 단순한 선형 차트를 그려 스프린트 단위의 진행도를 시각적으로 파악할 수 있도록 만든 차트이다. 번 업 차트도 번다운 차트와 유사한 시스템을 갖고 있지만, 앞으로 수행해야 할 작업이 아닌 이미 완료한 작업에 초점을 맞춘다. 누적 흐름도는 번 업 차트의 보다 정교한 버전으로 간주된다고 하는데, 시간 경과에 따른 작업 증가(또는 축소)를 추적해 주어진 상태의 작업량을 영역 그래프의 형태로 보여준다.
스프린트 플래닝부터 스프린트 회고에 이르는 스크럼 프레임워크의 프로세스를 간단히 정리해보면 다음과 같다.
PO가 유저 스토리를 기반으로, 프로덕트 목표를 달성하기 위해 가장 중요한 아이템들, 그리고 그것들이 프로덕트 목표와 어떻게 연결되는지 팀원들이 논의할 수 있도록 준비해야 한다. 이 과정에서 다음의 주제를 명확히 하고 넘어가야 한다.
이 스프린트가 왜 가치가 있는지
이 스프린트의 완료는 무엇인지
선정한 일을 어떻게 완료할 것인지
스프린트 플래닝 이후, 제품 백로그에서 결정된 우선 순위를 기반으로, 스프린트(1주~4주) 기간 동안 해야 하는 업무 리스트를 작성한다.
(*제품 백로그 : 전체 할 일 목록 / 스프린트 백로그 : 스프린트 기간 동안 할 일 목록)
스프린트 목표를 구현할 수 있도록, 각각의 요구사항을 Task 단위로 쪼개 개발자들이 나눠서 작업을 수행할 수 있도록 한다.
목적은 스프린트 목표 대비 진척을 점검하고, 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정하는 것이다. 팀원들이 늘어지는 것을 방지하기 위해 스탠드업 미팅 형식으로 매일 정해진 시간과 장소에서 15~20분 동안 짧게 진행한다.
데일리 스크럼의 장점은 어제 했던 일과 오늘 할 일, 수행 중 발견된 장애요인 등을 공유하고 해결할 수 있고, 프로젝트 후반부에 갑자기 발생하는 문제를 사전에 예방할 수 있다는 점이다. 또한 별도로 다른 미팅을 진행할 필요성을 줄여주는데, 데일리 스크럼이 팀의 소통을 향상시키고 팀이 가지고 있는 장애물을 식별하며, 신속한 의사 결정을 촉진하는 역할을 하기 때문이다.
스프린트가 종료되었을 때, 팀이 스프린트 동안 개발한 기능을 이해관계자들에게 보여주고 피드백 받는 과정을 뜻한다. 목적은 스프린트의 결과물을 점검하고 향후에 적용할 것들을 결정하는 것으로, PM/PO는 해당 피드백을 정리해 다음 스프린트에 반영되도록 제품 백로그를 갱신하는 것이다.
중요한 것은 스프린트 리뷰가 스프린트 기간 내 하지 못 한 일을 다시 하기로 결정하는 것이 아니라, 새로운 우선 순위를 정해 신규 스프린트를 다시 설정하는 데 있다.
제품 기능이 아닌 팀에 대한 회고를 진행하는 과정이며, 품질과 효율을 높이기 위한 방법들을 계획하는 것을 목적으로 한다. 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 완료의 정의에 대해 지난 스프린트가 어떻게 진행되었는지를 점검하며, 이를 통해 다음 스프린트를 보다 나은 방향으로 개선하는 방법을 찾는다. 스프린트 회고를 마지막으로 스프린트가 종료되며 최대 시간이 정해진 이벤트로, 예를 들어 한 달 동안의 스프린트였던 경우 회고는 3시간을 넘지 않도록 한다.
스프린트 회고 과정에서 스크럼 마스터 또는 PO는, 중재 및 조정 역할을 하는 퍼실리테이터(facilitator), 촉진자 역할을 맡는다.
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Korean.pdf
https://www.redhat.com/ko/devops/what-is-agile-methodology
https://shiftee.io/ko/blog/article/howToKeepAgileTeams
*코드스테이츠 PMB 과정을 수강하며 과제로 작성한 내용입니다. 사실과 다르거나 부족한 부분이 있을 수 있으니 자유롭게 피드백주시면 감사하겠습니다!