스크럼(Scrum) 요약

Wiki와 MSDN 그리고 스크럼과 XP(헨릭 크나버그) 를 요약한 내용.
출처 : http://wildpup.cafe24.com/archives/533?ckattempt=1

1. 스크럼(Scrum)이란
    스크럼은 프로젝트를 위한 상호, 점진적 개발방법론이다. 스크럼은 소프트웨어 개발 프로젝트를 위하여 고안이 되었지만 소프트웨어 유지/보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.

 2. 스크럼의 간략한 설명 

가. 스크럼의 특성

스크럼은 특정 언어나 방법론에 의존적이지 않으며, 다음과 같은 특성을 가지고 있다.

• 솔루션에 포함될 기능 / 개선점에 대한 우선 순위를 부여
• 개발 주기를 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공
• 개발 주기마다 적용 할 기능이나 개선에 대한 목록 제공
• 날마다 15분 정도의 회의를 가짐
• 항상 팀 단위로 생각하고 행동
• 원활한 의사소통을 위하여, 구분 없는 열린 공간 유지

 

나. 스크럼의 기반

스크럼은 “지식창조기업”이라는 이름으로 소개된 일본의 조직론에 이론적 기반을 두고 있는데 지식 창조기업에서는 가정용 제빵기나 저가 복사기 등을 획기으로 개발한 일본의 조직론을 소개하고 있다.

이 지식 창조 프로세스를 촉진시키는 5가지 요소가 있는데 이는 다음과 같다.

• 조직의 의도 : 지식 창조의 목표나 팀을 지탱하는 축
• 자율성 : 팀의 멤버에게 자유로운 행동을 인정하는 열린 환경
• 역동적이고 창조적인 카오스 : 조직 내 외부 간의 역동적인 상호작용을 통한 지식창조 환경
• 잉여성 : 의도적으로 조직에 넘쳐나는 여분의 정보
• 최소 유효 다양성 : 복잡하고 다양한 환경에 기민하게 대응하기 위해서 조직 구성원이 가져야 하는 다양성

 

다. 스크럼의 진행

스크럼에서는 팀에서 정의한 주기로 실제 동작하는 제품을 만들면서 개발을 진행하는데, 아래는 스크럼 진행시 나타나는 중요 요소이다.

• 제품 백로그(Product Backlog) : 개발할 제품에 대한 요구 사항 목록
• 스프린트(Sprint) : 팀에서 정한 반복적인 개발 주기
• 스프린트 계획 회의(Sprint Planning Meeting) : 스프린트 목표와 스프린트 백로그를 계획하는 회의
• 스프린트 백로그(Sprint Backlog) : 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
• 일일 스크럼 회의(Daily Scrum Meeting) : 날마다 진행되는 진척 상황 미팅
• 실행 가능한 제품(Shippable Product) 개발 : 스프린트 결과로써 나오는 실행 가능한 제품

위의 요소들을 아래와 같은 순서에 따라 사용하여 스크럼을 진행 시킨다.

1) 제품에서 요구하는 기능과 우선순위를 제품 백로그로 지정

2) 제품 백로그로부터 스프린트를 통해 구현되어야 할 목표를 선택

3) 스프린트 목표를 보다 상세한 작업으로 모듈화한 스프린트 백로그를 작성한 뒤 작업 할당

4) 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 팀원이 참여하는 일일 회의 진행

5) 매일 스프린트가 종료할 때마다, 스크럼 리뷰 미팅을 가지고, 개발된 제품을 평가
6) 이후의 스프린트에 대비하여 제품 백로그의 내용과 우선순위 재검토

 

3. 제품 백로그 만들기

제품 백로그는 스크럼의 핵심이다. 제품 백로그는 기본적으로 우선 순위가 매겨진 요구사항의 목록으로 요구사항은 스토리 혹은 백로그 아이템이라 불려 진다.

각 스토리는 다음과 같은 항목으로 구성된다.

