■ 스크럼이란?
스크럼은 애자일 소프트웨어 개발 방법론의 종류중 하나로 반복적이고 점진적인 개발방법을 말한다. 전통적인 소프트웨어 모델과 달리 각 반복주기가 종료될 때마다 부분적으로 완성된 결과물이 만들어진다. 애자일에서는 반복주기를 이터레이션이라고 하지만 스크럼에서는 반복주기를 스프린트(sprint)라고 하며 주로 1~4주로 구성된다.
스크럼에는 제품 책임자, 스크럼 마스터와 개발팀이라는 3가지 역할이 있으며 이것들을 합쳐서 스크럼 팀이라고 부른다.
1. 제품 책임자(product owner)
- 제품 백로그를 관리, 작성하고 이해관리자로부터 요구사항을 추출하여 제품 백로그에 반영한다.
- 요구사항에 우선 순위를 매기고 각 스프린트마다 우선순위를 관리, 조정한다.
2. 스크럼 마스터(servant leader)
- 일반적인 프로젝트 관리자들과는 다르게 개발 팀원들을 코칭하고 개발팀이 프로젝트 진행중 문제가 생겼을 때 잘 해결할 수 있도록 도와주는 역할을 한다.
- 개발팀원들이나 스크럼에 참여하는 사람들이 스크럼을 제대로 알고 수행하고 있는지에 대한 책임을 가지며 스크럼의 이론, 규칙들을 잘 따르도록 보장해야한다.
3. 개발팀
- 고객으로부터 받은 요구사항을 가지고 제품을 개발, 테스트하는 팀으로 주로 5~7명으로 이루어진다.
- 개발팀에는 따로 리더가 정해져 있지 않으며, 팀원들이 자기 조직화(self-organization)되어 있어 외부의 명령 없이 스스로 스프린트 목표를 달성하기 위해 최상의 방법을 결정한다.
■ 스크럼 진행 과정
이미지 출처 : https://brainhub.eu/blog/differences-lean-agile-scrum/
1. 제품 백로그(product backlog) 작성
이미지 출처 : http://scruminfo.blogspot.com/2014/04/how-should-items-be-arranged-in-product.html
- 제품 책임자(product owner)가 사용자 스토리를 기반으로 제품 백로그를 작성한다.
제품 백로그는 이해관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록을 말한다. 제품 백로그는 우선순위를 가지며 위에 있을 수록 우선순위가 높고 상세화 되어있다.
사용자 스토리란 고객이나 개발자가 모두 이해할 수 있도록 고객이 작성하는 것이다. 사용자 스토리는 카드, 대화, 테스트 라는 세 측면을 이용하여 작성한다.
카드 (Card)
- 고객의 요구사항을 문서화하기 보다는 표현하기 위한것으로 대화의 매개체 역할을 한다.
- ‘나는 ~로써 ~하기 위해 ~하고 싶다’라는 카드를 작성하며 who, why, what 정보가 모두 포함되어 있어야 한다.
ex) 학생으로서 나는 학교에 지하철로 통학하기 위해 교통카드를 구입하기를 원한다.
대화(Conversation)
- 대화는 카드 내용의 세부사항을 구체화시킴으로서 인수기준이 정해지고, 이해의 공유(shared understanding)를 촉진시킨다.
테스트(Confirmation)
- 대화에서 논의한 인수 기준을 통해 스토리의 완료 여부를 판단한다.
- 인수 기준이 만족되었는지 여부를 확인하기 위해 긍정적인 테스트와 부정적인 테스트를 모두 사용해야 한다.
- 사용자 스토리에 대한 스토리 포인트(Story Point)를 추정하고 스토리 포인트를 이용하여 개발 규모를 추정한다.
스토리 포인트는 사용자 스토리를 구현하는데 걸리는 상대적인 노력이나 일의 양, 복잡도, 불확실성 등을 종합적으로 고려해서 나타낸 값을 의미한다. 스토리 포인트는 아래 카드로 플래잉 포커 게임(playing pocker game)을 이용해서 추정할 수 있다.
이미지 출처 : http://www.insightbook.co.kr/400
플래잉 포커 게임은 개발 그룹으로 부터 스토리 포인트에 대한 합의를 이끌어 내는 과정이다. 카드 숫자는 주로 피보나치 수열을 사용하며 0이면 ‘이미 완료된 것이다’라는 뜻이고 ?이면 ‘잘 모르겠다, 아무 생각이 없다’라는 뜻이다. 커피가 그려진 카드는 ‘잠시 쉬었다가 하자’는 의미이다.
스토리 포인트를 추정하는 과정
- 사용자 스토리를 낭독하고 질문과 답변을 한다.
- 각자사용자 스토리에 맞다고 추정하는 스토리 포인트 카드를 선택한다.
- 카드를 동시에 공개하고 스토리 포인트 추정치가 다를 경우 가장 높은 추정치를 정한 팀원과 가장 낮은 추정치를 내놓은 팀원이 이유를 설명하고 수렴할 때까지 반복한다.
- 사용자 스토리를 제거하거나 새로 추가할 때, 또는 사용자 스토리의 크기가 클 때 백로그 정제 회의(Backlog gromming/refinement meeting)를 통해 스토리 포인트를 다시 산정한다.
백로그 정제 회의(Backlog gromming/refinement meeting)에서는 다음 스프린트에 완성할 사용자 스토리를 정제하는 작업을 한다. 한 스프린트 내에 완성할 수 없는 큰 사용자 스토리(=epic)를 작은 사용자 스토리로 분할하고 분할한 사용자 스토리들의 스토리 포인트를 추정한다. 새로운 사용자 스토리에 대한 스토리 포인트를 추정하고 우선순위를 조정한다.
2. 스프린트 계획 회의
- 제품 책임자, 스크럼 마스터, 개발팀이 참여하며 제품 백로그를 기반으로 스프린트 목표와 스프린트 백로그를 계획하는 회의이다.
- 스프린트 계획 회의는 스프린트 계획 파트1과 스프린트 계획 파트2로 나뉜다.
- 스프린트 계획 파트1에서는 스프린트 동안 무엇(what)을 할지 우선순위가 높은 아이템들을 검토하고 스프린트 목표를 정한다.
- 스프린트 계획 파트2에서는 스프린트 계획 파트1에서 결정한 무엇을 어떻게(how) 실행할지에 대해 정한다.
- 스프린트 계획 회의가 끝날 때쯤, 개발팀은 각 스프린트가 끝날 때마다 어떤 결과물을 내놓을 것인지에 대한 현실적인 목표를 정하는데 이것을 스프린트 약속(Sprint Commitment)라고 한다.
3. 스프린트 백로그(sprint backlog) 작성
- 제품백로그에서 결정된 우선순위를 기반으로 스프린트 동안 해야 하는 일에 대한 리스트를 스프린트 백로그라고 한다.
- 스프린트 목표를 구현 가능하도록 각각의 요구사항을 task 단위로 나누어 개발자들이 나눠서 작업을 수행한다.
- 많은 팀들이 벽 크기의 업무 보드 형식의 스프린트 백로그를 만드는데 이것을 스크럼 보드(Scrum Board)라고 한다.
이미지 출처 : https://manifesto.co.uk/agile-concepts-scrum-task-board/
4. 일일스크럼 미팅(daily scrum meeting)
- 일일스크럼 미팅은 개발원들이 늘어지는 것을 방지하기 위해 스탠드업 미팅 형식으로 진행된다.
- 매일 정해진 시간에 정해진 장소에 모여 15분~20분동안 간단하고 빠르게 진행한다.
- 어제 했던일과 오늘 할일, 수행중 문제점이나 장애요인 등을 공유하며 문제가 있을 경우 미팅 후 바로 해결한다.
- 일일 스크럼 미팅을 함으로서 프로젝트 후반부에 문제점이 갑자기 발생하는 것을 예방한다.
- 매일 개발 팀원들은 스프린트 백로그에 있는 현재 작업을 완료하기 위해 작업이 얼마나 남았는지 번다운 차트(Burndwon Chart)를 통해 진척도를 추적한다.
번다운 차트는 소멸차트라고도 부르며 한 스프린트동안 남아있는 작업량을 보여주는 그래프를 말한다.
번다운 차트는 매일 팀이 완료할 작업이 얼마나 남았는지에 대한 새 추정치를 보여주며 기울기를 통해 작업의 수행 속도를 알 수 있다. 번다운 차트의 가로축은 1회 스프린트 기간이며 세로축은 남은 작업량을 나타낸다. 파란선은 계획에 따른 남은 작업량으로 이상적인 그래프를 보여주며 빨간선은 실제로 남은 작업량을 나타낸다.
이미지 출처 : https://en.wikipedia.org/wiki/Burn_down_chart
5. 실행 가능한 제품 개발
- 각 스프린트마다 목표는 실행 가능한 제품을 만들어서 배포하는 것이다.
- 매 스트린트의 결과로써 나오는 산출물을 잠재적으로 출시 가능한 제품 증분(Potentially Shippable Product Increment)이라고 부른다.
6. 스프린트 리뷰(sprint review)
- 스프린트가 종료되었을 때 개발팀이 스프린트동안 개발한 증분의 기능을 고객을 포함한 이해관리자들에게 보여주고 피드백을 받는 과정을 말한다.
- 고객은 자신이 요청한 요구사항이 해당 스프린트동안 제품이 잘 반영되었는지 평가한 후 피드백을 하면 프로덕트 오너는 고객의 피드백이나 여러 사항들을 정리하여 다음 스프린트에 반영되도록 제품 백로그를 다시 갱신한다.
- 스프린트의 한주당 스프린트 리뷰시간은 한 시간으로 제약되어있으며 스프린트 리뷰를 준비하는데 30분을 넘지 않도록 해야한다.
7. 스프린트 회고(sprint retrospective)
- 스프린트 리뷰 후 프로젝트를 진행하면서 좋았던점이나 문제점, 미진한 점 등을 도출함으로써 다음 스프린트를 보다 더 나은 방향으로 개선할 수 있도록 하는 과정을 말한다.
- 스프린트 회고 과정에서 스크럼 마스터는 중재및 조정 역할을 하는 퍼실리테이터(facilitator)역할을 할 수 있다.
- 스프린트 회고 과정을 통해 이미 정해진 프로세스로만 프로젝트를 수행하는 것이 아니라 프로세스가 끊임없이 개선되도록 하여 변화하고 있는 환경에 더 능동적으로 적응할 수 있도록 한다.
8. 다음 스프린트 시작
- 스프린트는 제품 책임자가 제품을 출시할 준비가 되었다고 판단할 때까지 계속된다.
- 스프린트가 회고 후 휴식 기간없이 다음 스프린트를 진행한다.
참고 문헌
scrum(software development) //wikipedia
스크럼의 이론과 실천에 대한 가벼운 안내서
Hansung University software Engineering class
