티스토리 뷰

이 글은 스크럼 프로세스 프레임워크의 공식 문서을 요약한 자료입니다.


용어

제품 책임자, 개발팀, 스크럼 마스터, 스프린트, time-box, 제품증분 (increment), 제품 백로그, 스프린트 백로그

1. 스크럼이란?

제품을 생산적이고 창의적으로 배포하기 위해 복잡하게 얽힌 적응적 문제들을 다룰 수 있도록 하는 프레임워크
경험적 프로세스 관리론에 기반해서 지식이 우리가 이미 알고 있는 것에 기반한 의사결정에서 온다는 가정하에 예측을 최적화하고 위험요소를 제거하는 반복적이고 점진적 접근방법을 사용한다.

2. 스크럼 팀

스크럼 팀은 3가지 역할로 나뉜다. 제품 책임자 1명, 개발팀 3~8명, 스크럼 마스터 1명으로 각자의 역할을 보면 꽤 명확하다.

2.1 제품 책임자

제품 가치와 결과물을 최상으로 만들 책임을 지닌다. 제품 백로그 관리를 담당하는 유일한 사람으로 관리는 
  • 제품 백로그를 분명히 설명하기
  • 목표와 미션 성공을 최적화하기 위한 항목 우선 순위화
  • 개발팀이 수행하는 작업의 가치를 최적화
  • 백로그가 가시적이고 모두가 이해했는지 확인하고 스프린트에 어떤 작업을 해야 할지 제시하기
  • 개발팀이 백로그 항목에 올바르게 이해하고 있는지 확인하기

2.2 개발팀

완료된 기능을 지속적으로 추가해 출시 가능한 제품을 배포할 수 있는 전문가이다. 스스로 일을 구성하고 관리할 수 있는 권한이 있다.
  • 제품을 만드는데 필요한 모든 기술이 있는 cross-functional 팀
  • 개발자 이외에 다른 직함은 가지지 않음
  • 개발팀에는 하위팀이 없음
  • 각 개발자가 특정 기술에 전문분야가 있다하더라도 제품 책임은 개발팀 전체가 짐
  • 개발팀 크기는 3명이상 9명 미만

2.3 스크럼 마스터

스크럼 팀이 스크럼을 제대로 이해하고 수행하고 있는지에 책임을 지닌다. 
제품 책임자에게
  • 백로그를 효과적으로 관리하기 위한 기술을 찾아줌
  • 백로그 항목이 명확하고 간결할 필요성을 알려줌
  • 최상의 가치를 위해 백로그를 어떻게 조정해야 하는지 책임자가 알고 있는지 확인
  • 애자일을 이해하며 실행
개발팀에게
  • 자기 조직화 팀이 되기 위해 개발팀을 코칭
  • 가치있는 제품을 만들 수 있게 도움
  • 개발 진행에 장애요소를 제거
조직을 위해
  • 스크럼이 잘 자리잡을 수 있게 도움
  • 스크럼 실행을 계획
  • 스크럼 팀의 생산성 향상을 위해 변화를 만들어줌 
 

3. 스프린트

한 달 또는 미만의 time-box 동안 계획한 기능들을 완료하여 사용 가능하고 출시 가능한 제품 증분 (increment)으로 만들어 낸다.


조건
  • 스프린트 목표에 위협을 주는 어떠한 변경도 허용하지 않는다.
  • 제품 품질 목표를 낮추지 않는다
  • 스프린트를 진행하며 개발범위에 대한 이해가 커지면 개발팀은 제품 책임자와 함께 개발 범위를 명확히 하거나 재협상 할 수 있다
취소조건
취소의 권한은 제품책임자가 가지지만 다른 멤버의 영향을 받아 결정 가능하다
보통 목표가 더이상 유효하지 않을 때 (회사 방향 전환 또는 시장이나 기술 상황의 변화)
취소되면 완료된 제품 백로그 아이템들을 검토해 일부가 출시 가능한 상태면 수용한다.
스프린트 취소는 또다른 스프린트를 위한 계획 재편성으로 리소스를 소비하게 한다. 

3.1 스프린트 계획

크럼 팀의 공동작업으로 최대 8시간 타임박스 미팅
스프린트가 한달 미만이면 더 짧게 미팅한다.
스크럼마스터는 팀이 스프린트 계획 미팅을 가졌는지 모든 참여자가 그 목적을 제대로 이해했는지 확인한다.
  • 이 스프린트에서 배포 가능한 제품 증분은?
  • 성공적 배포를 위해 필요한 작업은?
사전 준비
  • 제품 백로그
  • 가장 최근의 제품 증분
  • 가용 인력
  • 과거 생산성 자료
개발할 항목 수는 전적으로 개발팀이 결정
어떻게 구현할지 결정 -> 선택도니 제품 백로그 아이템들과 완료하여 배포하기위한 계획을 합쳐 스프린트 백로그라고 한다.
개발팀은 자기 조직화 팀으로서 스프린트 목표를 달성하기 위해 어떻게 작업할 것이고 어떻게 만들어낼 것인지 제품 책임자와 스크럼마스터에게 설명할 수 있어야 한다.

3.2 스프린트 목표

왜 제품증분을 만들고 있는지 가이드 제공하며 개발될 기능에 대한 약간의 유연성을 제공한다. 진행하기로 한 작업이 개발팀 예상과 다르면 스프린트 백로그를 제품 책임자와 재협상한다.

3.3 일일스크럼