• ID : 스토리의 고유 실별자로 스토리의 이름이 바뀌어도 스토리를 추적할 수 있게 한다.
• 이름 : 스토리를 설명하는 짧은 이름으로 예를 들어 “개인 트랜잭션 이력 보기” 등이 될 수 있다.
• 중요도 : 제품 책임자가 생각하는 스토리의 중요도이며, 10, 150과 같이 점수로 나타낸다. 점수가 클수록 더 중요하다.
• 최초 추정치 : 최초 추정치는 스토리 점수와 동의어로 사용되며 이상적인 man day 를 의미한다. 일반적으로 인원 x day = 스토리 점수로 계산이 되며 이 계산의 day는 팀원이 아무런 방해 없이 충분한 환경을 제공 받으면서 데모도 가능하고 테스트도 마쳐 출시할 수 있을만한 제품을 만들어 내는데 며칠이 필요한가를 의미 한다. 추정치는 절대적 보다는 상대적인 추정치가 중요하며 절대적인 추정치는 “2점짜리 스토리는 한명이 2일 만에 끝내야 한다.”를 의미하며 상대적인 추정치는” 2점짜리 스토리는 4점짜리 스토리의 절반의 노력이 필요하다.”를 의미 한다.
• 데모방법 : 상위 수준의 작동 묘사를 의미하며 이는 간단한 테스트 명세이기도 하다. “A를 하고 나서 B를 하면 C가 되어야 한다.” 등으로 묘사될 수 있다.
• 참고 : 위의 나열한 정보 이외의 정보를 간단하게 기록 한다.

아래는 제품 백로그의 예이다.

제품 백로그의 예

보통 제품 백로그 문서는 스프레드시트 등으로 관리하고 공유 기능을 이용하여 팀원 전체가 수정, 참고 가능하도록 한다. Google 스프레드시트를 이용하면 더 편리하게 공유할 수 있다.

문제를 해결하는 방법은 팀이 더 잘 알고 있다. 제품의 책임자는 비지니스 목표에 더 집중해야 한다. 예를 들어 특정 개발 시스템에서 사용하는 데이터베이스 설계 방법 등의 요소가 문제 해결 방법 등에 해당 된다. 제품의 책임자는 이러한 문제에 깊이 관여할 필요가 없다.

스프린트를 계획하기 전에 백로그를 깔끔하게 정리해야 한다. 이것은 모든 스토리가 완벽하게 정의되어있어야 한다는 것을 의미 한다. 그렇다고 모든 추정치가 정확해야 한다는 것은 아니다. 우선 순위의 변동이 없어야 한다는 것도 아니다.

그러나, 다음의 내용들에 대해서는 확실하게 정의가 되어 있어야 한다.

• 제품의 백로그는 반드시 존재해야 한다.
• 제품 백로그 하나에는 책임자가 반드시 존재해야 한다.
• 어느 정도 중요도가 있는 아이템에 중요도를 부여할 때에는 서로 다른 값을 가지고 있어야 한다.
• 중요도의 값은 아이템을 정렬하는 용도로만 사용되어야 한다. 이는 A의 중요도가 20이고 B의 중요도가 100이라고 해서 B가 A보다 5배 중요하다는 의미인 것은 아니라는 것이다.

제품 책임자는 각 스토리를 완벽하게 이해하고 있어야 한다. 구현하는데 무엇이 필요한지는 알 필요가 없지만 왜 그 스토리가 그곳에 있는지는 알고 있어야 한다.

제품 책임자 외에 다른 사람이 제품 백로그에 스토리를 추가할 수는 있으나 중요도를 부여할 수는 없다. 이것은 제품 책임자의 고유 권한이다. 개발 시간 추정도 할 수 없다. 이는 팀의 권한이다.

 

4. 스프린트 계획 수립

가. 스프린트 계획회의의 산출물

스프린트 계획 수립 회의는 스크럼에서 가장 중요한 이벤트이다. 잘못 진행된 스프린트 계획 회의는 스프린트 전체를 망쳐 놓을 수 있다.

스프린트 계획회의에서는 다음과 같은 구체적인 산출물이 나와야 한다.

• 하나의 스프린트 목표
• 팀원의 목록
• 스프린트 백로그 (해당 스프린트에 포함된 스토리 목록)
• 확정된 스프린트 데모 날짜 (시연 가능한 제품이 나오는 최종 시간)
• 확정된 일일 스크럼을 위한 시간과 장소

