연관토픽
- [상위] 애자일 방법론(Agile Method)
- [하위] 제품 백로그(Product Backlog)
- [하위] 스크럼 마스터(Scrum Master)
- [하위] 스프린트 백로그(Sprint Backlog)
- [하위] 스크럼 미팅(Scrum Meeting)
- [하위] 번다운 차트(burn down chart)
출제
개념 : Agile 대표 방법론
- 상호적이고 점진적으로 소프트웨어를 개발하는 방법으로 반복을 통해 개발 주기를 단축하여 팀의 생산성을 높이는 소프트웨어 개발 방법
- 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정기반의 경험적 관리 기법
- 제품 백로그(Product Backlog)를 바탕으로 하여 기술적으로 분할되고 재 해석된 스프린트(Sprint)를 스크럼 팀(Team)을 통해 구현해 나가는 개발 방법론
- 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정기반의 경험적 관리 기법
- 스프린트라는 짧은 주기 동안에 담당한 역할에 전념하며, 능동적으로 대처하는 프로세스에 특화된 대표적인 애자일 개발 방법론
스크럼의 특징
| 구분 | 설명 |
| 협업 중심 |
주로 팀 수준의 시안을 다루며 효율적으로 팀원들이 협업할 수 있는 환경을 제공하여 활동에 집중할 수 있게 하고 고품질의 제품을 생산할 수 있게 함 |
| 사회공학기법 |
프로젝트(Project) 이해관계자들의 적극적인 협력과 참여를 촉진하여, 관련자의 성취감 충족을 목적으로 함. |
| 스프린트(Sprint)수행 |
스프린트(Sprint)라는 통상 4~6주 정도의 잘 정의된 개발 주기를 가지며 개발 효율성을 극대화할 수 있는 환경 제공. |
| 일일미팅(Daily Meeting) |
8~10명 정도의 SCRUM 팀(Team)은 매일 15분 정도의 회의를 통해 진척관리와 이슈 중심의 계획 리뷰(Review) 실시 |
| 독립적 방법론 |
특정 언어나 방법론에 의존하지 않으며, 개발언어와 상관없이 적용 가능한 폭 넓은 응용 범위의 개발 기법 |
경험적 프로젝트 관리요소
| 구분 | 설명 |
| 투명성 (Transparency) |
|
| 검토 (Inspection) |
|
| 적응 (Adaptation) |
|
스크럼 개발 프로세스 [관리123-1]
- 스크럼의 4가지 회고 : Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
| 수행순서 | 프로세스 | 설명 |
| 프로젝트 시작 | 제품 백로그 생성 | - 아이템의 목적 정의 및 우선순위 정리 - 추정치(스토리 포인트)를 팀에 의해 산정 기록하고, 스프린트에 적당한 아이템 배분 |
| 스프린트 반복수행 |
스프린트 계획 회의, 스프린트 백로그 선정 |
- 팀 전체가 참여하여 회의 후 스프린트 계획을 정리 - 제품 백로그에서 이번 스프린트에 구현할 목표를 결정하여 스프린트 백로그에 기록 - 이번 스프린트 동안에 구현하기로 고객과 약속한(확약) 범위가 결정되고 이 범위를 개발자는 전념해서 구현함 |
| 일일 스크럼 | - 팀 전체가 참여하고 문제점과 장애요인들을 찾아냄 | |
| 스프린트 | - 이터레이션 길이를 2~4주로 고정하고, 항상 정해진 기간에 완료 - 팀이 외부로부터 방해 받거나 통제되지 않게 함(Time Boxing) |
|
| 스프린트 리뷰, 제품증분 |
- 매 스프린트 종료 후 데모를 수행하여 동작되는 소프트웨어를 보여줌 - 이해 당사자와 제품 책임자에게 피드백을 받음 |
|
| 프로젝트 종료 | 스프린트 회고, 제품완료 |
- 팀 전원과 제품 책임자가 참석 - 구체적인 개선안들을 도출 및 개선안들의 실제 적용 - 모든 스프린트가 완료되면 프로젝트가 종료됨 |
- 스프린트는 제품을 개발/ 배포하는 반복적인 주기이며, 통상적으로 2~4주 기간동안 진행됨
- 스프린트 기간동안 개발하기 위한 개발 목록을 스프린트 백로그라고 하며, 작업 현황판을 통해 관리
스크럼 구성요소
| 구분 | 설명 |
| 제품 백로그 (Product Backlog) |
|
| 스프린트 백로그 (Sprint Backlog) |
|
| 스프린트(Sprint) |
|
| 스크럼 미팅 (Daily Scrum) |
|
스크럼의 주요 산출물
| 구분 | 설명 |
| 제품 백로그 (Product Backlog) |
제품에 담고자 하는 기능의 우선 순위를 정리한 목록으로 제품 백로그에 정의된 기능을 사용자 스토리라고 부르며 사용자 업무량에 대한 추정은 주로 스토리 포인트라 불리는 기준을 이용 |
| 스프린트 백로그 (Sprint Backlog) |
하나의 스프린트 동안 개발할 목록으로 사용자 스토리와 이를 완료하기 위한 작업을 태스크로 정의하고 각 각의 태스크의 크기는 시간 단위로 추정 |
| 소멸 차트 (Burndown chart) |
개발을 완료하기까지 남은 작업량을 보여주는 그래프, 각 이터레이션 별로 남아 있는 작업량을 스토리 포인트로 나타낸 것 |
스크럼 미팅 유형(3가지)
- 스프린트를 시작하기 전에 스프린트 플래닝 미팅, 스프린트 기간 매일 스탠드업 미팅(일일 스크럼), 스프린트가 끝날 때 스프린트 회고
| 구분 | 설명 |
| 스프린트 계획 (Sprint Plan) |
|
| 일일 스크럼 (Daily Scrum) |
|
| 스프린트 리뷰 (Sprint Review) |
|
스크럼 마스터 역할
| 구분 | 설명 |
| 섬기는 리더 (servant leader) |
|
| 커뮤니케이션 (Communication) |
|
| 품질관리(QM) |
|
| 프로젝트 관리(PM) |
|
스크럼 조직(팀) 구성 [관리123-1]
| 담당자 | 역할 | 설명 |
| 제품 책임자 (Product Owner) |
Product Backlog 작성 | - 제품 백로그를 관리, 작성하고 이해관리자로부터 요구사항을 추출하여 제품 백로그에 반영 - 요구사항에 우선 순위를 결정하고, 각 스프린트마다 우선순위 관리, 조정 |
| 스프린트 운영 관여 안함 | - 스프린트 계획 수립 시 까지만 역할을 수행하고, 스프린트가 시작되면 팀 운영에 관여하지 않음 | |
| 스크럼 마스터 (Scrum Master) |
조력자 역할 애자일 촉진자 |
- SCRUM에서 PM(Project Manager) - 스프린트 동안의 팀이 속도 및 진척 관리 - 업무를 배분만 하고, 일은 강요하지는 않음 - Scrum 팀이 스스로 조직하고 관리하도록 지원 |
| 개발 방해 요소 제거 | - 개발 과정에 방해될 만한 요소를 찾아 제거 | |
| 스크럼 팀 (Scrum Team) |
요구사항 구현 | - 팀원은 보통 5~9명으로 구성되며, 사용자 요구 사항을 사용자 스토리로 도출하고 이를 구현 |
| 제품 시연 | - 하나의 스프린트에서 생산된 결과물을 제품 책임자에게 시연 | |
| 스크럼 회의 진행 | - 매일 스크럼 회의에 참여하여 진척 상황을 점검 | |
| 자기 조직화 (self-organization) |
- 자기 조직화(self-organization)된 구성원들로 구성되며, 자율적으로 스스로 스프린트 목표를 달성하기 위해 최상의 방법을 결정 |
- 스크럼은 Cross functional 팀으로 구성되며, 일정한 주기인 스프린트를 반복하며, 제품을 개발함
스크럼 장단점
| 구분 | 설명 |
| 장점 |
|
| 단점 |
|
스크럼 미팅 유형 비교
| 구분 | Sprint Planning | Daily Scrum | Sprint Review | Sprint Retrospective |
| 진행시점 | 스프린트 시작시점 | 스프린트 진행중 매일 | 스트린트 종료시점 | 스프린트 종료시점 |
| 목적 | 스프린트 백로그 계획 | Product Backlog 현황 공유 및 이슈사항 공유 | 스프린트 성과 리뷰 | 프로세스 개선사항 도출 |
| 결과물 | 스프린트 백로그 | 장애요소 제거 | 스프린트 결과물 | 스프린트 개선안 |
- Scrum은 다양한 미팅을 통해 Backlog 및 이슈 및 성과를 공유하고 Burn Down/up Chart를 통해 진척 관리 수행
SCRUM vs. XP
| 비교항목 | SCRUM | XP |
| 형태 | - 관리 및 조직적 실천법 집중 - 개발프로세스 프레임워크 |
- 프로그램 실천법에 집중 - 엔지니어링 방법에 초점 |
| 개발주기 | 4~6주(30일) | 1~2주(10일) |
| 요구사항변경 | - Sprint 내 요구사항 변경 불가 - 변화를 빨리 발견하여 처리하는 관점 |
- 리팩토링을 통해 요구사항 변경 수용 - 요구사항 변경은 당연히 발생한다는 개념 |
| 개발우선순위 | Team이 개발 우선순위 결정 | 고객(Customer)이 개발 우선순위 결정 |
| 공통점 | agile 방법론으로 짧은 개발주기로 반복 개발 | |
SCRUM 용어 vs. XP 용어
| SCRUM 용어 | XP 용어 |
| Product Owner | Customer |
| SCRUM Master | XP Coach |
| Team | Team |
| Sprint | Iteration |
모범답안
참고 동영상