[코드스테이츠 PMB 9기] 스크럼(Scrum) 과 칸반(Kanban)

스크럼 프레임워크

📌 스프린트 계획회의 ; 제품 책임자(PO)가 사용자 스토리 기반으로 제품 백로그 작성

📌 백로그 ; 이해관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록

📌 사용자 스토리 ; 고객이나 개발자가 모두 이해할 수 있도록 고객이 작성 혹은 고객이 서술하는 형식 채택 ; ‘나는 ~로써 ~하기 위해 ~ 하고 싶다. 라는 형식으로 작성 ; Who, Why, What 정보 모두 포함 되어야 함

 

스크럼 특징

• Self-organizing ; 팀원 스스로 스크럼 팀을 구성
• Cross-functional ; 개발 작업에 관한 모든 것을 스스로 해결

 

스크럼 철학

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

 

스크럼 원리

• 우리는 고객을 잘 알지 못함
• 이에 빠르고 자주 고객에게 릴리즈하고 새롭게 발견해야 함
• 이를 통해 여러 번의 가설 검증 단계를 거침
• 우리가 진짜 필요한 것이 무엇인지, 피해야 할 것이 무엇인지 파악함
• 이를 통해 우리는 이해관계자들에게 더 빠르게, 더 잘 그들이 원하는 것을 전달할 수 있음

 

스프린트 백로그

• 백로그에서 결정된 우선순위 기반으로 스프린트 동안 해야 하는 일들의 리스트
• 백로그 = 할 일 목록 / 기간은 1-2주에서 최대 1개월
• 벽 크기의 업무 보드 형식의 스프린트 백로그를 만드는데 이를 스크럼보드(Scrum Board)라고 함

 

데일리 스크럼 미팅

• 일일 스크럼 미팅은 개발원 리소스 고려하여 스탠드업 미팅 형식으로 진행
• 매일 정해진 시간과 장소에서 15-20min 빠르게 진행
• 어제 했던 일, 오늘 할 일, 수행중 문제점, 장애요인 공유하고 문제 있을 경우 미팅 종료 후 즉시 해결
• 프로젝트 후반부에 이슈 발생하는 것 예방

 

스프린트 리뷰

• 스프린트 종료 후 개발팀이 스프린동안 개발한 기능을 고객 및 이해관계자에게 보여주고 피드백 받는 과정
  • 고객 ; 요구사항이 해당 제품에 잘 반영되었는지 평가한 후 피드백
  • PO ; 피드백이나 여러 사항들을 정리하여 다음 스프린트에 반영되도록 백로그 업데이트
• 0.5 - 1h 시간 동안만 진행
• 제품 기능에 대한 회고

 

스프린트 회고

• 전반적인 스프린트 과정에 대한 회고
• 스프린트 리뷰 후 프로젝트를 진행하며 좋았던 점이나 문제점, 미진한 점등을 도출함으로써 더 나은 방향으로 개선하기 위한 과정
• 스크럼 마스터 혹은 PO는 중재 및 조정 역할을 하는 Facilitator, Moderator 역할을 함

---

 

제품 개발 방법론

 

제품 개발 방법론 선정 고려 요소

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

⇒ 개발 범위가 고정적이고 개발 기간동안 변화가 될 가능성이 낮을 경우, 워터폴 방식 검토
⇒ 개발 범위가 유동적이고 개발 기간동안 고객의 요구사항이 유동적인 경우, 애자일 방식 검토

 

워터폴 과정에서 PM의 역할

• 특정 프로젝트에서 요구되는 내용 파악
• 중간에 계획 수정 없도록 초기 계획 설계
• 우선순위 산정 → 기한 내 작업될 수 있게하고 투입 리소스 최소화 함

 

애자일 과정에서 PM의 역할

• 핵심 기능 위주로 빠르게 개발할 수 있도록 스코프를 잘게 나눔(Features / Functionaility)

---

 

스크럼 vs 칸반

 

칸반(Kanban)

• 팀과 조직이 작업을 시각화
• 업무의 병목과 리소스 낭비 처리할 수 있도록 돕는 애자일 프레임 워크
• 우선순위와 크기가 다른 요청으로 구성
• 작업 시각화, 진행 중인 작업 수 제한하며 효율성 추구

 

스크럼(Scrum)

• 잘 정의된 목표를 향한 팀워크, 책임 및 반복적인 진행을 강조
• 협업, 작동하는 S/W, 팀 자체 관리, 신속한 대응 같은 유연성 강조

 

 

---

스크럼 가이드

 

프로덕트오너

• 스크럼팀의 결과물인 프로덕트의 가치를 극대화 하는 책임을 갖음
• 백로그를 효과적으로 관리하는 책임을 갖음
  • 프로덕트 목표를 세우고 명쾌하게 소통할 것
  • 프로덕트 백로그 아이템을 생성하고 분명하게 소통할 것
  • 프로덕트 백로그 아이템을 우선순위에 따라 정렬
  • 프로덕트 백로그를 반드시 투명하고 가시적이며 이해 잘 되도록 만들 것

 

스프린트

• 스프린트 기간에 해야할 것
  • 목표 달성을 저해하는 변경을 해서는 안 됨
  • 품질을 떨어뜨려서는 안 됨
  • 필요 수준까지 프로덕트 백로그를 정제해야 함
  • 범위를 명확히 하고 필요한 경우, PO와 다시 협상함
