스크럼은
스크럼은 프로젝트 관리를 위한 애자일 방법론으로서 추정및 조정 기반의 경험적 관리기법의 대표적인 형태이다. 1986년 타케우지 & 노나카 교수가 HBR에 기고한 "The New Product Development Game"이라는 기사가 시작이며, 1995년 켄 슈와버와 제프 서덜랜드가 이방법을 소프트웨어 개발에 소개하면서 스크럼이라고 부르게 되었다.
스크럼의 특징
투명성(Transparency)
프로젝트가 현재 어떤 상태인지 계획대로 진행되고 있는지 어떤 문제점을 가지고 있는지 정확히 파악하는 것은 어려운일이다. 스크럼은 스크럼회의, 소멸차트, 스프린트 리뷰와 같은 기법을 이용하여 다른 방법론에 비해 프로젝트의 상태나 문제점을 잘 드러내 준다.
타임박싱(Time boxing)
스크러을 구성하는 모든 실천법에 있어 시간은 매우 중요하다. 일일 스크럼은 매일 15분 짧은 시간에 진행되어야 하며, 스프린트 리뷰는 매 이터레이션 마다 주기적으로 진행한다. 스크럼 자체를 진행하는데 들어가는 시간을 엄격하게 제한함으로써 프로젝트 진행에만 집중할 수 있게 한다.
커뮤니케이션(Communication)
스크럼은 팀원 간 커뮤니케이션을 원활하게 하기위해 많은 노력을 기울인다. 일일 스크럼에서 각 개발자들이 어떤 방해물로 인한 문제를 겪고 있는지를 공유하고 각 사용자 스토리의 구현 난이도/시간을 토론하는 절차는 프로젝트 내 커뮤니케이션을 원활하게 해 준다.
경험주의 모델(Inspect & Adapt model)
스크럼은 고유의 프로세스 모델을 가지고 있지만 많은 기법들이 프로젝트에 참여하고 있는 개개인의 경험에 기반한다. 프로젝트마다 고유한 상황과 특징을 가지고 있기때문에 기존의 정형화된 프로세스로는 이런 최근의 프로젝트 상황을 따라가기 어렵다. 그래서 스크럼은 기본적인 구조만 같을 뿐 실제로 일을 진행하게 되면 팀마다 달라지는것을 허용한다.
스크럼 역할
스크럼에는 크게 3가지 역할자가 있다.
제품책임자(Product Owner)
제품기능목록에 해당하는 제품 백로그(product backlog)를 만들고 우선순위를 조정하거나 새로운 항목을 추가하는 일을 관리한다. 스프린트에 대한 계획을 수립할때 까지 중요한 역할을 하지만 스프린트가 시작되면 최대한 팀 운영에 관여하지 않는것을 권장한다.
스크럼 마스터(Scrum Master)
스크럼의 원칙과 가치를 지키면서 스크럼팀이 개발을 진행할 수 있도록 지원한다. 스크럼팀의 업무를 방해하는 요소를 제거하기위해 노력한다.
스크럼 팀(Scrum Team)
보통 5~9명으로 구성되며 하나의 스프린트 기간동안 구현해야 할 기능을 사용자 스토리로 도출하고 이를 구현한다. 스프린트 동안 구현해야 하는 기능을 완료하기 위해 노력하며 이를 위한 권한을 가진다.
스크럼 프로세스
스크럼의 프로세스를 구성하는 것은 스프린트,3가지유형의 미팅, 산출물이다.
1. 스프린트(Sprint): 달격기준 1~4주 단위의 반복개발기간을 가리킨다.
2. 3가지미팅: 일일스크럼, 스프린트계획, 스프린트리뷰
3. 3가지 산출물: 제품백로그, 스프린트백로그, 소멸차트
3가지 미팅
스프린트 계획(Sprint Planning)
각 스프린트에 대한 목표를 세우고 제품 백로그로 부터 스프린트에서 진행할 항목을 선택한다. 각 항목에 대한 담당자를 배정하고 태스크 단위로 계획을 수립한다.
일일스크럼(Daily Scrum)
매일 진행하는 15분간의 프로젝트 진행상황을 공유하는 회의이다. 모든 팀원이 참석하고 매일매일 각자가 한일, 할일, 문제점등을 이야기 한다.
스프린트 리뷰(Sprint Review)
스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의이다. 스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백을 받는다. 가능하면 해당 스프린트 동안 진행된 모든 작업에 대한 데모를 진행하며 고객이 참여하는것이 좋다. 스크럼마스터는 스프린트 동안 잘된점, 아쉬웠던점, 개선할 사항등을 찾기위한 회고를 진행할 수 도 있다.
스크럼 산출물
제품백로그(Product Backlog)
제품에 담고자 하는 기능의 우선순위를 정리한 목록으로 고객을 대표하여 제품책임자가 주로 우선순위를 결정한다. 제품 백로그에 정의된 기능을 사용자 스토리라고 부르며 사용자 업무량에 대한 추정은 주로 스토리 포인트라고 불리는 기준을 이용한다.
스프린트 백로그(Sprint Backlog)
하나의 스프린트 동안 개발할 목록으로 사용자 스토리와 이를 완료하기 위한 작업을 태스크로 정의한다. 각각의 태스크의 크기는 시간 단위로 추정한다.
소멸차트(Burndown chart)
개발을 완료하기까지 남은 작업량을 보여주는 그래프, 각 이터레이션 별로 남아있는 작업량을 스토리 포인트라는 것으로 나타낸다.
'SW기술 > SW공학' 카테고리의 다른 글
| 클린코드란? (0) | 2019.06.18 |
|---|---|
| [SW공학] 애자일 방법론 (0) | 2013.05.28 |
