---

경제적인 Scrum Master 인증: 단계별 계획

이 글이 소개되었다는 기쁜 소식을 전합니다…
LinkedIn에서 여기 보기 >>>

다음이 등장하여 Scrum 프레임워크 가 소프트웨어를 개발하고 제공하는 최고의 방식 중 하나가 된 이후로, 모두에게 같은 목표가 있는 것 같습니다.

아침에 일어나 노트북을 열고, 이런 것을 갖췄다는 설레는 안도감을 느끼는 것입니다.

Scrum Master 인증.

바로 그 꿈 아닌가요?

뛰어난 것을 제공하세요 소프트웨어 를 고용주와 고객에게.

Scrum 프로세스에 대한 역량과 노하우, 그리고 다음 자격을 바탕으로 멋진 경력을 쌓으세요. Scrum Master 인증.

대부분은 Scrum Master 인증을 통해 Scrum 프레임워크에 입문합니다.

이 글에서는 처음으로 여러분의 Scrum Master 인증 취득을 돕는 고급 단계별 상세 가이드를 공유하고 싶습니다.

경제적이고 빠르며 번거로움 없이 온라인으로!

간단한 네 단계만 거치면 다음 인증과 함께 뛰어난 Scrum 전문가가 될 수 있습니다. Scrum Master 인증.

이 글의 목표는 Scrum이 경력을 지원하고 전문적인 효과성을 높이는 방법을 보여 드리는 것입니다. 또한 Scrum Master의 역량과 능력을 나중으로 미루지 않고 지금부터 계속 개발해야 하는 이유도 설명합니다.

정의 - Scrum Master 인증이란 무엇인가요?

다음이 무엇인지 가장 잘 설명한 정의를 찾아볼 수 있습니다 Scrum Master 인증 에 대해서는 다음에서 International Scrum Institute™는의 Scrum Master Accredited Certification™.

Scrum Master 인증은 Scrum 소프트웨어 개발 및 제공 프로세스에 대한 여러분의 역량을 증명합니다. Scrum Master 인증은 다음을 인정합니다 정식 객관식 시험 평가를 통해 입증한 Scrum 프레임워크에 관한 지식과 뛰어난 전문성을.

Scrum 소프트웨어 개발 프로세스는 지금까지 수백만 명의 전문가에게 막대한 이점을 제공해 왔습니다. 따라서 Scrum 프레임워크의 도움으로 경력과 역량을 발전시킨 뛰어난 남녀 전문가들과 여러분이 함께하지 못할 이유는 없습니다.

아직 고민 중이라면 분명히 말씀드리겠습니다. 이제 Scrum Master 인증 없이 성장하는 경력을 상상하기 어렵습니다. 이는 다음 분야에서의 역할, 직함 및 경험과 관계없습니다. 정보기술(IT) 생태계에서.

이제 IT 전문가가 아니어도 Scrum이 무엇이고 어떻게 작동하는지 이해하고 Scrum Master 인증을 취득할 수 있습니다.

생업이 무엇이든, IT 부서에 속해 있든 아니든, 필수적이며 부인할 수 없는 사실이 있습니다. 여러분이 조직에 제공하는 업무와 전문적인 비즈니스 가치는 IT, 소프트웨어 및 다음에 의존하고 서로 연결되어 있습니다. 애자일 Scrum 프로세스와 원칙.

또한 전통적인 비즈니스 모델이 다음으로 전환되면서 서비스형 소프트웨어(SaaS) 중심의 사업, 또는 이른바 디지털화 흐름으로, IT 부서 안팎의 전문가에게 Scrum Master 인증 취득은 더 이상 선택 사항이 아닙니다. 오늘날 Scrum Master 인증 취득은 필수입니다.

경력을 막 시작했든 경험 많은 IT 전문가이든 관계없습니다. Scrum Master 인증을 취득해야 합니다.

역할에 인력 관리와 기능 관리 활동이 포함될 수도 있고 아닐 수도 있습니다. 그것도 관계없습니다. 여전히 Scrum Master 인증이 필요합니다.

다음과 같은 직함을 가질 수 있습니다.

• 비즈니스 분석가,
• 소프트웨어 아키텍트,
• 엔터프라이즈 아키텍트,
• 소프트웨어 디자이너
• 사용자 경험(UX) 디자이너,
• 사용자 인터페이스(UI) 디자이너,
• 소프트웨어 개발자,
• 소프트웨어 개발 관리자,
• 테스트 엔지니어,
• 테스트 자동화 전문가,
• 테스트 관리자,
• IT 시스템 운영 전문가,
• Unix/Linux 관리자,
• 정보보안(InfoSec) 엔지니어,
• IT 네트워크 엔지니어,
• 데이터베이스 관리자(DBA),
• 프로젝트 관리자,
• 프로그램 관리자,
• 제품 관리자,
• 팀 리더, 관리자, 이사 또는 경영진,
• 또는 여기에 나열하지 않은 다른 어떤 직함이든.

Scrum 소프트웨어 개발 프레임워크를 배우고 오늘 Scrum Master가 되세요. 취득할 자격은 Scrum Master 인증.

애자일 Scrum 프로세스와 Scrum Master 인증 이전의 혼란과 좌절을 일으킨 3가지 요소

Scrum 프레임워크가 소프트웨어 엔지니어링 실천과 비즈니스에 미치는 영향을 더 잘 이해하려면, 일상 속 하루 또는 과거의 소프트웨어 프로젝트를 살펴보는 것이 좋습니다.

따라서 조직에 Scrum 개발 및 소프트웨어 제공 프레임워크를 도입하기 전의 소프트웨어 프로젝트를 간단히 이야기하고 싶습니다.

이 글을 쓰기 며칠 전, 거의 20년 전에 함께 일했던 전 동료와 점심을 먹었습니다. Marcus라는 이분은 다음 기관에서 Scrum Master 및 Scrum Product Owner 인증을 취득했습니다. International Scrum Institute™는.

현재 애자일 프로젝트 관리 소프트웨어 분야의 선도 소프트웨어 회사 중 한 곳에서 Scrum Master로 일합니다.

Marcus는 이제 Scrum Master로서 전 세계 여러 장소에 팀원이 분산된 애자일 Scrum 팀을 지원합니다.

점심 식사 중 Marcus는 분산 애자일 Scrum 팀에 일반적인 과제가 많다고 인정했습니다. 자신의 소프트웨어 프로젝트 구성과 관련해 특별히 언급한 문제 중에는 다음이 있습니다.

• Scrum 팀원 간 업무 방식의 차이,
• 시차,
• 문화적 부조화,
• 언어 제약.

이러한 어려움에도 Marcus는 애자일 Scrum 프로세스로 소프트웨어 프로젝트를 운영하는 편이 20년 전 일하던 방식보다 더 즐겁고 생산적이며 풍요롭다고 덧붙였습니다. Scrum 소프트웨어 개발 및 제공 프로세스 없이 일하던 시절과 비교해서 말입니다.

Marcus의 말은 뛰어난 성취와 경험을 가진 관리자이자 Scrum Master, Product Owner가 Scrum 프레임워크의 가치를 입증하는 큰 증언이었습니다.

Marcus, 감사합니다!

이후 Scrum 프레임워크를 알기 전의 소프트웨어 프로젝트 하나를 이야기했습니다. 많은 Scrum Master가 인증 취득 이전의 프로젝트에서 비슷한 경험을 했으리라 생각합니다.

