[Day30 w8d2] 스크럼 프레임워크와 스프린트_코드스테이츠 PMB 10기

럭비에서 유래한 용어 '스크럼'

 

변화와 혁신이 숨가쁘게 이루어지는 IT업계를 비롯한 많은 스타트업에서는 애자일하게 제품 개발을 하기 위하여 스크럼 프레임워크를 많이 채택한다. 럭비에서 유래된 용어 스크럼은 위 사진과 같이 팀원들끼리 촘촘하고 굳건하게 어깨를 맞대는 대형을 의미한다. 경기 중 빠르게 경기를 재개할 때 쓴다고 하는데, 스크럼을 짠 팀원들은 재빨리 한가운데 위치한 공을 확보해야 한다.

 

이 사진을 접하고 보니 프레임워크로써의 스크럼이 더 와닿는다. 10명 내외 인원으로 구성되는 스크럼 팀은 짧은 시간(스프린트 기간이라고 한다) 내에 하나의 결과물을 내기 위해 다같이 고군분투한다. 이 과정에서 PM(혹은 PO)는 스크럼 팀의 가치를 극대화하기 위하여 스크럼을 최적으로 관리해야할 책임을 갖는다.    

---

스크럼 프레임워크

혁신적인 제품과 서비스 개발 방식인 Agile 방법론의 대표적인 방식으로 팀이 중심이 되어 개발의 효율성을 높인다는 의미를 가진다. 이러한 스크럼 프레임워크를 활용하는 스타트업에서는 기존의 기업에서처럼 업무에 따라 딱 나누어서 구분되는 팀이 아닌, 프로덕트 팀(명칭은 다를 수 있다)이라는 한 팀 안에 개발, 디자인과 같이 하나의 프로덕트를 개발하기 위해 필요한 인력을 배치하고 구성한다. 즉 하나의 프로젝트를 위하여 구성되는 TF 팀과 같이 빠른 호흡으로 태스크를 진행하는데 이것이 계속 지속되는 것이라고 이해할 수 있었다. 

 

스크럼 프레임워크는 우리 팀이 고객의 문제 해결을 위하여 솔루션을 빠르게 도출하고 실현시키는데 의미가 있다. 사람 중심으로 프로젝트가 진행되며 개발 작업에 관한 모든 것을 스스로 해결하고자 노력한다.

 

프로덕트를 개발하는데 있어 스크럼 프레임워크가 적용되는 흐름은 아래와 같다.

스크럼 프레임워크 플로우 

1. 스프린트 계획회의 - 사용자 스토리 & '제품' 백로그 작성 
2. '스프린트' 백로그 작성
3. 데일리 스크럼 미팅
4. 스프린트 리뷰
5. 스프린트 회고 

먼저 스프린트 계획회의에서 사용자 스토리를 기반으로 제품 백로그를 작성한다. 제품 백로그는 단순히 프로덕트를 개발함에 있어 해야할 일 목록 뿐만 아니라, 관련된 이해관계자의 요구사항까지 모두 포함한다. (나는 프로덕트 개발 시 진행해야 하는 개발 관련 목록만 해당하는 줄 알았다) 제품 백로그는 사용자 스토리 중심으로 작성하여 팀 구성원 모두가 이해할 수 있어야 하고, 그 일을 진행해야 하는 근거로 활용될 수 있다. 

 

제품 백로그에서 결정된 우선순위에 따라 스프린트 기간 동안에 해야 할 일에 대한 목록을 스프린트 백로그라고 한다. 즉 제품 백로그보다 더 짧은 기간동안에, 스프린트 목표를 달성하기 위해 설정된 세부 목록이라고 볼 수 있다. 

 

스프린트 기간 동안에는 프로젝트가 어떻게 진행되고 있는 지, 어떻게 진행됐는 지 점검하고 피드백하기 위하여 다양한 미팅이 이루어진다. 데일리 스크럼 미팅, 스프린트 리뷰, 스프린트 회고.

 

 

데일리 스크럼 미팅

데일리로 이루어지는 데일리 스크럼 미팅은 그 전 날 어떤 일을 진행했는 지, 당일에 진행할 일은 무엇인 지 나누는 시간이다. 서로 간의 이슈사항을 바로 공유하여 후에 발생할 수 있는 리스크를 줄일 수 있다. 

스프린트 리뷰

스프린트가 종료되었을 때 새롭게 만들어졌을 결과물을 가지고 팀 내에서 발표하고 피드백을 주고받는 시간이다. 유저스토리에 따라 고객의 문제와 해결점을 잘 반영하였는지 평가하게 되며, 미흡할 경우 다음 스프린트에 참고할 수 한다.

스프린트 회고 

스프린트 리뷰 이후로 프로젝트의 '과정'에 대해 회고하는 시간으로, 스프린트 기간 내에 프로젝트가 진행되면서 좋았던 점이나 부족했던 점등을 나누며 다음 스프린트에 개선할 수 있도록 하는 것이 목표이다.

 

---

 

PM은 스크럼과 스프린트(전력질주)를 무사히 이끌어야 하는 "코치"이다

스크럼은 자율성을 가진 업무 방식이기에 자칫하면 목표를 잃고 흐트러질 수 있다. 실례로 스포티파이라는 해외의 유명한 음악 스트리밍 회사는 애자일하게 회사를 운영할 수 있는 조직구조 체계를 갖췄지만, 팀 내 중간관리자의 역할을 해줄 수 있는 코치가 없었기 때문에 실패한 스쿼드라고 평가받았다.   

 

따라서 PM(혹은 PO)는 스크럼을 관리하는데 있어 커뮤니케이션과 자원활용능력을 적절히 발휘할 수 있어야 한다. 

1. 제품 백로그 작성 후 우선순위 설정
2. 스프린트 목표(수행되어야 할 제품 백로그)에 따라 스프린트 기간 설정
3. 스프린트 기간 내 스크럼 팀 소통 활성화 
4. 이해관계자와의 소통 조율

 

스프린트 진행 시 가장 주의해야 할 점은 "신뢰와 투명성"이다.  

실제 스프린트가 진행되는 과정에서 중요한 부분은 스크럼 팀 내 팀원들간의 신뢰와 소통의 투명성이라고 느꼈다. 스프린트는 짧게는 1주로도 이루어진 기간동안 모든 팀원들은 하나의 동일한 목표를 향해 집중력 있게 달려가야 한다. 그렇기에 개인의 일 진행사항이라던가, 문제가 있다면 지체없이 공유되어야 한다. 

 

이는 팀원들 간의 신뢰를 기반으로 원활히 이루어질 수 있다고 생각한다. 만약 데일리 스크럼 미팅이 다른 팀원은 얼만큼의 일을 하고 있는지, 그들은 일을 잘하고 있는지 평가의 시간으로 진행된다면 투명하게 전달하지 못할 것이고 이는 결국 서로의 신뢰가 저하되는 악순환으로 이어질 것이다.

 

두 번째로 팀원들 간에 신뢰가 쌓여있다면 숨가쁘게 흘러가는 스프린트 기간에 협업 시너지 효과는 더 상승된다고 본다. 모두가 하나의 결과를 향해 함께 일하고 있다고 느낄 때 프로덕트에 대한 애정도는 상승할 것이고 그만큼 결과물의 퀄리티를 비롯해 여러 가치창출에도 긍정적인 영향을 미치는 것은 당연한 결과이다.(실제로 나도 이전 회사에서 일할 때 팀장님에 대한 신뢰가 높았을 때 스스로 더 열심히 했었다.)