스프린트 계획회의에 제품의 책임자는 반드시 참여를 해야 한다. 이는 모든 스토리가 범위, 추정치, 중요도를 가지고 있으며 이 요소들은 제품 책임자에 의해 결정되는 사항이기 때문이다.

 

나. 스프린트의 길이와 품질의 관계

스프린트 계획 수립 중 품질은 협상의 대상이 될 수 없다.

품질은 내적 품질과 외적 품질으로 구분될 수 있는데, 외적 품질은 시스템을 사용하는 사람이 느낄 수 있는 품질이다. 느리고 직관적이지 않은 사용자 인터페이스 등은 낮은 외적 품질의 예라고할 수 있다. 내적 품질은 사용자에게 직접 드러나지는 않지만 시스템을 구성하는 데 지대한 영향을 미칠 수 있는 것들을 지칭한다. 설계, 테스트, 코드 등이 이와 관련 된다.

일반적으로 내적 품질이 높은 시스템이라고 하더라고 외적 품질이 낮을 수 있지만 그와 반대되는 경우는 거의 있을 수 없다. 이는 우선은 다소 불편하면서 느린 사용자 인터페이스라도 시스템을 출시한 다음 나중에 깔끔한 버전을 출시하는 것이 경우에 따라서 비즈니스 관점에서 보았을 때 전혀 문제가 없는 결정일 수 있다. 이와 같은 트레이드오프를 제품 책임자가 결정 할 수 있다. 반면 내적 품질은 논의의 대상이 될 수 없다. 어떠한 상황에서도 시스템의 품질을 유지하는 것이야 말로 팀 전체가 책임져야할 사항이다.

내적 품질과 외적 품질의 문제의 구분은 다음과 같이 할 수 있다. 예를 들어 제품 책임자가 다음과 같이 이야기를 한다고 가정하자.

현재 스토리 점수를 6점이라 추정하고 있습니다.  하지만 제 생각에는 여러분이 마음만 먹으면 분명히 절반의 시간을 쓰면서 임시방편이라도 해결책을 내놓을 수 있을 거라 생각 합니다.

만약 제품 책임자가 스토리의 범위를 줄이는 비용을 치룰 의사가 없으면서 스토리의 추정치를 낮춰 잡으라고 요구한다면 이는 제품 책임자가 내적 품질을 변수로 사용할 생각이라고 판단할 수 있다.

내적 품질을 희생하는 것은 언제나 최악의 발상이다. 보통 이런 경우에는 범위 쪽으로 논의를 전개시킬 필요가 있다. 해당 기능을 일찍 마무리하는 것이 중요하다면 좀 더 빠르게 구현할 수 있도록 범위를 줄이는 것이다. 오류 처리를 단순화 하고 고급 오류 처리는 별개의 스토리를 만들어 나중에 구현할 수 있도록 하는 형태를 의미한다. 혹은 해당 스토리에 집중할 수 있도록 다른 스토리의 우선순위를 낮추는 행위도 가능하다.

 

다. 스트린트 계획회의 시간 산정

스프린트 계획회의에서 사실 가장 어려운 부분은 회의 시간의 산정이다.

스크럼에서 모든 것들은 타임박스를 가진다. 타임박스로 제한된 스프린트 계획회의가 끝나가고 있는데 스프린트 목표와 백로그가 완성될 기미가 보이지 않는다면 시간에 맞춰 끊을지, 시간을 연장해야할지, 다음날 회의를 계속해야할지를 결정해야 한다. 이런 일은 보통 신규 팀에서 반복적으로 발생되는데 회의가 늘어져 해당 타임박스 내에 적절한 결과가 도출되지 않는다면 시간 연장이 되어도 마찬가지일 경우가 많다. 책임자는 타임박스의 시간을 현실적으로 정하는 법을 익히고 그 타임박스를 고수해야 한다. 이것은 회의의 길이와 스프린트의 길이에 모두 해당 된다.

