PM

[PM스쿨 25기] 린캔버스와 Agile 방법론, Scrum의 Sprint, 칸반 - 3주차 학습일지(2)

Dawn_YI 2024. 4. 18. 06:04

 

제로베이스의 PM스쿨 25기를 진행하며 배운 내용을 나름의 방식으로 정리하는 글입니다.

 

목차

더보기

1. 린캔버스

2. Agile 방법론

3. Scrum - 애자일 방법론 (1)

4. 칸반 - 애자일 방법론 (2)

1. 린캔버스

린캔버스란?

비즈니스 모델을 쉽게 표현하는 도표

출처 - K-BIZ-PLAN

  1. 기업과 고객을 위한 해결이 필요한 문제 - 문제 정의
  2. 어떤 고객을 위한 것인가? - 타겟 고백
  3. 차별화 된 가치 - 제품 가치 정의
  4. 가치 제안을 위한 해결책 - 문제의 해결책
  5. 고객의 유입을 위한 경로 - 고객 유입(Channels)
  6. 어떻게 수익을 창출할 것인가? - 수익 구조
  7. 서비스가 유지되기 위해 발생되는 비용 - 서비스 유지 비용(리소스)
  8. 프로덕트의 중요 지표 분석 - 핵심 지표
  9. 핵심 Advantage - 차별화 전략

2. Agile(애자일) 방법론

Agile

출처 - InDevLAB

최소 기능 제품을 빠르게 개발해 유저의 피드백을 바탕으로 프로덕트를 지속 개선해가는 개발 방법론

장점

  1. 잘못된 제품 개발을 하는데 사용하는 시간을 최소화
  2. 빠른 유저 피드백을 통한 프로덕트의 실패 확률 낮추기
  3. 계획 또는 기능 수정과 변경에 유연하게 대처
    ex) 게임의 모든 스테이지를 개발하는 것이 아닌 첫 스테이지만 개발해 배포 후 유저의 피드백을 토대로 게임의 모든 스테이지를 개발해 나가는 것 → 개발 소요 시간을 최소화하며 실패를 낮춤
    ex) 급격하게 변하는 시장의 상황 속에서 정책 등에 대해 유연하게 대처하며 리소스의 낭비와 프로젝트 실패에 대한 확률을 줄임 - ‘타다’ 서비스 예시

단점

  1. 요구사항이 명확할 경우 오히려 속도가 늦춰질 수 있다.
  2. 최종 제품이 요구사항과 달라질 수 있다.
  3. 고객에게 제공하는 가치에 집중하기에 기술적 완성도가 떨어질 수 있다.

Agile에서 일을 쪼개는 단위

  1. Theme - ex) 모바일 배달음식 플랫폼
  2. Epic - ex) 고객은 배달 음식점의 리뷰를 본인에게 맞춰 개인화 함을 확인
  3. Story(기본 단위) - ex) 고객은 배달 음식점의 사진 리뷰만을 모아 볼 수 있다. (고객의 행동을 나타냄)
  4. Task - ex) 사진 리뷰 필터 구현, Task를 Sub Task로 쪼갤 수 있음(Story를 가능하게 하기위해 직접 수행해야 하는 업무)
  • PM은 특정 기간동안 어떠한 Story를 개발할 것인지를 정하고, 해당 Story를 완성하기 위해 어떤 작업을 해야할지 파악해 Task를 생성하고 담당 개발자들에게 할당
  • 이후 정기적인 미팅을 통해 Task들의 진행 상황을 지속적으로 파악하는 것이 PM의 주요 역할

예시 : 당근 마켓 아르바이트 중개 기능

  1. Theme : 지역기반 중고거래 플랫폼 → 지역기반 종합 플랫폼
  2. EPIC : 유저는 지역기반의 아르바이트 중개 기능을 사용
  3. User Story
    • 업체 사장님은 아르바이트 공고를 작성 - High
    • 일반 유저는 아르바이트 공고 리스트를 확인 - High
    • 일반 유저는 아르바이트 공고 리스트 중 선택해 열람 - High
    • 일반 유저는 아르바이트 공고 리스트를 업무별, 시급별 필터링 - Low
    • 일반 유저는 아르바이트 공고 중 원하는 공고를 저장 - Low
    • 일반 유저는 아르바이트 공고 중 원하는 공고를 지원 - Med
  4. Task
    • 업체 사장님은 아르바이트 공고를 작성 - High
      • 아르바이트 공고 작성 페이지 개발
    • 일반 유저는 아르바이트 공고 리스트를 확인 - High
      • 아르바이트 공고 리스트 개발
      • 지역별 공고 리스트 추천 로직 개발
    • 일반 유저는 아르바이트 공고 리스트 중 선택해 열람 - High
      • 아르바이트 공고 상세 페이지 개발

