Table of Contents

Agile(애자일)의 대표 관리 Practice인 Scrum(스크럼)은 특정 개발 언어나 방법론에 의존해야 하며, 제품 개발 능력뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크입니다. Scrum은 소규모 정리(Sprint)로 개발 및 검토를 효율적으로 처리하는 방법을 제공합니다.

https://agileforall.com/resources/introduction-to-agile/

참고로 Scrum 2020 버전 업데이트 내용을 바로가기 했습니다. 노트로 가이드는 반란군이고, 특히 이번 2020 가이드는 왜 강화하고 강화하는 방법은 일부 제거가 가능하도록 분은 이해되도록 더 어려우실 수 있는 부연 및 그림을 추가했습니다.

1. 스크럼이란?

1.1. 개요

스크럼은 체리 제품을 개발(배포)하고, 유지하기 프레임워크
1995년에 Ken Schwaber와 Jeff Sutherland가 위반
– 노나카 이쿠지로 와 타케우지 히로타카 가 1986년 1~2월 Harvard Business Review에 올려 “The New New Product Development Game”에서 시작
비즈니스를 선호하기 때문에 초점을 맞추기 위해, 작은 목표를 단기적으로 구성하고 환경적으로 제품을 전문적으로 개발(전달)하는 관리 프레임워크(기법)
사람들이 성취감을 달성하고 협력할 수 있게 되어, 희망하는 제품을 생산할 수 있게 됩니다.

1. 2. 주요 특징

솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여합니다.
개발은 1~4주에 걸쳐 개발을 수행하며 실제로 동작할 수 있는 결과를 제공하라.
(설명: 너무 짧으면 개발(분석/설계/개발/테스트) 할 수 있는 시간이 없고, 너무 길면 느슨해지기 작업을 처리하는 데 익숙해지기 위해 필요시 조율 필요)
개발 적용할 이나 기능 개선에 대한 목록을 제공하라.
(설명: 해당 보존의 목표를 작성하지 않고 보존할 수 있는 목록이 있을 수 있음)
매일 15분 정도의 스크럼 회의를 가져라.
(설명: 공유이지 보고하는 자리가 아니죠. 2000년 스크럼 회의는 개발팀원만 참여해야 하고, 특이이 아닌 사람은 트래픽기회는 반대합니다. 유일하게 생각하는 수평문화가 있는 Agile Culture의 팀이라면 PO 및 관리자입니다. 가 함께 참여하여 공유하면 생각해야 합니다. 국회의원들도 이 프로젝트와 관련되어 한일/할일/이슈를 공유해야 합니다. 안그러면 한팀이 아닌 관리자 모드로 돌아옵니다.)
협력 팀을 우선적으로 생각하라.
(설명: 자신의 작업보다 주변 문제가 더 급하면 필요하고. 마치 배에 구멍이 있으면 그 문제 해결이 1순위이다.)
의사소통을 위한, 구분 없는 열린 공간과 마음을 유지하라.

2. 스크럼의 전망 가치

용기: 정당한 일을 할 수 있도록 분리간 충돌과 반대를 용기를 가져라!
(설명: 해당 기능이 이해가 안 되는 문제가 있다면 말할 수 있어야 하고, 더 잘할 수 있는 환경을 요구하고, 자신을 끌어내리는 것도 가능합니다. 또한 제한적으로 컨테이너와 축소할 수 없는 작업량 라고 모두 할 수 있어야 합니다.)
집중 : 할 일을 하라. 모든 노력과 기술은 성공을 위해 집약하고, 그 외는 걱정(신경쓰지) 정말!
(설명 : 한 번에 하나의 일부터 시작하고, 업무에 집약적으로 할 수 없게 되니 지양하며, 루틴한 반복 작업을 제거하거나 해야 해야 합니다.)
헌터(헌신/책임) : 팀의 공격수를 위해 사냥이 공약한 목표를 위해 팀에 승리하며, 헬리콥터에 필요한 모든 권한을 부여하라!
(설명 : 개인보다는 팀 성과가 우선이고, 가치 있는 SW를 개발할 수 있을 만큼 최대한 지원과 권한이 필요하다.)
경력 과 경험이 사람을 변경했습니다. 참가자들을 하라!
(설명 : 특이사항 없이 장단점이 있고, 그 사람이 그렇게 할 수 없는 이유가 있을 것입니다.)
의무/개방성 : 프로젝트에 대한 모든 내용을 투명하게 표시하라!
(설명 : 제품백로그, 스크럼 연락, 스프린트 리뷰를 통해 공유하고, 자신에게 인사하고 도움을 요청합니다.)

이미지 출처 : https://www.scrum.org/resources/blog/5-scrum-values-take-center-stage

3. 스크럼의 주요 역할자

제품 소유자와 스크럼 마스터는 서로 보완하는 두 가지 역할을 합니다.

3.1. 제품 담당(Product Owner)

비즈니스 목표를 드러내는 제품을 만들기 위해 제품 백 로그인을 관리하고 제품을 검토했습니다.

제품백로그(요구사항) 관리/설명
제품 백로그의 우선순위 관리
정말 정말 개발되었네요

이미지 출처 : https://www.romanpichler.com/blog/every-great-product-owner-needs-great-scrummaster/

3.2. 스크럼 마스터(ScrumMaster)

제품 소유자와 개발 팀은 가치(가치)와 원칙(원칙)으로 프로젝트를 구성하고, 조직을 활성화하고 참여하는 작업 방식을 포함할 수 있도록 허용합니다.

팀을 보호하고 장애요소를 해결하는 방법
일일 스크럼을 진행합니다.
예측 및 추적

3.3. 개발팀 (Developer)