어떠한 형태가 되었건 스프린트 계획회의 시간표를 사전에 짜 놓으면 타임박스를 지키지 못하게되는 리스크를 최소화 할 수 있다.
시간표의 예시는 다음과 같다.

시간표의 예시

 라. 스프린트 길이 결정

스프린트 계획회의 결과물 중 하나로 스프린트 데모 날짜가 결정되는데, 그러기 위해서는 스프린트의 길이가 결정되어야 한다.

스프린트가 짧은 경우 그리고 길 경우 각기 다른 장단점을 가지고 있는데, 짧은 스프린트는 회사를 ‘기민하게’, 다시 말하면 자주 방향을 수정할 수 있게 한다. 짧은 스프린트는 짧은 피드백 주기, 더 잦은 출시, 더 잦은 고객 피드백,잘못된 방향에 따른 시간 낭비 감소, 학습 및 개선 가속화 등을 가져온다.

반면 긴 스프린트는 팀이 추진력이 얻기 위해 충분한 시간을 갖게 되고, 발생하는 문제들을 해결하면서 스프린트 목표를 달성할 수 있는 충분한 여력을 가지게 되며 스프린트 계획회의나 데모에 대한 부담이 줄어들게 된다.

일반적으로 제품 책임자는 짧은 스프린트를 선호하고 개발자는 긴 스프린트를 선호한다. 따라서 스프린트의 길이는 잘 절충이 되어야 한다. 보통 3주에서 30일의 스프린트를 실시하는 회사들이 많다. 이 스프린트의 주기를 일정하게 유지하면 이 주기는 팀원 모두가 편안하게 적응하는 심장 박동같이 되며 출시 날짜를 두고 논쟁을 벌이는 일도 없어지게 된다.

 

마. 스프린트에 구현할 스토리 선택

스프린트 계획회의에 주요한 활동 중 하나는 해당 스프린트에 어떤 스토리를 포함시키는지 결정하는 것 이다. 이는 제품 백로그에서 어떤 스토리를 복사해서 스프린트 백로그에 붙여 넣을 것인지를 결정하는 것이다.

스토리 선택

위의 그림을 보면 각각의 네모 상자는 중요도에 따라서 정렬된 스토리이다. 가장 중요한 스토리가 목록의 맨 위에 있다. 각 네모 상자의 크기는 스토리의 크기, 즉 스토리 점수로 표현되는 시간 추정치이다. 괄호 친 부분의 길이는 다음 스프린트에서 완료할 수 있을 것으로 생각되는 스토리 점수를 의미 한다.

그림에서 오른쪽에 있는 스프린트 백로그는 제품 백로그에서 스토리를 꺼내어 그대로 옮겨 놓은 것이다. 이것은 팀이 이번 스프린트에서 완료하기로 결정한 스토리의 목록을 의미 한다. 해당 스프린트에 얼마나 많은 스토리를 포함할지는 팀이 결정하는 것이다.

팀이 스프린트에 포함시킬 스토리를 결정하는 방법에는 직감을 이용하는 방법과 속도를 계산하는 방법이 있다.

직감으로 추정하는 방법은 제품 책임자가 해당 담당자의 직감에 의한 결정사항을 검토하여 스토리를 결정하는 것이다.

속도를 계산하는 방법은 해당 스프린트에서 해당 담당자 mand day를 기반으로 추정속도를 계산하는 것이다.

맨-데이 x 집중도 = 추정속도

집중도는 팀이 얼마나 집중할 수 있는지를 추정한 값이다. 집중도가 낮다는 것은 팀에 방해(본연의 업무를 제외한 나머지 업무)가 많을 것으로 예상되거나, 시간 추정치를 낙관적으로 예측 했다는 것을 의미 한다. 합리적인 집중도를 결정하는 쵯헌의 방법은 가장 최근의 스프린트를 보거나 지난 몇 번의 스프린트의 평균치를 보는 것이다.

최근 스프린트의 집중도 = 실제속도 / 가능한 맨-데이

실제속도는 지난 스프린트에서 완료된 스토리의 초기 추정치를 모두 더한 값이다. 만약 세 명으로 구성된 팀이 최근 스프린트에서 3주간 총 45 맨-데이를 일해서 18 스토리 점수를 완료했다고 했을 때 다음 스프린트를 위한 추정 속도를 계산하려고 한다면

