Notice
Recent Posts
«   2024/07   »
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
관리 메뉴

Sutella의 자기 발전소:)

[정리] About 스크럼: 스크럼 프레임워크와 스프린트 본문

코드스테이츠| PMB 11/Review

[정리] About 스크럼: 스크럼 프레임워크와 스프린트

Sutella 2022. 5. 3. 20:01
728x90
📢 스크럼 프레임워크
  • 스크럼: 팀이 중심이 되어, 개발의 효율성을 높인다는 의미의 용어
    • Self-organizing: 팀원 스스로 스크럼 팀 구성
    • Cross-functional: 개발 작업에 관한 모든 것을 스스로 해결
  • 철학: 가치 중심과 경험 중심을 바탕으로 신뢰를 만들어냄
    • Values(가치 중심), Commitment (헌신), Focus (집중), Respect (존중), Courage (용기), Openness (개방성), Trust (믿음), Empiricism (경험 중심), Transparency (투명성), Inspection (점검), Adaptation (적응)
  • 스프린트: 프젝을 빠른 시간 내에 개발하고 해결하는 단기간 프로덕트 방법론
  • 원리
    1. 우리는 고객을 잘 모른다.
    2. 그렇기 때문에 빠르게, 그리고 자주 고객에게 릴리스하고 새롭게 발견해야 한다.
    3. 여러 번의 가설 검증 단계를 거치고
    4. 우리가 진짜 필요한 것이 무엇인지, 피해야 할 것이 무엇인지 발견한다.
    5. 이해관계자들에게 더 빠르게, 더 잘 그들이 원하는 것을 전달

 

출처: 워킹어스

STEP
  1. 스프린트 계획 회의: 유저 스토리를 기반으로 프로덕트 백로그 작성
    1. 유저 스토리는 사용자나 개발자 등 이해관계자가 모두 이해할 수 있도록 작성되어야 함
  2. 스프린트 백로그: 프로덕트 백로그에서 결정된 우선순위를 기반으로, 스프린트 기간 동안 해야 할 일에 대해 만든 리스트
    • 스프린트 기간: 2주~1달
    • 스프린트 목표를 구현가능하도록 각각의 요구사항을 task 단위로 나누어 개발자들이 나눠서 작업 수행
      • 벽 크기의 업무 보드 형식에 스프린트 백로그 작성 → 스크럼 보드
      • 스크럼 보드와 칸반 보드와의 차이점
        • 칸반 보드: to do
        • 스크럼 보드: 유저 스토리 + task 구분(Not Started / In progress / Done)
  3. 데일리 스크럼 미팅: 개발원들이 늘어지는 것을 방지하기 위해. 15-20분 정도.
    • 번다운 차트: 남은 스프린트 백로그의 작업량을 나타내는 그래프
  4. ⇒ 프로젝트 후반부에 갑자기 발생할 수 있는 문제 방지 가능
  5. 스프린트 리뷰: 스프린트 기간 동안 만든 것을 이해관계자에게 보여주는 단계. 1시간 이내로 진행. 준비 시간은 30분 이내.
  6. 스프린트 회고: 스프린트 리뷰는 제품 기능에 대한 회고. 스프린트 회고는 전반적인 스프린트 프로젝트에 대한 회고. 스크럼 마스터(/PO/PM)는 중재자 역할

 

📢 제품 개발 방법론 선정의 기준
  • 애자일 vs. 워터폴, 어떤 것을 선택해야 할까
    • Scope (업무 범위)
    • Schedule(시간)
    • Resource(자원)
    을 고려하여 방법론 선택

 

  • Scope의 유동성
    • Scope가 잘 설정되어 있고, 중간에 변경한다면 프로젝트에 차질이 있을 때 → Waterfall ( ↔ Agile)
      • 특히 SW에 애자일이 적합한 이유가 이 때문! (HW는 한 번 만들면 바꾸기 어렵지만, SW는 비교적 수정이 용이함)
    • PM의 역할
      • 워터폴: 요구 사항 파악 및 초기 계획 구성 (중간에 바뀌지 않도록), 모든 유형의 자원을 시간 내에 배치하여 정상 궤도로 작업할 수 있도록 계획. min Input에 의의
      • 애자일: Scope 잘게 쪼개기 (핵심 기능 위주로 빠르게 개발할 수 있도록 쪼개기)

 

📢 칸반 vs. 스크럼
  • 공통 목표: 프로세스 흐름에 의존하고 낭비를 줄이는 것
  • 칸반: 팀과 조직의 작업 시각화, 업무의 병목 현상과 리소스 낭비 처리 도움. 우선순위와 크기가 다른 요청들의 작업을 시각화하고 WIP limit을 통해 효율성 추구
    • 목표: 지속적인 흐름 달성 → 시간 제한 X, 지속시간의 효율성을 기반
    • 업무 진행에 대한 필수 요구사항 X, 중도 변경 가능. 새 항목 추가 가능.
    • 회의 필수 X
  • 스크럼: 잘 정의된 목표를 향한 팀워크, 책임이 반복적인 진행을 가중화. 협업/SW/팀 자체 관리/신속 대응을 위한 유연성 강조.
    • 목표: 시간에 기반을 둔 time pass frame work. 스프린트라는 기간 고정
    • 계획에 대한 의존성이 높음. 모든 작업을 작은 유저스토리로 나눔.
    • 회의 의무적.
728x90