Chap 05. 서비스 기획 업무 A~Z 애자일방법론 스크럼이란? Scrum 개념 진행 프로세스 (2)

 

애자일 방법론 개념은 이전 포스팅 참고해 주세요 

Chap 05. 서비스 기획 업무 A~Z 린캔버스 , 애자일방법론 이란? 애자일방법론 개념, 일을 쪼개는 단

 

 

 

---

 

1. 스크럼 Scrum 이란? 

 • 애자일의 대표 관리 Practice로, 팀이 중심이 되어 개발의 효율성을 높이는 일종의 프로세스 프레임워크
 • 개발팀/기획팀/디자인팀이 따로 존재하지 않고 하나의 팀(프로덕트팀)으로 개발을 함께 진행해 나가는 애자일 소프트웨어 개발 방법론

 • 애자일에서는 반복주기를 이터레이션, 스크럼에서는 반복주기를 스프린트(Sprint)라고 한다.

 • 팀이 협업하고 목표를 달성하기 위해 필요한 관리 프레임워크

 

• 무엇을 하는지, 할지에 대해 명확하다면 -> 워터폴 방법론 사용 추천
• 어떻게 할지에 대해 복잡성이 요구되는 상황 -> 애자일 방법론 사용 추천

 

 

스크럼의 원리 

1. 우리는 고객을 잘 모른다.

2. 그렇기 때문에 자주 고객에게 릴리스하고 새로운 피드백을 받아야 한다.

3. 지속적인 개발과 피드백을 통해 여러번의 가설 검증 단계를 거친다.

4. 가설 검증의 단계를 통해 우리가 진짜 필요한 것이 무엇인지, 피해야 할 것이 무엇인지 알아낸다.

5. 그렇게 이해관계자들에게 더 빠르게, 더 잘 그들이 원하는 것을 전달할 수 있다.

 

스크럼의 원리는 이 순으로 진행된다. 

 

---

 

2. 스프린트 전에 진행되는 프로세스 

 

 

 

< 프로세스 절차 >
1) 프로덕트 백로그 관리 
2) 스프린트 플래닝 미팅 
3) 스프린트 백로그 선정
4) 스프린트 1~4주 진행되는 도중 매일 진행되는 데일리 스크럼
5) 업무 완료 후 스프린트 리뷰 + 회고
=> 이 과정이 반복적으로 지속

 

 

- 백로그란 개발해야할 기능 또는 제품에서 요구하는 기능과 우선순위를 뜻한다.
- 스크럼에서는 각각 프로덕트 백로그, 스프린트 백로그가 있다. 

- 프로덕트 백로그가 프로덕트 항상 목표로 업무를 우선순위에 따라 정렬한 목록이라 한다면,

- 스프린트 백로그는 우선순위를 기반으로 스프린트 목표를 달성하기 위해 프로덕트 백로그에서 선택된 할 일 목록을 뜻한다.

- 스프린트(Sprint)는 모든 팀원이 정해진 기간동안 정해진 태스크를 전력 질주하듯 집중해서 업무를 수행하는 것을 의미

 

 

 

1) Product Backlog 관리

진행하는 사람 : Product Owner

 

• Product Backlog 란?

- 제품 개설을 위해서 진행되어야할 다양한 요구사항

- 제품 관련 다양한 인원들로부터 수집

- 요청자/백로그 생성 이유/추정시간/요구명세 등 다양한 내용을 포함

- 우선순위는 반드시 포함 !!

- Product Owner는 백로그의 구성사항을 지속적으로 개선해야 한다.

 

• Product Backlog 작성법 

- 요구사항을 작성하되 구체적인 실행방안에 대해서는 작성하지 않아도 된다

- 백로그 진행이 중요한 이유에 대해서 자세히 작성할수록 우선순위가 높게 산정되고 제품 개발이 빨라진다

 

• 우선순위가 높은 백로그일수록 ->  최대한 구체화, 더 작은 단위로 쪼개서 -> 다음 스프린트에서도 개발이 진행 가능한 상태로 만들어줘야 한다.

우선순위가 설정된 이유에 대해서 프로덕트팀, 외부팀원들에게 논리적으로 설명할 수 있어야 한다.

 

 

2) 스프린트 플래닝 미팅 > Sprint Backlog 선정 

- 통상 1~4주 정도의 Time box 성격을 가진 개발주기

  ex. 오늘의 집 - 2주 정도로 운영 / 보통 2~4주 정도 운영

- 각 Sprint 단계 종료 시 새로운 기능이 추가되어 제품에 반영되는 것을 목표로 한다

- 스크럼은 Sprint를

 

 

 • Sprint Planning Meeting 이란?

- 백로그들 중에 이번 스프린트에 어떠한 백로그를 진행할지 모든 팀원들이 함께 논의하는 회의

  -> 프로덕트 백로그 중에 스프린트 백로그를 선정하는 회의

- 프로덕트 오너는 독단적으로 목표를 설정하면 안 됨, 정해진 기간 안에 수할 수 있는 백로그만 가져와야 한다.

- Sprint Planning Meeting를 통해 Sprint Backlog를 선정

- 보통 Sprint Backlog는 Sprint가 시작된 이후 변경하지 않는 것을 원칙으로 한다
(중요도, 수행가능성, 일의 크기를 종합적으로 판단해서 팀원들이 깊이 있게 토의하는 것이 중요)

 

 