• 진척 예측 방법
  • 번 다운 차트
  • 번 업 차트
  • 누적 흐름도
• 계획
  • 이 스프린트가 왜 가치가 있는가?
    • PO가 스프린트에서 프로덕트가 어떻게 가치와 효용성을 높일 수 있는지 제안함
    • 스프린트 목표를 정의할 때, 스프린트가 이해관계자들에게 중요한 이유 담아야 함
    • 스프린트 목표는 반드시 스프린트 계획을 마치기 전에 결정되어야 함
  • 이 스프린트 완료는 무엇인가?
    • 프로덕트 백로그 아이템 선정
    • 스크럼 팀은 이 과정에서 프로덕트 백로그 아이템을 정제할 수 있음
    • 지난 성과, 다음 번에 수용 가능한 업무량, 완료의 정의에 대한 이해가 깊을수록 이후 스프린트 계획에 확신 갖을 수 있음
  • 선정한 일을 어떻게 완료할 것인가?
    • 프로덕트 백로그 아이템을 하루 안에 완료할 수 있는 크기로 더 작게 세분화하는 것으로 구성되며 이는 개발자들의 재량 영역임
    • 스프린트 백로그= 스프린트 목표 + 스프린트를 위해 선정한 백로그 아이템 + 완료 계획

---

스프린트와 스크럼의 중요 요소

 

1. 고객 파악

• 프로덕트를 사용하는 사람은 누구인지?
• 개개인이 아닌 법인이나 단체가 이 프로덕트를 사용하는 경우도 있는지?
• 사용자는 어떤 가치를 얻으려고 하는지?
• 프로덕트가 그 가치를 직접적으로 제공해줄 수 있는지?
• 성공적으로 제공했다는 사실을 데이터로 증명 가능한지?
• 동일한 가치를 추구하는 사용자 집단을 묶을 수 있는지?

 

2. Product Brief(스펙 요약 문서)

1. 이 프로덕트의 목적 & 목적이 아닌 것
   1. 목적 : 제품/기능의 목적
   2. 목적이 아닌 것 : 효율적인 논의가 가능하도록 제품/기능의 목적이 아닌 것 작성
2. 배경
   1. 배경 요약 : 해당 기능/제품의 배경 작성
   2. 고객 문제 가설 : 고객이 마주한 문제를 작성 / 고객의 여러 문제 중 어떤 문제가 현재 중요하고 해결해야하는지 이유 포함
   3. 솔루션 가설 : 고객 문제 가설을 해결할 수 있는 솔루션 가설 작성 / 여러 솔루션 중 가장 효율/효과적인 솔루션을 제안
3. 기회 요약 및 임팩트 예측
   1. 기회 요약 : 시장에 어떤 기회가 있고, 살펴본 데이터가 어떠한지 작성
   2. 예상되는 사용자 행동 : 해당 제품/기능으로 사용자가 어떤 행동을 할지 작성
   3. 가설을 검증하기 위한 지표 : 예상되는 사용자의 행동으로 어떤 지표가 영향이 있을지 예측 / 가설 검증 핵심 지표인 Primary metric과 의사결정에 참고하기 위한 Secondary Metric을 지정
   4. 예상임팩트 : 예상되는 사용자의 행동과 이로 인해 변화될 지표에 따라 어떤 임팩트가 예상되는지 추정하여 작성
4. 솔루션 디자인
   1. 주요 화면 : 간단히 화이트보드에 그려본 제품의 디자인, 디자이너가 빠르게 그려본 디자인 예시 등 솔루션이 어떤 모습일지 주요 화면을 첨부
5. User Story
   1. 사용자가 어떤 순서로 제품/서비스를 사용하게 되고, 이때 제품/서비스의 각 화면과 버튼 어떻게 동작해야 되는지 작성
6. 이벤트 명세
   1. 새로운 제품/기능이 구현된다면, 가설 검증을 위해 데이터를 어떻게 수집할지 고민해야 함
   2. 새로운 제품/기능에서 어떤 이벤트(데이터)를 수집할지 정의하는 것 필요
7. 의존점 및 협업 요소
   1. 회사 내/외부 의존점 및 협업 필요 요소 : 제품 개발을 위해 위해 필요한 회사 내/외부의 협업이 필요한 요소 기입
   2. 예상 리스크 :제품/기능이 실패할 수 있다면 어떤 이유 때문일지 사전부검(Pre-Mortem)을 통해 예상되는 주요 리스크 작성
8. 마일스톤
   1. A 기능 구현 ( 2022. XX. XX ~ 2022. XX. XX )
      1. 담당자 :
      2. 세부 내용 및 관련 링크 :
9. 관련 문서 링크

 

3. 이전 스프린트 회고 문서

1. 지난 회고 액션 아이템 점검
2. 회고 목표
3. 회고 규칙
4. 회고 진행
   1. 체크인 : 회고 진행 소감 나누기
   2. 회고 위한 자료조사 리뷰 : 스프린트 시작 과정에서 정의한 이슈, 추가된 이슈, 완료한 이슈 검토
   3. 포스트인 분류 : 회고 목표에 맞게 기억 남는 업무 작성(부정적 감정 들었던 업무는 별도 표시)
   4. 일정 리뷰
   5. 업무상 유사 요소 그룹핑 후 문제 파악
   6. 가장 큰 문제와 해결책 논의