1990년대 후반, 저는 다음과 같은 스마트카드 기반 시스템을 구축하는 소프트웨어 엔지니어링 그룹에 속해 있었습니다 공개 키 기반 구조. 스마트카드는 기반 구조 구성원의 개인 키를 안전하게 보호했고, 관련 공개 키와 이를 감싸는 인증서는 공개라는 이름처럼 공개적으로 배포했습니다.

당시에는 이것만으로도 상호 의존적인 여러 하드웨어 및 소프트웨어 엔지니어링 팀이 필요한 비교적 복잡한 IT 프로젝트였습니다. 저희는 막대한 양의 연구개발(R&D)을 수행해야 했습니다 . 완전하게 작동하는 하드웨어 및 소프트웨어 시스템을 만들기 위해서였습니다.

다음이 등장하기 전의 시절임을 기억하세요 최소 기능 제품(MVP) 즉 실험하고 만들고 배우고 다시 실험하는 개념입니다.

애자일 방법론에서 MVP를 만드는 방법에 관심이 있다면 다음을 살펴보세요 기사 Cleevio의 글로, 이 복잡한 프로세스를 더 폭넓게 이해하도록 도와줍니다.

Scrum 없이 수많은 하드웨어와 소프트웨어 요소로 구성된 정교한 인프라를 만드는 것은 정말 어려웠습니다.

Scrum Master나 인증 보유자가 팀에 전혀 없을 때 겪었던 세 가지 주요 문제를 소개합니다.

Scrum Master 인증 없이 겪은 혼란과 좌절의 1번째 요소: 프로젝트가 무엇인지 이해하기 전에 전체 프로젝트를 계획해야 했습니다

Scrum이 없던 시절, 팀은 고객의 요구를 충족하지 못하는 완전히 잘못된 소프트웨어 및 하드웨어 제품을 만들고 제공했습니다.

전문가로 일하며 외부 기업이 소프트웨어 제품이나 서비스를 어떻게 만들어야 하는지 강요하던 때도 있었습니다.

역량 성숙도 모델(CMM), ISO 9001:2008 및 기타 파생 방식은 올바른 소프트웨어를 올바른 방법으로 구축하도록 기업을 돕고자 했습니다.

얼마나 성공적이었는지는 이 글의 주제가 아닙니다. 이 글은 품질 관리 및 프로세스 개선 표준을 Scrum의 사라진 대안으로 취급하기보다 Scrum 프로세스와 Scrum Master 인증의 장점에 집중하려는 글입니다.

다만 Scrum 소프트웨어 엔지니어링 프레임워크 이전에는 이러한 프로세스 개선 프레임워크를 프로젝트에 단계적으로 구현했다는 점을 덧붙여야겠습니다. 단계별 소프트웨어 엔지니어링 접근법을 사용했으며 다음과 같이 불렀습니다 폭포수 소프트웨어 엔지니어링 모델.

폭포수 모델에서는 각 소프트웨어 프로젝트가 고객의 필요와 바람을 이해하려는 요구사항 분석으로 시작하도록 했습니다.

그다음 요구사항을 설계하고 구현하고 테스트(검증)한 뒤 운영 환경에서 유지보수했습니다. 마침내 소프트웨어 엔지니어링 생명주기의 끝에 도달했습니다.

하지만 현실은 그렇게 진행되지 않았습니다!

폭포수 모델의 특정 단계에서 예상치 못한 지연이 발생하면 이후 단계에도 부정적인 영향이 불가피했습니다.

Scrum 프레임워크 이전의 모습이었습니다.

Scrum Master 인증 전문가의 안내 없이 여러 팀 사이로 소프트웨어를 주고받다 보니 업무가 관료적이고 복잡하며 비생산적으로 되었습니다.

결국 제품뿐 아니라 직원의 사기와 조직 사명에 대한 헌신도 완전히 무너졌습니다.

Scrum Master 인증 없이 겪은 혼란과 좌절의 2번째 요소: 서로 다른 팀 사이의 확약, 변경 관리 및 협업 규율 부족

Scrum 이전에 사용한 프로세스 개선 프레임워크의 가장 큰 약점은 다음과 같았습니다. 주로 리더십 자체의 이익을 위한 조직적 요구에 집중했습니다.

그러한 요구에는 감시, 준수, 예측 가능성이 있습니다. 고객을 잘 지원하고 직원 사기를 높이는 데는 전혀 관심이 없었습니다.

따라서 소프트웨어 관리 팀과 다양한 내부 및 외부 이해관계자는 소프트웨어 제공 프로젝트의 마감일을 고정하고 소프트웨어 엔지니어링 단계의 진척을 쉽게 감시하려 했습니다.

계획에서 벗어나는 일이 생기면 사람들에게 불이익을 주었고 예정된 프로젝트 완료일 전에 발생한 문제를 해결하기를 바랐습니다.

게다가 독립적인 사일로가 완전히 분리된 소프트웨어 엔지니어링 단계를 수행했습니다. 예를 들어 개발 팀은 테스트(검증) 팀과 완전히 독립되어 있었습니다. 같은 사업 사명을 위해 일해야 할 대부분의 사람이 서로의 이름조차 몰랐습니다.

조직이 사업 사명과 직원의 직업적·사업적 성숙도에 집중하는 대신 이런 사일로 사고방식을 갖게 된 이유가 무엇인지 짐작하시겠나요?

이유는 간단히 말해 매트릭스 관리입니다. 매트릭스 관리는 조직의 관리 및 인력 구조로 1970년대부터 기업에 존재해 왔습니다. 얼핏 보면 매트릭스 조직이나 관리의 차별화된 발상은 영리해 보입니다.

리더십은 비슷한 기능 및 기술 역량을 가진 직원을 같은 사일로, 기껏해야 이웃한 사일로에 모아 조직 구조를 만듭니다.

당시 기업에서 이른바 "역량 센터"를 흔히 볼 수 있었으며, 각 센터는 독립적이고 자율적인 사일로였습니다.

C++ 개발자 사일로 하나, 데이터베이스 관리자 사일로 하나, 해외의 완전히 분리된 품질 보증 사일로 하나 등 끝없이 이어졌습니다. 참 이상한 일이죠!

매트릭스 조직 구조의 가장 큰 과제는 Scrum 프레임워크와 Scrum Master 없이 소프트웨어 프로젝트를 제공하려면 프로젝트 관리자가 사일로에서 직원을 임시로 빌려 와야 한다는 점이었습니다.

이 직원들은 프로젝트 팀과 물리적으로 함께 있지도 않고 각자의 역량 센터 사무실에 계속 있었습니다.

프로젝트가 끝나면 임시 팀은 해산되었고 참여자는 다른 프로젝트를 위한 다음 임무로 이동했습니다.

따라서 진행 중인 소프트웨어 프로젝트가 목표로 하는 사업 가치는 이 독립된 사일로들의 최우선 과제가 된 적이 없었습니다.

이들은 자신의 일을 여기 프로젝트와 저기 프로젝트에서 체크하는 항목으로 보는 경향이 있었습니다.

리더십과 매트릭스 조직 모델은 전문가들이 매출, 수익, 이익을 포함한 최종 실적 개선을 위해 사업에 어떻게 헌신해야 하는지 가르치지 않았습니다.

McKinsey & Company가 쓴 McKinsey Quarterly 기사도 이러한 매트릭스 조직 이면의 비용 최적화 착각을 명확히 보여 주었습니다.

