스크럼(Scrum) 공부 및 정리

스크럼(Scrum)

프로젝트 관리를 위한 상호, 점진적 개발 방법론, 애자일 소프트웨어 공학 중 하나이다. 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.

- 각 반복 주기가 종료될 때마다 부분적으로 완성된 결과물이 만들어진다.

- 보통 반복 주기를 반복 주기를 이터레이션이라고 하지만 스크럼에서는 반복 주기를 스프린트(Sprint)라고 하며 주로 1~4주로 구성된다.

- 스크럼에는 제품 책임자, 스크럼 마스터, 개발팀 3가지 역할이 있다.

 

1. 제품 책임자(product owner)
   • 제품 백로그를 관리, 작성하고 이해 관리자로부터 요구사항을 추출하여 제품 백로그에 반영한다.
   • 요구사항에 우선순위를 매기고 각 스프린트마다 우선순위를 관리, 조정한다.
2. 스크럼 마스터(servant leader)
   • 일반적인 프로젝트 관리자들과는 다르게 개발 팀원들을 코칭하고 개발팀이 프로젝트 진행 중 문제가 생겼을 때 잘 해결할 수 있도록 도와주는 역할을 한다.
   • 개발팀원들이나 스크럼에 참여하는 사람들이 스크럼을 제대로 알고 수행하고 있는지에 대한 책임을 가지며 스크럼의 이론, 규칙들을 잘 따르도록 보장해야 한다.
3. 개발팀
   • 고객으로부터 받은 요구사항을 가지고 제품을 개발, 테스트하는 팀으로 주로 5~7명으로 이루어진다.
   • 개발팀에는 따로 리더가 정해져 있지 않으며, 팀원들이 자기 조직화(self-organization) 되어 있어 외부의 명령 없이 스스로 스프린트 목표를 달성하기 위해 최상의 방법을 결정한다.

 

+) 애자일(Agile)이란?

애자일은 짧은 주기를 가지고 눈에 보이는 결과물을 만들어내며 클라이언트와 소통한다. 그다음 주기에서는 수정사항을 반영하여 계획하고, 개발을 수행한다. 이러한 주기를 계속 반복하여 최종적으로는 클라이언트가 원하는 제품에 가장 근접하게 개발할 수 있도록 하는 것이다.

 

 

 

 

스크럼의 특성

스크럼은 특정 언어나 방법론에 의존적이지 않으며, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용 범위의 개발 기법이다. 스크럼은 애자일 소프트웨어 개발 과정의 하나로 다음과 같은 특성을 가지고 있다.

• 솔루션에 포함할 기능/개선점에 대한 우선순위를 부여한다.
• 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
• 날마다 15분 정도 회의를 가져라.
• 항상 팀 단위로 생각하라.
• 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.

 

 

스크럼의 진행 개념

스크럼에서는, 30일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다. 아래는 스크럼 진행 시 나타나는 중요 요소이다.

    1. 일반적인 권장기간은 30일이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주의 유연성을 가진다.

 

• 제품 백로그(Product Backlog)
  • 개발할 제품에 대한 요구 사항 목록
• 스프린트(Sprint)
  • 반복적인 개발 주기(회사에서 정하는 이터레이션이 개발 주기가 된다. 계획 회의부터 제품 리뷰가 진행되는 날짜까지의 기간이 1스프린트이다.)
• 스프린트 계획 회의(Sprint Planning Meeting)
  • 스프린트 목표와 스프린트 백로그를 계획하는 회의
• 스프린트 백로그(Sprint Backlog)
  • 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
• 일일 스크럼 회의(Daily Scrum Meeting)
  • 날마다 진행되는 미팅(어제 한 일, 오늘 할 일, 장애 현상 등을 공유)
• 실행 가능한 제품(shippable product) 개발
  • 스프린트의 결과로써 나오는 실행 가능한 제품

상기 요소들을 아래와 같은 순서에 따라 사용하여 스크럼을 진행한다.

1. 제품에서 요구하는 기능과 우선순위를 제품 백로그를 정한다.

2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율한다. 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 된다.

3. 스프린트 목표를 구현 가능하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.

4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.

5. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해한다.

6. 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 갖는다.

7. 스프린트 기간 중 다음 스프린트를 준비하기 위해 PO와 필요 인원이 모여 백로그를 준비하는 시간을 갖는다.

 

 

 

스크럼 진행 과정