40% = 18 스토리 점수 / 45 맨-데이

일 때

50 맨-데이 ㅌ 40% = 20 스토리 점수

라는 결과를 도출할 수 있다. 즉, 팀은 다음 스프린트에 20점이 될 때가지 스토리들을 더해야 한다는 의미가 될 수 있다.

. 스토리의 크기를 추저하고 우선 순위를 변경하고, 명확하게 만들고, 더 작게 나누는 것이다.

이 때 사용하는 괜찮은 기법들 중에 하나로 인덱스 카드를 만들어 벽에 붙이는 것이다.

인덱스 카드

인덱스 카드

위와 같이 스토리 인덱스 카드로 만든다. 인덱스 카드를 이용하는 방법은 사람들이 서서 걸어 다니면서 회의를 진행하므로 회의에 집중할 수 있게 한다. 또한 개개인 모두가 적극적으로 참여하고 있다고 느낄 수 있으며 여러 스토리를 동시에 수정할 수 있고 우선순위를 조정하는 것이 매우 쉽다.

스프린트 계획회의가 끝나면 책임자는 인덱스 카드에 작업한 내용을 스프레드시트로 옮긴다. 인덱스 카드에는 중요도가 있는데 이렇게 함으로써 중요도에 따라 인덱스 카드를 정렬하기가 수월해 진다. 일단 카드를 벽에 붙이고 나면 기존의 중요도는 무시되고 벽에 붙어 있는 실제 정렬 순서가 중요도가 된다.

시간 추정은 스토리를 작업 단위로 나누고 나면 더 쉬워진다. 그리고 더 정확해 진다. 작업으로 나누는 것도 인덱스 카드를 가지고 하는 것이 효과적이다. 작업 단위로 나뉘고 난 후의 벽의 모양은 다음과 같이 된다. 사실 작업을 나누는 것은 스프레드 시트에 적용하지 않는 경우가 많은데 다음의 이유로 그렇다.

• 작업 나누기는 대개 일시적인 경향이 강하다. 예를 들어, 분할된 작업들은 스프린트 진행되는 중에 빈번히 수정되는 이를 일일이 제품 백로그 스프레드시트에 반영하여 최신 상태를 유지하기란 너무 번거로운 일일 수 있다.
• 책임자가 이 정도 수준의 세부적인 사항에까지 관여할 필요는 없다.

아래는 실제의 모습이다.

실제 모습

 

바. 스토리를 작은 스토리로 분해

스토리는 너무 작거나 크면 안된다. 만약 0.5점짜리 스토리가 많다면 십중팔구 팀이 미시적 관리를 받고 있다는 징조이며, 반면에 40점 짜리 스토리는 결국 일부만 완료될 위험이 크다. 이렇게 되면 회사에 가치를 전혀 제공하지 못하고 관리할 대상만 늘어나게 된다. 더욱이 추정 속도가 70이고 최고 상위 스토리 2개의 점수가 각각 40이라면 계획을 세우기가 정말 힘들어 진다. 이 때는 하나만 선택하여 일을 적게 하거나 둘 다 택하여 일을 과하게 하는 것 중 하나를 선택해야만 하는데 다른 방안으로 큰 스토리를 여러 개의 작은 스토리로 쪼개는 방법이 있다. 단 작게 나눈 스토리가 여전히 비즈니스 가치를 제공할 수 있는 출시 가능한 단위인지 확인해야 한다.

예를 들어 사용자 관리라는 큰 스토리는 사용자 추가 / 수정과 사용자 검색이라는 스토리로 나뉘어질 수 있다.

 

사. 기술 스토리

기술 스토리라는 복잡한 문제가 있다. 책임자에게 직접적인 가치를 제공하는 것도 아니지만 전달할 수 있는 성질의 것도 아니면서 다른 특정 스토리에 직접적으로 관여되지 않으면서도 완료해야하는 것이다.

예를 들어 빌드 서버 구축, 시스템 설계 개요 작성, 데이터베이스 튜닝, 버그 추적 시스템 구축 등이 있다고 가정할 때 이 스토리들이 일반적인 개념에 맞는 것이 아니라는 점이다.