원문 기사는 Gartner의 전 세계 연간 추정치를 인용합니다 IT 시스템을 복구하는 데 6,000억 USD를 지출한다고 추정했습니다 . 예정되지 않은 유지보수 작업과 결함 때문입니다.

이제 소프트웨어 프로젝트에서 변경 관리와 장애물 처리가 어떻게 이루어졌는지 잠시 그려 보겠습니다. 폭포수 모델과 매트릭스 조직을 사용하고 Scrum 프로세스가 없는 프로젝트 구성에서의 모습입니다.

네, 맞습니다. 경영진과 직원들은 다음을 취급했습니다 변경 관리, 장애물 및 오류 처리를 애초에 일어나서는 안 되는 잘못된 예외인 것처럼.

따라서 소프트웨어 프로젝트의 변화는 지연과 동의어였습니다. 대개 연쇄 지연의 도미노 효과를 일으켰습니다. 팀은 결함과 장애물을 두고 비난하고 손가락질할 누군가가 필요했습니다.

마지막으로 사일로에는 오류를 처리하고 수정하며 배우는 체계가 없었으므로 같은 실수를 계속 반복했습니다.

게다가 다음의 양을 계속 늘려 갔습니다 기술 부채 . 문제에 수동적으로 대처하려 했기 때문입니다.

Scrum Master 인증 없이 겪은 혼란과 좌절의 3번째 요소: 독단적인 결정이 민주적인 결정을 무시했습니다

Steve Jobs는 이렇게 말했습니다.

“똑똑한 사람을 고용하고 무엇을 하라고 지시하는 것은 말이 되지 않습니다. 우리는 똑똑한 사람들이 우리에게 무엇을 해야 할지 알려 주도록 고용합니다.”

하지만 이는 Scrum 이전에 주류 리더십 대부분이 결정을 내리던 방식과 정확히 반대입니다.

조직에 Scrum 프로세스가 없던 시절에는 리더의 독단적인 결정이 팀의 집단 지성을 무시했습니다.

실제 업무를 담당하는 집단의 민주적인 의사결정 능력을 무효화했습니다 . 그 업무는 소프트웨어 구상부터 운영까지 전체 소프트웨어 엔지니어링 생애주기에 걸쳐 있었습니다.

결정이 영향을 받는 작업 현장인 팀에서 멀어질수록, 업무상 중대한 올바른 결정을 내리기가 어려웠습니다.

리더의 판단은 보통 충동적이고 충분히 생각하지 않은 것이었으며 대체로 늦고 잠정적이었지만 때로는 너무 이르기도 했습니다.

이러한 독단적 결정은 위에서 강요되어 직원들이 존중받지 못한다고 느끼게 했습니다. 경쟁적인 사업 및 소프트웨어 문제를 해결할 창의적이고 혁신적인 해결책을 내놓는 조직의 능력을 완전히 가로막았습니다.

또한 의사결정에 참여해 달라고 할 때조차 소프트웨어 엔지니어링 팀이 의견을 내지 못하도록 위축시켰습니다.

조직에 Scrum 프레임워크를 도입하기 전 소프트웨어 서비스와 서비스 제품을 개발하고 제공하던 방식을 간단히 살펴봤습니다. 이제 Scrum 프로세스의 도움으로 이러한 혼란과 좌절을 어떻게 해결했는지 살펴보겠습니다.

Scrum이란 무엇인가요?

우선 이 부분을 Scrum 프레임워크에 관한 모든 질문에 답하는 참고서로 쓰려는 의도는 아니었음을 강조하고 싶습니다. 그래도 여기서 다루는 내용은 대부분의 초급 및 중급 Scrum 전문가에게 깊이 있는 출발점이 될 것입니다.

좀 더 고급이면서도 실용적인 가이드로 Scrum 프레임워크를 빠르게 배우고 싶은 분을 위한 자료도 있습니다. 다음을 권합니다 여기 링크에서 Scrum 프레임워크 가이드를 다운로드하세요.

Scrum이란 무엇일까요? 너무 복잡하게 만들지 않고 다음과 같이 정의할 수 있습니다.

Scrum은 복잡한 문제에 대한 적응형 해결책으로 가치를 창출하는 경량 프레임워크입니다. 반복적이고 점진적인 소프트웨어 개발은 중요한 적용 분야 중 하나입니다.

소프트웨어가 Scrum 프레임워크의 주된 초점이지만 반복적이고 애자일한 Scrum 프로세스는 소프트웨어 산업 밖에도 적용할 수 있으며 이미 적용되고 있습니다.

IT 업계의 많은 사람은 "Scrum"이라는 용어가 새로운 애자일 소프트웨어 개발 및 제공 동향과 함께 2000년대 초에 만들어졌다고 믿습니다. 이는 잘못된 정보입니다!

1986년 1월 Harvard Business Review 기사는 이후의 Scrum 프레임워크에 앞선 제품 개발 접근법을 설명했습니다. Hirotaka Takeuchi와 Ikujiro Nonaka가 쓴 기사 제목은 The New New Product Development Game입니다. (맞습니다. New가 두 번 나옵니다)

다음을 살펴보세요 "The New New Product Development Game" Scrum의 모든 것이 어떻게 시작되었는지 알 수 있습니다!

IT 업계에서 Scrum 프레임워크를 이야기할 때 "Scrum"과 함께 "애자일 Scrum"이라는 용어도 자주 듣습니다. 그 때문에 일부는 두 용어의 차이를 생각하고 찾게 되었습니다.

반가운 소식이 있습니다. "애자일 Scrum"과 "Scrum"은 같은 것을 가리킵니다. 둘 다 Scrum 소프트웨어 엔지니어링 프로세스를 뜻합니다. 그렇다면 왜 때로 "Scrum" 앞에 "애자일"을 붙일까요?

Scrum 프레임워크가 다음을 완전히 수용하고 통합했기 때문입니다 애자일 선언(애자일 소프트웨어 개발 선언) 를 핵심 프로세스, 원칙 및 기반 철학에 통합했기 때문입니다. 그러므로 Scrum 프로세스의 기술적인 세부 사항을 깊이 살펴보기 전에 애자일 선언과 Scrum의 가치를 더 잘 이해해야 합니다.

애자일 선언(애자일 소프트웨어 개발 선언)

애자일 선언의 가치:

• 프로세스와 도구보다 개인과 상호작용,
• 포괄적인 문서보다 작동하는 소프트웨어,
• 계약 협상보다 고객과의 협력,
• 계획을 따르기보다 변화에 대응하기.

오른쪽 요소에도 여전히 상당한 가치가 있지만, 애자일 선언은 왼쪽 요소를 더 높이 평가하고 우선시합니다.

선호하는 요소는 시간의 검증을 거쳐 다음을 위해 신중히 선택되었습니다.

• 고객과 이해관계자를 더 잘 돕고 소프트웨어로 가치를 만들기,
• 역할, 직함 및 경력 수준과 관계없이 소프트웨어 엔지니어링 전문성을 높이기.

Scrum 프레임워크의 가치

Scrum 프레임워크는 단순한 소프트웨어 엔지니어링 프로세스가 아니라고 이미 말씀드렸습니다. 탄탄한 기반 원칙도 갖추고 있습니다.

사실 대부분의 전문 사업 분야에서 이 원칙을 적용하고 활용할 수 있습니다.

Scrum으로 큰 성공을 거두려면 Scrum Master 인증 취득만으로는 충분하지 않습니다. 성공하려면 Scrum의 가치를 확실히 이해해야 합니다.

