[Agile] 스크럼 알아보기

 

 

스크럼은 프로젝트 관리를 위한 애자일 방법론으로 추정 및 조정 기반의 경험적 관리 기법의 대표적인 형태이다.

기원

1986년 타케우치 & 노나카 교수가 HBR에 기고한 "The New New Product Development Game"을 기원으로 본다.
1995년 켄 슈와버와 제프 서덜랜드가 이 방법을 소프트웨어 개발에 소개하며 스크럼이라 부름

역할

1. 제품 책임자 (Product Owner)
   제품 기능 목록에 해당하는 백로그 (product backlog)를 만들고, 우선순위를 조정하거나 새로운 항목을 추가하는 일을 관리한다. 스프린트에 대해 계획을 수립할 때까지 중요한 역할을 하지만, 스프린트가 시작되면 최대한 팀 운영에 관여하지 않는걸 권장한다.
2. 스크럼 마스터 (Scrum Master)
   스크럼 원칙과 가치를 지키며 스크럼팀이 개발을 진행할 수 있도록 지원한다. 스크럼 팀의 업무를 방해하는 요소를 제거하기 위해 노력한다.
3. 스크럼 팀 (Scrum Team)
   보통은 5~9명으로 구성되며, 스프린트 기간동안 구현해야 할 기능을 사용자 스토리로 도출하고 구현한다. 스프린트 동안 구현해야 하는 기능을 완료하기 위해 노력하며 이를 위한 권한을 갖는다.

프로세스

스크럼의 프로세스는 스프린트와 3가지 유형의 미팅과 산출물이다.

1. 스프린트 (Sprint): 달력 기준 1~4주 단위의 반복 개발 기간을 가리킨다
2. 미팅: 일일 스크럼, 스프린트 계획, 스프린트 리뷰
3. 산출물: 제품 백로그, 스프린트 백로그, 소멸 차트

스프린트 진행 방식

스크럼 산출물?

• 제품 백로그 (Product Backlog)
  제품에 담고자 하는 기능의 우선순위를 정리한 목록이다. 고객을 대표하여 제품 책임자가 주로 우선순위를 결정한다. 제품 백로그에 정의된 기능을 사용자 스토리(요구 사항)라 부르며 업무량에 대한 추정은 주로 스토리 포인트라 불리는 기준을 이용한다.
• 스프린트 백로그 (Sprint Backlog)
  하나의 스프린트 동안 개발할 목록으로 사용자 스토리와 이를 완료하기 위한 작업을 태스크로 정의한다. 각각의 태스크 크기는 시간 단위로 추정한다.
• 소멸 차트 (Burndown Chart)
  개발을 완료하기까지 남은 작업량을 보여주는 그래프. 각 이터레이션 별로 남아있는 작업을 스토리 포인트라는 것으로 나타낸 것이다.

스크럼 미팅?

• 스프린트 계획 (Sprint Planing)
  각 스프린트에 대한 목표를 세우고 제품 백로그부터 스프린트에서 진행할 항목을 선택한다. 각 항목에 대한 담당자를 배정하고 태스크 단위로 계획을 수립한다
• 일일 스크럼 (Daily Scrum)
  매일 진행하는 15분간의 프로젝트 진행상황 공유 회의이다. 모든 팀원이 참석하여 매일매일 각자가 한 일, 할 일, 문제점 등을 이야기한다.
• 스프린트 리뷰 (Sprint Review)
  스프린트 목표를 달성 했는지 작업 진행과 결과물을 확인하는 회의이다. 스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백을 받는다. 가능하면 해당 스프린트 동안 진행된 모든 작업에 대해 데모한다. 고객이 참여하면 좋다. 이때, 스크럼 마스터는 스프린트 동안 잘된 점, 아쉬웠던 점, 개선할 사항 등을 찾기 위해 회고를 진행할 수 있다.

특징

투명성 (Transparency)

프로젝트가 현재 어떤 상태인지, 계획대로 진행되고 있는지, 어떤 문제점을 가지고 있는지 정확히 파악하기는 어려운 일이다.
스크럼은 스크럼 회의, 소멸 차트, 스프린트 리뷰와 같은 기법을 이용해 다른 방법론에 비해 프로젝트의 상태나 문제점을 잘 드러낸다

타임 박싱 (Time Boxing)

스크럼을 구성하는 모든 실천법에 있어 시간은 매우 중요하다. 일일 스크럼은 매일같이 15분이라는 짧은 시간에 진행해야 하며, 스프린트 리뷰는 매 이터레이션마다 주기적으로 진행한다. 스크럼 자체를 진행하는데 들어가는 시간을 엄격하게 제한함으로써 프로젝트 진행에만 집중할 수 있게 해준다.

커뮤니케이션 (Communication)

스크럼에서는 팀원 간 커뮤니케이션을 원활하게 하기 위해 많은 노력을 기울인다. 일일 스크럼에서 각 작업자들이 어떤 방해물(blocker)로 인한 문제를 겪고 있는지 공유하고, 흔히 플래닝 포커라는 방식으로 진행되곤 하는 각 사용자 스토리의 구현 난이도/시간을 토론하는 절차는 프로젝트 내 커뮤니케이션을 원활하게 해주는 스크럼 특징 중 하나이다

경험 주의 모델 (Inspct & Adapt model)

스크럼은 고유의 프로세스 모델을 가지고 있지만, 많은 기법들이 프로젝트에 참여하는 개개인의 경험에 기반한다. 프로젝트마다 고유한 상황과 특징을 가지고 있기 때문에 기존의 정형화된 프로세스로는 이런 최근의 프로젝트 상황을 따라가기 어렵다. 그러므로 스크럼은 기본적인 구조만 같을 뿐, 실제로 일을 진행하게 되면 팀마다 달라지는 것을 허용한다.

더 알아보기

• 사용자 스토리 (User Story)
  통상 요구사항 이라 부르는 시스템의 기능 설명을 사용자 관점에서 이야기 한 것이다. 모든 요구사항을 사용자 스토리로 간주해서는 안되고, 사용자에게 가치 있는 것들만 골라내어야 한다. 요구 사항이 아니라 사용자 스토리라 부르는 이유는 '사용자 관점에서 사고' 한다는 의미가 되겠다.
• 스토리 포인트 (Story Point)
  사용자 스토리를 실제 동작하는 기능으로 구현하는게 얼마나 어려운지 나타내는 값이다. 이 포인트는 개인이 주관적으로 정하는것이 아닌, 스토리 포인트를 사용하는 집단 다수의 관점에서 내리는 객관적인 값이다. MD(Man-Day) 로 나타내는 업무량 척도와는 다르게, 구현하려는 사용자 스토리 그 자체의 난이도에만 온전히 집중한다.