DAILY

[코드스테이츠 PMB 9기] 스크럼

Ellaso 2022. 1. 11. 12:20
W8D2 학습목표
- 애자일 기반 개발 절차의 각 단계별 업무를 도식화하여 설명할 수 있다. 
- 상황에 맞게 적합한 개발 방법론을 선택할 수 있다.

개념 정리
- 스크럼 핵심
- 칸반

이후 답변 가능한 질문
- 스크럼 프레임워크는 어떤 과정으로 애자일 개발을 구현하는가?
- 칸반이 스크럼 프레임워크에서 하는 역할은 무엇인가?

스크럼 프레임워크란?

Agile(애자일) 접근법은 혁신적인 제품과 서비스 개발 방식입니다. 그 중에서도 대표적인 방식인 스크럼에 대해 알아보겠습니다.

스크럼은 팀이 중심이 되어, 개발의 효율성을 높인다는 의미의 용어입니다.

  • 스크럼은 팀원 스스로 스크럼 팀을 구성합니다. (Self-organizing)
  • 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 합니다. (Cross-functional)
  • 역할은 아래와 같은 구성으로 팀이 이루어집니다.

스크럼 프레임워크의 철학

Values 가치 중심
Commitment 헌신
Focus 집중
Respect 존중
Courage 용기
Openness 개방성
Trust  믿음
Empiricism 경험 중심
Transparency 투명성
Inspection 점검
Adaptation 적응

 

스크럼 프레임워크의 원리

  1. 우리는 고객을 잘 모릅니다.
  2. 그렇기 때문에 빠르게, 그리고 자주 고객에게 릴리즈하고 새롭게 발견해야 합니다.
  3. 그렇게 여러 번의 가설 검증 단계를 거치고
  4. 우리가 진짜 필요한 것이 무엇인지, 피해야 할 것이 무엇인지 알아냅니다.
  5. 그렇게 우리는 이해관계자들에게 더 빠르게, 더 잘 그들이 원하는 것을 전달할 수 있습니다.

 

스프린트 계획회의, 사용자 스토리와 백로그

스프린트 계획 회의에서는 제품 책임자(product owner)가 사용자 스토리를 기반으로 제품 백로그를 작성합니다. . 제품 백로그는 이해관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록을 말합니다.사용자 스토리는 고객이나 개발자가 모두 이해할 수 있도록 고객이 작성하거나, 고객이 서술하는 형식으로 작성되어야 합니다. 일반적으로 유저스토리의 작성은, '나는 ~로써 ~하기 위해 ~하고 싶다’라는 형식으로 작성하며 who, why, what 정보가 모두 포함되어 있어야 합니다. 제품 백로그는 이 유저 스토리를 바탕으로 작성됩니다.

이런 식으로 유저스토리를 한 문장으로 정의하면, 모든 팀이 커뮤니케이션하기에 용이하다는 장점이 있습니다.

 

스프린트 백로그(sprint backlog) 작성

제품 백로그에서 결정된 우선순위를 기반으로 스프린트 동안 해야 하는 일에 대한 리스트를 스프린트 백로그라고 합니다. 제품 백로그가 할일 목록이라면, 스프린트 백로그는 짧은 기간 동안 할일 목록입니다. 일반적으로 스프린트 기간은 적게는 1주~2주 길게는 한 달 정도로 설정합니다.

그 다음엔 스프린트 목표를 구현 가능하도록 각각의 요구사항을 task 단위로 나누어 개발자들이 나눠서 작업을 수행합니다. 많은 팀들이 벽 크기의 업무 보드 형식의 스프린트 백로그를 만드는데 이것을 스크럼 보드(Scrum Board)라고 합니다.

데일리 스크럼 미팅(daily scrum meeting)

일일스크럼 미팅은 개발원들이 늘어지는 것을 방지하기 위해 스탠드업 미팅 형식으로 진행됩니다. 매일 정해진 시간에 정해진 장소에 모여 15분~20분동안 간단하고 빠르게 진행합니다. 어제 했던일과 오늘 할일, 수행중 문제점이나 장애요인 등을 공유하며 문제가 있을 경우 미팅 후 바로 해결합니다.

일일 스크럼 미팅을 함으로서 프로젝트 후반부에 문제점이 갑자기 발생하는 것을 예방합니다. 일일 스크럼 미팅 시에 해당 그래프를 팀원들과 함께 확인하고, PM은 일이 늦어지는 이유를 찾아내서 이슈를 해결해줘야 합니다.

스프린트 리뷰

스프린트 리뷰는 스프린트가 종료되었을 때 개발팀이 스프린트동안 개발한 기능을 고객을 포함한 이해관리자들에게 보여주고 피드백을 받는 과정을 말합니다. 고객은 자신이 요청한 요구사항이 해당 스프린트동안 제품이 잘 반영되었는지 평가한 후 피드백을 하면 프로덕트 오너는 고객의 피드백이나 여러 사항들을 정리하여 다음 스프린트에 반영되도록 제품 백로그를 다시 갱신합니다. 스프린트 기간에 해내지 못한 것이 있어도, 모두 다시 하는 것이 아니라- 스프린트 리뷰를 통한 피드백과 새로운 우선순위를 정해서, 모두 종합적으로 우선순위를 나누고 스프린트의 기간과 프로젝트 양을 다시 정하게 됩니다. 스프린트의 한주당 스프린트 리뷰 시간은 한 시간으로 제약되어 있으며 스프린트 리뷰를 준비하는데 30분을 넘지 않도록 해야한다.

스프린트 회고(sprint retrospective)