누가 이것들의 우선순위를 결정하는지 책임자가 이것들에 관여해야 하는지 명확하지 않다. 이럴 경우에는 다음과 같은 방법이 있다.

• 기술 스토리를 피하려고 노력한다. 기술 스토리가 있다면 측정할 수 있는 비즈니스 가치가 드러나는 일반적인 스토리로 바꿀 수 있는 방법을 찾기 위해 노력 한다.  그렇게 함으로써 제품 책임자가 절충안 중에서 올바른 결정을 할 수 있는 더 나은 기회를 가질 수 있다.
• 기술 스토리를 일반 스토리로 바꿀 수 없는 경우에는 다른 스토리의 하위 작업으로 처리할 수 없는지 확인 한다. 예를 들어 고객 데이터베이스 수정은 사용자 편집 관련 작업으로 나타낼 수 있을 것이다.
• 앞의 두 방법이 모두 통하지 않는다면 기술 스토리를 정의하고 기술 스토리들만 별도로 모아 목록을 관리 한다. 제품 책임자가 목록은 볼 수 있지만 수정은 할 수 없으며, 실무자는 책임자와 기술 스토리를 구현할 수 있는 시간을 확보하는 협상을 한다.

 

5. 스프린트 알리기

회사에서 모든 구성원이 현재 팀에서 벌어지고 있는 일들을 항상 알게 하는 것은 중요하다. 그렇지 않으면 사람들은 불만을 갖거나, 더 나쁘게는 현재 상황에 대한 잘못된 억측을 만들어 낸다.

이는 스프린트 정보 페이지를 이용하여 해결 할 수 있다. 이 스프린트 정보 페이지에는 스프린트 이름, 스프린트 목표, 스프린트 백로그, 일정 등이 소개 된다.

가끔은 각 스토리를 어떤 방법으로 데모할지에 대한 정보도 포함 한다. 스프린트 계획 회의가 끝나면 책임자는 이와 같은 페이지를 정리해서 올리고 회사 전체에 메일을 보낸다.

위키 페이지에는 현황판을 만들어 현재 진행 중인 모든 스프린트의 링크를 넣을 수 있다. 스프린트가 끝날 때쯤 되면 책임자는 곧 있을 데모에 대해 상기시키는 메일을 전원에게 보낸다.

 

6. 스프린트 백로그 만들기

가. 작업 현황판

스프린트 백로그는 스프린트 계획회의 후, 첫 번째 일일 스크럼 전에 완료되어야 한다.

스프린트 백로그를 나타내는 형식 중에서 효과적인 방법은 벽에 작업 현황판을 만드는 것이다.

작업 현황판

할 일에는 아무도 하지 않는 작업, 진행 중에는 누군가가 하고 있는 작업, 완료에는 아무도 더 이상 하지 않을 작업 등으로 구성되며 만약 스프린트가 끝나기 전에 백로그 항목을 모두 완료하게 되면 “다음”에서 새로운 항목을 가져와 추가할 수 있다.

원한다면 어떤 종류의 칸이라도 추가할 수 있다. 예를 들자면 “통합 테스트 대기 중”, “취소” 등이 될 수 있다. 하지만 문제를 더 복잡하게 만들기 전에 진지하게 생각해 보는 것이 좋다.

첫 번째 일일 스크럼을 마치고 나면 작업 현황판은 다음과 같이 변경될 수 있다.

첫 번째 일일 스크럼 이후

며칠이 지나고 나면 작업 현황판은 다음과 같이 변경될 것이다.

며칠이 지난 후의 작업 현황판

위의 그림에서 보듯이 팀은 “입금” 스토리를 완료 했다. 여기서 말하는 완료라 함은 소스 코드를 적용했고 테스트와 최적화 등을 마쳤다는 것을 의미한다. 이관 도구는 부분적으로 완료된 상태이며 백오피스 로그인은 시작되었지만 백오피스 사용자 관리는 아직 시작되지 않았다.