. 그래야 고객과 고용주가 좋아할 훌륭한 업무와 소프트웨어를 제공할 수 있습니다. 이제 Scrum 프로세스의 원칙을 더 설명하겠습니다.

용기

고객에게 최고의 가치와 이익을 제공하기 위한 올바른 행동이 가장 쉬운 선택은 아닐 때가 있습니다. 그런 순간 Scrum Master, Scrum Product Owner 및 팀원은 자신의 임무와 의무를 기억해야 합니다.

자신의 사업 및 IT 분야에서 최상의 제품과 서비스를 만드는 것입니다. 평범함을 넘어서려면 Scrum 팀은 조만간 이해관계자 생태계의 모든 사람을 만족시킬 수 없는 어려운 결정을 마주해야 합니다.

이를 해결하기 위해 모든 팀원은 Scrum Master 인증 교육에서 배운 것을 기억해야 합니다.

용기를 기억하고 용감하게 결정하고 행동하는 방법을 익혀야 합니다.

집중

Scrum 프레임워크에서 집중이라는 가치를 들으면 두 가지를 생각해야 합니다.

• 올바른 작업 파악: Sprint 목표를 달성하려면 어떤 작업이 필요한가? 고객이 제 일에 만족하도록 최고의 소프트웨어 제품과 서비스를 개발하는 데 무엇이 필수적인가?
• 우선순위 설정: 다음에는 어떤 작업을 해야 하는가?

매 순간 Scrum Master와 Product Owner를 포함한 팀 전체가 답해야 하는 중요한 질문이 하나 있습니다. 질문은 이렇습니다. "고용주가 처음 우리를 채용한 이유를 충족하려면 지금 무엇을 하는 것이 가장 중요한가?"

Scrum 프레임워크에는 사용자 스토리와 작업의 합리적인 우선순위 지정을 보장하는 여러 이벤트(의식)가 내재되어 있습니다. Scrum 프로세스에 따르면 사용자 스토리와 관련 작업의 우선순위 지정은 지속적으로 우선시되어야 합니다.

이를 통해 팀이 올바른 일을 올바른 순서로 수행하도록 보장합니다. 공식 Scrum 이벤트와 관련 정제 실천은 집중 대상을 점검하고 작업을 조정하도록 돕습니다.

• Scrum 그루밍 회의: 정제는 예정된 제품 백로그 항목을 명확히 하고 나누며 크기를 산정할 뿐 아니라 순서 결정에도 정보를 제공합니다. 회의는 이러한 지속적인 활동을 수행하는 한 가지 방법입니다.
• Sprint Planning 회의: 스토리 제공을 위한 의존성과 올바른 작업 순서를 보게 합니다.
• Daily Scrum 회의: Daily Scrum(일일 스탠드업) 회의는 앞으로의 업무일에 방향을 잡도록 돕습니다. 가장 필요한 곳에 집중해야 합니다.
• Sprint Review 회의: Sprint 리뷰 회의는 향후 더 성공적인 리뷰를 위해 팀이 어디에 집중해야 하는지 간접적으로 보여 줍니다.
• Sprint Retrospective 회의: 이 회의들은 엔지니어링 프로세스의 어떤 측면을 먼저 개선해야 하는지 팀이 우선순위를 정하도록 돕습니다.

이 부분에서는 집중의 관점에서만 Scrum 의식을 다뤘습니다. 더 자세한 설명은 다음에서 찾을 수 있습니다. 이 글 뒷부분의 Scrum 행사 설명.

여기까지 읽었다면 Scrum 프레임워크에서 우선순위 지정과 집중이 얼마나 필수적인지 분명해졌을 것입니다.

이행 의지

Scrum Master, Scrum Product Owner 및 팀의 확약 없이는 소프트웨어로 뛰어난 결과를 제공할 수 없습니다.

Scrum 소프트웨어 개발 분야에서 많은 사람은 확약이라는 가치를 특정 Sprint 산출물의 목표를 합의하고 고정하는 것으로 해석합니다.

충분히 타당하지만 완벽한 이해는 아닙니다. Scrum 가치의 맥락에서 "확약"이라는 말을 들을 때, 저자는 헌신을 강조하려고 “몰두”라는 표현을 사용합니다. Scrum의 정의에서 확약은 팀의 목표와 상호 지원에 관한 것이며, 과로나 예측한 모든 항목에 대한 확실성을 요구하지 않습니다.

소프트웨어 엔지니어링과 삶, 비즈니스에서 성공하려면 목표에 몰두해야 합니다. 따라서 Scrum 프로세스의 맥락에서, 고객 문제를 해결할 훌륭한 소프트웨어를 만드는 데 몰입해야 합니다.

확약과 그에 수반되는 Scrum 목표에 대한 몰두는 왜 중요할까요? 뛰어난 소프트웨어를 만들고 제공한다는 팀의 사명에 몰두하지 않으면, 만만치 않은 장애물을 만날 때마다 업무가 느려지고 멈추기 때문입니다.

그러면 Scrum Master와 팀은 Sprint 목표를 달성하지 못하는 이유를 Product Owner에게 정당화하고 합리화하는 설명을 만들기 시작합니다. 평균 이상의 Scrum 팀이 되는 것이 목표라면 더 이상 팀에 변명의 자리가 있어서는 안 됩니다.

대단히 높은 수준의 헌신이 있어야 고객의 문제를 해결하고 소프트웨어로 고객을 돕고 가치를 만드는 일이 비교적 수월하고 보람 있어집니다.

존중

나이, 성별, 인종, 신념, 경험, 역량, 의견 및 업무 성과와 관계없이 모든 Scrum 팀원은 서로 존중하고 의지해야 합니다.

존중은 팀의 경계 안에만 한정되지 않습니다. 팀과 상호작용하는 모든 내외부 IT 및 비즈니스 이해관계자도 전적으로 존중하고 환영합니다.

경험 많은 팀원은 경험이 적은 팀원의 기여 의욕을 꺾지 않도록 주의해야 합니다.

특히 집단의 다수가 동의하지 않는 반대 의견도 적절히 받아들이고 답하는 것이 중요합니다.

개방성

Scrum의 가치 "개방성"은 흔히 평균적인 팀과 고성과 팀을 구분하는 주요 요소입니다. 팀의 개방성은 열린 마음을 가진 개인들이 모여 발휘하는 방대한 능력에 비유해 볼 수 있습니다.

이들은 창의적이고 혁신적이며 지적이고 정직하며 솔직하고 겸손합니다. Scrum 소프트웨어 엔지니어링 및 제공 프로세스에서 사람들은 과제와 다양한 견해를 공개적으로 논의할 수 있어야 합니다. 개방성이 모든 결정과 행동을 적절하게 만드는 것은 아닙니다. 존중, 품질 및 팀 목표는 여전히 중요합니다.

유일한 조건은 투명해야 하며 팀의 공동 사명에 기여하려는 목적을 가져야 한다는 것입니다.

모든 결정과 행동이 반드시 팀의 산출 속도를 높이고 중대한 성공 사례로 이어져야 한다는 뜻은 아닙니다.

개방성과 용기라는 가치 덕분에 Scrum 소프트웨어 개발 집단은 실수를 두려워하지 않습니다. 오류와 최적에 못 미친 결과를 전체 생산성과 작업 품질을 의미 있게 개선하는 중요한 기회로 봅니다.

Scrum 프레임워크의 주요 구성요소