각자 수행한 작업들을 확인한 후 조율해 다음 24시간동안 해야 할 작업들을 계획하는 15분 타임박스 미팅
매일 같은 시간 같은 장소에서
  • 나는 어제 하루 스프린트 목표 달성을 위해 무엇을 했는가?
  • 나는 오늘 하루 스프린트 목표 달성을 위해 무엇을 할 것인가?
  • 나 또는 개발팀이 목표 달성을 하는데 방해요소가 있나?
목표 달성확률을 최적화시키는 과정
스크럼마스터는 일일스크럼 미팅을 보장해야 하지만 미팅은 개발팀이 주도적으로 수행해야 한다. 

3.4 스프린트 리뷰

제품 증분을 검토하고 백로그 수정을 위해 스프린트 끝에 수행한다. 스크럼 팀과 이해관계자들이 이번 스프린트에서 무엇이 완료되었는지 확인한다. 수행중 변경된 백로그를 고려해 제품 가치 최적화를 위해 무엇을 할 지 논의한다. 1개월 기준 4시간 타임박스
  • 핵심 제품 이해관계자 참여
  • 완료/미완료 아이템 설명
  • 무엇이 잘 되었고 무슨 문제가 있었고 어떻게 해결했는지 논의
  • 완료 작업 시연 및 질문/답변
  • 제품 책임자는 현재 남은 제품 백로그 설명하고 (필요하면) 언제쯤 프로젝트가 완료될 지 보고
  • 전체 그룹이 다음에 무엇을 할지 의논
  • 제품 시장이나 잠재적 사용처의 변화, 다음에 해야할 가치있는 일을 검토
  • 제품의 다음 출시 일정, 예산, 잠재적 기능, 시장 검토
리뷰 결과로 백로그 재구성

3.5 스프린트 회고

스크럼 팀이 스스로를 돌아보고 다음 스프린트에 개선할 수 있는 부분을 계획한다. 1개월 기준 3시간 타임박스
  • 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행되었는지 검토
  • 잘 된 것들과 개선여지있는 항목을 알아내 순위화
  • 개선을 실천할 수 있도록 계획 수립
완료의 정의를 조정해 제품 품질을 높일 수 있는 방법들도 계획

4. 스크럼 산출물

4.1 제품 백로그

제품의 가능한 모든 요구사항에 대한 우선 순위화 목록으로 요구사항의 완성본은 아니다. 초기 개발은 팀이 이미 잘 알고 이해하는 요구사항에만 기반하고 유동적으로 변화

다음 릴리즈에 추가로 포함될 모든 피처, 기능, 요구사항, 개선사항, 수정할 버그 리스트
각각에 대한 설명, 우선순위, 예상견적, 가치 등 포함
시장에서 피드백을 받으며 백로그는 더 커지고 완전해진다. 요구사항은 변하므로 백로그는 살아있는 산출물이다.
개발팀은 모든 개발 견적에 대한 책임을 진다. 
전체 개발 목표 도달을 위한 총 작업량은 계산될 수 있다. 제품 책임자가 남아있는 작업량을 추적한다. (번다운 또는 번업)

4.2 스프린트 백로그

스프린트를 위해 선택된 백로그 항목의 집합이며 스프린트 목표 실현을 위한 계획서이다. 개발팀은 스프린트 백로그를 수정하고 추가적인 백로그 항목을 만들 수 있다. 작업이 계획대로 진행되고 목표 달성에 필요한 작업들을 더 많이 알게 되면서 항목 추가 가능
추가된 작업이 수행되거나 완료됨에 따라 남아있는 작업량의 추정치를 업데이트한다. 개발팀만 백로그 변경이 가능하다. 
스프린트 진행중 남은 백로그의 총 작업량을 알 수 있으므로 개발팀은 일일스크럼미팅에서 목표 달성을 위해 남은 작업량 추적을 해야한다. 

4.3 제품 증분

완료된 백로그 항목집합으로 이전 수행된 모든 스프린트에서 생산된 제품 증분의 가치를 포함한다. 스프린트 종료시점에 생산된 새로운 제품 증분은 반드시 완료상태여야 하고 그 말은 제품 출시와 상관없이 사용가능한 상태임을 뜻한다. 

5. 산출물 투명성

5.1 “완료”의 정의

이 정의가 명확해야 스프린트 계획 미팅에서 얼마만큼의 백로그를 선택할지 결정할 수 있다. 


사설

프로젝트를 시작하면서 프로세스나 규칙 등 프로젝트 관리의 필요성을 절실히 느끼고 있다. 이 모든 건 가장 효율적인 시간안에 우리가 만들고자 하는 결과물 즉, 최상의 가치를 지니는 제품을 내고싶기 때문이다. 아무런 프로세스, 규칙 없이 시작했을 때 정말 많은 문제들이 있었는데 스크럼 프레임워크를 보면서 '아 이때 이런 방법을 쓰는게 그 문제를 해결할 수 있을 수 있겠다' 싶은 부분이 여러 군데 있었다. 특히 개발이나 디자인을 하면서 큰 그림을 잊을 수 있는 부분은 스프린트 목표를 확인하며 리마인드 시킬 수 있고, 짧은 기간에 가능한 기능과 우선순위를 정하는 부분은 모든 팀원이 같은 일에 집중할 수 있는 초점을 제공해줄 수 있다. 리뷰와 회고를 철저히 집고 넘어가는 부분도 팀웍과 생산성을 계속해서 높일 수 있는 좋은 방법이라는 생각이 들었다. 

참고문헌

스크럼 가이드, 켄 슈와버, 제프 서더랜드, http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-KR.pdf


댓글