[소프트웨어 공학] 스크럼 (Scrum)

Posted Mar 19, 2024 Updated Apr 3, 2024

By Keem

11 min read

스크럼

1. 스크럼은 무엇인가?

애자일 방법론 중 하나로 널리 사용되는 애자일 방법론 중 하나

Scrum, Kanban, Extreme Programming 순으로 사용량 ↑

Agile에서 iteration은 Scrum에서 Sprint (반복주기)
초기에 설정된 Sprint 기간은 변경되지 않음
Scrum의 각 Sprint에서 해야할 일은 Sprint Backlog(Sprint 목표 달성을 위한 일)에 있음 (Sprint Planning Metting에서Product Backlog의 우선순위 정함)
Daily Scrum Meeting(15 minutes <= ) 을 진행함 (3 People to 9 People) - 진행 현황, 추후 방향성
Sprint Review(Product Review), Sprint Retrospective(Sprint Review)
Scrum의 최종 산출물 -> increment

2. 3-5-3

2.1 Scrum Team (3)

Product Owner - 무엇을 만들지, 왜 만들어야하는지
Scrum Master - 일을 더 잘할 수 있도록
Team(개발자)

2.1.1 Product Owner

고객의 니즈를 파악하여 제품 방향성 *(Vison) 설정하고 가치있는 제품을 위한 우선순위 선정
고객의 피드백 수용, 개발팀에 고객 니즈를 전달

Product Backlog (고객의 요구사항, 우선순위) 관리

Vison - 프로젝트의 방향성을 보여줌 (명확하고 간결하게 모두가 알고 있어야함)
- 목표 고객과 고객의 필요성
- 가치 전달
- 다른 제품과의 차별성

2.1.2 Scrum Master (일을 시키는 역할이 아님)

조직이 스크럼을 제대로 이해하고 수행하는지에 대한 책임
스크럼 팀을 도와주는 리더 (Servant-leader)
애자일 개발 프로세스 관리

2.1.3 Team (개발팀)

self-organization (자기조직화) - 외부 명령, 통제 없이 스프린트 목표를 위해 최상의 방법 결정
cross-functional
- 다양한 배경과 지식을 가진 팀원으로 구성
- Product Backlog의 항목을 가져와 스프린트 기간동안 완성하여 동작하는 소프트웨어를 만들 수 있는 일련의 기술 제공
Team Scale - Two Pizza Team
한 팀으로 행동하며 팀의 지속성이 필요

2.2 Scrum Event (5)

Sprint Planning - 스크럼 계획
Daily Scrums (일일 스크럼 미팅 Meeting)
- 스탠드업 미팅
- 진행현황, 이슈 공유 및 추후 발생할 문제점 예방
Sprint Review - stakeholder(이해 관계자) 참여
- Sprint Increment를 고객을 포함한 모두에게 구현 기능을 보여주며 데모 수행
- 고객의 요구사항 충족되었는지 피드백
- Sprint Review의 피드백을 바탕으로 다음 Sprint에 반영될 수 있도록 Product Backlog 갱신
Sprint Retrospective (고객 X)
- Sprint가 끝나는 시점
- Sprint 프로세스 과정에 대한 피드백
스프린트

각 Scrum Event는 시간이 제약 되어 있음 (Time Boxed) 모두 암기

Event	1 Week	2 Week	3Week	4 Week
Sprint Planning	2 hr	4 hr	6 hr	8 hr
Daily Scrums	15 mins daily	15 mins daily	15 mins daily	15 mins daily
Sprint Review	1 hr	2 hr	3 hr	4 hr
Sprint Retrospective	.75 hr	1.5 hr	2.25 hr	3 hr

Scrum의 산출물 - Product Backlog, Sprint Backlog, Increment

제품 백로그 - 제품에 필요한 모든 것을 기술한 우선순위가 있는 업무 (Product Owner)

업무 분류	백로그 업무 항목 (PBI, Product Backlog Item)
기능	포인트 조회 기능
비기능	1분 이내 조회 -> 성능
오류 수정	코드 오류 수정
Spike (지식 습득)	시제품을 만들어본다

