스크럼이 뭐야?

date

Jun 30, 2023

slug

scrum

author

status

Public

애자일 소프트웨어 개발이 뭐야?

목적을 달성하기 위해 모든 관계자가 긴밀하게 협업한다.

한번에 전체를 완성하기보다 조금씩 만들되, 조기에 동작시켜 피드백을 받는다.

사용자나 관계자의 피드백을 바탕으로 결과물과 계획을 지속적으로 보완한다.

기존의 소프트웨어 개발 프로세스가 지나치게 무겁고 변화에 취약한 구조이었다. 이를 해결하기 위해 찾은 가볍고 변화에 유연한 대안들 중 하나이다.

기존	애자일 소프트웨어 개발
모든 요구사항 수집 후 필요한 시간, 비용, 인력 견적을 내는 방식	개발 기간과 인원을 먼저 정하고 중요한 것부터 먼저 만드는 방식

💡

세상에 모든 상황에서 통하는 만병통치약 같은 것은 없다. 각각의 목적과 상황에 좀 더 적합한 방식이 있을 뿐이라고 생각한다. 애자일 소프트웨어 개발 방식의 핵심 가치는 결과물에 대해서 사용자나 관계자의 빠른 피드백을 바탕으로 완성된다. 시장이 원하는 제품을 만드는데 유리하다. 또한 빠른 피드백은 업무 몰입도와 효율을 높일 수 있고 좀 더 즐겁게 협업할 수 있도록 한다. 관련해서 테오님의 ‘즐겁게 협업하는 방법! 애자일과 피드백 그리고 게임’을 읽어볼 것을 추천한다.

스크럼이 뭐야?

애자일 개발 기법의 하나로 다음과 같은 특징을 가지고 있다.

가치와 위험도, 필요성을 기준으로 요구 사항을 정렬한다.

순서대로 구현하며 성과를 극대화한다.

정해진 시간 안에 작업을 완료한다. (타임박스)

현재 상태와 문제점을 명확하게 밝힌다. (투명성)

개발한 제품과 진척에 이상은 없는지 수시로 확인한다. (점검)

더 나은 방법으로 작업 방식을 개선한다. (보완)

개요

역할

프로덕트 오너

제품의 What을 담당한다
제품의 가치를 극대화한다
1개의 제품에 1명의 프로덕트 오너를 둔다
프로덕트 백로그를 관리한다 (우선순위, 완료 여부)
디벨로퍼와 상의하되 간섭하지 않는다
이해관계자와 협업한다
거시적인 관점에서 계획을 세운다
제품의 비전을 명확히 하고 주변과 공유한다
프로덕트 백로그를 최신 상태로 업데이트한다
다른 사람이 프로덕트 백로그를 이해할 수 있도록 풀어서 설명한다
이해관계자와 프로덕트 백로그를 검토하고, 납기나 구현 순서를 상의한다
프로덕트 백로그의 각 항목이 완료되었는지 점검한다

디벨로퍼 (기획자, 디자이너, 개발자를 포괄한다)

제품의 How를 담당한다
제품을 동작하게 만든다
팀원은 3명에서 9명 정도가 적절하다

스크럼 마스터

스크럼이라는 프레임워크가 자리 잡게 돕는다
일하는데 방해되는 요소를 제거한다
봉사하는 마음으로 팀을 지원한다
퍼실리테이터와 코치 역할을 겸비한다
업무 할당이나 진척 관리를 하지 않는다
프로덕트 오너와 개발자에게 애자일 개발과 스크럼에 관해 알려준다
스프린트 플래닝이나 스프린트 회고에서 진행을 돕는다
프로덕트 오너와 개발자의 커뮤니케이션을 돕는다
프로덕트 오너와 개발자의 생산성이 높아지도록 변화를 꾀한다
프로덕트 백로그와 스프린트 백로그를 잘 쓰는 방법을 알려준다
프로덕트 백로그와 스프린트 백로그를 잘 관리하는 방법을 알려준다

활동

프로젝트를 짧은 주기로 나눠서 진행한다
각 주기는 같은 간격이며 1달을 넘기지 않는다
하나의 주기를 스프린트라고 부른다
스크럼의 활동 중 가장 큰 덩어리로 다른 4가지 활동을 포함한다

스프린트 플래닝 (스프린트가 2주일 때 4시간)

개발계획 수립을 위한 착수 회의다
스프린트 기간 동안 할 일을 계획한다
Why: 왜 하는지 생각한다
What: 무엇을 할지 생각한다
How: 어떻게 할지 생각한다

데일리 스크럼 (15분)

목표 달성에 문제가 없는지 진행 상황을 점검한다

스프린트 목표를 달성하기 위해 어제 한 일은 무엇인가?
스프린트 목표를 달성하기 위해 오늘 할 일은 무엇인가?
스프린트 목표를 달성하는데 방해가 되거나 도움이 필요한 일은 무엇인가?

문제를 해결하기보다 문제가 발생한 상황에 집중한다
매일 하되 15분의 타임박스를 지킨다
이야기가 길어지면 회의를 따로 잡는다

스프린트 리뷰 (스프린트가 2주일 때 2시간)

프로덕트 오너가 주관하고 이해관계자가 참석한다
개발자가 만든 결과물을 이해관계자에게 시연한다
피드백을 받고 프로덕트 백로그를 재점검한다
완성된 것과 완성되지 않은 것을 구분한다
전체 진행 상황과 남은 작업을 점검한다

스프린트 회고 (스프린트가 2주일 때 90분)

일하는 방식을 개선한다
사람, 관계, 프로세스, 툴의 관점에서 스프린트를 점검한다
버그를 고치기보다 버그를 유발하는 작업 방식에 집중한다
한 번에 너무 많은 것을 고치려 하지 않는다
잘 된 점과 안 된 점을 정리한다
다음 스프린트에서 실천할 실행 항목을 뽑는다

산출물

프로덕트 백로그

구현하고 싶은 것을 목록으로 만든다
항목은 언제든지 추가, 삭제할 수 있다
우선순위에 맞춰 정렬한다
우선순위가 높은 항목부터 작업량을 추정한다
정기적으로 항목의 순서나 내용, 작업량을 보완한다

프로덕트 백로그에서 작업할 항목을 고른다
실행 가능하게 작업을 구체화한다
작업을 추가하거나 삭제할 수 있다
하루 안에 끝나는 크기로 분할한다

인크리먼트

개발자는 백로그를 작업한 결과로 동작하는 제품을 만든다
이전 스프린트의 결과물에 이번 스프린트의 결과물이 더해진다
결과물은 릴리스 여부와 상관없이 동작하고 점검받을 수 있어야 한다

완료 조건

프로덕트 오너와 개발팀은 어떤 상태를 ‘완료'로 볼 것인지 조건을 정해야 한다