내 머리속에서 애자일(Agile)하면 제일 먼저 떠오르는 것은 바로 스크럼(Scrum)이다. 요즘에는 관심이 좀 식었지만 한 때 폭발적인 관심으로 애자일 = 스크럼이 될 정도였었다. 대기업에서는 특히 스크럼을 실행하는 곳이 많았는데 사이트를 가면 스크럼 기반으로 만들어진 팀부터 프로젝트 관리까지 스크럼 투성이었다.
몇년전 당시 다니던 회사의 본부장님은 SW 품질쪽으로는 유명하신 분이라서, 애자일과 스크럼, 칸반에 관련된 문서를 잔뜩 뽑아서 나눠졌던 기억도 있다. 그만큼 SW 품질이나 관리를 하는 사람들에게는 도저히 못들어본 말일 것이다.
우선 스크럼의 탄생은 일본 히토츠바시 대학의 노나카 이쿠지로와 타케우지 히로타카가 1986년 1~2월 Harvard Business Review에 올린 "The New New Product Developement Game" 에서 시작된다. 이 아이디를 기반으로 1991년 디그라스(DeGrace)와 슈탈(Stahl)이, "Wicked Problems, Righteous Solutions" 에서 스크럼을 처음 언급한다.
스크럼이라는 용어의 탄생은 럭비(미식축구)에서 나오는 용어로 스크럼은 한 팀의 선수들이 서로 팔을 건 상태에서 상대 팀을 앞으로 밀치는 대형을 말한다.
스크럼
스크럼은 일단 사소한 반칙이 일어나면 그 주변으로 7~8명이 뭉쳐서 서로간의 힘겨루기를 하는 모양새를 보이는데 인원수도 그렇고 이 모습이 이 방법론과 닮아있어서 이 이름을 붙이는 것이라 생각한다.
현재는 애자일이라는 개념이 혁명처럼 퍼지는게 아니라 수많은 애자일들을 사이트에 맞게 변형(테일러링)해서 사용하는 곳이 많은데 오늘은 바로 대표적인 애자일 기법인 스크럼에 대해서 설명해보고자 한다.
Sprint를 활용한 대표적인 Agile, 스크럼(Scrum)의 개요
스크럼의 개념 및 정의
- 작은 개발팀, 짧은 개발 주기, 팀의 집중력과 생산성을 유지시켜 점진적으로 소프트웨어(SW)를 산출하는 대표적인 애자일 방법론
- Agile 방법론 중의 하나로 Product Backlog를 바탕으로 기술적으로 분할되고 재해석된 스프린트(Sprint)를 스크럼 팀으로 통해 구현해 나가는 개발 방법론
- Product Backlog를 바탕으로 하여 기술적으로 재해석된 Sprint를 구현해 나가는 Agile 방법론
스크럼의 특징
- 프로젝트 관리 강조 : XP와 달리 진행 체계 수립, 역할, 정의에 중점
- 포괄적 정의, 포용 : 기존의 개발방법론, 표준, 공학적 접근법의 포괄적 수용
- 시간적 조정 설정 : 15분의 Daily Meeting, 30일 정도의 개발주기(Time Box)
- 관리적 체계 : 전체 제품 요구사항 관리, 개발주기 내 요구사항, 업무 진행 가시화
- 팀 중심적 : 5~9명으로 구성, 팀 내에서 역할 분담, 모든 팀원 구성원간 업무 교환
- 확약 : 약속한 것을 확실히 실현하는 것
- 전념 : 확약한 것의 실현에 전념하는 것
- 정직 : 어떤 것이 자신에게 불리해도 숨기지 않는 것
- 존중 : 자신과 다른 사람에게 경의를 표하는 것
- 용기 : 팀 구성원 은 자신이 옳은 일을 할 수 있도록 팀원간 갈등과 도전을 통해 작업 할 수있는 용기
SCRUM의 프레임워크 및 프로세스
스크럼은 최대 한달안에 Sprint Backlog를 처리하는 프로세스이다
SCRUM의 프로세스 (설명 및 특징)
Prepare Product Backlog
- 실제로 구현되어야 하는 기능 목록을 나열
- SRS(요구사항정의서)나 TRS(기술요구 사항정의서)로부터 목록 도출
- 특징 : 추정리소스, 우선순위 등
Release Planning
- 해야 할 작업(일)에 대한 계획 수립
- Milestone을 정하여 Release시가 마다 작동 가능한 Product Release
- 특징 : 위험의 조기 발견
Sprint Planning
- Release Planning 이후 각 Release를 달성하기 위한 Sprint 계획 수립
- 특징 : 20%버퍼 법칙 적용
Sprint Tracking
- 일일 미팅(Daily Scrum)을 수행하면서 계획에 따른 프로젝트 수행
- 특징 : Daily Scrum, Burn down chart
Ending Sprint
- 정해진 기간 동안 Sprint가 종료되면, 정리 실시
- 특징 : 계획된 일정, 예산 소진 시 까지
Review Sprint
- Sprint가 종료된 후에는 Sprint에서 구현된 산출물을 Review하는 단계
- 구현된 코드, 산출물
- 특징 : Test, Code Review
Update Product Backlog
- Review과정에서 나온 추가 요건이나 변경사항을 반영하여 Product Backlog update
- 특징 : 우선순위 재조정, 요구사항 구체화
Retrospective
- Scrum팀에 운영중인 방법론 자체에 대한 Review, 문제 개선
- 특징 : SWOT분석
스크럼 구성원 및 산출물들
- 제품에 담고자 하는 기능의 우선순위를 정리한 목록
스크럼 적용 현황 및 고려사항
스크럼 적용 현황
- 금융, 보험 등 보수적인 산업에 있는 기업과 Google, Yahoo, MS 등도 SCRUM을 선택
- Agile 방법론을 실행하는 팀 중 약 50%가 Scrum을 사용하고, 20%가 Scrum을 XP 구성 요소와 함께 사용하고, 12%가 XP만을 사용
- Kanban과 결합한 애자일 모델이 유행했으며, 최근에는 데브옵스(DevOps)로 전환하는 중
https://dzone.com/articles/is-devops-agile
SCRUM 적용 시 고려사항
- 전체 프로젝트에 대한 큰 Mile Stone은 기존 개발방법론을 사용하고, SCRUM 방법론은 각 단계에 대한 Task를 위해서 사용
- 어떤 전문화된 시스템이나 도구가 아니라, 팀이 최대한의 효율을 낼 수 있는 프로세스가 중요
참고문헌
연관토픽
'정보처리기술사 > 소프트웨어공학' 카테고리의 다른 글
| 낭비요소를 제거하는 개발방법론, 린(Lean) (0) | 2019.01.05 |
|---|---|
| 비즈니스 요구에 빠른 대응의 가능한, XP(eXtreme Programming) (0) | 2019.01.02 |
| IT 서비스관리 국제표준, ISO/IEC 20000 (0) | 2018.03.28 |
| OOP(Object-Orientied Programming, 객체지향프로그래밍) 5대 원칙 (0) | 2018.03.26 |
| 모델 기반의 소프트웨어 개발방식, MDA(Model Driven Architecture) (0) | 2017.09.27 |