3) 스프린트

진행하는 사람 : 스크럼 마스터 또는 PO가 담당하는 경우가 많다

 •  스크럼 마스터 Scrum Master

- 스프린트의 진행상황을 검토하고, 목표달성에 위협이 되는 사항들을 확인하여 해결하는 역할

- 팀원들 간의 커뮤니케이션 이슈, 예상보다 어려운 개발 난이도, 우선순위 산정에 대한 이견 등 모든 문제들을 지속적으로 파악하고 조정하는 역할 => 반드시 Servant LeaderShip이 필요하다.

- 보통 스크럼 마스터를 따로 두고 있는 기업은 드물고, PO 또는 PM이 이 역할을 병행

- 팀원 옆에서 지속적으로 경청, 공감하며 팀원의 아래에서 그들이 목표를 달성할 수 있도록 서포트해 주는 역할

 

 

 • Daily Scrum Meeting 데일리 스크럼 미팅

- 매일매일 약 15분씩 진행되는 짧은 미팅(콤팩트하게) 
- 결과를 보고하는 자리 x / 목표 달성 확률을 최적화하기 위해 팀원들에게 공유하고 도움이 필요할 경우에는 빠르게 요청할 수 있는 자리 

- 스프린트가 목표에 맞게 진행되고 있는지, 스프린트 백로그에 있는 작업이 잘 완성되고 있는지 검토

- 데일리 스크럼은 개발팀이 스프린트 목표를 달성할 수 있는 확률을 최적화한다

- 전체 개발팀이나, 팀원들은 종종 일일 스크럼 미팅이 끝나자마자 더 상세한 의논을 하거나 스프린트 작업에 대한 조정 및  재계획을 하기 위해 추가적인 미팅을 할 수 있다

 

 

4) 스프린트 후 프로세스 : 스프린트 리뷰 + 회고

모든 스크럼 팀원이 참여하여 진행하는 회의

 

 • 스프린트 리뷰 

- 스프린트를 통해 무엇이 완료되었는지를 팀원과 이해관계자들이 모여 확인

- 리뷰 결과와 스프린트 수행 중 변경된 백로그를 고려하여 다음에 무엇을 할지 함께 의논

- 성과 보고를 위한 미팅 x
- 스프린트를 통해 완료된 개선사항을 발표함으로써 피드백을 받고 협력을 촉진하기 위한 회의

 

 •  스프린트 리뷰가 진행되는 동안 PO(프로덕트 오너)의 역할

- 팀원들이 해낸 사항들에 있어서 가장 쉽고 명확하게 전달할 수 있는 것이 중요

- 팀이 해결한 문제가 얼마나 중요한 문제인지, 이를 통해 어떤 성과를 얻었는지 

- 향후 어떠한 성과를 얻어 나갈 것인지 대해 명확하게 설명 => 팀원들의 의욕을 상승시키기

 

 

 • 스프린트 회고 (리뷰 다음 순서)

- 스프린트 리뷰 vs 회고 차이점

스프린트 리뷰 : 스프린트 동안에 만들어진 결과물에 대한 이야기를 나누는 자리

회고 :  스프린트 진행 과정에 대해 이야기를 나누는 자리 

 

- 다음 스프린트 동안 무엇을 개선할 수 있을지 계획하는 단계

- 스프린트 리뷰 미팅 후 & 스프린트 플래닝 미팅 전에 수행

- 회고의 목적

지난 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행되었는지 검토

잘된 것들과 개선의 여지가 있는 항목을 알아내고 우선순위 결정

개선을 실천할 수 있도록 계획 수립

 

 •  회고 방법론 : KPT

Keep / Problem / Try

좋았던 부분 / 안 좋았던 부분(문제점이라고 생각) / 시도해 볼 수 있는 부분 

 

 • KPT 진행 방법

- 화이트보드에 Keep / Problem / Try 영역을 나누어 적어보기

- Keep : 좋았던 부분, 계속 유지되었으면 하는 부분

- Problem : 잘되지 않았던 부분, 고쳐야 할 부분

- Try : Problem을 해결할 수 있도록 실천할 수 있는 부분

 

- 포스트잇에 적어 붙여 나가는 것 

이때, PO의 역할 : 팀원들에게 고민할 시간을 충분히 제공 -> 많은 양의 포스트잇이 붙여질 수 있도록 독려

-> 이를 통해 발견되는 해결책 또한 가치가 높아진다

 

- Try는 이중 가장 중요한 부분, 구체적이고 실행 가능해야 한다

 

ex)
Problem [상황]
"이번 스프린트를 진행하는 동안 기획서 중간중간에 개발에 필요한 내용들이 빠진 부분이 많아서 개발속도가 전체적을 늦춰졌다/"

[Try]
안 좋은 예 / 앞으로 기획자가 조금 더 신경 쓰자(구체적 x)
좋은 예 / 기획자가 개발 진행 전, 기획문서를 디자이너와 개발자에게 충분히 리뷰받는 프로세스를 만들어보자
(실행가능 o, 구체적 o) 

 

 

- Try의 우선순위도 만들기 

- 가장 우선순위 높은 try를 정하는 것이 중요

- 우선순위 높은 Try들을 다음 스프린트에 진행하고, 다음 회고 때 진행상황에 대해 공유하는 것이 중요

- 이때 PO의 역할 : 지속적으로 트래킹 하고 팀원들을 독려하기

 

 

---