애자일하게 일하기, 스크럼(Scrum) [코드스테이츠 PMB 10기]
스크럼(Scrum)이란?
스크럼은 럭비에서 유래된 용어이다. 경기가 반칙으로 인해 잠시 중단되었을 때, 양 팀 선수들이 공을 중간에 놓고 어깨를 밀착해서 형성하는 전술 대형이다. 단어의 유래와 위 이미지에서 알 수 있듯이 스크럼은 팀워크와 책임감이 중요한 업무 프로세스 방법이다.
스크럼은 반복적이고 점진적인 방식을 쓴다. 전체적으로 업무를 수행하는데 필요한 모든 기술과 전문성을 갖출 수 있도록 사람들을 스크럼에 참여시키고, 필요에 따라 그러한 기술을 공유하고 습득한다.
스크럼에는 점검과 적응을 하기 위한 네 개의 공식 이벤트(스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고)가 이벤트의 하나인 스프린트 안에 포함된다. 이 이벤트들을 통해 경험주의적 스크럼의 기둥인 투명성 Transparency, 점검 Inspection, 적응 Adaptation을 현실로 실천한다.
투명성
업무를 실행하거나 일의 결과물을 받는 사람들에게 신규 업무 프로세스와 일이 무엇인지는 반드시 가시적이어야 한다.산출물의 투명성이 낮은 경우에 하는 의사결정은 가치를 떨어뜨리고 리스크를 높일 수 있다.
점검
잠재적으로 바람직하지 않은 변화와 문제점을 발견하기 위해서는 스크럼 산출물과 달성하기로 한 목표에 대한 진척을 반드시 자주 부지런하게 점검해야 한다.
적응
만약에 프로세스의 어떤 측면이 수용 가능한 범위를 벗어나거나 그 결과물이 받아들일 수 있는 수준이 아닌 경우, 진행하는 프로세스와 생산하고 있는 것들을 반드시 조정해야 한다.
스크럼팀
스크럼 조직의 기본이 되는 단위인 스크럼 팀은 적은 수의 인원으로 구성된다. 스크럼 팀은 한 명의 스크럼 마스터, 한 명의 프로덕트 오너, 그리고 개발자들로 구성된다. 스크럼 팀 내에는 하부 팀이나 수직구조가 없다. 스크럼 팀은 하나의 프로덕트 목표에 동시에 집중하는 전문가들의 모임이다.
스크럼 팀은 민첩할 수 있도록 작지만, 한 스프린트 내에 의미 있는 일을 완료할 수 있을 만큼 충분한 크기여야 한다. 일반적으로 10 명 또는 그보다 적은 수의 인원으로 구성된다. 만약 스크럼 팀이 너무 커지면, 이들을 다수의 스크럼 팀으로 재구성하는 것을 고려해야 하고, 각 팀은 하나의 동일한 프로덕트에 집중하도록 화합해야 한다. 그렇게 하여 동일한 프로덕트 목표와 프로덕트 백로그, 프로덕트 오너를 공유해야 한다.
스크럼 팀은 프로덕트와 관련한 모든 활동들에 책임을 진다. 이해관계자와의 협력, 검증, 유지보수, 운영, 실험, 연구개발과 같이 필요한 모든 것들에 대해서다. 그들은 서로 화합하며 스스로 일을 관리할 수 있는 권한을 조직으로부터 부여받는다. 매 스프린트마다 지속 가능한 속도로 일하는 것이 스크럼 팀의 집중과 꾸준함을 향상한다.
스크럼 팀 전체는 매 스프린트마다 가치 있고 유용한 증가분을 만들어내는 것에 책임을 진다. 스크럼은 스크럼 팀 내에 세 가지 특정한 직책을 정의한다: 개발자들, 프로덕트 오너, 스크럼 마스터
프로덕트 오너(Product Owner)의 역할
프로덕트 오너는 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는다. 이 업무를 수행하는 방법은 조직, 스크럼 팀, 개인에 따라 다를 수 있다.
프로덕트 오너는 '해야 할 일들의 목록(product backlog)'을 효과적으로 관리하는 것에도 책임이 있는데, 다음 사항들을 포함한다.
- 프로덕트 목표를 세우고 명쾌하게 소통하는 것
- 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
- 프로덕트 백로그 아이템을 우선순위에 따라 정렬
- 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것
프로덕트 오너는 위에 나온 일을 직접 하거나 혹은 다른 사람들에게 그 책임을 위임한다. 어떤 식으로 하든지 최종 책임은 프로덕트 오너가 갖는다. 또한 성공적으로 일을 하기 위해서는 조직 전체가 반드시 프로덕트 오너의 결정을 존중해야 한다. 프로덕트 오너가 내린 결정들은 프로덕트 백로그의 내용과 우선순위에 따라 정렬한 것을 통해 확인할 수 있다. 또한 스프린트 리뷰 때에 점검 가능한 증가분을 통해서도 볼 수 있다. 프로덕트 오너는 프로덕트 백로그와 연관된 많은 이해관계자들의 요구를 대표한다. 따라서 프로덕트 백로그를 변경하고 싶은 사람들은 프로덕트 오너를 설득하여야 한다.
스프린트
스크럼 팀이 한 가지의 일을 완수하는 전 과정을 스프린트라고 한다. 스프린트는 꾸준함을 갖기 위해 1주~4주의 기간으로 고정된다. 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작한다.
스프린트 동안 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 프로덕트 목표를 달성하기 위해 필요한 모든 업무를 수행한다.
스프린트 기간 동안에는:
- 스프린트 목표 달성을 저해하는 변경을 해서는 안 된다
- 품질을 떨어뜨려서는 안 된다
- 필요한 수준까지 프로덕트 백로그를 정제해야 한다
- 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다
스프린트를 진행하게 되면 적어도 한 달에 한 번은 프로덕트 목표 대비 진척을 점검하고 조정을 할 수 있기 때문에 프로젝트 진척에 대한 예측 정확도를 높일 수 있다. 스프린트 기간을 너무 길게 잡으면, 스프린트 목표가 효력이 없어지거나 복잡도가 늘어나고 리스크가 높아질 수 있다. 더 짧은 스프린트 기간일수록 더 많은 학습 기회를 가질 수 있고, 짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있다. 각 스프린트는 짧은 프로젝트와 같이 여겨질 수 있다.
스프린트 플래닝
최소 1주일에서 최대 1 달이라는 기간 동안 우리 팀이 집중해서 일하는 기간을 스프린트라고 한다. 그리고 스프린트 플래닝이란 바로 이 스프린트 기간 동안 우리가 어떻게 일을 해 나갈지, 모든 팀원이 모여 스프린트 첫날에 업무 계획을 공유하고 소통하는 것을 말한다.
스프린트 계획은 다음과 같은 주제를 다룬다.
- 주제 1: 이 스프린트가 왜 가치가 있는가?
프로덕트 오너가 이번 스프린트에서 프로덕트가 어떻게 가치와 효용성을 높일 수 있는지를 제안한다. 전체 스크럼 팀원들이 협력해서 스프린트 목표를 정의한다. 스프린트 목표를 정의할 때에는 이 스프린트가 이해관계자들에게 중요한 이유를 담아야 한다. 스프린트 목표는 반드시 스프린트 계획을 마치기 전에 결정되어야 한다.
- 주제 2: 이 스프린트의 완료 Done는 무엇인가?
프로덕트 오너와 논의를 하면서 개발자들이 이번 스프린트에 포함할 프로덕트 백로그 아이템을 선정한다. 스크럼 팀은 이 과정 중에 프로덕트 백로그 아이템을 정제할 수 있다. 이를 통해 내용을 더 정확히 이해하고, 할 일에 대한 확신을 가질 수 있다.
한 스프린트 내에 얼마나 완료할 수 있을지를 정한다는 것은 쉬운 일은 아니다. 그렇지만, 개발자들이 그들의 지난 성과와 다음번에 수용 가능한 업무량, 완료의 정의 Definition of Done에 대해 많이 알면 알수록 그들이 스프린트를 예측할 때에 더 확신을 가질 수 있을 것이다.
- 주제 3: 선정한 일을 어떻게 완료할 것인가?
개발자들은 선정한 모든 프로덕트 백로그 아이템들을 가지고, 완료의 정의를 충족하는 증가분을 만드는 데에 필요한 업무들을 계획한다. 대체적으로 이것은 프로덕트 백로그 아이템을 하루 안에 12 완료할 수 있는 크기로 더 작게 세분화하는 것으로 이루어진다. 중요한 것은 이 과정은 절대적으로 개발자들의 재량이다. 다른 누구도 개발자들에게 프로덕트 백로그 아이템을 어떻게 증가분으로 만들지에 대해 정해주어서는 안 된다.
스프린트 백로그
일주일에서 한 달이라는 기간 동안 우리가 해야 할 일 목록
스프린트 목표, 스프린트를 위해 선정한 프로덕트 백로그 아이템들, 그리고 이것을 완료하는 것에 대한 계획을 모두 포함하여 스프린트 백로그라고 한다. 스프린트 계획은 최대 시간이 정해진 Timeboxed 이벤트로 일 개월 기간의 스프린트인 경우 8 시간이 넘지 않도록 한다. 스프린트 기간이 더 짧은 경우 보통 스프린트 계획 시간도 더 짧다.
데일리 스크럼
하루 시작 전 모든 팀원들이 모여서 현재 일의 진행상황과 직면한 문제를 서로 공유하는 자리
데일리 스크럼의 목적은 스프린트 목표 대비 진척을 점검하고, 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정하는 것이다. 데일리 스크럼은 복잡성을 줄이기 위해 같은 시각에 같은 장소에서 15분간 스프린트 기간의 모든 근무일마다 수행한다. 데일리 스크럼은 팀의 소통을 향상하고 팀이 가지고 있는 장애물을 식별하며 신속한 의사 결정을 촉진하여 별도로 다른 미팅을 할 필요성을 줄여준다.
스프린트 리뷰
스프린트를 진행한 우리 팀원들 뿐만 아니라, 고객이나 혹은 회사의 의사결정권자와 같이 프로덕트에 관계된 이해 관계자들이 함께 모여, 인크리먼트를 살펴보고, 다음 스프린트는 어떻게 효율적으로 진행할지 이야기한다.
스프린트 리뷰의 목적은 스프린트의 결과물을 점검하고 향후에 적응할 것들을 결정하는 것이다. 스크럼 팀은 주요 이해관계자들에게 일의 결과물과 논의된 프로덕트 목표 대비 진척을 보여준다.
스프린트 리뷰 동안 스크럼 팀과 이해관계자는 이번 스프린트에 성취한 것과 그동안 비즈니스 환경에서 변한 것이 무엇인지를 검토한다. 이 정보에 기초하여 참여자들은 다음으로 무엇을 할 것인지 협력하여 논의한다. 새로운 기회를 창출하기 위해 프로덕트 백로그를 수정할 수도 있다. 스프린트 리뷰는 이와 같은 활동을 하는 시간이므로 발표만 하고 끝나지 않도록 해야 한다.
스프린트 리뷰는 스프린트의 끝에서 두 번째로 하는 이벤트이다. 최대 시간이 정해진 이벤트로 일 개월 기간의 스프린트인 경우 4 시간이 넘지 않도록 한다. 스프린트 기간이 더 짧은 경우, 보통 스프린트 리뷰 시간도 더 짧다.
스프린트 회고
스프린트 리뷰가 끝나고 나면, 우리 팀원들끼리만 모여 우리가 이번 스프린트에 어떻게 일 했는지. 어떻게 하면 앞으로 더 잘 일할 수 있을지 이야기하는 시간을 갖는다.
스프린트 회고의 목적은 품질과 효율을 높이기 위한 방법들을 계획하는 것이다. 스크럼 팀은 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 완료의 정의에 대해 지난 스프린트가 어떻게 진행되었는지를 점검한다. 업무 영역 별로 점검하는 사항들은 차이가 날 수 있다. 팀이 잘못된 방향으로 가게 된 가정들을 확인하고, 그것들의 근본 원인을 찾아낸다. 스크럼 팀은 무엇이 잘 진행되었는지에 대해서도 논의한다. 어떤 문제를 만났고 그 문제를 어떻게 풀었는지(또는 풀지 못했는지)에 대해 의견을 나눈다.
스크럼 팀은 그들의 효율을 향상하기 위해 가장 도움이 되는 변화를 찾아야 한다. 가장 영향이 큰 개선책을 최우선으로 고려해야 한다. 이런 개선책을 다음 스프린트에 수행하도록 스프린트 백로그에 추가할 수도 있다. 스프린트 회고를 마지막으로 스프린트가 종료된다. 최대 시간이 정해진 이벤트로 일 개월 기간의 스프린트인 경우 3 시간이 넘지 않도록 한다. 스프린트 기간이 더 짧은 경우, 보통 스프린트 회고 시간도 더 짧다.