[소프트웨어공학] scrum이란...!

 

애자일 방법론에는 종류가 많다. Kanban, Feature-driven development 등등. 애자일하게 일하기 위한 방법들이다.

이중 scrum에 대해 알아보자. 

 

scrum팀에는 세가지 역할이 있다.

 

1️⃣ Product Owner

고객이 원하는 바를 파악하고 이를 제품에 반영한다.

제품의 vision을 설정하고 고객이 가장 가치 있는 제품을 빠르게 전달받을 수 있도록 우선 순위를 매기고 수정한다.

고객의 피드백과 needs를 제품에 반영한다.

Product Backlog를 전반적으로 관리한다.

 

2️⃣ Scrum Master

scurm에 대해 사람들이 이해하고 수행하는가를 책임진다.

팀이 scrum 규칙, 이론, 실천을 잘 따르고 있는가를 보장해야 한다.

servant-leader

 

3️⃣ Team

말 그대로 팀이다. 팀은 3~9명으로 크지 않게 구성된다.

팀 전체가 성공/실패해야 하며 지속성이 있어야 한다.

self-organization : 외부 명령/통제 없이 스스로 sprint 목표를 달성하기 위해 최상의 방법을 결정한다.

Cross-functional : 다양한 배경과 지식을 가진 팀을 구성. 

 

 

✅ Product backlog란

Product Owner가 stake holder(이해관계자, 쉽게 말해 고객)의 요구사항을 모아 놓은 것.

업무는 기능/비기능/오류 수정/지식습득(spike)로 분류되며 각 항목은 Product Backlog Item(PBI)라 불린다.

우선순위 별로 정렬한다. 

✅ Sprint planning meeting이란

product backlog에서 sprint backlog를 작성하는 과정

✅ Sprint backlog란

sprint 동안 수행해야 할 일의 목록이다. Product Owner가 product backlog를 보고 정한 우선순위를 기반으로 작성된다.

✅ Daily Scrum Meeting이란

매일 진행하는 15분의 회의. 프로젝트 현황을 공유한다. 오늘 할 일 등을 공유한다. 해결책을 말하자는 건 아니다.

scrum master는 이때 scrum의 문제점을 파악하고 새로운 인원에게 scrum 방식을 공유하는 등의 일을 한다.

참여 가능한 모든 인원이 참가한다.

✅ Sprint review란

제품을 평가하는 시간이다. sprint 동안 만들어진 production을 stakeholder에게 보여주는 데모를 수행한다. 우선순위를 조정하거나 product backlog를 다시 갱신할 수 있다.

✅ Product Increment란

한 sprint가 끝나면 나오는 동작 가능한 software

✅ Sprint retrospective란

프로세스를 평가하는 시간이다. sprint가 끝나면 일정 주기로 진행한다. 프로젝트 문제점, 좋았던 점 등을 공유하고 개선 방법을 모색한다. 

 

 

사용자 요구사항은 story로 표현되는 경우가 많다.

story는 세 측면이 있다. 3Cs

✅ Card : 대화를 위한 매개체. 간단하게 작성되어야 하며 Who, What, Why를 포함한다.

✅ Conversation : 세부사항의 구체화

✅ Confirmation : story의 완료 여부 판단

 

좋은 story라면 INVEST

1️⃣ Independent 

story끼리 의존성이 적어야 한다. (의존성이 높으면 priority 선정이 애매해짐/개별 개발이 어렵다)

2️⃣ Negotiable

협상이 가능해야 한다.

3️⃣ Valueable

모든 story는 사용자에게 가치를 줘야 한다.

4️⃣ Estimable

추정이 가능해야 한다. (너무 볼륨이 큰 story == epic은 분할해야 한다)

5️⃣ Small

알맞은 크기의 story가 좋다.

6️⃣ Test

story가 언제 완료 되는지 확인할 수 있어야 한다.

 

 

Product backlog는 DEEP

1️⃣ Detailed appropriately

당장 수행할 PBI 말고는 비슷한 수준으로 상세화를 덜! 해야 한다.

2️⃣ Emergent

상황에 따라 product backlog는 변경된다.

3️⃣ Estimated

PBI는 추정치(크기)를 갖고 있다(사용자 story 규모를 나타내는 상대적인 story point가 있다).

우선순위가 낮은 story는 크기가 큰 epic일 가능성이 높다.

4️⃣ Prioritized

 

story point란

사용자 story의 규모를 표현하는 단위다. story를 구현하는 데 소요되는 시간, 노력 등을 종합적으로 표현한다.

story point는 fibonacci 값으로 표현하며 팀 안에서 이 값이 수렴할 때까지 point를 맞추는 Planning poker를 하기도 한다.

 

우선순위는 MosCow

✅ Must

✅ Should have

✅ Could have

✅ Wont have

 

 

Backlog refinement(refinement) meeting이란

epic을 적절히 task로 분할하고 우선순위 조정 등의 작업을 진행한다. Planning poker도 진행할 수 있다.

meeting을 sprint 안에 하기에는 sprint가 매우 짧기 때문에 sprint 이전에 진행한다.

story를 준비 상태로 만들고(DoR 요건 만족) sprint동안 DoD요건을 만족하도록 한다.

 

Definition of Read(DoR)

product backlog에서 sprint backlog로 이동하기 위해 만족해야 하는 요건 목록

Definition of Done(DoD)

Done 상태로 가기 위해 만족해야 할 요건 목록, 모든 story에 적용된다.