1. 제품 백로그(product backlog) 작성
   • 제품 백로그는 설정한 비전 / 제품이 제공해야 하는 기능 / 개발할 제품에 대한 요구사항 목록을 말한다.
   • 요구사항 추출 방법 : 설문조사, 인터뷰가 가장 보편적이지만 임팩트 맵핑(Impact Mapping) 등이 있다.
     • 임팩트 맵핑(Impact Mapping) : 비즈니스 목적과 요구사항 간의 연결 관계를 가시적으로 보여준다. 즉, 목적 달성하는데 필요한 것만 뽑아낸다.(고객이 프로젝트 진행 도중 비즈니스 목적과는 관계없는 요구사항들을 계속 요구하거나 개발자가 비즈니스 목적과 관계없는 기능을 알아서 계속 추가하는 현상을 방지)
     • why, who(actor), how(impact), what(deliverable) 요소를 식별해야 한다.
   • 요구사항 우선순위 결정 : 프로젝트에서 사용할 수 있는 자원(시간, 비용, 인력)이 정해져 있어 요구사항들이 제품 백로그에 기록이 되면 우선순위를 정해야 한다.
     • 우선순위 결정에 영향을 미치는 요인들 : 고객에게 주는 가치가 높을수록 우선순위가 높고 성능, 보안, 안정성 같은 품질 속성도 우선순위를 높게 해주는 것이 좋다.
   • 스토리 포인트(story point) 부여 : 스토리(요구사항)를 구현하는데 소요되는 상대적인 노력의 양과 개발 복잡도 그리고 내재된 위험성 등을 종합적으로 분석하여 나타낸 값을 의미한다.
     • 보통 스토리 포인트를 추정할 때에는 피보나치수열을 사용하며 스크럼에서 실제 추정할 때 사용하는 스토리 포인트는 0, 1, 2, 3, 5, 8, 13, 20, 100과 과 같은 수열을 사용한다.
     • 포인트 0인 스토리는 해당 스토리를 개발하는데 아무 노력이 들지 않은 경우이며 보통 완료된 스토리를 의미한다.
     • 포인트 100인 스토리는 1포인트를 갖는 스토리보다 100배 큰 스토리를 의미하지 않고 해당 스토리의 크기가 매우 불확실하기 때문에 보다 정확한 추정을 위해 더 많은 토론과 노력을 기울일 필요가 있는 스토리로 해석한다.
     • 스토리 포인트는 절대적 크기가 아닌 상대적 크기를 추정하는 단위이다.
     • 제품 책임자(product owner)가 사용자 스토리(고객의 요구사항)를 기반으로 제품 백로그를 작성한다.
     • 사용자 스토리의 세 측면(3C)
       1. 카드(Card) : 요구사항을 단순하지만 명확하게 기술하겠다는 의미로 대화의 매개체 역할을 한다.
       2. 대화(Conversation) : 카드의 내용의 세부사항을 구체화시켜 인수기준이 정해지고, 이해의 공유를 촉진한다.
       3. 테스트(Confirmation) : 구현되고 있는지 인수기준을 통해 완료 여부를 판단한다.
2. 스프린트 계획 회의
   • 제품 책임자, 스크럼 마스터, 개발팀이 참여하여 제품 백로그를 기반으로 스프린트 목표와 스프린트 백로그를 계획하는 회의이다.
   • 스프린트 동안 무엇(what)을 할지 우선순위가 높은 아이템을 검토하고 어떻게(how) 실행할지에 대해 정한다.
3. 스프린트 백로그(sprint backlog) 작성
   • 제품 백로그에서 결정된 우선순위를 기반으로 스프린트 동안 해야 하는 일에 대한 리스트를 스프린트 백로그라고 한다.
   • 스프린트 목표를 구현 가능하도록 각각의 요구사항을 task 단위로 나누어 개발자들이 나눠서 작업을 수행한다.
   • 즉, 스프린트 백로그란 해당 스프린트에서 개발할 스토리를 실제 개발자가 수행하는 task라는 작업들로 분할하여 도출한 것을 말한다.
4. 일일 스크럼 미팅(daily scrum meeting)
   • 개발원들이 늘어지는 것을 방지하기 위해 스탠트업 미팅 형식(서서 진행)으로 진행된다.
   • 매일 정해진 시간에 정해진 장소에 모여 15~20분 동안 간단하고 빠르게 진행한다.
   • 어제 했던 일과 오늘 할 일, 수행 중 문제점이나 장애요인 등을 공유하며 문제가 있을 경우 미팅 후 바로 해결한다.
   • 매일 개발 팀원들을 스프린트 백로그에 있는 현재 작업을 완료하기 위해 작업이 얼마나 남았는지 번다운 차트(Burndown Chart)를 통해 진척도를 추적한다.
     • 번-다운 차트는 소멸차트라고도 부르며 한 스프린트 동안 남아있는 작업량을 보여주는 그래프이다.
     • 매일 팀이 완료할 작업이 얼마나 남았는지에 대한 새 추정치를 보여주며 기울기를 통해 작업의 수행 속도를 알 수 있다.
     • 번-다운 차트의 가로축은 1회 스프린트 기간이며 세로축은 남은 작업량을 나타낸다.
5. 실행 가능한 제품 개발
   • 매 스프린트의 결과로 나오는 산출물은 잠재적으로 출시 가능한 제품 증분이라고 부른다.
6. 스프린트 리뷰(sprint review)
   • 스프린트가 종료되면 개발한 제품을 고객을 포함한 이해 관련자에게 구현된 기능을 보여 주면서 데모를 수행하는 것
   • 고객은 자신의 요구사항이 잘 반영되었는지 평가 후 피드백을 하면 프로덕트 오너는 고객의 피드백이나 여러 사항들을 정리하여 다음 스프린트에 반영되도록 제품 백로그를 다시 갱신한다.
   • 스프린트의 한 주당 스프린트 리뷰 시간은 한 시간으로 제약되어 있다.
7. 스프린트 회고(sprint retrospective)
   • 스프린트가 끝나는 시점이나 일정 주기로 수행되며 회고를 통해 프로젝트 진행하면서 좋았던 점, 여러 가지 문제나 미진한 점 등을 도출하고 다음 스프린트를 보다 더 나은 방향으로 개선할 수 있도록 하는 과정이다.
   • 스프린트 회고 과정에서 스크럼 마스터는 중재 및 조정 역할을 하는 facilitator 역할을 할 수 있다.
   • 프로세스가 끊임없이 개선되도록 하여 변화하고 있는 환경에 더 능동적으로 적응할 수 있도록 한다.
8. 다음 스프린트 시작
   • 제품 책임자가 제품을 출시할 준비가 되었다고 판단할 때까지 계속된다.
   • 스프린트가 회고 후 휴식 기간 없이 다음 스프린트를 진행한다.