Agile Scrum(애자일 스크럼)
Scrum의 정의
- Scrum은 Project를 위한 상호, 점진적인 개발 방법론이며, Agile 소프트웨어 공학 중 하나이다. Scrum은 소프트웨어 개발 Proejct를 위한 고안되었지만, 소프트웨어 유지보수 팀이나, 일반적인 프로젝트/프로그램 관리에도 적용 가능하다.
Scrum의 특성
- Scrum은 특정 언어나 방법론에 의존하지 않으며, 개발 언어는 물론이고, 객체 지향 언어와도 관련이 없는 넓은 응용 범위의 개발 기법이다. Scrum은 Agile 소프트웨어 개발 과정의 하나로 다음의 특성을 가진다.
- 솔루션에 포함할 기능/개선점에 대한 우선순위를 부여한다.
- 개발 일정은 30일 정도로 조절하고, 각각의 개발 일정마다 실제 동작할 수 있는 결과를 제공하라
- 첫 번째 개발 일정부터 최소한으로 동작하는 한 세트가 나와야 한다. 고객은 산출물을 통해 개발자에게 피드백을 전달할 수 있으며, 이를 통해 최소한의 미스 커뮤니케이션이 발생한다.
- 개발 일정마다 적용할 기능이나 개선에 대한 목록을 제공하라.
- 날마다 15분 정도의 회의를 가져라(Daily Scrum)
- 항상 팀단위로 생각하라.(5~6명의 팀을 최적이라 생각한다.)
- 원활한 의사소통을 위해서 구분 없는 열린 공간을 유지하라.
Scrum이 추구하는 가치
- Scrum은 다음의 5가지 가치에 중점을 두어 진행된다.
- 확약
- 약속한 것을 확실히 실현되는 것
- 전념
- 확약한 것의 실현에 전념하는 것
- 숨기지 않음
- 비록 자신에게 있어서 불리한 일에서도 숨기지 않는 것
- 존중
- 자신과 다른 사람에게 경의를 표하는 것
- 용기
- 위의 사항을 언제든지 지킬 수 있는 용기
Scrum의 진행
- Scrum에서는 30일 간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다. 아래는 Scrum 진행 시 나타나는 중요 요소이다.
- Product Backlog
- 개발할 제품에 대한 요구사항 목록
- Sprint
- 30일을 반복적인 개발 주기 (상황에 맞게 30일 내에서 일정 조절 가능)
- Sprint Planning Meeting
- Sprint 목표와 Sprint Backlog를 계획하는 회의
- Sprint Backlog
- 각각의 Sprint 목표에 도달하기 위해 필요한 작업 목록
- Daily Scrum Meeting
- 날마다 진행되는 진척 상황 미팅
- Shippable product
- Sprint의 결과로써 나오는 실행 가능한 제품
- 상기 요소들을 아래와 같은 순서에 따라 사용하여 Scrum을 진행시킨다.
- 제품에서 요구하는 기능과 우선 순위를 Product Backlog로 정한다.
- Product Backlog로 부터 Sprint를 통해 구현되어야 할 목표를 선택한다.
- Sprint 목표를 보다 상세한 작업으로 모듈화 한 Sprint Backlog를 작성한 뒤, 작업을 할당한다.
- Sprint를 진행하는 동안, 매일 정해진 시간과 장소에 모든 개발 팀원이 참가하는 Daily Scrum Meeting(15분 내외)를 가진다.
- 매회의 Sprint가 종료할 때마다 Scrum Review Meeting을 가지고, 개발된 제품을 평가한다. 이 때 개발된 모든 요소를 평가한다.
- 이 후의 Sprint를 대비하여 Product Backlog의 내용과 우선순위을 재검토한다.
Scrum Master는 일반적인 관리를 수행하는 프로젝트 관리자들과는 달리 팀원을 코칭하고, 프로젝트의 문제 상황을 해결하는 역활을 하며, 제품 책임자는 Sprint 목표와 Backlog 등의 결정에 있어 중심이 되는 상위 관리자로, 제품 책임자는 독단적으로 목표를 정하지 않고, 고객과 관리자 및 팀원들이 모여서 목표를 정한다.
이러한 과정을 거친 뒤, 개발 팀원들이 주도적으로 Sprint 목표를 달성하기 위한 작업을 정해나가면 된다. 보통 각 작업들은 4~16시간 정도 걸리도록 정한다. 물론 작업을 정하고, 할당하는데는 고객이나 제품 책임자와는 상관없이 팀원 자율로 진행한다. 이와 같은 자율적인 행위를 통하여 팀원들은 의사를 활발하게 주고받게 되며, 끈끈한 협업 체계를 가지게 된다.
Agile 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화를 중요하게 여기고 있다. 하지만 이러한 부분과 더불어 Agile 프로세스는 무질서해보이기 때문에 전통적인 프로세스 개선과 마찰이 생기게 되는 것이다.
'QA > Theory' 카테고리의 다른 글
탐험적 테스팅(EXPLORE IT) (0) | 2016.02.03 |
---|---|
애자일 테스팅(Agile Testing) (1) | 2014.10.21 |
소프트웨어 테스팅의 기초-4 (0) | 2010.04.07 |
소프트웨어 테스팅의 기초-3 (0) | 2010.04.07 |
소프트웨어 테스팅의 기초-2 (0) | 2010.04.07 |
댓글