| PMB 12기 | W8D2 | 스크럼 가이드 정리

최초 작성일 : 2022.06.30

 

 

---

 

프로덕트 개발 방법론

 

🌊 Waterfall

제품를 스스로 정해서 고객 테스트 없이 팀 내 혹은 기업 내 이해관계자들끼리의 결정만으로 제품 개발 후 시장에 내놓는 전략이다. 처음부터 고객 문제를 해결하는 솔루션을 정의하고, 위에서부터 아래로 내려가면서 개발하는 탑-다운 방식을 진행하는 것이 특징이다.

 

🌊 Waterfall 개발 과정

요구사항 수집과 분석 → 설계 → 테스팅 → 프로젝트 최종 결과물 → 유지 보수

 

 

🔄 Agile

아주 작은 핵심 요소만으로 제품 혹은 샘플을 만들어서 소비자 반응을 확인하고 점점 살을 붙여 나가는 방식이다. 각 주기는 제품이나 서비스 개발을 지속해서 향상하는 데 초점이 맞춰져 있으며, 반복적이며 사람 중심적인 개발 방식을 취한다.

 

🔄 Agile 개발 과정

계획 → 설계 → 개발 → 테스팅 → 피드백

 

 

스크럼 (Scrum)

 

The Scrum Framework, visualized by Thea Schukken

📌 Scrum

스크럼은 Agile(애자일)의 대표 프레임워크로, 팀이 중심이 되어 개발의 효율성을 높인다는 것을 의미한다.

 

• 스크럼은 팀원 스스로 스크럼 팀을 구성 (Self-organizing)
• 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 함 (Cross-functional)

 

📌 Scrum Team

• 스크럼 조직의 기본이 되는 단위인 스크럼 팀은 적은 수의 인원으로 구성
• 한 명의 스크럼 마스터, 한 명의 프로덕트 오너, 그리고 개발자들로 구성 (하부 팀, 수직구조 X)
• 하나의 프로덕트 목표에 동시에 집중하는 전문가들의 모임

 

📌 Scrum Product Owner

스크럼은 Agile(애자일)의 대표 프레임워크로, 팀이 중심이 되어 개발의 효율성을 높인다는 것을 의미한다.

프로덕트 오너는 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는다. 또한 PO의 책임은 프로덕트 백로그를 효과적으로 관리하는 것이다.

 

• 프로덕트 목표 명쾌하게 소통하는 것
• 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
• 프로덕트 백로그 아이템을 우선순위에 따라 정렬
• 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것

 

PO는 한 사람이지 여럿으로 구성된 위원회가 아니며, 프로덕트 백로그와 연관된 많은 이해관계자들의 요구를 대표한다. 그렇기에 프로덕트 백로그를 변경하고 싶은 사람들은 프로덕트 오너를 설득하여야 한다.

 

 

스프린트 (Sprint)

 

What is a Sprint in Scrum?, vpadmin

 

📌 Sprint

스프린트는 스크럼의 심장 박동과 같으며, 스프린트는 꾸준함을 갖기 위해 한달 또는 그보다 짧은 기간으로 고정된 길이의 이벤트이다. 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작한다.

스프린트 동안 스프린트 계획 → 데일리 스크럼 → 스프린트 리뷰 → 스프린트 회고를 포함하여 프로덕트 목표를 달성하기 위해 필요한 모든 업무를 수행한다.

 

• 스프린트 목표 달성을 저해하는 변경을 해서는 안된다
• 품질을 떨어뜨려서는 안된다
• 필요한 수준까지 프로덕트 백로그를 정제해야 한다
• 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다

 

스프린트 기간이 짧을수록 학습 몰입력이 크고, 짧은 기간의 비용과 노력으로 리스크를 한정할 수 있다. 다만 스프린드의 목표가 효력이없게 되면, 오직 PO만이 스프린트를 취소할 수 있다.

 

• 스프린트 계획 : 해당 스프린트 동안 수행할 업무를 팀 전체가 참여하여 계획.
• 데일리 스크럼 : 스프린트 목표 대비 진척을 점검, 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정. 스크럼팀의 개발자들만 참여하는 15분 길이의 이벤트
• 스프린트 리뷰 : 스프린트의 결과물을 점검하고 향후에 적응할 것들을 결정하는 것.
• 스프린트 회고 : 품질과 효율을 높이기 위한 방법들을 계획하는 것. 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스 툴, 완료의 정의에 대해 지난 스프린트가 어떻게 진행 되었는지를 점검

 

---

 

📌 스크럼 이벤트

스프린트는 다른 모든 이벤트들을 담는 컨테이너라할 수 있다. 각 스크럼이벤트는 스크럼 산출물을 점검하고 적응하는 공식적인 활동이고, 필요한 투명성을 확보할 수 있도록 특별하게 설계되었다.

스크럼 이벤트들은 주기적이고 반복적인 활동이기 때문에 또 다른 미팅을 할 필요성을 줄여준다.

​

📌 스크럼 산출물

스크럼의 산출물은 업무 또는 가치를 나타내며, 핵심 정보의 투명성을 극대화하도록 설계 되어 모두가 산출물을 점검하는 것은 적응을 하기 위한 동일한 기반 정보를 얻는 것이다.

 

• ​프로덕트 백로그에는 프로덕트 목표가 있다.
• 스프린트 백로그에는 스프린트 목표가 있다.
• 증가분에는 완료의 정의가 있다.

 

📌 프로덕트 백로그

프로덕트 백로그는 프로덕트를 향상시키기 위한 것으로 발생하는 업무를 우선순위에 따라 정렬한 목록이다.

프로덕트 백로그 정제는 프로덕트 백로그 아이템을 구체적으로 정의하여 보다 명확하게 일을 작은 단위로 나누는 것이며, 설명, 우선순위에 따른 정렬, 크기와 같은 세부 사항들을 지속적으로 추가하는 활동이다. 속성 항목들은 주로 업무 영역에 따라 다를 수 있다.

• 약속 : 프로덕트 목표 (스크럼 팀이 목표로 삼아 계획하는 프로덕트의 미래 상태)

 

📌 스프린트 백로그

스프린트 백로그는 스프린트 목표(왜), 스프린트를 위해 선택된 프로덕트 백로그 아이템들의 모음(무엇을), 증가분을 전달하기 위한 실행할 수 있는 계획(어떻게)으로 구성된다.

스프린트 백로그는 개발자들에 의한 개발자들을 위한 계획이다. 매우 가시적이며, 개발자들이 스프린트 목표를 달성하기 위해 스프린트 동안 완수하기로 계획한 업무를 실시간으로 보여주는 그림이다.

• 약속: 스프린트 목표 (스프린트에 대한 단 하나의 목표)

​

📌 증가분

증가분은 프로덕트 목표로 향하는 단단한 디딤돌 역할하며, 각각의 증가분은 모든 이전에 누적된 증가분에 더해진다.증가분은 철저하게 검증된 것이어야하며, 가치를 제공하기 위해 증가분은 반드시 사용 가능한 것이어야 한다.

스크럼 기간동안 PM 역할

Q&A 세션 정리

📌 팀원들의 어려움 해결

📌 QA팀과 의논 및 지원

📌 다음 스트린트 기획 산출물 정리 (요구사항 정의서, 리서치 등 )

 

스프린트 가이드에서의 PO의 역할은 팀원들과의 의사소통과 책임이 중심이다.

 

---