[소프트웨어공학] 애자일 소프트웨어 개발 방법론: Scrum 완벽 정리

시리즈 글 보기 

[소프트웨어공학] 애자일 소프트웨어 개발 방법론: Crystal 완벽 정리

 

 

B. Boehm, “A survey of agile development methodologies.” Laurie Williams, 2007.

보헴의 A Survey of Agile Development Methodologies 내용 중 스크럼 방법론에 관하여 정리한 내용입니다.

 

---

1. 스크럼 방법론 개요

 

- 스크럼 철학은 팀, 태스크를 가능한 가장 작은 절차를 주기적으로 반복 진행하는 것

- 스크럼 팀은 근거리에서 일하며, 자기 주도적(Self-directed)이며 자기 조직화(Self-organizing)적인 특징을 가짐

- 팀은 정의된 목표를 반복해서 수행하며, 목표를 가장 잘 충족하는 최선의 방법을 결정하는 권한, 자율성과 책임이 부여됨

- 정해진 주기(보통, 30일)동안 실제 동작하는 제품을 만들면서 개발을 진행

 

* 스프린트 : 반복적인 개발 주기를 말하는데, 회사에서 정하는 이터레이션이 개발주기

 - 계획 회의로부터 제품 리뷰가 진행되는 날짜까지의 기간이 1스프린트로 정의

 

 

2. 스크럼 방법론 문서 및 산출물

스크럼 팀에 의해 산출된 주요 3가지 산출물 : 제품 백로그, 스프린트 백로그, 스프린트 소멸 차트

 

 Product Backlog(제품 백로그)

개발할 제품에 대한 요구 사항 목록

  - 릴리즈동안 고쳐야 할 필요성이 있는 결함이나 시스템에서 개발될 필요성이 있는 비즈니스 및 기술적인 기능이 우선 순위화 되어있는 목록

  - 요구사항, 카테고리(특성, 향상, 결함), 상태, 우선순위 및 특성에 대한 평가에 대한 고유 식별자를 포함

  - 스프레드시트 포맷에 유지됨

 

 Sprint Backlog(스프린트 백로그)

각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

  - 스프린트동안 예정된 모든 비즈니스와 기술 기능, 향상된 기능 및 결함 목록

  - 모든 작업은 누가 작업을 맡았는지, 작업 상태, 작업 완료까지 남은 시간 등을 기술하는 짧은 작업 설명을 포함

  - 업무 완료까지 남은 일을 평가를 하기 위해 팀 멤버를 방문하는 Daily tracker가 매일 업데이트함

  - 스프레드시트 포맷에 유지됨

  

Sprint Burndown Chart(스프린트 소멸 차트)

개발을 완료하기까지 남은 작업량을 보여주는 그래프

  - 스프린트 작업을 완료하는 데 남은 시간이 그래프로 표시됨

  - 팀을 위해 디스플레이됨

 

스프린트 소멸 차트! 고지가 얼마 안남았다!를 보여주네!

 

3. 스크럼 방법론 역할

스크럼 팀의 주요 3가지 역할 : 제품 책임자, 스크럼 마스터, 개발자

 

Product Owner(제품 책임자)

제품 백 로그를 정의하여 우선순위를 정함

 - 제품 백로그를 만들고, 우선 순위화함

 - 다음 반복(스프린트)에 무엇이 포함될지 선택

 - 스프린트 마지막에 시스템을 리뷰

 

Scrum Master(스크럼 마스터)

프로젝트 관리자(코치)

  - 제품 반복, 목적, 스크럼의 가치와 관행을 알고 강화함

  - 데일리 회의(스크럼 미팅)와 반복 데모(스프린트 리뷰) 실시

 - 진행 상황을 듣고 스크럼 팀의 업무를 방해하는 요소를 제거하며, 자원 제공

 - 개발자로서, 관리뿐만 아니라 제품 개발에도 참여

 

Developer(개발자)

 - 스크럼 팀의 일원

 - 스크럼 팀은 스프린트 목표를 달성하기 위해 노력하고 목표를 달성하기 위해 무엇이든지 할 수 있는 모든 권한을 가지고 있음

 - 스크럼 팀의 크기는 5~9명

 

 

 

4. 스크럼 방법론 프로세스

 

스크럼 프로세스

1) Sprint Planning Meeting (스크럼 계획 회의)

스프린트 목표와 스프린트 백로그를 계획하는 회의

 - 개발팀, 관리자, 제품 책임자와 함께 개최

 - 제품 책임자는 보통 고객의 대표로, 제품 책임자는 제품 백로그를 결정하고 우선 순위화함

 - 제품 책임자는 다음 스프린트동안 포함될 기능을 선택

 - 개발 팀은 기능을 제공하는데 필요한 작업과 자원을 파악하고, 다음 스프린트에 포함될 합리적인 기능의 수를 결정

 - 기능의 집합이 확인되면, 스프린트동안은 우선순위화를 바꾸지 않음

 

2) Sprint(스프린트)

스프린트

 - 스프린트 동안, 코드는 통합되고 매일 테스트 됨

 

3) Sprint Meeting(스프린트 회의)

날마다 진행되는 미팅 (어제 한일, 오늘 할일, 장애 현상 등을 공유)

 - 매일하는 15분 정도의 짧은 회의

 - XP Stand Up Meeting과 비슷함

 - 회의는 업무를 기술할 수 있도록 화이트보드가 있는 방에서 열림

 - 관리자와 같은 사람들은 스프린트 회의에 참여할 수 있지만 스크럼 팀 구성원과 스크럼 마스터만 말할 수 있음

 - 스크럼 회의는 스크럼 방법의 필수적인 요소

 - 너무 많은 사람이 참여하면 관리하기 어려울 수 있으므로, 각 팀은 최대 7명으로 하는 것이 좋고 더 큰 팀이라면 작은 그룹으로 세분화하고 그 그룹의 대표가 <스크럼의 스크럼> 미팅에 참여하면 됨

 

4) Sprint Review(스프린트 검토)

스프린트 주기 마지막에 진행하는 스프린트 리뷰 회의

 - 스프린트 주기 마지막에 고객과 관리자 사용자 그리고 제품 오너에게 진행사항 리뷰, 기능 시연하며  프로젝트를 기술적인 관점에서 리뷰

 - 회의는 스크럼 마스터에 의해 진행

 - 제품 책임자와 다른 이해 당사자들도 참여

 - 피피티 발표와 같은 형식적인 발표는 금지되고, 제품 자체를 보여주는 것에 초점을 둠

 

5) 스프린트 계획 회의

 - 다음 스프린트의 기능을 선택할 수 있는 스프린트 계획 회의 진행

 

 

---

 

출처 
B. Boehm, “A survey of agile development methodologies.”
 http://www.cems.uwe.ac.uk/~pchatter/2011/isd_hk/AgileMethods.pdf