애자일(Agile) 방법론 - 스크럼

이 포스팅은 "애자일 조직은 이렇게 일합니다" 도서를 읽고 작성한 글입니다.

 

애자일 방법론을 채택한 팀이라면, 아마 스크럼 미팅을 진행하고 있을 것이라 생각합니다.

스크럼 미팅에서는 "내가 하고 있는 개발일에 대한 전반적인 사항"을 공유하고, 다른 동료들에게도 동일하게 공유받습니다.
그럼 스크럼은 무엇을 의미하는 걸까요?

 

스크럼

스크럼은 가볍지만 체계적이고 잘 짜여진 팀 워크플로우 관리 방식입니다.
특정 기술 실천법을 강요하지 않고, 팀에서 일을 어떻게 다뤄야하는지 조정하고 팀이 사용하는 특정 열할과 업무 조정에 필요한 방법을 규정합니다.

스크럼은 요구사항을 담당하는 PO가 만든 제품 백로그로 시작됩니다.

제품 백로그는 스크럼팀이 전달해야 하는 요구사항, 진행 중인 요구사항, 히처, 기능, 개선사항과 수정사항의 묶음입니다.
즉, 앞으로 할 일이 됩니다.

제품 백로그는 모든 요구사항의 완벽한 리스트를 제공하는 대신, 가장 중요하고 가장 시급하며 가장 ROI가 높은 요구사항에 초점을 둡니다.

 

스프린트

스크럼팀은 1~4주의 반복적인 시간 주기인 "스프린트" 안에서 작업을 수행합니다.
개인적인 경험으로는 2주 정도의 주기가 가장 많았던 것 같고, 적당했던 것 같습니다.

스프린트는 "스프린트 계획 회의" 로 시작합니다. 이 회의에 스크럼팀은 제품 백로그를 검토하고, 스프린트에 포함될 작업을 고릅니다.
스프린트가 종료되었을 때 배포될 대상을 선정하고 스프린트 수행에 필요한 계획들을 세웁니다.

그리고 스프린트의 초점을 간결하고 명확히 담아낸 "스프린트 목표"를 정의합니다.
이것은 스프린트 진행중에 돌발 상황이 전개되었을 때, 스프리트 세부사항을 재협상하기 위한 원칙적인 근거를 제공합니다.

스프린트가 진행되는 동안에는 PO가 스프린트를 취소하고 다시 시작하기로 동의하지 않는다면 그 어떤 요구사항을 더하거나 빼지 않습니다.

상호 합의안에 변경될 수는 있지만, 기본은 계획된 스프린트를 그대로 진행하는 것으로 합니다.

 

일일 스크럼

스크럼팀은 스프린트 기간동안 "일일 스크럼" 혹은 "일일 스탠드업" 이라고도 하는 만남을 가집니다.
제한시간 15분동안 스프린트 목표를 향한 진행상황을 점검하는 데 초점을 둡니다.

내용은 보통 아래 세 가지 질문에 대한 대답으로 제한합니다.
"어제는 무엇을 했나", "오늘은 무엇을 할 것인가?", "일을 방해하는 요소가 있나?" 입니다.

예전 회사들과 지금까지 위와 같은 형태의 회의를 매번 진행했습니다.
이 질문들을 제외한 토론은 다른 자리에서 가지는 것이 일반적이지만, 팀 혹은 회사마다 다릅니다.

실제로 15분만 딱 사용하고 스크럼 회의가 끝나는 경험은 거의 없었던 것 같습니다.
인원이 많아서, 이슈에 대해 논의하기 등등의 이유로 말이죠.

 

스프린트 리뷰

팀은 스프린트를 진행하는 내내 작업을 높은 품질로 유지합니다.
스프린트가 끝날 무렵, 작업은 팀의 "완료 정의"를 만족하는 "릴리스 가능한" 품질에 도달해야 합니다.

스프린트가 종료될 때 마다 릴리스할 필요는 없지만, 품질은 우수해야 한다는 것입니다.
다음 스프린트에서 이전 스프린트에서 구현한 것을 더 이상 변경하지 않고 릴리스할 수 있을 만큼의 품질을 갖춰야 합니다.

스프린트가 끝나면 스크럼팀은 "스프린트 리뷰" 혹은 "스프린트 데모" 회의를 통해 작업의 가시적인 결과를 보여줍니다.
프로젝트의 이해관계자를 초대하여 그들의 관점을 공유하고 피드백을 받습니다.

팀은 스프린트 리뷰 동안 얻은 피드백을 사용해 제품과 프로세스와 실무를 개선합니다.

 

스프린트 회고

스프린트의 마지막 이벤트는 "스프린트 회고" 입니다. 이것을 통해 스프린트의 성공 유무를 검토합니다.
이것을 통해 팀은 소프트웨어 개발에 사용하는 프로세스를 개선할 수 있는 기회를 가집니다.

팀은 이전 개선사항을 검토하여 각각을 계속 진행할지 혹은 되돌릴지를 결정합니다.
또한 다음 스프린트에 시행하는 새로운 프로세스 변경에 동의합니다.

 

스크럼의 역할들

PO는 스크럼팀과 비즈니스 관리, 고객, 기타 이해관계자들의 인터페이스 역할을 합니다.
스크럼팀이 만들어 내는 가치를 극대화하는 방법으로 제품을 정의하는 중요한 책임을 부여받습니다.

스크럼 마스터는 스크럼 실행을 담당합니다. 스크럼 이론, 실천법 등을 팀이나 더 큰 조직이 이해할 수 있도록 돕습니다.
그리고 프로세스 관리, 프로세스 시행, 장애물 제거, 다른 스크럼팀 코칭을 돕습니다.
시간이 충분한 스크럼 마스터는 기술적인 기여자가 될 수도 있습니다.

개발팀은 백로그 항목을 직접 구현할 수 있는 교차기능적인 개인 기여자들로 이루어집니다.

종합하면, 스크럼팀은 3~9명의 개발팀과 스크럼 마스터, PO로 구성됩니다.

 

실패하는 스프린트, 성공하는 스프린트

아마 모두가 스프린트를 성공적으로 마치고 싶어할 것입니다.
어떤 스프린트가 실패하고 어떤 스프린트가 성공할 수 있을까요?

스프린트가 어떻게 구성되고 어떻게 진행되는지를 이해하면, 실패하는 요소들을 어렴풋이 알 수 있습니다.

일일 스크럼 미팅을 하지 않는다거나, 회고를 하지 않는다거나, PO가 없거나 또는 비효율적인 PO가 있다는 등의 이유가 될 수 있습니다.  그리고 백로그를 잘못 정의하는 케이스, 잘못된 스프린트 주기 설정 등등 다양한 요소가 있겠죠.

하지만 이런 수 많은 요소들을 완벽하게 준비하기란 정말 어려운게 사실이겠죠.

반대로, 이런 실패 요소들을 반대로 한다면 성공하는 스프린트에 가까워지거나, 스프린트를 성공할 수 있을 것입니다.

효과적인 PO, 좋은 백로그 정의, 효율적인 일일 스크럼, 적당한 스프린트 주기 등이 그 요인이 될 수 있을 것입니다.

 

오늘은 스크럼과 스프린트에 대해 알아보았습니다.
모두 성공적인 스프린트를 향해 화이팅해봅시다. :)