Scrum 팀은 Product Owner 한 명, Scrum Master 한 명 및 개발자로 구성되며, 서로 구분되는 세 가지 책무가 있습니다. 이 글 앞부분의 “Scrum Team Member”는 개발 집단을 뜻하며, 네 번째 책무나 별도의 전체 Scrum 팀을 뜻하지 않습니다.

전 세계 학습자에게 제공하는 다른 프로그램과 더불어 International Scrum Institute™는 이 세 역할을 위한 세 가지 주요 교육 및 인증 프로그램을 제공합니다.

이 프로그램들은 다음과 같습니다 Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™), 그리고 Scrum Team Member Accredited Certification™ (STMAC™).

제대로 된 Scrum 조직은 이 세 가지 역량을 가진 사람을 충분히 갖춰야 합니다. 이는 Scrum 소프트웨어 개발 프레임워크의 성공에 특히 필수적입니다.

각 Scrum 책무는 충족되어야 합니다. 책임은 서로 구분됩니다. Product Owner나 Scrum Master도 Sprint Backlog 작업을 할 때 개발자로 기여할 수 있으며, 그 밖의 책무에 대한 책임도 유지합니다.

하나의 제품을 만드는 여러 Scrum 팀은 Product Owner, 제품 목표 및 제품 백로그를 공유합니다. 각 팀에는 Scrum Master 책무가 있으며 효과적인 지원이 필요합니다. Scrum은 한 사람이 한 팀만 지원할 수 있다고 정하지 않습니다.

이 역할들의 목적과 기능을 이해하고 적절한 인재를 배치하는 것의 중요성을 과소평가하지 마세요. 팀이 겪는 어려움의 근본 원인은 역할을 이해하지 못하거나 적합한 사람을 배치하지 않은 데 있는 경우가 많았습니다.

이제 세 가지 역할을 이야기하겠습니다.

Scrum의 세 가지 역할 - Scrum Product Owner 역할

Scrum Product Owner는 제품 가치를 극대화하도록 제품 백로그의 순서를 정하고 제품과 릴리스 결정을 위해 이해관계자와 협력합니다. 개발자는 Sprint에서 완료할 수 있으리라 예측하는 작업을 선택합니다. 릴리스 방식은 제품의 맥락에 따라 달라집니다. Product Owner는 최종 사용자의 기능 및 비기능 요구를 대변합니다.

Product Owner의 역할은 전통적인 프로젝트 관리, 프로그램 관리자, 제품 관리 역할보다 훨씬 넓습니다.

이 역할은 제품 관리와 프로젝트 관리 업무를 통합하며 소프트웨어 개발 및 제공과도 긴밀히 연결됩니다.

Scrum Product Owner의 필수 업무는 다음과 같습니다.

• 프로젝트 요구사항 관리 및 명확화,
• 출시 안내 및 투자 수익(ROI) 확보,
• Scrum 팀과 긴밀히 협력하기,
• 이해관계자 관리하기.

Scrum의 세 가지 역할 - Scrum Team Member 역할

Scrum 팀은 소프트웨어를 구현합니다. 개발자는 다음 기간에 완료할 수 있다고 예측하는 작업량을 선택합니다 Sprint. Sprint는 길이가 고정된 이벤트이며, 그동안 만든 사용 가능한 제품 결과물은 완료의 정의를 충족하는 증가분입니다.

고성과 Scrum 팀에는 일반적으로 대부분의 소프트웨어 엔지니어링 역량이 있습니다. 개발자, 아키텍트, 테스터, 데이터베이스 관리자 및 다른 모든 역할의 팀원이 함께 일합니다.

이들은 고객이 비용을 지불하는 훌륭한 소프트웨어를 함께 만들고 제공합니다.

Scrum 팀원은 더 이상 매트릭스 조직의 기능별 사일로에 속하지 않습니다. 개발자는 개발 역량 센터에, 테스터는 테스트 역량 센터에 속하는 식의 구분이 사라집니다.

조직에서 과거 어디에 있었든 팀원은 해당 Scrum 프로젝트에 속합니다. 이제 역할은 Product Owner의 요구사항을 제공할 최선의 소프트웨어를 만드는 것입니다.

Scrum 팀의 특성은 다음과 같습니다.

• 권한을 부여받음,
• 자율적임,
• 여러 기능을 아우름,
• 자기 조직적임,
• 소규모임,
• 참여자가 충분한 시간을 낼 수 있음(전일제 참여는 흔한 조직적 선택),
• 같은 장소에 있든 분산되어 있든 긴밀하게 협업할 수 있음,
• 하나는 모두를 위해, 모두는 하나를 위해.

Scrum의 세 가지 역할 - Scrum Master 역할

Scrum Master는 모든 프로젝트 참여자와 외부 이해관계자가 Scrum 프레임워크를 올바르게 이해하고 적용하도록 돕습니다. 팀이 Scrum 프로세스를 성공적으로 실행하고 생산성과 성과를 지속적으로 개선하도록 지원합니다.

Scrum Master의 역할은 새로운 사고방식과 행동 방식인 Scrum 프로세스를 정착시키는 것입니다.

또한 Scrum Master는 변화 촉진자로 활동합니다. 팀이 새로운 규범과 표준을 개발하도록 코칭합니다. 팀이 쉽게 연락할 수 있도록 합니다. 물리적으로 가까우면 도움이 될 수 있지만 Scrum의 요구사항은 아닙니다.

Scrum Master의 필수 책임은 다음과 같습니다.

• 비즈니스 및 IT 생태계에 Scrum 정착시키기,
• 팀이 Scrum 가치를 이해하고 실천하도록 코칭하기,
• Product Owner와 팀 사이의 긴밀한 협업 보장하기,
• 장애물 제거하기,
• 봉사하며 이끌기,
• Daily Scrum에 대한 개발자의 주도권을 지키면서 효과적인 Scrum 이벤트를 지원하고 필요할 때 진행을 돕기.

제품 백로그(Scrum 백로그)

Product Backlog(Scrum Backlog) 또는 Scrum Product Backlog는 는 Scrum 프로젝트의 알려진 모든 요구사항을 관리하는 핵심 요소입니다.

성공적인 프로젝트를 수행하고 완료하는 데 필요한 모든 고객 요구사항과 작업 항목으로 구성됩니다. 요구사항에는 기능 및 비기능 요구사항, 그리고 다음과 관련된 다른 기능이 포함됩니다 사용자 경험 및 사용자 인터페이스 설계.

제품 백로그에는 기능 요청과 상위 수준의 다음 내용이 포함됩니다 사용자 스토리. 테스트 및 개발 환경 구축과 같은 선행 또는 보완 프로젝트 요구사항도 포함될 수 있습니다. 알려진 버그 해결, 기술 부채 감소 또는 특정 기능 개선에 필요한 다른 사용자 스토리도 제품 백로그에 포함됩니다.

각 제품에는 제품 백로그가 있습니다. Product Owner는 이를 만들고 유지하며 세밀하게 조정할 책임이 있습니다. 제품 백로그는 요구사항을 어떻게 개발하고 제공할지 답하지 않으며, 답해서도 안 됩니다.

이는 Scrum 팀의 의무입니다. 팀은 요구사항을 충족하는 데 필요한 작업을 결정하여 Sprint Backlog에 문서화합니다. 제품 백로그의 항목이 Sprint Backlog의 내용을 이끌지만, 둘은 구분되는 산출물이며 반드시 물리적으로 별도의 문서나 도구여야 하는 것은 아닙니다.