오른쪽 하단에는 팀이 미쳐 계획하지 못했던 항목이 3개가 있다. 이렇게 하면 스프린트에 대해서 회고를 할 때 이것들을 기억해내는 데 유용하다. 스프린트 백로그는 스프린트가 진행되면서 지저분해 지기 마련이지만 오래도록 남겨둘 것이 아니므로 문제는 없다.

 

나. 소멸 차트

위 그림의 우측 상단의 소멸차를 통해서 누구나 스프린트가 얼마나 잘 진행되고 있는지 알 수 있다. 소멸차트의 라인이 오래도록 떨어지는게 더디다면 스프린트 항목에 대한 조정을 생각해 보아야 한다. 만약 그 반대라면 스프린트에 새로운 백로그 아이템 추가를 고려해야 한다. 책임자는 작업현황판과 팀이 주는 경고 신호에 맞춰 대응해야 할 책임이 있다.

 

7. 일일 스크럼 회의 진행

일이 스크럼은 정시에 매일 같은 장소에서 시작 하는 것이 좋다. 회의 시간이 15분을 넘기는 일이 생기지 않도록 회의를 서서 진행하는 것도 좋은 방법이다.

가. 작업 현황판 업데이트 하기

일일 스크럼을 진행하면서 작업 현황판을 업데이트 한다. 한 사람씩 자신이 어제 한 일과 오늘 할 일을 이야기하면서 현황판의 포스트잇을 옮긴다. 아직 계획을 잡지 못한 일이 있을 경우 새 포스트잇에 적어 현황판에 붙인다. 자신의 시간 추정을 바꿔야 한다면 새로운 추정치를 포스트잇에 적어 놓고 기존 추정치는 줄을 그어서 지운다. 가끔은 사람들이 이야기하는 동안 책임자가 포스트잇을 다루는 일을 하기도 한다.

어떤 팀은 회의 전에 각자가 작업 현황판을 업데이트하도록 규칙을 정하기도 한다. 팀의 스프린트 백로그를 어떤 모양으로 관리하건 스프린트 백로그를 최신으로 유지하는 일에는 팀 전체가 참여해야 한다. 책임자 혼자서 스프린트 백로그를 관리하도록 하고 매일 팀원 전체에게 남은 시간에 대한 추정치를 물어보는 식으로 스프린트를 진행하는 경우에는 책임자가 팀을 지원하고 장애물을 제거하는 대신 관리적은 일에 너무 많은 시간을 빼앗길 수 있으며 팀원들이 스프린트 백로그에 관심을 기울여야할 필요가 없어지면 팀원들 스스로 스프린트 진행 상황을 알지 못하게 될 수 있다. 이렇게 피드백이 부족해지면 팀의 전체적인 기민함이나 집중력이 저하될 수 있는 위험이 있다.

일일 스크럼 회의가 끝나면 누군가 시간 추정치를 모두 합하여 스프린트 소멸차트에 새 점을 그려 넣는다. (완료 칸에 있는 것들을 빼고 더한다.)

 

8. 스프린트 데모

스프린트 데모는 스프린트 검토회의라고도 하며 모든 스프린트는 데모로 끝이 나야 한다.

그 이유는 다음과 같다.

• 팀원들의 성취에 대해 인정받을 수 있다.
• 우리의 팀이 어떤 일을 했는지 알게 된다.
• 데모는 이해 당사자들로부터 중요한 피드백을 이끌어 낼 수 있다.
• 데모는 여러 다른 팀과의 교류로 서로의 일에 대해 토론할 수 있는 이벤트이다.
• 팀으로 하여금 실제로 일을 끝내고 그것을 런칭하도록 유도 한다.

스프린트의 데모 체크 리스트

• 스프린트 목표를 정확히 제시한다. 이 제품을 전혀 모르는 사람이 참석해 있다면 몇 분 정도의 시간을 들여서라도 제품을 설명한다.
• 데모 준비에 너무 많은 시간을 쓰지 말아야 한다. 특히 발표를 위한 겉치레를 피해야 한다.
• 빠른 속도를 유지해야 한다. 데모를 멋지게 만들기 보다는 빠른 속도로 진행하는 데 초점을 둔다.
• 비즈니스가 중심이 되도록 데모 수준을 유지한다. 어떻게 했는가보다는 무엇을 했는가에 집중 한다.
• 가능하다면 참석자들이 직접 제품을 사용해 보도록 한다.
• 소소한 버그 수정이나 사소한 언급은 하되 데모하지는 말도록 한다.

 

