스크럼 프레임 워크와 PO, 스프린트

 

 

스크럼 프레임워크란?

 

Agile(애자일) 접근법은 혁신적인 제품과 서비스 개발 방식이다. 그 중에서도 대표적인 방식인 스크럼은 팀이 중심이 되어, 개발의 효율성을 높인다는 의미의 용어이다.

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

---

스크럼 프레임워크의 철학

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

---

 

스크럼 프레임워크의 원리

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

---

스크럼 가이드

스크럼 가이드는 켄 슈와버와 제프 슈덜랜드(Ken Schwaber, Jeff Sutherland)가 공동 저술한 가이드북으로 스크럼에 대한 핵심적인 내용과 용어들을 간략하게 이해할 수 있도록 구성되었다. 웹사이트에서 무료로 다운로드가 가능하며 한국어판을 제공한다. 오늘 과제는 핵심 내용을 요약하여 정리하는 것으로 진행했다. 

 

---

스크럼이란?

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

 

스크럼은 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법 Adaptive solutions을 활용하여 가치를 창출하도록 도와주는 경량 Lightweight 프레임워크이다. 스크럼은 스크럼을 사용하는 사람들의 집단지성을 기반으로 만들어진다. 사람에게 상세한 지침을 주는 것 보다는 스크럼 원칙은 사람들 간의 관계와 소통을 안내하는 것이다. 프레임워크 안에서 다양한 프로세스, 테크닉, 방법을 이용해 볼 수 있다. 기존의 실천법을 스크럼 프레임워크 내에서 수행할 수 있다. 또한 스크럼으로 인해 기존의 업무 방식이 불필요해 질 수도 있다. 현재의 관리, 환경, 업무 기법과 관련된 효과를 스크럼을 통해 가시화하여 개선을 할 수 있다.

 

스크럼의 주요 특징

• 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
• 개발 주기는 1~4주 정도로 하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
  (설명:너무 짧으면 개발(분석/설계/개발/테스트) 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로 적용해보면서 필요시 조율 필요)
• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
  (설명:해당 주기의 Goal을 작성하지 않으면 목적을 잃은 기능 목록이 될 수 있음)
• 매일 15분 정도의 Scrum meeting 회의를 가져라.
  (설명:공유이지 보고하는 자리가 아니다. 교과서적으로 Scrum meeting은 개발팀원만 참여해야하고, 팀원이 아닌 사람은 발언기회는 없다고 한다. 개인적인 생각으로는 수평문화가 되어 있는 Agile Culture의팀이라면 PO 및 관리자가 함께 참석하여 공유하면 좋다고 생각한다. 이들도 참석한다면 이 프로젝트와 관련되어 한일/할일/이슈를 공유해야 한다. 안그러면 한팀이 아닌 관리자 모드로 돌아선다.)
• 항상 팀을 우선으로 생각하라.
  (설명:자신의 task보다 주변 이슈가 더 급하면 도와줘야 한다. 마치 배에 구멍이 나면 그 문제 해결이 1순위이다.)
• 원활한 의사소통을 위하여, 구분 없는 열린 마음을 유지하라.

 

 

---

스크럼에서 프로덕트 오너(Product Owner)의 역할

 

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

스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는다. 이 업무를 수행하는 방법은 조직, 스크럼 팀, 개인에 따라 다를 수 있다. 백로그를 효과적으로 관리하는 것 또한 프로덕트 오너의 책임중 하나이다. PO는 백로그를 효과적으로 관리하기 위해 아래 사항에 책임을 갖는다.

 

• 프로덕트 목표를 세우고 명쾌하게 소통하는 것
• 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것 → 이해관계자, 팀 내부에서 생성된 유저스토리를 백로그로 관리
• 프로덕트 백로그 아이템을 우선순위에 따라 정렬 → 제한된 시간&리소스 내에서 스코프 조정을 위해 고객가치와 사업가치의 측면, 데이터 기반 결정
• 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것 → 칸반, 스크럼 보드 등을 통해 업무를 시각화, 데일리 스크럼에서 업무 공유를 리드해 효율 UP

 

PO결정은 백로그 내용, 백로그 우선순위에 따른 정렬과 스프린트 리뷰 때 점검 가능한 증가분을 통해 볼 수 있다. 백로그 변경의 결정권은 PO에게 있으며 백로그를 변경하고 싶은 사람은 PO를 설득해야 한다.

 

---

스프린트

스프린트는 아이디어를 가치로 만들어 내는 이벤트로 마치 스크럼의 심장 박동과 같다. 스프린트는 꾸준함을 갖기 위해 한달 또는 그보다 짧은 기간으로 고정된 길이의 이벤트이다. 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작한다. 스프린트 동안 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 프로덕트 목표를 달성하기 위해 필요한 모든 업무를 수행한다

 

💡스프린트 프로세스 스프린트 계획 → 데일리 스크럼 → 스프린트 리뷰  → 스프린트 회고

 

스프린트는 모든 스크럼 이벤트들을 담는 컨테이너로 스프린트가 진행되는 과정에서 중요하게 생각해야 하는 점은 다음과 같다.

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

---

<이미지 및 자료 출처>

 

 

 

[Agile] Scrum(스크럼) 이해하기