Agile Process - Scrum

제품을 개발(배포)하고, 유지하기 위한 프레임워크

- 비즈니스 요구를 충족시키는데 초점을 맞추기 위해 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 프레임워크(기법)

- 사람들이 효과적으로 성취감을 충족하며 협업할 수 있게 하여 복잡하고 정교한 제품을 생산

 

Scrum:

- Is an agile, lightweight process

- 소프트웨어와 프로덕트 개발을 관리, 제어 가능

- 반복적, 점진적 방법

- 간단한 구현

- 생산성 향상

- 시간 감소

- 적응형 경험적 시스템 개발 수용

- 소프트웨어 개발 프로젝트에 국한되지 않음

- 워터폴 접근 방식의 반대를

 

스크럼 사용

-> 프로젝트의 규모와 난이도 면에서 요구사항이 너무 복잡하면 안되고 좀 중간 정도의 난이도가 적절

 

Product Backlog

-> 그 중 하나 Sprint Backlog

-> 나눠서 Backlog tasks

-> 데일리 스크럼 미팅 등..

 

모든게 Sequntial 하기 보다는 Overlap 되어 진행됨

Sprint 진행 중에는 변화가 있어선 안됨

 

Scrum Framework

Roles

- Product owner

- Scrum Master

- Team

 

Ceremonies

- Sprint planning

- Sprint review

- Sprint retrospective

- Daily scrum meeting

 

Artifacts

- Product backlog

- Sprint backlog

- Burndown charts

---

Scrum Roles

Product owner (고객측)

- 제품의 기능 정의

- 출시일 및 컨텐츠 결정

- 제품의 수익성을 책임짐 .. ROI (Return of Investment)

- 시장 가치에 따라 기능 우선 순위 지정

- 필요에 따라 모든 반복 기능 및 우선순위 조정

- 작업 결과 수락 또는 거부

 

The Scrum Master (개발 팀장)

- 프로젝트의 경영진을 나타냄

- 스크럼 가치 및 관행 제정 담당

- 장애물(impediments) 제거

- 팀이 완전히 기능적이고 생산적인지 확인

- 모든 역할과 기능에 걸쳐 긴밀한 협력 지원

- 외부의 간섭으로부터 팀 보호

 

The team (개발팀)

- 일반적으로 5~9명

- Cross-functional: 프로그래머, 테스터, UX 디자이너 등

- 멤버는 full-time이어야 함 (예외는 DB 관리자)

- 팀은 자체적으로 조직화 (직함 없음)

- 스프린트 사이에만 멤버십 변경 가능

---

Ceremonies

Sprint Planning Meeting

팀 역량, 프로덕트 백로그, 비즈니스 컨디션, 현재 생산물, 기술

=> Sprint planning meeting => Sprint goal, Sprint backlog

 

Sprint prioritization

- 프로덕트 백로그 분석, 재평가

- Sprint Goal 선택

=> Sprint Goal

 

Sprint Planning

- 어떻게 Sprint Goal 달성할 것인지 결정(design)

- Product backlog items(user stories)에서 Sprint Backlog(및 tasks) 생성

- Sprint backlog 예상 시간 추정

=> Sprint Backlog

|

- 팀은 완료할 수 있는 프로덕트 백로그에서 항목 선택

- 스프린트 백로그 생성

- 작업이 식별되고 각각 추정됨 (약 8시간~16시간)

- 스크럼 마스터 혼자 수행하지 않는 협업

- 높은 수준의 설계 고려됨

 

Daily Scrum Meeting

Parameters

- 매일, 최대 15분, 일어서서

- 지각하면 1달러 같은 패널티

 

Not for problem solving

- 누구나 초대됨

- 팀 멤버, 스크럼 마스터, 프로넉트 오너만 말할 수 있음

- 불필요한 미팅을 피하는데에 도움

 

팀원은 세 질문에 답함

- 어제 뭘 했나

- 오늘 무엇을 할 것인가

- 어떤 장애물이 있는가

 

The Sprint Review

- 팀이 스프린트 과정에서 달성한 성과 발표

- 일반적으로 새로운 기능이나 기본 아키텍처의 데모 형태를 취함

- 비공식: 2시간 이내의 준비 시간, 슬라이드 없이

- 전체 팀 참여

- 전세계 초대

 

Sprint retrospective

- 주기적으로 작동하는 것, 하지 않는 것 살펴보기

- 15~30분

- 모든 스프린트 종료 후

- 전체 팀 참여

- 스크럼 마스터

- 프로덕트 오너

- 팀

- 고객 및 기타 등등

---

Artifacts

액셀 스프레드 시트로 관리됨

다른 툴이 있긴 한데 비싸거나, 별로거나, 개발 중

 

Product backlog

- 요구 사항

- 프로젝트에서 원하는 모든 작업 목록

- 각 품목이 제품의 사용자 또는 고객에게 가치가 있도록 이상적으로 표현

- 제품 소유자가 우선순위 지정

- 각 스프린트가 시작될 때 우선순위 지정

 

The sprint goal

- 스프린트 중에 집중할 작업에 대한 짧은 설명

 

User stories

who (사용자 역할) - 고객, 직원, 관리자?

what (goal) - 달성/개발해야 하는 기능은 무엇인가?

why (이유) - 왜 그 목표를 달성해야 하는가?

 

[who .. user role]로서 [what .. goal]을 달성하고 싶고, 그러면 [why .. reason] 할 수 있다

 

 

Sprint Backlog

- Product Backlog에서 하나 뽑음

- 개인이 선택한 작업에 등록

- 작업이 할당되지 않음

- 남은 예상 작업은 매일 업데이트

- 팀원 누구나 스프린트 백로그 추가, 삭제, 변경 가능

- 작업이 불분명한 경우 시간이 더 긴 스프린트 백로그 항목을 정의하고 나중에 세분화

- 더 많은 정보를 알게 되면 남은 것 업데이트 작업

 

Sprint Burndown Chart

- 완료된 작업과 완료해야 할 작업이 무엇인지 표시

- 개발자 또는 작업 항목 별로 하나씩

- 매일 업데이트됨

(매일 완료되는 시간을 추측)

 

변형: Release burndown chart

- 전체적인 진척을 보여줌

- 스프린트의 각 끝에서 업데이트됨

 

번다운 차트가 일직선 : 진척 안됨

번다운 차트가 내려갔다 일직선이다.. : 되곤 있는데 빠르고 효과적이진 않음

번다운 차트가 급하락: 너무 빨리 끝남

---

Scalability

- 일반적으로 7+-2명의 사람

- 확장성은 팀의 팀으로 만듦

 

Factors

- Type of application

- Team size

- Team dispersion

- Project duration

...

스크럼은 500명 이상의 프로젝트에도 사용 가능