3. Scrum

스크럼은 스프린트를 반복해 제품을 개발해 나가는 방법론으로 프로젝트 진행 도구

프로덕트 백로그란?

  1. 제품 개선을 위해 진행돼야 할 다양한 요구사항
  2. 제품 관련 다양한 인원들로부터 수집
  3. 요청자, 백로그 생성 이유, 추정 시간, 요구 명세 등 다양한 내용 포함
  4. 우선 순위 반드시 포함

백로그 작성법

  1. 요구사항을 작성하되, 구체적인 실행 방안에 대해 작성하지 않아도 됨
  2. 백로그 진행이 중요한 이유에 대해서 자세히 작성할수록 우선순위 산정 및 제품 개발에 용이

백로그 우선순위 설정 방법

  • 비즈니스와 테크적 중요도를 파악해 각 백로그 별 우선순위를 정한다.
  • 우선순위가 높은 백로그일수록 최대한 구체화하고 더 작은 단위로 쪼개 개발이 가능한 상태로 만듦

Sprint 

  • 통상 1~4주 정도의 Time Box(특정 시간에 특정업무를 배정함으로써 정해진 시간 내에 배정된 업무를 완수하도록 돕는 시간 관리 방법) 성격을 가진 개발 주기
  • 각 Sprint 단계 종료시 새로운 기능이 추가돼 제품에 반영되는 것을 목표
  • Scrum은 Sprint를 반복하며 제품을 개발 및 개선해가는 과정

Sprint 전 단계 - Sprint Planning Meeting

  • 백로그 중에 이번 스프린트에 어떠한 백로그를 진행할지 모든 팀원들이 함께 논의하는 회의
  • PM은 독단적으로 목표를 설정해선 안됨
  • Sprint Planning Meeting을 통해 Sprint의 백로그를 선정
  • 보통 Sprint의 백로그는 Sprint가 시작된 이후에 변경하지 않는 것을 원칙

Sprint의 진행 - Daily Scrum Meeting

Scrum Master - 스프린트의 진행상황을 검토하고 목표 달성에 위협이 되는 상황 등을 확인해 해결하는 역할로 커뮤니케이션 이슈와 우선순위 선정에 대한 이견 등 모든 문제들을 조정하는 역할

 

Daily Scrum Meeting

  • 날마다 약 15분씩 진행하는 짧은 미팅(컴팩트하게 진행)
  • 스크럼을 통해 스프린트가 목표에 맞게 진행되고 있는지, 또 스프린트의 백로그에 있는 작업이 잘 완성되고 있는지 검토
  • 일일 스크럼은 개발팀이 스프린트 목표를 달성할 수 있는 확률을 최적화
  • 스크럼에서 PM의 주요 확인 사항은
    1. 어제 하루동안 스프린트 목표 달성을 위해 무엇을 했는지?
    2. 오늘 하루동안 스프린트 목표 달성을 위해 무엇을 할건지?
    3. 나와 팀이 스프린트 목표 달성을 위해 방해되는 요소가 있는지?

Sprint 후 - 리뷰와 회고

스프린트 리뷰

  • 스프린트를 통해 무엇이 완료 됐는지를 팀원과 이해관계자들이 모여 확인
  • 리뷰 결과와 스프린트 수행 중 변경된 백로그를 고려해 다음에 무엇을 할지 함께 의논
  • 경과 보고를 위한 미팅이 아닌 스프린트를 통해 완료된 개선 사항을 발표함으로써 피드백을 받고 협력을 촉진하기 위한 회의

스프린트 회고

  • 스프린트 회고 미팅은 팀이 다음 스프린트 동안 무엇을 개선할 수 있을지 계획할 기회를 제공
  • 스프린트 리뷰 미팅 후 또는 스프린트 플래닝 미팅 전에 수행
  • 회고의 목적
    • 지난 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행됐는지 검토
    • 잘된 것과 개선의 여지가 있는 항목을 알아내고 우선 순위 결정
    • 개선을 실천할 수 있도록 계획 수립

4. 칸반

특정 단계의 작업이 완료 됐을때, 전 단계의 작업 수행을 지시 끌어 당기는 방식으로 진행하는 개발 방법론

