[코드스테이츠 PMB 14] Daily
이 주전부터 데이터로 근거를 제시하는 PM을 꿈꾸면서 [칼퇴족 김대리는 알고 나만 모르는 SQL]이라는 SQL 관련 기초 도서를 읽었다.
내용을 소개하려는건 아니고, 책의 진행 방식이 재미있어서 이야기를 해보려고 하는데 해당 책을 펴는 순간부터 영업 지원팀으로 갑자기 발령받은 '인문학도 김 대리'로 변신하게 된다. 성격이 급한 영업지원팀 장부장은 김 대리(=나)에게 데이터에 관련한 질문을 와다다 쏟아낸다.
SQL의 S도 모르는 김 대리는 기어들어가는 목소리로 '모른다'고 대답했고, 이를 안타깝게 바라보던 이 차장님은 그날부터 2주간 김 대리의 SQL 마스터를 위한 김대리의 사부님이 된다.
이런 책의 전개 방식이 아주 흥미로웠다. 입사 후 모르는 부분에 대해 2주동안 집중 코치해주는 천사 사수를 영접한 것만 같았다. (옆 사진처럼 가끔 이 차장님의 급발진에 당황한 적은 많지만,,)
그래서 오늘은 이 차장처럼 스크럼 프레임워크에 대해 알려주는 형식으로 글을 작성했다. (나,,,심심한가,,?)
김피엠, 난 배피오요.
스크럼 마스터는 나에게 맡겨줘!
해당 글은 Ken Schwaber & Jeff Sutherland의 스크럼 가이드를 참고하여 작성되었습니다:)
소프트웨어는 하드웨어와는 다르게 시장의 변화나 예기치 못한 상황에 대한 대처가 상대적으로 쉽다. 그래서소프트웨어 프로덕트를 보유한 스타트업들은 시시각각 격변하는 시장에 효과적으로 대응하기 위해 애자일(agile: 민첩한) 문화를 선호하는 경향이 있다.
그러나, 아무리 스타트업이라도 변화가 쉽지만은 않다. 하나의 변경 사항, 새로운 목적의 생성에도 조직의 모든 이해관계자들이 하나의 목표를 인식, 이해, 협업하는 과정은 꽤나 손이 많이 가는 힘든 일이다.
그래서 나타난 것이 스크럼이다. 스크럼은 애자일 방법론에서 쓰이는 프로세스 도구 중 하나로, 하나의 목적을 이루기 위해 협력해서 작업하는 형태로 진행되며, 효율적인 업무를 위해 일을 작은 단위로 쪼개어 짧은 주기 동안 진행하고 지속적으로 반복하여 개발해가는 방식이다.
그렇다면 애자일하게 일할 수 있도록 하는 스크럼은 어떻게 진행되는 것일까?
해당 도식과 같이 스크럼은 크게 5가지 단계로 나누어진다.
1) 스프린트 계획 회의
: 스프린트 계획 회의에서 프로덕트 오너가 사용자 스토리를 기반으로 제품 백로그를 작성한다. 제품 백로그는 이해관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록을 말한다.
일반적으로 유저스토리의 작성은, '나는 ~로써 ~하기 위해 ~하고 싶다’라는 형식으로 작성하며 who, why, what 정보가 모두 포함되어 있는 것이며, 제품 백로그는 이 유저 스토리를 바탕으로 작성된다.
2) 스프린트 백로그 작성
: 제품 백로그에서 결정된 우선 순위를 기반으로 스프린트 동안 해야 하는 일에 대한 리스트를 스프린트 백로그라고 한다. 제품 백로그가 할 일 목록이라면, 스프린트 백로그는 짧은 기간 동안 할 일 목록이다. 일반적으로 스프린트 기간은 적게는 1주~2주 길게는 한 달 정도로 설정한다.
이후에는 스프린트 목표를 구현할 수 있도록 각각의 요구사항을 task 단위로 나누어 개발자들이 나눠서 작업을 수행한다. 벽 크기의 업무 보드 형식의 스프린트 백로그를 만드는 스크럼 보드를 통해 스프린트 백로그의 진행 상황을 시각화한다.
3) 데일리 스크럼 미팅
: 데일리스크럼 미팅은 개발원들이 늘어지는 것을 방지하기 위해 스탠드업 미팅 형식으로 진행된다. 매일 정해진 시간에 정해진 장소에 모여 15분~20분 동안 간단하고 빠르게 진행한다. 어제 했던 일과 오늘 할 일, 수행 중 문제점이나 장애요인 등을 공유하고, 문제 발생 시, 미팅 후 즉시 해결한다.
일일 스크럼 미팅을 통해 프로젝트 후반부 예기치 못한 문제를 예방한다. 일일 스크럼 미팅 시에 해당 그래프(주로 번다운 차트)를 팀원들과 함께 확인하고, PM은 일이 늦어지는 이유를 찾아내서 이슈를 해결한다.
4) 스프린트 리뷰
: 스프린트가 종료되었을 때 개발팀이 스프린트 동안 개발한 기능을 이해관계자들에게 보여주고 피드백을 받는 과정이다. 고객이 요청한 요구사항이 해당 스프린트동안 제품이 잘 반영되었는지에 대한 피트백을 프로덕트 오너가 정리하여 다음 스프린트에 반영되도록 제품 백로그를 다시 갱신한다. 스프린트 기간에 해내지 못한 것이 있어도, 모두 다시 하는 것이 아니라, 스프린트 리뷰를 통한 피드백과 새로운 우선순위를 정해서, 모두 종합적으로 우선순위를 나누고 스프린트의 기간과 프로젝트 양을 다시 정하게 된다. 한 주당 스프린트 리뷰 시간은 한 시간으로 제약되어 있으며 스프린트 리뷰를 준비하는데 30분을 넘지 않도록 해야 한다.
5) 스프린트 회고
: 스프린트 리뷰가 제품 기능에 대한 회고라면, 스프린트 리뷰 후 프로젝트를 진행하면서 좋았던 점이나 문제점, 미진한 점 등을 도출함으로써 우리 팀에 업무 방식에 관한 내용을 중점적으로 다룬다. 이를 통해 다음 스프린트를 보다 더 나은 방향으로 개선할 수 있도록 한다. 스프린트 회고 과정에서 PO는 중재 및 조정 역할을 하는 촉진자 역할을 하게 된다. 스프린트 회고 과정을 통해 스프린트 프로세스가 끊임없이 개선되도록 하여 변화하고 있는 환경에 더 능동적으로 적응할 수 있도록 이끈다.
대체로 프로덕트 오너는 프로덕트 백로그를 어떻게 효과적으로 관리할 수 있을지 고민하는 것이 주요하다.
그에 대한 구체적인 방법은 다음과 같다.
1) 프로덕트 목표를 세우고 명쾌하게 소통하기
2) 프로덕트 백로그 아이템을 생성하고 분명하게 소통하기
3) 프로덕트 백로그 아이템을 우선순위에 따라 정렬
4) 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것
1) 스프린트 목표 달성을 저해하는 '변경'은 안된다.
2) 서비스 품질을 떨어뜨려서는 안된다.
3) 필요한 수준까지 프로덕트 백로그를 정제해야 한다.
4) 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상한다.
5) 스프린트 기간은 짧게 잡는다.
6) 스프린트 목표가 효력이 없게 되면, 스프린트를 취소한다. 그리고 취소권한은 프로덕트 오너만이 가진다.
해당 문장은 내가책의 마지막 챕터에서 기대했지만, 나오지 않은 문장이다. 2주동안 이 차장님과 살을 부대끼며 SQL을 공부했는데,,,그리고, 이 차장님의 엄청난 급발진 질문들에 모두 답했는데,, 왜 이런 말을 듣지 못했을까..?
스크럼도 결국 애자일한 업무를 위한 방법론이다. 스포티파이의 실제 사례처럼 스크럼에 대한 기본 개념을 모두 알고 있어도, 이를 완벽하게 행하기는 어렵다. '사람들이 우리가 하는 일을 보고 그대로 따라하고 구현할 수 있는 프레임워크라고 생각할 때 걱정이 된다.'라는 Anders Ivarsson, Spotify 백서 3 의 공동 저자의 걱정처럼, 스크럼 그 자체를 그저 모방하는 것은 오히려 악영향을 끼칠 수 있다. 내부 조직의 팀워크 역량, 커뮤니케이션 정도, 팀 자율성 정도를 파악하고 이를 반영해 스크럼 과정을 전반적으로 관리, 조정할 수 있는 능력을 체화하는 것이 진정한 스크럼 마스터의 길이라고 생각했다. 또한, 반복적인 회고를 통해 우리 팀의 색을 반영한 업무 개선 사항을 찾는 것 또한 스크럼 마스터의 중요한 밑바탕이 될 것이다. 따라서 SQL도, 스크럼도 방법론만으로 마스터할 수는 없다. 방법론을 '잘' 적용하기 위해서 필요한 부수적인 능력, 예를 들자면 PM의 목표 지향적 사고, 고객 문제 해결, 설득 능력, 커뮤니케이션 등 복합적인 능력이 있어야 스크럼을 마스터 할 수 있겠다는 생각이 들었다.
해당 글은 커리어를 도와주는 시작 페이지 [서플]에 기고되었습니다:)
#PM부트캠프 #코드스테이츠 #PMB #PM #프로덕트매니저 #공감 #brunch #스크럼 #애자일 #스타트업 #서비스기획 #일상 #취준 #취준생 #직장인 #기획자 #기획