사용자 스토리 - 사용자 요구사항 (사용자 관점)
- Who, Why, What
- ATM 관리자로서 나는 고객이 현금을 인출할 수 있도록 ATM에 현금을 채우고 싶다.
- ~~사용자로서 나는 키워드 정보만으로 책을 탐색하고 싶다.~~ -> Why가 없음
- 스토리의 세 측면 ( 3C )
  - Card - 고객의 요구사항 (간결함, 대화를 위한 매개체)
  - Conversation - 대화를 통해 세부사항 구체화
  - Confirmation - 스토리 완료 여부 판단
- ~~전통적 개발 방식~~
  - 대화 X, 모두 문서화
  - 모든 요구사항들을 같은 수준으로 상세화
- Acceptance Criteria (인수 기준, Confirmation)
  - What에 대한 기능에 대한 충족 및 오류가 없는지 확인
- 3C
- Invest (좋은 스토리를 위한 6가지 조건)
  - Independent - 의존성이 크면 우선순위 설정이 어려움
  - Negotiable - 계약서가 아닌 상세 사항은 협상이 가능해야함
  - Valuable - 고객과 사용자에게 가치 전달해야함
  - Estimable - 크기를 추정하여 노력과 비용 추정 가능해야함
  - Small - 스토리는 알맞은 크기가여야 함
  - Test - 스토리의 완성여부 판단이 가능해야함 (Acceptance Criteria)
DEEP - Product Backlog가 가져야하는 4가지 특성
- Detailed Appropriately
  - Product Backlog Item : Product Backlog에 있는 항목 (스토리)
  - PBI는 우선순위에 따라 상세화 정도가 다름
  - 우선순위가 높은 PBI는 바로 작업할 수 있을 정도의 작은 크기
- Emergent
  - 비즈니그 환경 변화 및 고객 요구 사항 변경으로 Product Backlog는 계속 변경된다. (Sprint Review)
  - Agile 선언문 = 계획의 순응 < 변화에 반응
- Estimated
  - PBI 크기를 가지고 있다. (우선순위가 높으면 작게 분할)
- Prioritised - (MoSCoW)
  - M ust - 필수적인 기능
  - S hould have - 중요하며 가능하다면 포함
  - C ould have - 만족도 높이지만 없어도 문제 X
  - W on’t have - 없어도 됨 (unnecessary waste)
  PBI 모두를 우선순위하려고 노력하지 말라.
스토리 포인트
- 스토리 구현에 필요한 상대적인 노력, 개발 복잡도, 위험성들 대략적으로 분석하여 나타낸 값
- 사용자 스토리의 규모를 표현하는 상대적 크기
- 피보나치 수열 값을 많이 사용함 (0은 이미 완료 or 매우 간단)
- Planning Poker - 스토리 포인트 추정
- 우선 순위가 낮은 스토리는 Epic (large user story)일 가능성이 있음 (13 이상이면 분할할 필요가 있다고 함)

2.3 Sprint Planning (3)

스프린트를 준비하기 위한 회의

Part 1: “What”
- Product Owner, Scrum Master
- 스프린트 목표 설정
Part 2: “How”
- Team, Scrum Master, Product Owner
- Sprint Item 선정하고 스토리를 태스크 단위로 분할
태스크 분할 및 소요 시간 추정
- 스토리를 태스크로 분할 후 소요 시간 추정
- 팀의 가용시간이 넘지 않을 때 까지 스토리 추가
- Pull (Not push) -> Self-Organization
Backlog refinement meeting (grooming, 백로그 정제 회의) - Scrum Event X
- EPIC (한 Sprint에 완성 X) 분할
- Emergent
- 스토리 크기 추정
- 스프린트 10%할애
- DoR (Definition of Ready) - Product -> Sprint Backlog로 이동하기 위한 조건
  - 가치 명확
  - 의존 사항 식별
  - 인수 기준 명확
  - PBI가 충분히 작음
- PBI들이 DoR을 만족하도록 정제하는 회의