칸반 실천법 6가지

  1. 시각화
    • 칸반 보드는 시작 지점과 끝지점이 열로 나눠져 왼쪽부터 오른쪽으로 흘러가는 구성
    • 카드는 작업단위, 열은 해당 카드의 프로세스 단계를 나타냄
    • 각 단계 사이에 진행 중 업무인 WIP 갯수를 제한해 표기 해야함
    • 카드의 열을 옮기기 전에 완료돼야 하는 일이 무엇인 명확한 정책(기준)을 만들어둬야 함
  2. WIP를 제한
    • WIP를 제한해 Pull 형태로 업무 방식 변경
    • 하나의 열에 WIP 제한 기준만큼의 카드가 있을 경우, 카드를 완료 다음 단계로 보내기 전까지 새로운 카드를 당겨 올 수 없음
    • 이를 통해 부분적으로 완료한 업무를 줄이고 완성된 제품을 배포할때 까지의 리드타임을 줄여 고객에게 자주 배포하고 피드백을 얻음
  3. 흐름 관리
    • 업무 흐름이 완성된 가치 생산을 최대화하도록 지속 관리
    • 완성 제품이 생산될 때까지의 리드타임이 줄고, 가능한 예측 가능해야 함
    • 특정 업무가 막힐 경우 해당 업무를 개선해 업무 흐름을 개선
  4. 정책 명시화
    • 칸반 방법론에서 정책을 명시화해 모든 구성원이 동일한 방식으로 일하는 것이 중요
    • 다만, 해당 정책은 토론을 통해 언제든지 변경될 수 있어야 지속적으로 개선된 칸반을 실천 가능
    • WIP 제한도 정책 중 하나이며 각 열의 완료 정의 또한 정책 중 하나
  5. 피드백 루프 실행
    • 칸반 방법론에서 7가지 리뷰 - '전략, 운영, 위험, 서비스 제공, 재보충, 칸반, 제공 계획' 리뷰를 진행
    • 핵심은 주기적인 리뷰 세션을 통해 칸반이 더 나은 방향으로 개선되기 위해 다양한 사항들을 팀원 모두가 살펴보고 수정하고 개선되는 것
  6. 개선과 실험을 통한 발전
    • 칸반은 규범에 얽메이지 않고, 조직의 상황에 적응하며 발전
    • 칸반은 조직의 현 상태에서 시작해 지속적이고 점진적인 개선을 추구
    • 경험을 통해 조직에 맞는 최선을 찾는 것이 중요

장점

  1. 규범이 많지 않아 조직에 도입하기 용이
  2. 연속적인 흐름 관리이기에 데드라인은 없으나 속도에 대한 압박이 존재(흐름 정도를 보기 쉽게 확인 가능)
  3. 시간 리소스 낭비를 방지
  4. 병목 지점을 명확히 파악해 개선이 빠르고 용이
  5. 저품질 상태의 배포가 최소화

단점

  1. 규범이 없어 아노미 상태가 될 수 있음
  2. 압박감이 없어 자발적 실천 문화가 약한 경우 긴장감과 전체적인 생산성이 떨어질 수 있음

스크럼과 칸반의 차이점

  1. 칸반은 역할을 지정하지 않는다.
  2. Iteration이 진행되지 않는다.
    • 기간이 정해진 스프린트를 반복하는 스크럼과 달리 칸반은 기간을 고정하지 않음
    • 배포 가능한 기능이 완성될 때마다 배포하고 새로운 기능 개발이 가능한 시점에서 끌어와 개발을 시작하는 방식으로 진행해 맺고 끊음 없이 지속적 업무 흐름이 유지
  3. 업무 속도 파악의 방법
    • 스크럼은 스프린트 백로그의 양을 조정해 팀 제품의 개발 속도를 측정하지만, 칸반은 Iteration을 사용하지 않기에 WIP 갯수 제한을 지정해 일의 속도 조절 및 파악
  4. 스프린트 백로그 변경 가능 여부
    • 스크럼에서는 스프린트가 시작되면 백로그를 변경하지 않는 것이 원칙이지만 칸반은 언제든 작업을 추가 및 수정 가능
  5. 보드 초기화 여부
    • 스크럼에서는 스프린트 마다 보드가 생성되고, 해당 스프린트를 진행할 사항들을 보드에 넣어두고 그전에 끝내지 못한 사항들은 다시 백로그로 보내는 작업을 하지만 칸반은 지속적으로 개발 보드가 유지됨