스프린트 리뷰가 제품 기능에 대한 회고라면, 스프린트 리뷰 후 프로젝트를 진행하면서 좋았던 점이나 문제점, 미진한 점 등을 도출함으로써 다음 스프린트를 보다 더 나은 방향으로 개선할 수 있도록 하는 과정을 말합니다. 스프린트 리뷰는 개발한 기능에 대한 리뷰라면, 스프린트 회고는 전반적인 스프린트 과정에 대한 리뷰라고 보시면 됩니다. 스프린트 회고 과정에서 스크럼 마스터 또는 PO는 중재 및 조정 역할을 하는 퍼실리테이터(facilitator), 촉진자 역할을 하게 됩니다. 스프린트 회고 과정을 통해 이미 정해진 프로세스로만 프로젝트를 수행하는 것이 아니라 프로세스가 끊임없이 개선되도록 하여 변화하고 있는 환경에 더 능동적으로 적응할 수 있도록 합니다.

 

제품 개발 방법을 선정해야 할 때 고려해야 하는 요소

  1. 스코프: 업무 범위가 얼마나 되는가 (무슨 기능을 만들어야 하는가)
  2. 스케쥴: 투입 가능한 시간이 어떻게 되는가, 시간이 얼마나 있는가, 기한이 언제인가
  3. 리소스: 투입할 수 있는 리소스(돈과 자원, 사람 등)이 얼마나 있는가

워터폴 개발 과정에서 PM의 역할

워터폴 개발 절차에서 PM은 특정 프로젝트에서 요구되는 내용들을 파악하고, 중간에 바뀌지 않도록 초기에 계획을 잘 구성해야 합니다. 그 과정에서 우선 순위를 매겨 모든 유형의 자원을 시간 내에 배치하여 정상적인 궤도로 작업될 수 있도록 계획해야 합니다. 자원의 배치를 잘 해서 기한 내에 작업될 수 있도록 하여 투입되는 리소스를 최소한으로 하는 데 의의가 있습니다.

애자일 개발 과정에서 PM의 역할

애자일 개발 과정에서 PM이 하는 역할 중에 가장 중요한 것은 이 스코프를 잘게 쪼개는 것입니다. 핵심 기능 위주로 빠르게 개발할 수 있는 형태로 최대한 잘게 쪼개고 실제로 구축될 수 있도록 하는 것입니다.

 

칸반과 스크럼의 업무 방식 차이

칸반 스크럼
지속적인 흐름을 달성 시간에 기반을 둔 타임 박스 프레임 워크
시간의 제한을 가지지 않고, 지속 시간이 아닌 ‘효율성’을 기반 Scrum의 반복은 Sprint라고 하는 기간이 고정되어 있고, 이 반복 주기는 보통 2-4주 정도
업무 진행에 대한 필수 요구 사항이 없음 계획에 의존성이 높고
작업 프로세스 진행 중에 변경이 가능하며 새 항목을 추가할 수도 있음 스프린트 계획으로 시작해 스프린트 회고로 프로세스가 종료
회의를 권장하긴 하지만 필수 사항은 아닙  회의는 모든 팀원에게 의무적
daily meeting, risk review, strategy review와 같은 여러 회의가 있습니 daily 회의는 일반적으로 매일 같은 장소에서 같은 시간에 개최, 스크린트 계획, 데일리 스크럼, 스프린트 리뷰, 회고와 같은 회의
작업을 시각화하고 효율성과 흐름을 극대화하는 것을 목표  
Kanban board를 작업 흐름을 최적화할 수 있는 워크플로우 시각화 도구로 활용  
상태/진행 상황/문제를 알리고 공유하는 것이 목적
진행중인 병목 지점을 파악하는 데에 도움
  

 

 

 

 

아래 사이트에 접속해 Korean을 찾아 스크럼 가이드 한국어 버전을 다운로드 받습니다.https://scrumguides.org/download.html'프로덕트 오너' 파트를 읽고 프로덕트 매니저로서 스크럼을 관리하는 과정에 필요한 업무 요소를 요약 정리해 봅니다.'스프린트' 파트를 읽고 실제 스프린트가 진행되는 과정에서 중요하게 생각해야 하는 점을 요약 정리해 봅니다.그 외의 파트들에 대해서도 상세하게 검토를 하고, 학습한 내용과 연결지어 중요한 부분을 추출해 정리해 봅니다.

 

 

 

 

프로덕트 오너는 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는다. 이 업무를 수행하는 방법은 조직, 스크럼 팀, 개인에 따라 다를 수 있다.    8 프로덕트 오너는 프로덕트 백로그를 효과적으로 관리하는 것에도 책임이 있는데, 다음 사항들을 포함한다:  프로덕트 목표를 세우고 명쾌하게 소통하는 것;  프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것;  프로덕트 백로그 아이템을 우선순위에 따라 정렬;  프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것.    프로덕트 오너는 위에 나온 일을 직접 하거나 혹은 다른 사람들에게 그 책임을 위임한다. 어떤 식으로 하든지 최종 책임은 프로덕트 오너가 갖는다.    프로덕트 오너가 성공적으로 일을 하기 위해서는 조직 전체가 반드시 그의 결정을 존중해야 한다. 프로덕트 오너가 내린 결정들은 프로덕트 백로그의 내용과 우선순위에 따라 정렬한 것을 통해 확인할 수 있다. 또한 스프린트 리뷰 때에 점검 가능한 증가분을 통해서도 볼 수 있다.    프로덕트 오너는 한 사람이지 여럿으로 구성된 위원회가 아니다. 프로덕트 오너는 프로덕트 백로그와 연관된 많은 이해관계자들의 요구를 대표한다. 프로덕트 백로그를 변경하고 싶은 사람들은 프로덕트 오너를 설득하여야 한다.