제품 백로그는 살아 있는 문서입니다. 소프트웨어가 점진적으로 개선되듯 팀이 배우면서 제품 백로그도 추가, 삭제 및 순서 변경을 통해 바뀝니다. Scrum 프레임워크는 별도의 변경 관리 프로세스 자체를 요구하지 않습니다. Product Owner는 제품에 대한 초기의 최선의 이해를 바탕으로 제품 백로그의 첫 버전을 만듭니다.

Sprint를 거치며 제품이 드러나는 모습을 면밀히 관찰하고 고객 요구사항에 대한 지식이 늘어남에 따라, 제품 백로그의 요구사항을 추가하고 제거하고 조정합니다.

Product Owner는 제품 백로그의 요구사항에 우선순위를 정합니다. 항목의 우선순위가 높을수록 더 상세해야 합니다. 그래야 팀이 중요 요구사항을 쉽게 이해하고 구현에 필요한 작업을 만들 수 있습니다.

또한 다음과 같은 추정 방식을 사용하여 스토리 포인트로 팀은 제품 백로그의 요구사항을 정기적으로 추정합니다. 높은 우선순위의 사용자 스토리는 추정치를 조정하고 개선하여 Sprint 계획 준비를 갖춰야 합니다.

Sprint

Scrum 프레임워크에서 요구사항 구현을 위한 모든 활동은 Sprint 중에 이루어집니다. Sprint는 출시 가능한 소프트웨어 제품 또는 서비스 Increment를 개발하는 작업 활동의 주기입니다. Sprint는 반복 주기라고도 합니다.

Sprint를 작은 프로젝트라고 생각하세요. "Sprint"라는 용어처럼 오래 걸리지 않으며 한 달 이내입니다. 사 주 Sprint는 흔한 예이지 프레임워크의 정확한 최대 달력 기간은 아닙니다.

달리기 경주와 달리 Sprint가 끝날 때 팀이 숨이 차고 지쳐서는 안 됩니다. 오히려 상쾌한 상태에서 활기차게 다음 Sprint를 시작해야 합니다.

Scrum 소프트웨어 개발 및 제공 프레임워크는 팀원에게 압력이나 스트레스를 주려는 것이 아닙니다. 집중하고 마음이 편하며 방해받지 않을 때 최고의 성과를 낸다는 것은 잘 알려진 사실입니다. 올바르게 적용한 Sprint는 바로 이를 이루도록 돕습니다.

모든 Sprint는 다음으로 시작합니다 Sprint Planning 회의. Sprint 계획 회의에서 팀은 해당 Sprint에서 어떤 요구사항을 얼마나 구현할지 결정합니다. 이후 요구사항을 제공하기 위한 활동을 시작합니다.

Daily Scrum(Daily Scrum 회의) 은 Sprint의 매 업무일에 같은 시간과 장소에서 열립니다. 개발자는 Sprint 목표를 향한 진행 상황을 점검하고 다음 날의 계획을 조정하는 데 활용합니다. 팀원은 Sprint의 진행을 늦추거나 막을 수 있는 장애물을 제거하도록 Scrum Master에게 도움을 요청할 수도 있습니다.

팀은 Sprint 리뷰와 Sprint 회고 회의로 Sprint를 마무리합니다. Sprint 리뷰 회의 를 통해 팀과 주요 이해관계자는 Sprint 결과와 제품 목표를 향한 진행 상황을 점검하고 향후 조정을 논의합니다. 이는 업무 세션이며 Product Owner의 최종 승인 관문이 아닙니다.

다음 회의에서 Sprint 회고 회의, 팀은 협업 방식, Scrum 프레임워크의 활용 방식 및 개선 방법을 되돌아봅니다.

이에 따라 다음 Sprint 계획 회의에서 이러한 개선 가능성과 피드백을 함께 고려합니다. Sprint는 작은 작업 묶음으로 짧은 기간 안에 이러한 피드백 순환을 가능하게 합니다. 이는 Scrum 프레임워크가 팀과 조직의 지속적인 개선을 돕는 중요한 이유이자 방법 중 하나입니다.

Scrum의 점검과 적응

Scrum의 점검과 적응은 이해하기는 간단하지만 올바르게 구현하고 숙달하기는 가장 어려운 개념입니다.

기업은 마침내 어떤 프로젝트 관리자도 복잡한 시스템의 전체 모습을 완전히 예측할 수 없다는 사실을 확인했습니다. 신뢰할 수 있는 전체 과정의 계획을 세우지 못했습니다. 다른 것을 시도해야 한다는 점이 분명했습니다.

다음과 함께 린 제조 (다른 이름은 린 운동), 기업은 전략적으로 역량을 강화할 프로세스를 개발해야 했습니다. 프로젝트뿐 아니라 운영 중에도 배우고 행동 방향을 바로잡도록 돕는 표준 운영 절차가 필요했습니다.

그렇게 탄생한 것이 Toyota 개선 카타로, Scrum의 점검 및 적응과 비교하는 데 유용합니다. 두 개선 접근법은 목적이 관련되지만, Toyota 개선 카타가 단순히 Scrum의 경험적 기둥을 다르게 부르는 이름은 아닙니다. "Scrum의 점검과 적응"에 따르면:

• 1단계. 점검: 현재의 노하우와 이해 수준을 바탕으로 프로젝트의 현재 상태를 파악하기 위해 최선을 다합니다.
• 2단계. 적응: 프로젝트의 다음 단계에 대한 방향과 비전을 정한 뒤 이를 실현할 전략을 세우고 실행합니다.
• 3단계. 학습: 세심하게 관찰하고 배우며 그 과정에서 서로 가르칩니다. 업무 중 무엇이 효과가 있고 없는지 지속적으로 기록합니다.
• 4단계. 다시 시작: 다시 1단계부터 시작합니다.

아래 네 단계는 교육을 위한 비유이며 Scrum 이벤트와 일대일로 대응하는 정의가 아닙니다. 점검, 적응 및 학습은 Sprint 내내 이루어집니다.

• 1단계. 점검 은 Sprint 리뷰 및 Sprint 회고 회의에 비유할 수 있습니다.
• 2단계. 적응 은 Sprint 계획 회의에 비유할 수 있습니다.
• 3단계. 학습 은 Daily Scrum 회의에 비유할 수 있습니다.
• 4단계. 다시 시작 은 Sprint의 종료와 새 Sprint의 시작에 비유할 수 있습니다.

자기 조직화

Scrum 팀은 스스로 조직합니다. 팀원은 Sprint 목표 달성에 필요한 작업을 합의하여 결정합니다. 자기 조직적인 팀에는 관리자나 팀 리더가 필요하지 않습니다.

Scrum 프레임워크의 자기 조직화는 매우 규율 있게 이루어집니다.

Sprint Backlog 및 Daily Scrum 회의 는 자기 관리를 지원합니다. 다음과 같은 Sprint 번다운 차트 는 진행 상황을 보이게 하는 선택적 방법 중 하나입니다.

대부분의 팀은 스스로 업무를 구성하는 법을 배우는 기간이 필요합니다. Scrum Master 인증을 보유한 유능한 Scrum Master는 팀이 자기 조직화에 빠르게 능숙해지도록 지원합니다.

자기 조직화에는 팀원 간 의견 차이와 잠재적 갈등에도 함께 일하는 능력이 포함됩니다. 공동 의사결정 과정에 대한 준수와 신뢰가 필요합니다.

