[코드스테이츠 PMB 11기] 스크럼 가이드
스크럼(Scrum)은 럭비에서 유래된 용어로, 경기가 반칙으로 인해 잠시 중단되었을 때, 양 팀 선수들이 공을 중간에 놓고 어깨를 밀착해서 형성한 전술 대형이라고 한다.
럭비의 전술처럼 애자일 프로세스에서 스크럼은 팀, 조직이 복잡한 문제나 프로젝트 관리를 위해 상호 점진적으로 개발하는 방법론을 의미한다. 스크럼의 장점은 팀원끼리 적극적으로 독려하고 서로에게 피드백을 제공하며 궁극적으로 제품/서비스의 발전을 위해 꾸준히 노력한다는 점이다.
스크럼은 위 이미지와 같이 이루어진다 각 단계에 대해서 알아보자
스프린트 계획 회의에서는 제품 책임자(product owner)가 사용자 스토리를 기반으로 제품 백로그를 작성한다. 여기서 제품 백로그는 이해 관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록을 말한다.
제품 백로그에서 결정된 우선순위를 기반으로 스프린트 동안 해야 하는 일에 대한 리스트를 스프린트 백로그라고한다. 제품 백로그는 단순히 할 일 목록이라면, 스프린트 백로그는 짧은 기간 동안 할 일의 목록이다. 일반적으로 스프린트 기간은 적게는 1~2주, 길게는 한 달 정도로 설정한다.
일일 스크럼 미팅은 개발원들이 늘어지는 것을 방지하기 위해 스탠드업 미팅 형식으로 진행하는 경우가 많다. 매일 정해진 시간에 정해진 장소에 모여 15~20분 동안 간단하고 빠르게 진행한다. 어제 했던 일과 오늘 할 일, 수행 중 문제점이나 장애 요인 등을 공유하며 문제가 있을 경우 미팅 후 바로 해결한다.
스프린트 리뷰는 스프린트가 종료되었을 때 개발팀이 스프린트 동안 개발한 기능을 고객을 포함한 이해관계자들에게 보여주고 피드백을 받는 과정을 말한다. 고객은 자신이 요청한 요구사항이 해당 스프린트 동안 제품이 잘 반영되었는지 평가한 후 피드백을 하면 프로덕트 오너는 고객의 피드백이나 여러 사항들을 정리하여 다음 스프린트에 반영되도록 제품 백로그를 다시 갱신한다.
스프린트 리뷰가 제품 기능에 대한 회고라면, 스프린트 리뷰 후 프로젝트를 진행하면서 좋았던 점이나 문제점, 미진한 점 등을 도출함으로써 다음 스프린트를 보다 더 나은 방향으로 개선할 수 있도록 하는 과정을 말합니다.
스프린트는 꾸준함을 갖기 위해서 한 달 또는 그보다 짧은 기간으로 고정된 길이를 가진다. 스크럼 가이드에서 스프린트 동안 하지 말아야 할 것과 해야 할 것을 다음과 같이 이야기했다.
스프린트 목표 달성을 저해하는 변경을 해서는 안된다.
품질을 떨어뜨려서는 안 된다.
필요한 수준까지 프로덕트 백로그를 정제해야 한다.
범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.
스프린트를 진행하게 되면 적어도 한 달에 한 번은 프로덕트 목표 대비 진척을 점검하고 조정을 할 수 있기 때문에 프로젝트 진척에 대한 예측 정확도를 높일 수 있다. 스프린트 기간을 너무 길게 잡으면, 스프린트 목표가 효력이 없어지거나 복잡도가 늘어나고 리스크가 높아질 수 있다. 더 짧은 스프린트 기간일수록 더 많은 학습 기회를 가질 수 있고, 짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있다. 스프린트 기간에 대한 정답이 있는 것은 아니다. 내가 가진 프로덕트에게 적합한 기간을 찾아 스프린트를 진행하되 중간 점검을 계속 진행하면서 목표 대비 진척을 확인하고, 원하는 목표를 달성하는 것이 중요할 것이다.
스크럼의 과정에서 PM에게 가장 중요한 업무는 무엇일까? 스크럼 가이드에 따르면 우선순위에 따라 제품 백로그를 효과적으로 관리하는 것에 가장 큰 책임 가질 뿐만 아니라 다음과 같은 사항들도 중요하다고 한다.
프로덕트 목표를 세우고 명쾌하게 소통하는 것
제품 백로그 아이템을 생성하고 분명하게 소통하는 것
제품 백로그 아이템을 우선순위에 따라 정렬하는 것
제품 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것
스크럼 팀에서 PM은 프로덕트 목표를 세우고, 그에 따른 제품 백로그의 우선순위를 정한 후 팀원과 이해관계자들이 모두 이해하고 잘 따를 수 있도록 커뮤니케이션하는 것까지 모두 다 중요하다고 할 수 있다. 나는 그중에 가장 중요한 것을 꼽으라고 하면 프로덕트의 목표를 세우는 것이라고 생각한다. 물론 맨 처음 시작하는 첫 단추여서 그런 것도 있다. 하지만 팀원의 역량과 시간, 자원을 생각하지 않고 너무 터무니없이 높은 목표를 설정하게 되면 전체적인 팀원의 사기가 떨어지게 된다. 그렇다고 적당히 할만한 목표나 너무 쉬운 목표를 잡게 되면 팀원들이 해이해질 수 있다. 너무 높지도 낮지도 않은 적당한 선을 찾아서 목표를 정하는 것이 PM에게 중요한 것이 아닐까? 하고 생각한다.
참고자료