9. 스프린트 회고

회고에 있어서 가장 중요한 것은 실제로 회고가 이루어지도록 하는 것이다. 회고는 팀이 개선할 수 있는 최고의 기회이다.

물론 좋은 아이디어를 내기 위해서 꼭 회고를 할 필요는 없다. 아이디어를 내는 것이라면 어디서든 가능하다. 하지만 그 아이디어를 팀이 받아들이는가가 중요하다. 만약 해당 아이디어가 팀으로부터 나온 것이라면 즉, 모두가 아이디어를 내고 토의하도록 마련된 회고 중에 나온 아이디어라면 팀이 수용할 가능성은 더 높아 진다.

회고를 하지 않으면 팀이 같은 실수를 반복할 가능성이 높아 진다.

가. 회고 구성

일반적인 구성은 약간씩 다를 수 있으나 일반적으로 다음과 같다.

• 예상되는 토론 분량에 따라 1 ~ 3시간을 잡는다.
• 참석자는 제품의 책임자와 팀 전체이다.
• 밀폐된 방을 떠나 구석진 아늑한 소파나, 커피숍 등과 같이 토론에 방해 받지 않을 장소로 한다.
• 책임자는 노트북이나 그 밖에 것들을 이용해 스프린트 백로그를 보여주고 팀원들의 도움을 받아 스프린트 기간 동안 어떠한 중요한 사건과 결정사항이 있었는지 요약한다.
• 한 명씩 돌아가며 방해 받지 않고 말할 기회를 가진다. 각자 좋았던 것과 더 잘할 수 있는 것, 다음번 스프린트에서 다르게 해보고 싶은 것들을 이야기 한다.
• 추정 속도와 실제 속도를 살펴 본다. 차이가 많이 난다면 왜 그런지 분석한다.
• 마칠 즈음에는 책임자는 다음 스프린트를 더 잘하기 위해 팀이 무엇을 할 수 있는지 구체적인 제안들을 요약한다.

 

나. 문제의 식별

팀이 예를 들어 “팀 내 의사 소통이 부족해 우리끼리 서로에게 문제를 일으키고 설계를 망치고 있다.”라는 결론을 내렸다고 했을 때 어떻게 해야 할까를 생각해 본다고 가정하겠다. 일일 설계 회의 를 도입할 수 있고 의사소통을 도와줄 새로운 도구를 도입할 수 있고 위키 페이지를 추가할 수도 있다. 그러나 다른 한편으로는 그렇게 하지 않을 수도 있다. 하지만 많은 사례들을 통해서 단지 문제를 명확하게 식별하는 것만으로도 다음 스프린트에서 문제가 저절로 해결되기에 충분할 수 있다.

 

10. 스프린트 사이의 휴식

현실에서 항상 전력질주(스프린트)만 할 수 는 없다. 전력질주 사이에 휴식을 취해야 한다. 만약 팀이 항상 전력질주를 하고 있다면 실제로는 조깅하는 것일 수도 있다.

스프린트는 매우 격렬하다. 팀원들은 진정한 휴식은 절대 취하지 못하면서 매일 넌더리나는 회의에 참석하여 어제 한 일을 모든 이에게 이야기해야할 수도 있다.

휴식 그 자체에 필요성 이외에도 스프린트 사이에 약간의 여유를 두는 데에는 또 다른 이유가 있다. 스프린트 데모와 회고를 끝낸 후에 팀과 제품 책임자 모두에게는 정리할 정보와 아이디어들로 넘쳐날 것이다. 만약 이 상태에서 곧장 다음 스프린트 계획회의를 시작한다면 정보와 교훈들을 되새길 수 있는 기회를 잃게 될 것이다. 스프린트 회고와 후석 스프린트 계획 회의가 같은 날에 진행되는 것은 최악의 상황이다.