Scrum의 의사결정 과정에는 팀이 공동 책임을 지는 업무의 계획, 추정, 구현, 보고 및 검토 등이 포함됩니다.

Scrum 이벤트와 지속적인 백로그 정제

Scrum 이벤트 1. Sprint 계획(왜, 무엇을, 어떻게)

다음 회의에서 Sprint Planning 회의에서 팀은 해당 Sprint에서 구현할 요구사항을 정하는 실행 가능한 Sprint Backlog를 만듭니다.

Sprint 계획 회의에서 여러 Scrum 역할의 의무는 다음과 같습니다.

• Product Owner는 Sprint가 어떤 가치를 가질 수 있는지 제안합니다. 팀 전체가 Sprint 목표를 함께 수립하고, 개발자는 완료할 수 있으리라 예측하는 제품 백로그 항목을 선택합니다.
• 팀은 필요한 작업과 추정치를 파악합니다. 개발자는 과거 성과, 처리 역량 및 완료의 정의를 참고하여 Sprint에서 어떤 항목을 얼마나 완료할 수 있을지 예측하고 결정합니다.
• Scrum Master는 회의를 진행하며 팀의 자기 조직화와 자율적인 의사결정 능력이 유지되도록 합니다.

Sprint 계획 회의에는 Scrum Product Owner가 반드시 참석해야 합니다. 팀의 질문에 답하고 요구사항과 인수 기준을 명확하게 설명하기 위해서입니다.

팀은 조언을 얻기 위해 최종 사용자나 관리자 등 다른 사람을 Sprint 계획에 초대할 수 있습니다. 초대된 참여자는 조언을 제공하되 작업 방식에 대한 개발자의 결정을 대신하지 않습니다.

Scrum 이벤트 2. Daily Scrum 회의(일일 스탠드업 회의)

이 Daily Scrum 회의 는 최대 15분 회의입니다. 매 업무일 같은 시간과 장소에서 열립니다. Sprint Backlog와 Sprint 번다운 차트에 바로 접근할 수 있는 환경에서 진행하는 것이 좋습니다. 그러면 Scrum Team은 모든 팀원에게 보이는 사실과 진척을 바탕으로 Daily Scrum 회의를 진행할 수 있습니다.

Daily Scrum 회의는 Scrum Team의 자기 조직화를 지원하고 장애물을 체계적으로 파악하는 것을 목표로 합니다.

Daily Scrum은 개발자를 위한 것입니다. Sprint Backlog 항목을 작업하는 Product Owner나 Scrum Master는 개발자로 참여합니다. 다른 참여 방식도 개발자의 집중과 자기 관리를 지켜야 하며, Scrum은 모든 역할이나 이해관계자의 참석을 요구하지 않습니다.

개발자는 Sprint 목표와 실행 가능한 계획에 집중하는 유용한 구조를 선택합니다. 다음 세 질문은 익숙한 선택적 형식이며, 현재 Scrum이 규정한 질문은 아닙니다.

• Daily Scrum 회의 - 질문 #1. 지난 Daily Scrum 회의 이후 어떤 활동을 수행했는가?
• Daily Scrum 회의 - 질문 #2. 다음 Daily Scrum 회의까지 어떤 활동을 수행할 계획인가? 나의 실행 계획은 무엇인가?
• Daily Scrum 회의 - 질문 #3. 작업의 진척을 늦추거나 막을 수 있는 장애물을 만났거나 예상하고 있는가?

개발자들이 자신의 Daily Scrum을 운영합니다. Scrum Master는 필요할 때 개발자가 목적과 효과성을 이해하도록 돕습니다. 이벤트는 여전히 15분이며 세 질문 형식은 선택 사항입니다.

Daily Scrum 회의의 목표에는 시간이 오래 걸리는 결정이나 문제 해결이 포함되지 않습니다. 결정에 합의하고 문제를 해결하려면 팀이 필요에 따라 별도 회의를 마련할 수 있습니다. 이런 회의는 보통 Daily Scrum 직후에 열립니다.

Scrum Master는 파악한 장애물과 날짜를 팀이 접근할 수 있는 별도 기록, 플립 차트 또는 보고서에 문서화합니다. 저는 Daily Scrum 마지막에 미해결 장애물의 상태를 빠르게 갱신하는 것이 매우 유익하다고 생각합니다.

Scrum 이벤트 3. Sprint 리뷰 회의

이 Sprint Review 회의 는 Sprint가 끝날 때 열립니다. 일부 팀에는 한두 시간의 리뷰가 적합할 수 있습니다. 공식 최대 시간은 한 달 Sprint에 네 시간이며, 더 짧은 Sprint에는 보통 더 짧은 이벤트가 적합합니다. 소프트웨어 종류와 가용 인프라에 따라 회의실, 연구실 또는 팀 공간에서 열립니다.

Sprint 리뷰 회의의 목표는 Sprint 중 만든 출시 가능한 제품 증가분을 검토하고 제품 개발 프로세스에 투명성을 부여하는 것입니다.

팀은 업무 결과를 시연합니다. 팀과 이해관계자는 달성한 것과 환경의 변화를 논의합니다. 결과를 점검하고 다음에 할 일을 고려하며, 리뷰는 미리 약속한 고정 작업 목록을 대조하는 준수 검사가 아닙니다.

Sprint 리뷰에서 팀과 이해관계자는 제품 결과를 점검하고 제품 백로그를 조정합니다. 이후 팀 전체가 다음 Sprint 목표를 함께 수립합니다. 따라서, Sprint 리뷰 회의는 "점검과 적응"을 공식적이고 실용적으로 적용하는 자리입니다.

참석자는 Scrum 팀, Scrum Product Owner 및 Scrum Master입니다. 선택적으로 최종 사용자, 고객, 비즈니스 담당자 등 다른 모든 이해관계자도 참여할 수 있습니다.

Sprint 리뷰 회의에서는 시연한 제품 증가분에 대한 피드백을 제공할 수 있습니다. 이렇게 팀은 자신이 소프트웨어를 만드는 대상인 이해관계자로부터 가공되지 않은 직접적인 의견을 얻을 기회를 갖습니다.

Scrum 이벤트 4. Sprint 회고 회의

이 Sprint 회고 회의 는 Sprint 리뷰에 이어 열리며 Sprint를 마칩니다. 한 달 Sprint의 최대 시간은 세 시간이며 더 짧은 Sprint에서는 보통 더 짧습니다.

Sprint 회고 회의의 목표는 팀원의 팀워크와 Scrum 프로세스 적용을 개선하는 것입니다.

따라서 생산성, 팀원의 성과 및 소프트웨어 품질이 향상됩니다.

Sprint 회고는 개선 가능성을 정의하고 프로세스 관련 장애물을 제거하는 소규모 사후 분석과 같습니다. 프로젝트에서 자주 보는 개선 가능성의 예는 다음과 같습니다.

• 다음과 같은 애자일 소프트웨어 개발 실천 도입: 익스트림 프로그래밍(XP) 또는 테스트 주도 개발(TDD).
• 새로운 팀 규범과 원칙 파악 또는
• Scrum Product Owner의 가용성 향상.

팀은 예외 없이 모든 Sprint가 끝날 때 회고 회의를 진행합니다. 그래야만 팀이 프로젝트의 특성에 맞게 Scrum 프로세스의 활용을 체계적으로 조정하고 개선할 수 있습니다.

