용어 정리
등장인물
스크럼마스터
프로덕트 오너
이해관계자
개발자
제품에 대해 고민하는 사람과 코딩으로 구현하는 사람이 서로 힘을 합쳐서 한 팀으로 프로젝트를 진행.
- 목적을 달성하기 위해 모든 관계자가 긴밀하게 협업한다.
- 한 번에 전체를 완성하기보다 조금씩 만들되, 조기에 동작시켜 피드백을 받는다.
- 사용자나 관계자의 피드백을 바탕으로 결과물과 계획을 지속적으로 보완한다.
이런 개발하는 방식을 애자일 소프트웨어 개발 줄여서 애자일 개발이라고 한다.
스크럼
- 가치와 위험도, 필요성을 기준으로 요구 사항을 정렬한다.
- 순서대로 구현하며 성과를 극대화한다.
- 정해진 시간 안에 작업을 완료한다. (타임박스)
- 현재 상태와 문제점을 명확하게 밝힌다. (투명성)
- 개발할 제품과 진척에 이상은 없는지 수시로 확인한다. (점검)
- 더 나은 방법으로 작업 방식을 개선한다. (보완)
프로덕트 백로그 (product backlog)
- 구현하고 싶은 것을 목록으로 만든다.
- 항목은 언제든지 추가, 삭제할 수 있다.
- 우선순위에 맞춰 정렬한다.
- 우선순위가 높은 항목부터 작업량을 추정한다.
- 정기적으로 항목의 순서나 내용, 작업량을 보완한다.
프로덕트 백로그를 작성할 때 반드시 지켜야 할 규칙은 없다. 보통은 사용자 스토리 (User Story)라는 형식으로 쓰는게 일반적이다.
프로덕트 오너
프로덕트 백로그를 관리하는 사람을 프로덕트 오너(product owner) 혹은 제품 책임자라고 한다.
역할
- 제품의 What을 담당한다.
- 제품의 가치를 극대화한다.
- 1개의 제품에 1명의 프로덕트 오너를 둔다.
- 프로덕트 백로그를 관리한다(우선순위, 완료 여부)
- 개발자와 상의하되 간섭하지 않는다.
- 이해관계자와 협업한다.
프로덕트 백로그를 관리하는 것 말고도 다음과 같은 일을 해야 한다.
- 거시적인 관점에서 계획을 세운다.
- 제품의 비전을 만드는 데 소요되는 예산을 관리한다.
- 프로덕트 백로그를 최신 상태로 업데이트한다.
- 다른 사람이 프로덕트 백로그를 이해할 수 있도록 풀어서 설명한다.
- 이해관계자와 프로덕트 백로그를 검토하고, 납기나 구현 순서를 상의한다.
- 프로덕트 백로그의 각 항목이 완료되었는지 점검한다.
프로덕트 오너가 결정한 내용은 다른 사람이 함부로 바꿀 수 없습니다. 막강한 권한을 갖는 만큼 결과에 대한 책임도 커진다.
개발자
- 제품의 How를 담당한다.
- 제품을 동작하게 만든다.
- 팀원은 3명에서 9명 정도가 적절하다.
- 팀원의 역량이 곧 제품 개발 능력이다.
- 특수 목적의 보조 팀을 두지 않는다.
개발자는 보통 3명에서 9명이 함께 협업한다. 3명보다 적으면 팀원 간의 시너지가 발휘되기 어렵거나, 개인의 역량에 의존하게 되므로 전체적인 퍼포먼스가 떨어질 수 있다. 9명보다 많으면 커뮤니케이션 비용이 늘어나면서 개발하는 효율이 떨어질 수 있다.
이때는 상황에 맞게 작은 그룹으로 나누어 전체적인 복잡도를 줄이는 게 좋다.
개발팀 내에는 직무나 역량 수준에 따른 별도의 직함이나 호칭을 사용하지 않습니다. 개발팀 내의 의사결정은 개발자 상호 간의 합의가 있어야 하고, 작업 방식에 대해서도 외부 간섭을 받지 않습니다. 스크럼 가이드에선 이런 방식을 자기관리화(Self-managing)라고 합니다.
스플린트
작업 기간을 짧은 간격으로 나눈다.
- 프로젝트를 짧은 주기로 나눠서 진행한다.
- 각 주기는 같은 간격이며 1달을 넘기지 않는다.
- 하나의 주기를 스플린트라고 부른다.
- 스크럼 활동 중 가장 큰 덩어리로 다른 4가지 활동을 포함한다.
스프린트 기간은 제품이나 팀의 규모, 팀원의 숙련도, 비즈니스 상황 등을 고려해서 결정한다. 길면 1달, 짧으면 1주로 주 단위로 끊는 것이 보통이다.
스프린트 플래닝, 스프린트 백로그
스프린트에 할 일을 계획한다.
스프린트를 왜 하는지(why), 무엇을 할지(what), 어떻게 할지(how) 생각하며 계획은 세운다. 스프린트 플래닝이라 한다. 스프린트 플래닝에 필요한 시간은 스프린트가 1달일 때 8시간 정도가 적당하다.
- 개발계획 수립을 위한 착수 회의다.
- 스프린트 기간 동안 할 일을 계획한다.
- Why: 왜 하는지 생각한다.
- What: 무엇을 할지 생각한다.
- How: 어떻게 할지 생각한다.
Why
프로덕트 오너는 이번 스프린트 결과가 이해간계자에게 어떤 가치를 주는지, 얼마나 중요한지를 생각하고, 이번 스프린트를 반드시 해야 하는 합당한 이유를 찾습니다.
What
스프린트에서 무엇을 할지 생각하는 것, 프로덕트 오너는 스프린트 목표를 달성하기 위해 해야 할 일감을 고른다. 보통을 프로덕트 백로그에 먼저 나온 순서로 집어오는데 작업의 크기나 개발자의 경험치, 할애할 수 있는 시간에 따라 일감의 개수가 달라집니다.
How
스프린트 목표를 어떻게 달성할지 생각합니다. 선택한 일감을 어떻게 작업할지 구체적인 작업 방법을 고민하고, 필요하다면 일감을 추가하거나 더 상세하게 구체화해도 됩니다.
스프린트 백로그
- 프로덕트 백로그에서 작업할 항목을 고른다
- 실행 가능하게 작업을 구체화한다
- 작업을 추가하거나 삭제할 수 있다
- 하루 안에 끝나는 크기로 분할한다
인크리먼트
- 개발자는 백로그를 작업한 결과로 동작하는 제품을 만든다.
- 이전 스프린트의 결과물에 이번 스프린트의 결과물이 더해진다.
- 결과물은 릴리스 여부와 상관없이 동작하고 점검을 받을 수 있어야 한다.
프로덕트 오너와 개발팀은 어떤 상태를 ‘완료’로 볼 것인지 조건을 정해야 한다. 이것을 완료 조건(definition of done)이라 합니다.
완료 조건의 예시
- 위키 문서에 제품 명세서를 등록했다.
- 위키 문서에 관련 자료를 등록했다.
- 리포지터리에 소스 코드를 등록했다.
- 모든 public 메서드의 테스트 코드가 구현되었다.
- 모든 테스트가 성공했다.
- 소스 코드를 빌드하고 시연할 수 있다.
데일리 스크럼
진행사항을 매일 점검해야 하는데, 이런 활동을 데일리 스크럼(daily scrum)이라고 합니다.
- 목표 달성에 문제가 없는지 진행 상황을 점검한다.
- 문제를 해결하기보다 문제가 발생한 상황에 집중한다.
- 매일 하되 15분의 타임박스를 지킨다.
- 이야기가 길어지면 회의를 따로 잡는다.
특별한 규칙은 없지만 인원 수와 상관없이 15분의 타임박스로 진행하고 시간을 연장하지 않는 게 원칙입니다.
참여자는 다음 질문에 답하면서 상황을 공유한다.
- 스프린트 목표를 달성하기 위해 어제 한 일은 무엇인가?
- 스프린트 목표를 달성하기 위해 오늘 할 일은 무엇인가?
- 스프린트 목표를 달성하는 데 방해가 되거나 도움이 필요한 일은 무엇인가?
15분 타임 박스를 넘지 않는 것이 중요하다. 데일리 스크럼은 문제를 해결하기 위한 모임이 아니므로, 상황 공유가 끝났다면 데일리 스크럼을 마쳐야 한다.
스프린트 레트로스펙티브 (회고)
했던 일을 돌아보고 더 좋게 보완한다.
스프린트 막바지엔 스프린트 레트로스펙티브 (회고) 한다.
일하면서 어려움은 없었는지, 더 나은 성과를 내기 위해 개선할 점은 없었는지 되돌아보고, 다음에 시도할만한 개선 사항 몇 가지 정리해본다.
- 일하는 방식을 개선한다.
- 사람, 관계. 프로세스, 툴의 관점에서 스프린트를 점검한다.
- 버그를 고치기보다 버그를 유발하는 작업 방식에 집중한다.
- 한 번에 너무 많은 것을 고치려 하지 않는다.
- 잘 된 점과 안 된 점을 정리한다.
- 다음 스프린트에서 실천할 실행 항목을 뽑는다.
회고하기 적당한 시간은 스프린트가 1달일 때 3시간 정도로, 스프린트가 짧아지면 회고 시간도 함께 줄여줍니다.
스크럼 마스터
일이 되게 만드는 숨은 조력자
더 좋은 제품이 나올 수 있도록 프로덕트 오너와 개발자를 돕는 이가 있는데요. 바로 스크럼 마스터(scrum master), 줄여서 SM이라고 한다.
- 스크럼이라는 프레임워크가 자리 잡게 돕는다.
- 일하는 데 방해되는 요소를 제거한다.
- 봉사하는 마음으로 팀을 지원한다.
- 퍼실리테이터와 코치 역할을 겸비한다.
- 업무 할당이나 진척 관리를 하지 않는다.
스크럼을 도입하는 초기 단계에서는 프로덕트 오너나 개발자에게 스크럼의 개요와 협업하는 방식을 알려주고, 스크럼의 핵심 활동(scrum event)을 실천하는 단계에서는 진행자 역할로 소통을 돕기도 한다.
- 프로덕트 오너와 개발자에게 애자일 개발과 스크럼에 관해 알려준다.
- 스프린트 플래닝이나 스프린트 회고에서 진행을 돕는다.
- 프로덕트 오너와 개발자의 커뮤니케이션을 돕는다.
- 프로덕트 오너와 개발자의 생산성이 높아지도록 변화를 꾀한다.
- 프로덕트 백로그와 스프린트 백로그를 잘 쓰는 방법을 알려준다.
- 프로덕트 백로그와 스프린트 백로그를 잘 관리하는 방법을 알려준다.
스크럼 5가지 가치 (Scrum Values)
- 확약(commitment): 목표를 달성하기 위해 전력을 다할 것을 굳게 약속한다.
- 전념(focus): 목표를 달성하기 위해 각자가 맡은 일에 집중한다.
- 공개(openness): 모든 상황과 문제를 투명하게 공유한다.
- 존중(respect): 팀원의 역량과 존재 가치를 존중한다.
- 용기(courage): 올은 일을 한다는 용기로 어려움을 극복한다.
 출처 : https://www.yes24.com/Product/Goods/115632480
출근했더니 스크럼 마스터가 된 건에 관하여 - YES24
스크럼을 만화와 해설로 배울 수 있는 애자일 소프트웨어 개발 방법 입문서이다. 스크럼은 IT 회사에서 소프트웨어를 개발하는 방법 중 하나이다. 경험을 기반으로 변화에 능동적으로 대처하는 방식이다. 스타트업에서 대기업까지 활용법은 조금씩 다르지만 기본적인 골격은…