스크럼과 PM, 그리고 애자일
[코드스테이츠 PMB 10기] 스크럼 vs 칸반
애자일하게 일하고 싶다면
스크럼부터 알자
1. 스크럼, 그리고 PM
직전 과제에서 리디북스는 애자일하게 일하기 위해 스크럼 미팅을 매일 아침마다 하고 매주마다 스프린트 회고를 진행한다고 언급한 적이 있다. 그럼 여기에서 말하는 스크럼이란 도대체 무엇일까?
스크럼(Scrum)이란 애자일의 대표 관리 Practice로, 팀이 중심이 되어 개발의 효율성의 높이는 일종의 프로세스 프레임워크이다. 스크럼은 작은 주기 단위(Sprint)로 개발 및 검토를 하며 효율적인 협업 방법을 제공한다.
스크럼의 원리
결국, 스크럼의 원리는 다음과 같은 순으로 진행된다.
1. 우리는 고객을 잘 모른다.
2. 그렇기 때문에 자주 고객에게 릴리스하고 새롭게 피드백을 받아야 한다.
3. 지속적인 개발과 피드백을 통해 여러 번의 가설 검증 단계를 거친다.
4. 가설 검증의 단계를 통해 우리가 진짜 필요한 것이 무엇인지, 피해야 할 것이 무엇인지 알아낸다.
5. 그렇게 이해관계자들에게 더 빠르게, 더 잘 그들이 원하는 것을 전달할 수 있다.
이 과정을 아래의 자료 화면을 통해 더 잘 이해할 수 있다. 해당 영상은 워킹어스에서 제작한 것으로, 아이스크림 죠스바를 성공시키기 위해 무엇이든 하는 가상의 팀이 스크럼 방식으로 일하는 모습을 담고 있다.
위의 자료를 보면 스크럼에는 크게 다섯 단계의 이벤트가 진행됨을 알 수 있다.
스프린트 계획 회의, 사용자 스토리와 백로그
스프린트 백로그(sprint backlog) 작성
데일리 스크럼 미팅(daily scrum meeting)
스프린트 리뷰
스프린트 회고(sprint retrospective)
스크럼 속 PM의 역할
그렇다면 이 프로세스 중에서 프로덕트 매니저(PM)가 수행해야 하는 역할은 무엇일까? 이에 대해 자세히 살펴보고자 스크럼을 이해하기 위한 안내서, 스크럼 가이드를 참고해보고자 한다. (참고)
먼저, 스크럼 가이드에서는 스크럼을 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법을 활용하여 가치를 창출하도록 도와주는 경략 프레임워크라고 정의하고 있다. 그리고 이 과정에서 프로덕트 오너 또는 프로덕트 매니저는 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 가지며 백로그를 효과적으로 관리해야 한다고 말한다.
여기에서의 백로그란 개발해야 할 기능 또는 제품에서 요구하는 기능과 우선순위를 말한다. 그리고 스크럼에서는 각각 프로덕트 백로그, 스프린트 백로그가 있다. 프로덕트 백로그가 프로덕트 향상 목표로 업무를 우선순위에 따라 정렬한 목록이라 한다면, 스프린트 백로그는 우선순위를 기반으로 스프린트 목표를 달성하기 위해 프로덕트 백로그에서 선택된 할 일 목록을 뜻한다.
그리고 이러한 백로그를 효과적으로 관리한다는 것은 프로덕트의 목표를 세우고 명쾌하게 소통하는 것, 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것, 백로그 아이템을 우선순위에 따라 정렬하며 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것을 포함한다.
결국 PM은 프로덕트 개발 구성원들이 스크럼 초기에 설정했던 목표를 달성할 수 있도록 지속적으로 가는 길을 닦아야 하는 사람이다. 마치 스톤이 제자리를 찾을 수 있도록 열심히 빙판길을 닦는 컬링 선수에 비유할 수 있지 않을까?
2. 개발, 스프린트로 달려!
리디북스에서도 스프린트 회고를 한다고 말하고, PM은 스프린트 백로그를 효과적으로 관리해야 한다고 쓰여있다. 그러면 스크럼 속에서 스프린트란 무엇일까?
스프린트(Sprint)라는 '단거리 질주'라는 단어의 의미와 동일하게 모든 팀원이 정해진 기간 동안 정해진 태스크를 전력 질주하듯 집중해서 업무를 수행하는 것을 의미한다. 단거리 질주라는 뜻에 걸맞게 스프린트 기간은 최소 1주, 최대 1달로 매우 짧게 설정이 된다.
그리고 이 짧은 기간 동안 효과적으로 일을 수행하기 위해, 스크럼 가이드에서는 다음과 같은 항목들을 스프린트 기간 동안 지킬 것을 권장한다.
스프린트 목표 달성을 저해하는 변경을 해서는 안된다.
품질을 떨어뜨려서는 안 된다.
필요한 수준까지 프로덕트 백로그를 정제해야 한다.
범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.
하지만 스프린트를 수행함에 있어 정말 전력 질주하듯 달리기만 하면 올바른 성과를 얻을 수 없다. 왜냐하면 무작정 앞만 보고 달린다면 우리 팀이 정말 잘 가고 있는지 확인할 수 없기 때문이다. 이를 위해 지속적으로 '우리가 잘 가고 있는지' 확인하는 과정이 필요하다. 그것이 바로 데일리 스크럼 미팅(Daily Scrum Meeting)이다.
스프린트의 감초, 데일리 스크럼 미팅
데일리 스크럼은 스프린트 목표 대비 진척을 점검하고, 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조절하기 위해 시행한다. 이를 위해 스크럼 팀의 개발자들끼리 모여 최대 15분 동안 일의 진척도와 문제사항을 파악한다.
이를 통해 팀의 소통은 활성화시키고 업무수행 중에 혹시나 발생할지도 모르는 문제사항은 미리 식별하여 빠른 의사소통을 추진할 수 있다.
3. 스크럼 vs 칸반
스크럼 이외에도 이번 학습에서 칸반(Kanban)이라는 애자일 프레임워크도 배웠다. 칸반은 팀과 조직의 작업을 시각화하여, 업무의 병목 현상과 리소스 낭비를 처리할 수 있도록 돕는데 목적을 두고 있다. 칸반 역시 중요하다 생각이 되는 프레임워크 중 하나인데, 왜냐하면 일전에 PM으로서의 면접 질문으로 칸반의 장단점에 대한 답변을 요구했다는 이야기를 들은 적이 있기 때문이다.
스크럼과 칸반, 그럼 어떤 측면에서 다른 점이 있을까? 좀 더 그 차이를 명확히 이해하기 위해 노션에 정리를 해보았다.
이렇게 보니, 칸반은 전체적으로 개발이 지속적으로 흐르는지를 확인하기 위한 방법이고 스크럼은 모든 task가 스프린트 별로 진행되고 있는 지를 확인하기 위한 방법임을 알았다. 즉, 칸반이 전체적으로 개발의 흐름, 숲을 보기 위함이라면 스크럼은 하나하나의 스프린트 단위별로, 각 나무별로 확인하는 프로세스인 것이다.
애자일하게 일할 수 있는 PM이라면 각각의 프레임워크의 차이를 명확히 알고 본인이 속해있는 개발팀에 맞는 프레임워크를 쓸 줄 알아야 할 것이다.
참고 자료.