관련 실천: 제품 백로그 정제(그루밍)

Scrum 백로그 정제(그루밍) 회의 는 제품 백로그를 최신 상태로 유지하는 것을 목표로 합니다. 따라서 진행 중 프로젝트에 대한 팀의 최선의 노하우와 이해를 반영합니다.

정제는 필요에 따라 또는 예정된 논의를 통해 이루어질 수 있습니다. 주당 30분씩 두 번은 실무의 한 예이며 필수 빈도나 상한이 아닙니다. Product Owner와 개발자가 협력하며 Scrum Master 및 다른 기여자는 도움이 될 때 참여합니다.

Scrum 백로그 정제(그루밍) 회의에서 참여자는 다음 활동으로 제품 백로그를 세밀하게 조정합니다.

• 새로 발견한 요구에 따라 스토리 추가.
• 더 이상 제품에 필요 없는 스토리 제거.
• 스토리 추정 세부 조정.
• 스토리 우선순위 갱신.
• 거대한 스토리를 소화하기 쉬운 작은 스토리로 나누고 우선순위 설정.

Scrum Master 인증을 취득하는 간단한 네 단계

Scrum Master 인증 취득은 매우 간단하고 빠르며 전 과정을 온라인으로 진행합니다.

다음 덕분에 International Scrum Institute™는이제 그 어느 때보다 빠르고 경제적으로 Scrum Master 인증을 취득할 수 있습니다.

여러분의 인증을 취득하는 간단한 네 단계 Scrum Master 인증 시간과 돈을 낭비하지 않고 번거로움 없이 진행하는 단계는 다음과 같습니다.

• 1단계. 온라인 등록

  다음을 이용해 온라인으로 Scrum Master 인증을 신청하세요 Scrum Master Accredited Certification™ 등록 페이지.

  등록 후 International Scrum Institute™는 시험 접속 코드를 온라인으로 즉시 제공합니다.

  다음 링크에서 할 수 있습니다 Scrum Master 인증 프로그램 등록.

• 전체 크기 이미지 열기 ↗

  2단계. 온라인 학습

  다음을 이용해 온라인으로 Scrum Master 인증을 공부하세요 Scrum 학습 가이드 The Scrum Framework™.

  The Scrum Framework™는 철저히 실무 중심이 되도록 설계되었습니다. 유능한 Scrum Master로서 직장과 경력에서 마주하는 일상적인 과제를 해결하도록 돕습니다. 가장 성공적인 Scrum Master의 일상을 보여 주는 사례 연구와 실무 예제가 가득합니다.

  다음 링크에서 할 수 있습니다 The Scrum Framework™ 무료 도서 요청.

• 3단계. 온라인 Scrum Master 인증 시험 응시

  Scrum 학습 가이드 The Scrum Framework™를 꼼꼼히 읽고 공부하고 이해했다면 이제 준비가 되었을 것입니다! Scrum Master 인증 시험에 합격할 수 있다는 충분한 자신감을 느낄 것입니다.

  다음 링크에서 할 수 있습니다 Scrum Master 인증 시험 접속.

• 4단계. Scrum Master 인증 취득

  시험에 합격하면 Scrum Master 인증서를 즉시 제공합니다.

  고용주와 고객은 고용주용 Scrum 인증 검증 도구로 인증의 진위를 확인할 수 있습니다. 다음 링크에서 할 수 있습니다 고용주용 Scrum 인증 검증 도구 이용.

Scrum Master 인증에 대한 마무리 생각

이제 되짚어 볼 시간입니다. Scrum Master가 되는 단계별 가이드를 전부 읽을 기회가 없었다면 제 생각을 정리해 드리겠습니다. 인증 취득의 장단점에 대한 제 생각은 이렇습니다.

장점

직원, 프리랜서, 코치 및 강사를 위한 장점

• Scrum Master 인증은 Scrum 분야의 역량과 최신 노하우를 인정받는 증거가 됩니다.
• 더 이상 스스로 발전하지 않는 동료보다 앞설 수 있도록 돕습니다. 인증받은 유능한 Scrum Master로서 꿈꾸던 직장에 채용되도록 돕습니다.
• 시야를 넓히고 지속적인 학습에 더 열린 마음을 갖게 합니다. 더 많은 책임과 멋진 경력 기회를 얻도록 돕습니다.
• 고객과 고용주가 좋아할 뛰어난 제품과 서비스를 제공할 완전히 새로운 도구 모음을 제공합니다.

조직과 고용주를 위한 장점

• Scrum Master 인증은 팀, 활동 및 프로세스의 효율성을 높여 비용을 줄입니다.
• 교육받고 숙련된 직원들과 함께, 그렇지 않으면 수주하지 못할 프로젝트를 확보하도록 돕습니다.
• 직원이 교육받고 역량을 개발하도록 장려하여 만족도와 헌신을 높입니다.
• 산출물의 품질과 고객 만족도를 높이고, 궁극적으로 조직의 성공과 수익성을 향상합니다.

단점

• Scrum Master 인증 때문에 학습을 멈춰서는 안 됩니다. 인증 취득은 첫 단계일 뿐임을 잊지 마세요.

  Scrum에서 배운 "점검과 적응"의 정신에 따라 지속적으로 실험하고 관찰하고 배우는 것은 여전히 여러분의 임무이자 의무입니다.

• 전 세계 모든 조직에 꼭 맞는 단일 해결책은 없습니다. Scrum 소프트웨어 개발 및 제공 프레임워크도 예외가 아닙니다.

  관찰한 바에 따르면 Scrum에서 최고의 성과를 얻지 못한 대부분의 조직에는 공통점이 있습니다. Scrum을 자체 비즈니스 및 IT 생태계에 맞게 조정하지 못했다는 것입니다.

  따라서 다시 "점검과 적응"의 정신에 따라 Scrum을 100% 성공 보장 처방으로 보지 마세요. 자체 비즈니스와 IT의 역학에 맞게 조정할 인지 능력을 과소평가하지 마세요. 사실 보수를 받는 전문가라면 Scrum으로 최고의 처리량과 비즈니스 성과를 얻기 위해 바로 그렇게 해야 합니다.

• Scrum이 IT 부서의 모든 문제를 해결한 것은 아닙니다. 다음과 같은 방법으로 계속 자신을 발전시키세요. DevOps와 같은 새롭게 등장하는 소프트웨어 개발 및 제공 프로세스.

  Scrum 프레임워크의 알려진 약점과 DevOps의 해결 방식을 더 이해하려면 나중에 다음 주요 기사를 살펴보세요. DevOps와 Scrum의 주요 차이점 6가지는 무엇인가요?

Scrum Master 인증은 애자일 소프트웨어 개발 및 제공 실천을 시작하는 훌륭한 방법입니다.

Gartner 연구에 따르면 “더 나은 Scrum Master 되기” 2019년에 발표된 이 기사는 2023년에 대해 다음과 같이 예측했습니다 전 세계 기업의 92%, 미국 기업의 96%가 애자일 Scrum 실천을 도입할 것이라고. 이는 원문 기사가 보도한 예측이며 현재 도입률을 측정한 수치가 아닙니다.

따라서 지금보다 더 좋은 때는 없습니다. 이제

• Scrum 프레임워크 무료 학습 시작하기 및
• International Scrum Institute™의 매우 합리적인 비용으로 Scrum Master 인증 취득하기.

이제 남은 질문은 언제 시작하시겠느냐는 것뿐입니다.