[펌] Agile - Scrum 개발론

본 포스팅은 흔히 나선형이라고 불리는 Agile개발 방법중에 하나인 Scrum 개발론에 대해서 포스팅하고자 합니다. 우선 Scrum 의 특성을 WIKI 에서 퍼왔습니다.

===========================================================

* Scrum 의 특성

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

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

===========================================================

 

* Scrum 의 진행단계

1. Epic

-> 팀원들이 개발하려고 할 아이디어를 마치 브레인스토밍처럼 여러개 생각해냅니다. 예를 들어 개발자들이 어떤 제품의 컨트롤러를 만들려고 합니다. 그 컨트롤러 방식이 IR일수도 있고, 블루투스도 있는 등 여러가지 방법이 있을 것입니다. 그런 아이디어들을 여러가지 생각해냅니다.

2. User Story

-> 개발자들이 개발할 상품을 사용자 입장에서 생각해봅니다. 사용자와 직접 미팅하여 어떤 기능을 요구하는지 수용합니다. 개발자들이 생각한 아이디어가 과연 사용자가 필요한 기능인지 불필요한 기능인지를 생각해보고 불필요하다면 그 기능은 보류하도록 합니다.

3. Product Backlog

-> User Story 의 결과로 제품백로그를 완성하고 스프린트 목표와 스프린트 백로그를 회의합니다. 팀원들은 스프린트 종료시까지 얼마나 해낼 것인지 약속합니다. 또한 Product Owner가 매긴 주문목록에 우선 순위를 매깁니다.

4. Sprint Backlog

-> 개발 백로그에서 주문된 목록에서 Estimate 즉, 각 목록의 예상치를 매깁니다. 스프린트 기간에는 하루에 15분정도 시간을 내서 팀원들과 일일 스크럼 회의를 합니다.

5. Sprint Backlog

-> 4. Sprint Backlog 에서 매긴 예상치를 주단위로 구체적으로 예상치를 매깁니다.

6. Pairing Dashboard

-> 팀원들이 각각 무엇을 하는지 표시합니다. 온라인상에서 SVN과 같은 시스템에서 표시를 해도 되지만 오프라인에서 간단하게 포스트잇으로 내가 뭐하고 있는지를 표시해두면 팀원들이 지나가면서 이 팀원이 무엇을 하는지 알 수 있도록 합니다. 게시판에 Doing or To Do, Issue, Solved 와 같은 목록을 작성하여 그 밑에 포스트잇과 같은 메모지에 작성하여 붙입니다. 이런 식으로 하면 현재 팀원들이 무엇을 할 수 있는지 그리고 프로젝트 현재 진행상황을 가시적으로 확인할 수가 있습니다.

7. Burn down/up Chart

-> 프로젝트 진행 현황을 차트에 기록하여 표시합니다.

8. Retrospection

-> Sprint가 종료되고 모든 작업이 끝나면 팀원들과 Review할 필요가 있습니다. 다음 주기에는 어떻게 실행될 것이고, 다음 주기를 위해서 어떤 팀룰을 정할건지 회의합니다.

이렇게 주기별로 각각의 제품들을 완성하고 최종적으로 제품들을 통합하여 완성시킵니다.