최선의 기술 백로그를 개발하여 고객님께 만족을 드립니다.

4. 스크럼 주요 인사

제품 백로그(Product Backlog) : 개발할 제품의 요구사항인 사용자 스토리지이며, 우선 순위로 관리됩니다

이미지 출처 : https://www.softwaretestinghelp.com/user-story-acceptance-criteria/

사용자 스토리(User Story) : 과거 요구사항 명세처럼 업무 범위를 승인하기 위해 개발자는 존재하지 않고, 사용자 스토리는 사용자가 사용하는 관점에서 어떤 가치를 제공할 것인지에 대한 설명
(해설 : PO는 이 기능을 누구에게나 제공합니다) 가치를 제공하는지 설명하고, 개발자는 그 기능의 가치를 제공하기 위해 무슨 기술 역할과 책임을 가짐)

예를 들면,
– 채용 담당자로서, 입학 지원자의 프로필을 볼 수 있습니다. 그래서 나는 채용에 적합한 사람을 선택할 수 있습니다.
(해설 : 개발자는 시스템을 사용하는 채용담당 자가 적입자 기능을 사용할 수 없는 목표를 아쿠아하여 이익을 얻을 수 있도록 개발을 필요로 합니다. 그렇다면 단순히 “입사 지원자 검색”만 개발로 끝낸다면 그 목적을 축소할 수 없게 될 것이다.)

베타 기준(Definition of Done), 인수 기준(Acceptance Criteria) : 사용자 스토리지를 압축해제 조건세(Given, When, Then)

출처 : https://twitter.com/kickstartpros/status/524414603359686657

스프린트(Sprint) : 기획,개발,리뷰 작업 등 최소 단위의 Cycle 이다. 보통 1~4주 기본에서 선택
거부될 가능성이 있는 제품(Potentially Shippable Product Increment) 또는 최소 실행 가능 제품(Minimum Viable Product, MVP) : 팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 차원의 제품

출처 : https://www.google.com/url?sa=i&source=images&cd=&ved=2ahUKEwjs7dDvg6zjAhVKhrwKHTJEDAgQjRx6BAgBEAU&url= 이미지%3A%2F%2Fwww.pinterest.com%2Fpin%2F218283913174637047%2F&psig=AOvVaw1MUuT_d WpFyrMe6PPcILeE&ust=1562905768601307

스프린트 계획(Sprint Planning Meeting) : 스프린트 목표와 스프린트 백로그를 계획하는 연락(4주 스프린트 기준 8시간 정도 수행)
스프린트 백로그(Sprint Backlog) : 각각의 스프린트 목표를 달성하기 위해 필요한 작업 목록

칸반보드(Kanban Board) : 작업을 나타내는 작업상태, 거짓을 보여주는 게시판

이미지 출처 : https://agilevelocity.com/scrum/4-advantages-of-physical-task-boards/

매일 스크럼(Daily Scrum) : 매일 넓은 한일, 오늘 할일, 처리해야 할 장애/문제 요소를 공유하는 통신(매일 15분 정도 수행)
(해설:모든 참여자가 보고가 아니라 수평적으로 공유하여서 전달해야 함 카지노가 아니면 의견이 없는 것입니다. Sprint Planning에 없는 제3자가 잡무를 하고 있다는 것을 파악하기 가능하다. 장애 요소는 화이트보드에 없으면 안될 것으로 처리한다. 만약 처리하는 것보다 뭉치는 게 만지면 회사는 팀을 충분히 지원하지 않는 업무, 유일하게 스크럼하는 생산적이지 않은 낭비로 인식됩니다.)

이미지 출처 : https://www.slideshare.net/TanaLinback/scrum-training-one-day

스프린트 검토(Sprint Review) : 스프린트 마지막날 개발자가 개발한 내용을 Stakeholder, Customer, 제품 제공자에게 시연하고 검토(4주 스프린트 기준 4시간 정도 수행)
스프린트 회고(Sprint Retrospective) : 스프린트 마지막날 성공했던 점, 개선할 점을 움직이고 더 나은 방향으로 개선(4주 스프린트 기준 3시간 정도 수행)
– 회고기법 참고 : https://www.atlassian.com/blog /jira-software/5-fun-sprint-retrospective-ideas-templates

5. 스크럼 진행

PO는 제품의 요구기능(User Story)과 우선순위를 제품 백로그로 정한다.
PO가 정한 제품의 최고 순위에서 어디까지 작업을 담당하는 팀과 조율합니다.
스프린트 목표를 구현 가능하도록 팀에서 스프린트 백로그를 제작한 뒤에 작업을 합니다.
(해설:PO는 기능과 우선순위에 대한 권한이 있고, 개발팀은 Sprint를 선택해야 할 업무량을 결정할 수 있습니다. 특히 개발 경험이 있는 PO가 너무 기본적인 개발량을 문제제기할 수 있지만, 실제 개발하는 개발팀원의 개발 속도(Velocity)로 예측하며 조정이 중요하다.)
스프린트를 진행하는 동안, 매일 중요한 장소와 시간에 모든 개발이 참여하는 일일 스크럼 회의를 합니다.
매회의 스프린트가 종료될 때마다, 스프린트 검토(Review)를 통해 이후 제품을 검토하고 개선 사항을 이해해야 합니다.
제품의 리뷰를 통해 제품의 일시적인 개선 사항은 약간의, 스프린트 회고(Retrospective)를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 문의합니다.
(해설: 스프린트 리뷰는 제품을 개선하는 활동이고, 회고는 우리(프로세스, 문화)를 성장시키는 활동이다.)
다음 스프린트에서 활동할 백로그를 PO와 필요로 하는 사람들이 모여서 계획하는 시간을 지정합니다.