들어가는 글

스크럼은 방법론이 아닌 프레임워크이며 정확히 무엇을 해야 하는지 알려주지 않는다.

이 책(스크럼과 XP)은 스크럼을 저자가 어떻게 적용했는지 상세하게 설명하는 것이 장점이고, 저자가 적용한 스크럼만 언급하기 때문에 단점이라고 볼 수 있음을 미리 말한다. 따라서 저자와 다른 상황에 있다면 다른 방식으로 스크럼을 진행해야하며, 스크럼의 장점이자 단점은 처한 상황에 맞게 융통성을 발휘해야 한다고 한다.

즉, 이 책에선 스크럼을 실행하는 정도(正道)를 주장하려는 것이 아님

그럼에도 책을 쓴 이유는 실전 경험에서 얻은 소중한 정보를 풀어서 다른사람에게 유용한 피드백을 주기 위함이라고 함.

제품 백로그 만들기

제품 백로그는 기본적으로 우선순위가 매겨진 요구사항의 목록으로 스크럼의 핵심이다. 요구사항 대신 스토리나 기능 혹은 다른 어떤 이름이라도 상관 없고, 이것들을 스토리 또는 백로그 아이템이라고 부른다.

스토리에는 아래와 같은 항목이 포함된다.

• ID: 자동으로 매겨지는 고유 식별자(이름이 변경되어도 스토리 추적을 위함)
• 이름: 스토리를 설명하는 짧은 이름(ex: 개인 트랜잭션 이력 보기)
• 중요도: 제품 책임자가 생각하는 스토리의 중요도(점수)
• 최소 추정치: 다른 스토리와 비교하여 스토리를 구현하는 데 상대적으로 얼마나 많은 노력이 필요한지에 대한 팀의 최초 추정치. 단위는 스토리 점수이고 이상적인 맨데이에 해당
• 데모 방법: 스프린트 데모에서 이 스토리를 어떤 형태로 데모할 것인지에 대한 상위 수준 묘사
• 참고: 그 밖의 다른 정보나 설명, 참고사항 등

위와 같은 문서를 제품 책임자가 관리하면서 다른 사람들이 편집할 수 있게 공유 폴더에 넣어둔다. 개발자가 문서를 열어 어떤 사항을 구체화하거나 추정치를 변경하기도 함.

추가 스토리 항목

• 트랙: 대강의 스토리 분류로 '백 오피스'나 '최적화' 같은 것을 의미
• 컴포넌트: 보통 엑셀 문서의 '체크박스'로 표현되며 데이터베이스, 서버, 클라이언트 같은 것을 의미 → 해당 스토리 구현 시 어떤 팀이 어떤 스토리를 가져갈지 결정할 때 유용하게 사용
• 요청자: 해당 아이템을 처음으로 요청한 사람을 기억해두고 진척 상황을 알리고 싶어하는 경우 사용
• 버그추적: 스토리와 관련 버그들 사이의 추적성 부여를 위해 사용

제품 백로그를 비즈니스 수준으로 유지하기

제품 책임자는 비즈니스 목표에만 집중해야한다. 문제를 해결하는 방법은 팀이 더 잘 알기 때문이다. 기술적인 관점에서 작성된 스토리는 그 밑바탕에 깔려있는 본래의 목적이 드러나도록 스토리를 다시 쓴다.

예를들어, 이벤트 테이블에 인덱스 추가하기라는 스토리는 기술적인 관점이 들어가있으며 이 '인덱스 추가하기' 라는 진짜 목적(ex: 백오피스 이벤트 검색 폼 속도 개선)이 드러난 스토리를 적어야한다.

스프린트 계획회의 준비하기

스프린트 계획회의 이전에 제품 백로그를 깔끔하게 정리해 두어야한다는 교훈을 얻는다. 이것이 의미하는 바는 아래와 같다.

• 제품 백로그는 반드시 존재해야 함.
• 제품당 제품 백로그가 하나, 제품 책임자가 한명이어야 함.
• 중요한 아이템에 중요도를 부여할 때, 모두 서로 다른 값을 부여
  • 다음 스프린트에 포함될 가능성이 희박한 모든 스토리에는 특별한 중요도 값을 동일하게 부여
  • 중요도 값은 아이템을 정렬하는 용도로만 사용
  • 중요도 사이에 간격을 둠
• 제품 책임자는 각 스토리를 이해하고 있어야 함

중요도는 제품 책임자가, 개발 시간 추정은 팀이 한다.

저자의 팀이 시도했던 방법

• 제품 백로그 용으로 Jira를 사용했는데 너무 많은 클릭을 필요로 해 MS 엑셀 사용
• VersionOne, ScrumWorks, XPlanner 같은 애자일 프로세스 지원 도구 사용

스프린트 계획 수립하기

스프린트는 스크럼에서 가장 중요한 이벤트이다. 이것이 잘못되면 스프린트 전체를 망칠 수 있기 때문이다. 스프린트 계획회의는 팀에게 충분한 정보를 주고, 팀원들이 그렇게 할 수 있도록 제품 책임자에게 충분한 신뢰를 주는 데 있다.

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

• 하나의 스프린트 목표
• 팀원의 목록
• 스프린트 백로그
• 확정된 스프린트 데모 날짜
• 확정된 일일 스크럼을 위한 시간과 장소

제품 책임자가 회의에 참석해야하는 이유

모든 스토리가 서로 깊이 연관된 3개의 변수(범위, 중요도, 추정치)를 갖고 있기 때문이다. 범위와 중요도는 제품 책임자에 의해 결정되고 추정치는 팀에 의해 결정된다. 이 변수들은 계속적으로 세밀하게 대화를 통해 조정된다.

대화를 통해 스토리를 검토하고 추정하며 범위를 확인하고 다시 추정하는 직접적인 협력은 스크럼의 핵심 요소이며 모든 애자일 소프트웨어 개발의 핵심 요소이다.

왜 품질은 협상의 대상이 아닌가?

품질은 내적 품질과 외적 품질로 구분할 수 있다.

• 외적 품질: 시스템을 사용하는 사람들이 인식하는 품질
  • 외적 품질은 범위의 한 부분이라고 볼 수 있다. 좋지않은 UI더라도 먼저 출시한 후 추후 깔끔한 버전을 출시하는 것이 비즈니스 관점에서 전혀 문제가 없는 결정일 수 있기 때문이다.
• 내적 품질: 시스템을 유지보수하는 데 지대한 영향을 미칠 수 있는것을 지칭(설계 일관성, 테스트 커버리지, 코드의 가독성, 리팩터링 등)
  • 논의의 대상이 될 수 없다. 팀은 내적 품질을 유지하는 것에 책임을 져야한다.

내적품질을 희생하는 것은 나중에 품질을 되돌려 놓기 어렵게 한다. 따라서 이를 희생하려는 논의가 생기면 범위 쪽으로 논의를 전개하여 내적 품질은 협상의 대상이 아니라는 점을 강조해야함.

질질 늘어지는 스프린트 계획회의

스프린트 계획회의에서 가장 어려운 부분은 오래 걸린다는 것이다. 그래서 타임박스를 가지고 이 시간에 끝나지 않으면 무자비하게 끝낸다 이렇게 끝내면 스프린트가 고전하게 될 수 있지만, 팀은 교훈을 얻고, 다음번 스프린트 계획은 훨씬 더 효율적으로 진행될 것이다.

타임박스의 길이를 현실적으로 정하는 방법을 익히고 그 타임박스를 고수해야 함

스프린트 계획회의 시간표

스프린트 계획회의의 시간표를 사전에 짜두면 타임박스를 지키지 못하는 리스크를 줄일 수 있다.

시간표 예시(4시간, 1시간마다 10분 휴식)

• 제품 책임자가 스프린트 목표 검토 제품 백로그 요약(30분)
• 팀이 시간 추정, 필요에 따라 항목 세분화. 제품 책임자가 중요도 업데이트(1시간 30분)
• 팀이 스프린트에 포함시킬 스토리 선정(1시간)
• 일일 스크럼 회의의 시간과 장소 정함(1시간)

이를 철저하게 지켜야 하는것은 아님

스프린트 길이 결정하기

적절한 스프린트 길이란 얼마일까? 짧은 스프린트는 회사를 기민하게, 긴 스프린트는 팀의 추진력을 얻는데 충분한 시간과 목표 달성을 위한 충분한 여력을 갖게 해준다.

제품 책임자는 짧은 스프린트를 선호하고, 개발자는 긴 스프린트를 선호함. 저자는 약 3주가 적절한 길이라고 생각. 적절한 스프린트 길이를 위해 분석에 힘쓰기보다 직접 실험을 해보고 일정 기간은 이를 고수해보는 것을 추천한다.

스프린트 목표 결정하기

스프린트 목표를 세우기란 어렵다. 중요한 것은 목표를 비즈니스적인 말로 나타내야 한다는 것이다. 또한 아직까지 달성하지 못한 것이어야 한다.

이러한 스프린트 목표는 스프린트 중반에 사람들이 무엇을 해야 하는지 혼란스러워하기 시작하는 순간에 진가를 드러낸다. 목표를 잘 보이는 곳에 게시해두자.

스프린트에 구현할 스토리 고르기

스프린트 동안 어떤 스토리를 포함시킬지 결정해야한다. 제품 백로그 → 스프린트 백로그를 결정하는 일이다.

네모 상자의 크기는 스토리 점수로 표현되는 시간 추정치이며 괄호 친 부분의 길이는 팀의 추정속도(다음 스프린트에서 완료할 수 있을 것으로 생각되는 스토리 점수) 이다.

얼마나 많은 스토리를 포함할지는 팀이 결정한다. 이 과정에서 아래와 같은 의문점이 생길 것 이다.

• 제품 책임자가 팀의 결정에 영향을 미치려면 어떻게 해야하는가?
  • 중요도에 따른 순서를 재조정 한다.
  • 범위를 변경한다.(스토리 하나의 범위 조정)
  • 스토리를 둘로 나눈다.
• 팀은 스프린트에 포함시킬 스토리를 어떻게 결정하는가?
  • 직감
  • 속도 계산

속도 계산은 두 단계로 진행된다.

1. 추정 속도 정하기
2. 추정 속도 내에서 스토리를 얼마나 추가할 수 있는지 계산

속도는 '왼료한 작업의 양'에 대한 측정 값이다. 아래 그림은 스프린트를 시작할 때의 추정 속도와 그 스프린트가 끝날 때의 실제 속도의 예이다.

실제 속도는 각 스토리의 초기 추정치를 기준으로 계산되었다. 스프린트 중에 거의 완료한 스토리는 포함하지 않는데, 이는 스크럼이 완전히 출시 가능한 형태로 완료한 것만 인정한다는 사실을 강조한다

속도를 추정하는 방법으로 팀의 이력을 보는 것이다. 어제의 날씨라고 알려진 방법을 활용해 지난 몇 번의 팀의 속도가 얼마였는지 측정한다.

추정한 단위가 스토리 점수, 이상적인 맨-데이에 해당하는 값이기 때문에 집중도라는 값도 활용한다.

스프린트의 추정속도 = 가능한 맨-데이 x 집중도

집중도는 팀이 얼마나 집중할 수 있는지 추정한 값이다. 이를 통해 이번 스프린트의 추정 속도는 아래의 식으로 구할 수 있다.

저자의 기본 집중도는 70% 정도로 설정한다고 한다.

집중도 x 가능한 맨-데이 = 스토리 점수

어제의 날씨는 상식에 맞게 사용해야한다. ex) 새로운 멤버가 스프린트에 합류하는 경우 교육을 위해 집중도를 낮춤.

우리가 인덱스 카드를 사용하는 이유

스프린트 계획회의의 대부분은 제품 백로그에 있는 스토리를 가지고 진행한다. 이를 키보드를 가진 사람이 엑셀에서 조정하며 사람들이 화면을 보며 진행하는 것보다, 인덱스 카드를 만들어 벽에 붙이는 것이 좋다.

그 이유는 아래와 같다.

• 사람들이 서서 걸어 다녀 졸지 않고 주의를 기울임.
• 개개인 모두 더 적극적으로 참여하고 있다고 느낌.
• 여러 스토리 동시 수정 가능.
• 인덱스 카드를 옮겨 우선순위 조정 가능.
• 회의 끝나면 인덱스 카드를 가져다가 작업 현황판에 사용 가능

이러한 인덱스 카드에 작업한 내용을 스크럼 마스터가 엑셀로 되어있는 제품 백로그에 반영한다. 처음 엑셀로 정한 중요도보다 벽에 붙어 있는 실제 정렬 순서가 중요도를 나타내며 이를 액셀에 다시 갱신해야한다.

시간 추정은 스토리를 작업단위로 나누면 더 쉬워지는데 스토리 아래에 작은 포스트잇을 붙이는 식으로 이뤄진다. 하지만 작업 나누기는 엑셀에 반영하지 않는데 작업 나누기는 일시적인 경향이 강하며, 제품 책임자가 세부적인 사항에까지 관여할 필요가 없기 때문이다.

완료의 정의

'출시할 준비가 되었음'을 완료 정의로 사용하지만 '테스트 서버에 배치되고, 인수 테스트에 넣을 준비가 되었음'으로 정의해야 할 때도 있다. 하지만 실제로 모든 스토리를 동일하게 취급할 수 없으며 가끔 상식이 형식적인 체크리스트보다 더 낫다.

플래닝 포커를 사용하여 시간 추정하기

추정은 팀 활동이며 팀원 전원이 참여한다.

• 계획 단계에서 누가 어떤 스토리의 어느 부분을 구현할지 알 수 없음.
• 스토리 구현을 위해 다양한 분야의 전문가가 필요.
• 추정치를 제시하기 위해 팀원이 스토리가 어떤 것인지 어느 정도 이해할 필요 있음.
• 완전히 다른 추정치를 내놓은 두 팀원의 견해차를 발견하고 토론할 수 있음.

플래닝 포커는 각 팀원이 자신이 생각하는 시간 추정치를 의미하는 카드를 선택해 다른사람의 추정치에 흔들리지 않고 자신의 생각대로 할 수 있게 한다. 추정시에 중요한 점은 해당 스토리에 포함된 전체 일의 양을 추정해야 한다는 것인데, '자기' 부분만 추정하지 않는다는 이야기다.

스토리 명확하게 하기

제품 책임자가 데모 이후에 자신이 생각한 제품과 다르다고 생각이 들면 최악의 상황이다. 하나의 스토리에 대해 제품 책임자와 팀간 발생하는 명백한 오해를 확인하는 몇 가지 방법이 있다. 가장 간단한 방법은 각 스토리의 필드를 모두 채웠는지 확인하는 것이다.

예시

• '사용자 추가'라는 스토리의 추정치가 없는 경우
  • 팀은 추가/삭제/검색이 가능한 웹이라 생각해서 스토리 점수 20점을 추정
  • 제품 책임자는 단지 SQL을 사용해 수작업으로 DB에 사용자 추가를 의미
  • 다시 추정해 5점으로 결정

간단히 기술하는 것만으로도 스토리의 범위에 대한 중대한 오해가 풀릴 수 있다.

스토리를 작은 스토리로 분해하기

스토리가 너무 작거나 크면 안된다. 크다면 작은 스토리로 쪼개고, 작다면 그 스토리들이 비즈니스 가치를 제공할 수 있는 출시 가능한 단위인지 확인하라.

저자의 팀은 전형적인 팀의 속도이 40~60이고 하나의 스프린트는 평균적으로 10개 정도의 스토리를 갖게된다고 한다. 가끔은 5개가 되고 15개가 될때도 있다고 한다.

스토리를 작업 단위로 나누기

스토리: 제품 책임자가 관심을 갖는 전달 가능한 것 작업: 전달할 수 없는 것이나 제품 책임자가 관심을 갖지 않은 것

이런 과정에서 흥미로운 점이 있다.

• 이처럼 사전에 스토리를 작업으로 나누느라 시간을 보내는 것을 내켜하지 않는다.
• 스토리를 명확하게 이해하고 있다면 사전에 작업 단위로 나누는게 용이하다.
• 이렇게 하다보면 추가적으로 해야할 일이 생겨 시간 추정치가 늘어나는 경우가 종종 발생한다. 그래서 더 실제에 가까운 스프린트 계획인 된다.
• 사전에 작업 나누기를 하는 방식은 일일 스크럼 회의를 더 효과적으로 진행할 수 있게 한다.

저자는 이 과정을 포함시킬 만큼 스프린트 계획회의의 타임 박스를 길게 잡는다고 한다. 시간이 모자라다면 이 과정을 누락시킨다.

일일 스크럼의 시간과 장소 결정하기

일일 스크럼은 모든 사람들이 일의 시작을 선언하는 킥오프다.

오후 스크럼의 단점: 오늘 할 일이 무엇인지 어제 이야기한 내용이 무엇인지 기억해야함. 아침 스크럼의 단점: 어제 일한 내용이 무엇인지 기억해야 함.

저자는 첫 번째 단점이 더 나쁘다고 생각하는데 가장 중요한 것은 이제 무엇을 할 것인가이지 무엇을 했느냐가 아니기 때문이다.

어디에 선을 그을까

시간이 모자란 경우 쳐내야할 저자가 생각하는 우선순위는 아래와 같다.

• 우선순위 1: 스프린트 목적과 데모 날짜
• 우선순위 2: 이번 스프린트에 포함하기로 인정한 스토리 목록
• 우선순위 3: 스토리에 대한 추정치
• 우선순위 4: 각 스토리에 대한 데모 방법
• 우선순위 5: 스프린트 계획의 현실성 검증을 위한 속도 및 자원 계산
• 우선순위 6: 일일 스크럼의 시간과 장소 결정
• 우선순위 7: 스토리를 작업으로 나누기

기술 스토리

기술 스토리라는 복잡한 문제가 있다. 이는 다른 특정 스토리에 직접적으로 관련되지 않으면서도, 완료해야 하는 일이다.

아래와 같은 것들이 기술 스토리가 될 수 있다.

• 지속 빌드 서버 구축(개발자들의 시간 절약)
• 시스템 설계 개요 작성(전체적인 설계, 일관된 코드를 위한 것)
• DAO 레이어 리팩터링(DAO 레이어를 위한 것)
• Jira 업그레이드(현재 버전이 버그가 많고 느리다면 업그레이드를 해야함)

저자는 기술스토리를 다루기 위해 아래와 같은 방법을 취한다.

1. 기술 스토리를 피하고 비즈니스 가치가 드러나는 일반적인 스토리를 바꿀 수 있는 방법을 찾으려고 한다.
2. 일반 스토리로 바꿀 수 없다면 다른 스토리의 하위 작업으로 처리할 수 있는지 확인한다.
3. 기술 스토리를 정의하고 기술 스토리들만 모아 별도의 목록으로 관리한다. 이를 구현할 시간을 확보하는데 '집중도'와 '추정 속도'를 이용한다.

제품 책임자에게 기술 스토리의 이점을 집중도와 추정속도를 활용해 제공하고, 전체적인 우선순위를 결정하도록 제안한다.

버그 추적 시스템과 제품 백로그

저자의 경우 버그 추적시스템은 엑셀로 어렵고, Jira를 활용한다고 한다. 하지만 이 방법은 팀마다 또 모든 스프린트마다 답이 달라질 것이다. 가장 추천하는 방법은 제품 책임자가 우선순위가 높은 Jira 항목을 프린트해서 스프린트 계획회의에 가져오는 것이다.

스프린트를 알리는 방법

'스프린트 정보 페이지'를 이용해 어떤 팀이 어떤 일을 하는지 보여줄 수 있다.

스프린트 정보 페이지 예시

스프린트 계획회의 이후, 스크럼 마스터가 이와 같은 페이지를 만들어서 위키에 올린다. 위키에는 '현황판' 페이지를 만들어 현재 진행중인 모든 스프린트의 링크를 넣는다.

이런 스프린트 정보 페이지를 팀방의 바깥 볕에 붙여놓으면 팀이 무슨 일을 하고 있는지 알 수 있다. 또한 스프린트가 끝날 때쯤 스크럼 마스터가 데모에 대해 상기 시키는 메일을 전원에게 보내 회사에서 벌어지고 있는 일을 알릴 수 있다.

이를 통해 사람들이 불만을 갖거나 현재 상황에 대한 억측을 방지할 수 있고, 현재 벌어지고 있는 일들을 항상 알고 있게 만들 수 있다.

스프린트 백로그 만들기

스프린트 백로그는 스크럼 마스터가 스프린트 계획회의 후, 첫 번째 일일 스크럼 전에 만들어야 한다. 이 백로그를 만들 때 Jira, Excel등 다양한 방법이 있지만 아래 그림처럼 벽을 이용한 작업 현황판을 가장 추천한다.

작업 현황판의 원리

• 할 일: 오늘 아무도 하지 않는 작업
• 진행 중: 오늘 누군가 하고 있는 작업
  • 가끔 큰 팀의 경우 이 작업을 누가하고 있는지 기억 못해 이름을 적어놓는 등의 정책을 도입하기도 함
• 완료!: 아무도 더 이상 하지 않을 작업
• 소멸차트: 일일 스크럼을 마친 뒤 바로 점을 찍을 공간
  • 가로는 날짜, 세로는 남은 작업량 추정(스토리 점수)을 의미한다.
  • 추세선을 보고 잘 진행되고 있는지 알 수 있어야 한다.
• 계획에 없던 항목: 미처 계획하지 못한 항목
  • '스프린트 회고'를 할 때 이것들을 기억해내는 데 유용하다.
• 다음: 스프린트가 끝나기 전에 백로그 항목을 모두 완료하면 새 항목을 가져갈 곳

날짜로 추정하기와 시간으로 추정하기

시간으로 추정하는 것(맨-아워)은 너무 잘게 나눠져 있어 지나치게 세부적인 내용까지 관리하는 미시적인 관리로 치우치는 경향이 있다. 그래서 작업량을 추정하는 기준으로 맨-데이를 사용한다고 한다.

팀방 꾸미기

설계 토의가 주로 작업 현황판 앞에서 즉흥적으로 이루어지는데, 이러한 공간을 '설계 구역'이라 한다.

'설계 벽면'은 가장 중요한 설계 스케치와 설계 문서(순서도, GUI 프로토타입, 도메인 모델)를 포함한다.

팀을 한자리에 모아라

저자는 효과적인 스크럼 팀을 구축하기 위해선 팀을 한자리에 모으는 것이 필수적이라고 한다.

'한자리'가 의미하는 바는 다음과 같다.

• 가청성: 자기 자리를 벗어나거나 소리치는 일 없이도 다른 사람과 이야기할 수 있다.
• 가시성: 팀의 모든 멤버는 다른 멤버들을 모두 볼 수 있다.
• 단절성: 갑작스러운 토의 진행 시, 방해 받을 정도로 가까운 곳에 팀 외부 인원이 있으면 안된다.

분산으로 인해 팀을 한자리에 모을 수 없다면 이 피해를 최소로 줄일 수 있는 기술적 보조 도구(화상 회의, 웹캠, 바탕화면 공유 도구 등)들을 사용하자.

제품 책임자 떨어뜨려 놓기 제품 책임자는 팀 가까이서 작업 현황판을 둘러볼 수 있어야 하지만 팀과 같은 자리에 있어서는 안된다. 팀에 깊게 관여하게 되면 팀이 자율적인 관리가 이뤄지지 못하고 생산성이 높은 상태로 갈 수 없기 때문이다.

저자의 경험적인 추측이라고 함.

관리자와 코치 떨어뜨려 놓기

관리자가 팀에 가까운 곳에 있다면 자율적 관리는 자동적으로 거리가 멀어진다. 스크럼 코치도 마찬가지이다. 스크럼 코치라면 가능한 긴밀하게 참여하면서도 한정된 기간 동안만 그렇게 하라.

개선할 부분을 발견하게 된다면 스크럼 마스터를 따로 불러 코치하라. 잘 운영되는 스크럼 팀이라면 그들이 필요한 것들은 모두 스스로 구할 것이라고 믿어라.

일일 스크럼 진행하기

일일 스크럼을 팀방, 작업 현황판 바로 앞에서 규칙대로 진행한다. 또한 회의 시간이 15분을 넘는 일이 생기지 않도록 서서한다.

작업 현황판 업데이트하기

일일 스크럼 중에 계획을 잡지 못한 일이 있다면 새 포스트잇에 적어 현황판에 붙이고, 기존 추정치에 줄을 그어 새로운 시간 추정치를 적는 등 작업 현황판을 업데이트한다.

물론 일일 스크럼 회의가 끝나면 시간 추정치를 모두 합해 스프린트 소멸 차트에 새 점을 그려야한다.

중요한 것은 스프린트 백로그를 최신으로 유지하는 일에는 팀 전체가 참여하도록 해야 한다. 이렇지 않고 스크럼 마스터가 혼자 관리하게 되면 아래와 같은 단점이 생긴다.

• 팀을 지원하고 방해물을 제거하는 대신 관리적인 일에 너무 많은 시간을 빼앗긴다.
• 스프린트 백로그에 팀원들이 관심을 기울일 필요가 없어져 진행상황을 알지 못하게 된다. 따라서 피드백이 부족해지면 팀의 전체적인 기민함이나 집중력이 저하된다.

지각자 다루기

1분이라도 지각하면 정해둔 금액만큼 통에 넣어서 이를 친목에 다지는 행사에 사용한다.

'오늘 할 일을 모르겠어요' 문제 다루기

작업 현황판의 내용이 실제와 일치하는지, 각 항목들의 의미는 모두 이해하고 있는지 등을 체크한다. 그 이후 다시 물어본다. 그래도 아니라고 하면 짝 프로그래밍 기회가 있는지 고려해 본다.

팀이 스프린트 목표를 달성하지 못했음에도 할일을 찾고 있지 못하면?

• 구식 방법: 작업 할당
• 수치심 자극: 집 가거나 그냥 앉아 있게 하기
• 동료 집단의 압력: 할일이 생각 날때까지 같이 서있기
• 강제 노역: 잡일 처리부 역할 맡기

특정 사람이 이런 상황을 자주 발생시키면 심각한 코칭이 필요하다. 중요한 인물이 아니라면 해고시키고, 맞다면 그의 '양치기' 역할을 할 수 있는 누군가와 짝을 지어보자.

스프린트 데모하기

스프린트 데모는 과소평가 하는 경향이 있지만 스크럼의 중요한 부분이다.

모든 스프린트가 데모로 끝나야 하는 이유

• 팀은 자신의 성취에 대해 인정받고 기분이 좋아진다.
• 다른 사람들이 팀이 어떤 일을 했는지 알게 된다.
• 이해당사자들로부터 중요한 피드백을 이끌어낸다.
• 다른 팀들과 교류하며 서로의 일에 대해 토론할 수 있는 사회적 이벤트이다.
• 일을 끝내고 그것을 릴리스하도록 유도한다.

데모를 하면서 다양한 피드백을 받고 데모를 무조건 잘해야 한다는 것을 알고, 데모할 유용한 것들을 만들어낼 가능성을 크게 높인다.

스프린트 데모 체크리스트

• 스프린트 목표를 명확하게 제시하라
• 실제로 동작하는 코드를 데모하는 일에만 집중하라
• 데모를 멋지게 만들기 보다 빠른 속도로 진행하는 데 초점을 맞추자
• '무엇을 했는가'에 집중해 비즈니스가 중심이 되도록 데모 수준을 유지하라
• 참석자들이 직접 제품을 사용해 보도록 하라
• 버그 수정 및 사소한 기능들을 데모하지 마라

'데모 불가' 항목 처리하기'

유저 10,000명 테스트와 같은 실제로 데모할 수 없는 것들은 부하테스트 보고서와 같은 것들로 데모를 대체하자.

스프린트 회고하기

모든 팀이 회고를 해야 한다고 주장하는 이유

회고에 있어서 가장 중요한 것은 실제로 회고가 이루어지도록 하는 것이다. 이는 개선을 할 수 있는 최고의 기회이기 때문이다. 회고를 하지 않으면 팀이 같은 실수를 반복해서 저지르는 것을 목격하게 될 것이다.

회고 구성하기

저자는 다음과 같이 회고를 구성한다고 한다.

• 예상되는 토론 분량에 따라 시간 정하기
• 참석자: 제품 책임자, 팀 전체, 나 자신
• 팀방이 아닌 토론에 방해 받지 않을 장소로 이동
• 도움이 역할 한 명 정하기
• 스크럼 마스터가 스프린트 백로그를 보여주고, 팀원들의 도움을 받아 스프린트 기간동안 어떤 사건과 결정사항 등이 있었는지 요약
• 좋았던 것, 잘할 수 있었던 것, 다음 스프린트에서 다르게 해보고 싶은 것 한 명씩 돌아가며 이야기
• 추정속도와 실제 속도 차이 확인
• 스크럼 마스터가 다음 스프린트를 더 잘하기 위해 무엇을 할 수 있을지 구체적인 제안 요약

회고 화이트보드는 세 칸으로 나눈다.

• 만족: 스프린트를 다시 하더라도 똑같이 반복할 것들
• 반성: 스프린트를 다시 한다면, 다른 방법으로 할 것들
• 개선: 향후 어떻게 개선할 수 있을지에 대한 구체적인 아이디어들

개선안들을 포스트잇에 붙여 팀원들이 투표할 수 있게 한 뒤, 이번에 집중할 프로세스를 정하고 다음 회고까지 유지한다.

팀 간 교훈 전파하기

지식의 교량 역할을 할 사람을 정해 모든 스프린트 회고에 참석하게 한다. 이런 사람에게는 중요한 규칙이 있다.

• 남의 말을 잘 들어주는 사람
• 그룹 내에서 활발한 토의를 유발할 수 있는 사람
• 전체 팀의 모든 회고에 참석하여 기꺼이 시간을 보내는 사람
• 어느 정도의 권한을 위임 받아, 개선 의견을 실행에 옮길 수 있는 사람

바꿀 것인가 바꾸지 않을 것인가

회고 내용을 팀방 벽면에 붙여놓는다면 문제를 명확하게 식별하는 것만으로도 다음 스프린트에서 문제가 저절로 해결되기에 충분하다.

회고 중에 드러날 수 있는 사례들

몇 가지 전형적인 사례와 대응 방법을 알아보자.

• "스토리를 하부 항목과 작업으로 세분화하는 데 더 많은 시간을 들였어야 했어요."
  • 전형적인 조치가 따로 없다. 팀은 자체적으로 이 문제를 해결하려 할 것이다.
• "외부 방해가 너무 많아요"
  • 팀이 다음 스프린트의 집중도를 낮추게 하여 현실적인 계획을 세울 수 있게 한다.
  • 방해요인들을 기록하도록 한다.
  • 팀의 '골키퍼' 역할을 할 사람을 한 명 지정한다. 모든 방해와 간섭이 그 사람을 거치게 한다.
• "지나친 약속을 했었어요. 절반밖에 완료하지 못했어요."
  • 전형적인 조치 없음. 팀은 지나친 약속을 하지 않을 것임.
• "우리 사무실이 너무 시끄럽고 지저분해요."
  • 더 나은 환경을 조성하고 팀을 다른곳으로 이전해보라.
  • 팀이 집중도를 낮추는 원인이 환경이라는 점을 명확하게 기술하게 하라. 제품 책임자가 상위 관리자에게 항의하도록 할 수 있을 것임.

스프린트 사이의 휴식 시간

현실에서 항상 스프린트만 할 수 없다. 사이사이에 휴식을 취해야한다. 스프린트를 끝낸 후 정리할 정보와 아이디어가 존재한다. 이 휴식이 정보와 교훈들을 되새길 수 있는 기회이다.

저자는 스프린트 회고와 후속 스프린트 계획회의가 같은 날에 진행되는 일은 반드시 피하려고 한다고 한다.

이를 위한 방법으로 '랩 데이'가 있다. 이날은 개발자들이 하고 싶은일 무엇이든지 하도록 허가해주는 날이다.

고정 가격 계약 하에서 릴리스 계획하기

한 번에 하나 이상의 스프린트를 내다보고 계획을 세워야 할 필요가 있다.(고정 가격 계약) 즉, "새로운 시스템의 1.0 버전을 늦어도 언제까지 납품할 수 있을까?"라는 질문에 답하려는 시도다.

허용 기준 정의하기

제품 백로그에는 제품 책임자가 허용 기준 목록을 정의하는데 허용 기준은 제품 백로그에서 중요도에 따라 간단히 분류한 것이다.

허용 기준 규칙의 예

• 중요도 >= 100인 모든 항목은 반드시 버전 1.0에 포함되어야 한다.
• 중요도 50 ~ 99인 모든 항목은 1.0에 포함되어야 하지만 바로 다음 릴리스에 넣을 수 있따면 미룰 수도 있다.
• 중요도 25 ~ 49인 항목은 필요하긴 하지만 다음 1.1 릴리스에 끝낼 수 있다.
• 중요도 < 25 인 항목들은 확실치 않거나 전혀 필요하지 않을지도 모른다.

위 사진은 앞서 기술한 규칙에 의거해 색을 칠한 제품 백로그 사례이다.

빨강 = 버전 1.0에 반드시 포함되어야 함 (바나나 - 배) 노랑 = 버전 1.0에 포함되었으면 함 (건포도 - 양파) 녹색 = 지연되어 됨(자몽 - 복숭아)

바나나에서 양파까지 모든 것들을 일정 내에 전달하면 안전하다. 시간이 별로 없다면 건포도, 땅콩, 도넛, 양파 등은 뺄 수도 있다. 양파 아래는 전부 보너스

가장 중요한 항목들의 시간 추정하기

릴리스 계획을 하기 위해선 제품 책임자가 계약서 상에 포함된 모든 스토리에 대해 추정해야 한다. 이를 위해 팀과 서로 협력해야 한다.

위 사진은 누가 추정했는지에 따라 추정에 들인 시간과 시간 추정의 가치가 어떠했는지를 보여준다. 정리하면 아래와 같다.

• 팀이 추정하게 하라
  • 제품 책임자는 각 항목의 범위를 명확하게 해줌
• 너무 많은 시간을 들이지 않게 하라
  • 팀은 회의 참석으로 현재 스프린트가 영향받고 있음을 알려 시간 추정 작업이 공짜로 이루어지지는 않는것을 이해시킴
• 시간 추정은 단순하고 완벽하지 않은 단지 추정일 뿐이며, 확정은 아니라는 것을 이해시켜라

속도 추정하기

스프린트 당 팀의 평균 속도를 추정해야한다. 이는 집중도를 결정해야 한다는 의미인데, 이 값은 절대 100%가 될 수 없다. 스프린트의 맨 데이에 집중도를 곱해 추정속도(스토리점수)를 얻는다.

전부 합쳐 릴리스 계획 만들기

팀의 스프린트당 추정속도를 얻었으니 제품 백로그를 여러개의 스프린트로 나눌 수 있다. 따라서 스프린트 몇번이 필요한지, 얼마나 걸릴지 알 수 있으므로 납품 날짜를 결정할 수 있다.

스프린트(3주)로 나눴을 때 좋은점은 3주마다 고객이 사용할 수 있는 기능을 데모하고, 진행 중에도 요구사항을 변경할 수 있다는 것이다.

릴리스 계획을 현실에 맞추기

현실이 계획에 맞춰주지는 않으므로 계획을 현실에 맞출 수밖에 없다. 스프린트가 끝나고 계획과 현실이 크게 차이가 난다면 다시 추정속도를 구한 뒤 릴리스 계획을 수정한다.

수정하기 힘들다면 고객과 협상에 들어가거나 계약을 어기지 않는 선에서 범위를 줄일 수 있는지 살펴본다.

스크럼과 XP 결합하기

• 스크럼: 관리 및 조직적 실천법에 집중
• XP: 대부분 실제 프로그래밍 실천법에 집중

이 둘을 효과적으로 결합할 수 있다. XP 실천법 중에 유익한 것들과 그것들이 업무에 어떤 식으로 적용되는지 알아보자.

짝 프로그래밍

• 코드 품질을 향상 시킨다.
• 팀이 집중을 더 잘 할 수 있게 한다.
• 한번 해보고 나서는 개발자들 중의 상당수가 좋아하게 된다.
• 자주 짝을 바꾸는 것이 좋다.
• 조직 내 지식 확산을 촉진 시킨다.
• 짝 프로그래밍을 좋아하지 않는 사람도 있음을 이해하자.
• 코드리뷰는 짝 프로그래밍의 좋은 대안이다.
• 항해자(네비게이터)도 자기의 컴퓨터를 가지고 있어야 한다. 필요할 때 스파이크(시도를 의미하는듯?)를 해보거나 운전자(드라이버)가 막혔을 때 관련 문서를 살펴보기 위함이다.
• 짝 프로그래밍을 강요하지 말고 분위기 조성과 적당한 도구를 제공하라.

테스트 주도 개발(TDD)

저자에겐 스크럼과 XP 둘을 합친 것보다 중요하다고 한다.

TDD는 자동화된 테스트를 하나 작성하고 테스트 통과를 위한 코드를 작성한 다음, 가독성을 높이고 중복을 제거하기 위해 코드를 리팩터링 하는 것이다.

테스트 주도 개발에 대한 소감

• TDD는 어렵고 프로그래머가 제대로 이해하려면 시간이 걸린다. 이를 제대로 하기위한 방법 중 하나는 TDD에 능숙한 다른 사람과 짝 프로그래밍을 해 보도록 하는 것이다.
• 시스템 설계에 긍정적인 영향을 미친다.
• 새 제품에 TDD가 제대로 돌아가기까지는 시간이 걸린다.(블랙박스 통합 테스트)
• 테스트를 쉽게 작성할 수 있도록 필요한 시간을 투자(적절한 도구, 교육, 유틸리티 클래스나 기반 클래스 제공)

TDD 관점에서 가장 복잡하고 어려운 작업은 자동화된 블랙박스 인수 테스트이다. 이는 시스템을 기동시키고 외부에 공개된 인터페이스만을 이용하여 시스템에 접근한다.

[!블랙박스 테스트] 제품 내부 구조나 설계에 대한 지식 없이 제품 또는 애플리케이션의 기능과 상호 호환성을 분석하는 테스트이다. 최종 사용자에게 초점을 맞출 수 있다.

이를 통해 개발-빌드-테스트를 극단적으로 빠르게 할 수 있다. 개발자들이 자주 리팩터링을 할 수 있게 자신감을 부여한다.

새 코드에 TDD하기

얻게되는 이득이 크기 때문에 새로 시작하는 모든 것들을 TDD로 개발한다.

오래된 코드에 TDD 하기

처음부터 TDD로 개발되지 않은 코드 베이스를 가지고 TDD를 하기란 어렵다. 바로 테스트를 자동화하기보단 차근차근 한 단계씩 진행해야한다. 수작업 테스트를 더 효율적으로 할 수 있는 도와주는 기능들을 만드는 것이 예이다.

점증적 설계

처음부터 설계를 단순하게 유지하면서 지속적으로 개선해 나가는 것을 의미한다. 적당한 시간을 들여 리팩터링을 해서 기존 설계를 향상시켜 이루어진다. 지속적인 설계 개선은 대부분 TDD를 실시함으로써 자동으로 얻어지는 부수효과이다.

지속적 통합

정교한 지속적 통합 시스템(지속 빌드 서버)은 코드 베이스의 건강 상태를 판단할 수 있는 참조 지점으로 '심판관'의 역할을 한다. 이 서버에서 모든 것을 깨끗한 상태로 빌드하고 모든 테스트를 실행한다. 문제가 생기면 문제가 생긴 코드를 바로 알 수 있다.

코드 공동 소유

짝 프로그래밍을 하게 되면 높은 수준의 코드 공동 소유가 가능해진다. 이를 통해 누군가 아파도 스프린트가 중단되는 일이 없어진다.

정보가 가득한 작업 공간

화이트보드와 빈 벽면 공간을 활용해 제품과 프로젝트에 관한 정보들을 볼 수 있게 배치하자. 쓸모 없는 것들은 치울 수 있게 팀마다 '가정부' 역할을 한 명씩 두어서 관리하자.

코딩 표준

간단하게 시작해서 점점 확장해나가는 코딩 표준을 정의하자. 대부분의 프로그래머는 자신만의 독특한 코딩 스타일이 있는데, 이는 시스템 설계의 일관성을 저해하거나 코드의 가독성을 떨어뜨린다. 코딩 표준은 이런 경우에 매우 유용하다.

지속 가능한 속도 / 활기 넘치는 작업

장기간 초과 근무는 생산성을 저해한다. 작업 시간을 적정 수준으로 유지해 생산성과 품질을 향상시킬 수 있게 하자.

테스트 하기

테스트는 가장 어려운 부분이다. 또한 조직마다 편차가 가장 심한 부분인데 이 장에선 저자의 경험으로 어떻게 해 오고 있는지, 거기서 배운 것이 무엇인지 설명한다.

인수 테스트 단계

일반적으로 스프린트가 끝나면 즉시 배포 가능한 버전의 시스템이 나오지는 않는다. 심각한 버그가 존재하고 일정 부분 수작업 인수 테스트 단계가 필요하다. 테스터들은 최종 사용자와 똑같은 방법을 시스템을 사용하면서 버그를 찾아낸다.

팀은 이에 따라 버그를 수정한 릴리스를 만들고 실제 출시가 가능한 버전이 나올 때까지 테스트, 디버깅, 재출시를 하는 전체 기간을 거친다. 이것이 바로 인수 테스트 단계이다.

이러한 인수 테스트 단계를 최소화할 수 있는 방법이 있다.

• 스크럼 팀에서 전달되는 코드의 품질을 최고로 높이기
• 수작업 테스트의 효율성을 최대화하기

스크럼 팀에서 전달되는 코드의 품질을 최고로 높이려면 어떻게 해야할까?

스크럼 팀에 테스터를 포함시켜 품질 향상 시키기

여기서 말하는 '테스터'는 주된 기술이 테스트인 사람을 의미하며, '역할이 오직 테스트인 사람'을 의미하는 것이 아니다.

테스터는 '종료 신호'를 보내는 사람이다.'

테스터가 '완료' 체크리스트를 검토하며 실제로 테스트를 하면서 완료되었다고 말해야하지만 실제로 '완료'된 것으로 간주한다.

스프린트 데모를 준비하기에 최적인 인물이 생기는 것

테스트 할 것이 없을 때 테스터는 무엇을 하는가?

테스트 스펙을 작성하거나 테스트 환경을 준비하는 등의 테스트 준비 작업을 하고 있어야 한다. TDD로 개발 중인 팀이라면 테스트 코드를 작성하는 개발자들과 짝 프로그래밍을 해야 한다. 훌륭한 테스터는 다른 종류의 테스트를 생각해낼 수 있어 서로를 보완하게 된다.

TDD를 하지 않거나 시간이 남는 경우 팀이 스프린트 목표를 달성하는 것을 돕는 일이라면 무엇이든지 하면 된다. 프로그래밍과 관련 없는 비프로그래밍 작업도 많다.(테스트 환경 구축, 요구사항 명확하 등..) 반대로 테스터가 병목지점일 때에는 팀원 전부가 테스터를 도와 조수역할을 할 수 있을 것이다.

스프린트 작업량을 줄여 품질 향상시키기

스프린트 작업량을 줄이면 더 적게 개발하면 안정적으로 개발할 수 있다. 자동적으로 품질이 향상되고, 인수 테스트 주기가 짧아지며, 최종 사용자에게 노출되는 버그가 적어지며, 장기적으로는 팀이 문제가 계속 생기는 기존 기능들을 고치는 대신 항상 새로운 기능에 집중할 수 있게 되어 생산성이 향상된다.

인수 테스트가 스프린트의 일부여야 하는가?

대부분의 팀들은 아래 두 가지 이유로 그렇게 하지 않는다.

• 스프린트 기간이 고정되어 있다. 인수 테스트는 기간을 고정하기 매우 힘들다.
• 여러 스크럼 팀이 같이 작업하는 경우는 각 팀들의 결과물 합쳐 수작업 인수 테스트를 해야만 한다.

스프린트 주기와 인수 테스트 주기

완벽한 스크럼 세상에선 스프린트가 끝날 때마다 당장 인도할 수 있는 시스템을 릴리스 할 것이다. 하지만 현실은 첫 번째 스프린트 이후, 두 번째 스프린트에서 버그 리포트가 쏟아져 대부분의 시간을 디버깅 하느라 보낸다. 이 문제에 대한 접근법을 알아보자.

1. 이전 것이 제품화 되기 전까지는 새로운 것을 만들려 들지 말라

스프린트와 스프린트 사이에 시간 제한이 없는 릴리스 기간을 추가하고, 그 기간에는 제품으로 릴리스 할 수 있는 버전을 만들 때까지 오직 테스트와 디버깅만 수행한다.

하지만 이는 규치적인 스프린트 심작박동을 깨뜨리고 이 방식으로는 문제를 완벽하게 해결하지 못한다. 이따금씩 긴급 버그 리포트가 나타나 이를 처리할 준비를 해야하기 때문이다.

2. 새로운 것을 만들 때가 되었더라도 이전 것을 제품화하는 것에 우선순위를 두라

저자가 선호하는 접근법이다.

이전 스프린트에서 넘어온 꽤 많은 버그를 수정할 수 있도록 스프린트 기간을 충분히 길게 잡는다. 이를 위해 집중도를 낮게 설정한다.

나쁜 접근법은 새로운 것을 만드는 데 집중하는 것이다. 기존 코드들이 점점 더 무거워져서 모든 것을 지연시키게 된다.

가장 느린 연결고리에서 무리하지 마라

병목이 되는 그 부분을 제거하는데 투자하라. 그 부분이 테스트와 관련한 것이라면 인원을 더 배치하거나 테스트를 위한 도구나 스크립트, 자동화된 테스트 코드를 넣는 방법이 있다.

여러 스크림 팀 다루기

같은 제품에 여러 스크럼 팀이 붙게 되면 여러 가지 면에서 더 힘들어진다. 이와 관련해 주된 의문 2가지가 있다.

• 팀을 몇 개 만들어야 하는가
• 각 팀에 사람들을 어떻게 할당할 것인가

팀을 몇 개 만들어야 하는가

서로 계속 간섭하게 되는 작은 팀을 여럿 두는 것보다 차라리 크다 하더라도 소수의 팀을 두는 것이 낫다. 서로 간섭할 일이 없는 경우에만 작은 팀들을 만들어라.

가상 팀

'큰 팀'이냐 '많은 팀'이냐라는 트레이드오프에서 내린 결정이 맞는지 틀리는지는 '가상 팀'의 형태를 보면 알 수 있다. 가상팀이 지속되는 것으로 보인다면 틀린 것이고, 가상 팀이 일시적인것으로 보인다면 옳은 것이다.

예 1. 하나의 큰 팀으로 만든 경우

작은 가상 팀이 가끔씩 변경되고 있다면 단일 스크럼 팀을 구성하기로 한 결정이 옳았다는 것을 의미한다. 그러나 가상 팀이 그대로 유지된다면 다음 스프린트에서는 스크럼 팀을 둘로 나누길 원할 것이다.

예2. 팀을 셋으로 나눈 경우

스프린트 중간까지는 1번 팀과 2번 팀이 서로 이야기를 나누다가 중간부터는 1번 팀과 3번팀이 서로 이야기를 나눈다면 전부 한팀으로 합치거나 그냥 세팀인 채로 놔두어야 할 것이다. 이런 경우 스프린트 회고 때 이 문제를 꺼내 팀들이 스스로 결정하도록 하자.

팀 분할은 스크럼에서 정말 어려운 부분이기에 실험해 보고, 가상 팀을 지켜보고, 회고를 하면서 이런 이야기를 충분히 토의하도록 해라. 그러면 상황에 맞는 해결책을 찾게 될 것이다. 중요한 것은 팀들이 안정적이어야하며 너무 자주 왔다 갔다 하지 않는 것이다.

최적의 팀 크기

대부분의 책에선 59명 정도라고 하는데 저자는 38명이라고 생각한다. 하지만 코드 베이스가 엉망인 상태이고 두 팀이 독립적으로 코드 베이스를 건드릴 방법이 없다면 팀원 수가 많아지더라도 우선 합쳐서 기존 코드 베이스를 수정하는 데 많은 노력을 투입해야 한다. 이러한 투자는 매우 빨리 제 값을 할 것이다.

스프린트 동기화할 것인가, 말 것인가

같은 제품을 세 개의 스크럼 팀이 개발하고 있는 상황에서 스프린트를 동기화 하는 것이 좋다. 장점은 아래와 같다.

• 팀을 다시 조직하기에 자연스러운 순간이 스프린트와 스프린트 사이이다.
• 모든 팀이 같은 스프린트에 같은 목표를 가지고 일할 수 있다. 스프린트 계획회의도 같이 할 수 있고 팀간 협업이 좋아진다.
• 스프린트 계획회의, 데모, 릴리스 등이 적어져 관리 부담이 줄어든다.

'팀 리드' 역할을 도입한 이유

제품 책임자(제품 소유자)는 도메인 전문가로 팀원들에게 나아갈 방향을 말해주는 사람이다. 누가 어느 팀에 들어가고, 인원을 분배하고 그런 자잘한 세부 사항까지 관여해서는 안된다.

이를 위해 '팀 리드' 역할을 도입해 특정 팀 하나만을 이끌지 않고 전체 팀의 스크럼 마스터 역할을 하거나 팀에 인원을 배분하는 등의 교차 팀 이슈들을 책임지게 한다.

팀에 인원 할당하기

각 팀에 인원을 할당하는 두 가지 일반적인 전략이 있다.

• 앞서 언급한 '팀 리드'나 제품 책임자 혹은 기능 관리자처럼 한 사람을 선정하여 인원을 할당하게 한다.
• 팀이 자체적으로 인원을 할당하게 한다.

두 전략을 합친 것이 가장 효과가 좋았다.

팀 리드가 처음에 제품 책임자와 스크럼 마스터를 불러 팀 할당 회의를 연다. 그 이후 다음 스프린트를 위한 팀 할당 제안을 작성한다. 이후 모든 팀원들에게 이 제안을 보여주고 임시적으로 결정된 것이니 자유롭게 어떤 팀으로 갈지, 팀을 분리할지 합칠지 의논하게 하여 팀원 할당을 결정한다.

특화 팀을 둘 것인가 말 것인가

대부분의 스토리들이 서버, 클라이언트, 데이터베이스에 걸쳐있는 경우 특화 팀으로 만드는 것은 좋지 않다. 따라서 교차 컴포넌트 팀을 만들어 특정 컴포넌트에만 국한되지 않게 한다. 각 팀은 스토리를 자체적으로 완전히 구현할 수 있게 되며 더 많은 일을 서로 독립적으로 진행할 수 있다.

스프린트 사이에 팀을 재구성하는 문제

스크럼의 가장 중요한 관점 중 하나는 '팀 융합'이다. 여러 스프린트에 걸쳐 함께 일한다면 팀원들은 아주 밀접한 사이가 될 것이고 집단 몰입 상태에 도달해 믿기 어려운 생산성을 발휘하는 법을 배울 것이다. 그러나 스프린트때마다 팀을 계속해서 바꾼다면 진정 견고한 팀 융합을 이룰 수 없다.

한 가지 예외로 대규모 팀에 스크럼을 처음으로 적용하기 시작할때는 모든 사람들에게 맞는 팀 분할을 찾을때까지 어느 정도 실험해볼 만하다.

비상근 팀원

일반적으로 스크럼 팀에 비상근 팀원을 포함하는 것은 좋은 생각이 아니다. 때때로 방법이 없어 비상근으로 운영할 수 있지만 이렇게 해야만 하는지 심사숙고해야 한다.

스크럼들의 스크럼 진행하기

스크럼들의 스크럼은 모든 스크럼 마스터들이 한자리에 모여 이야기하는 정기회의이다. 이 스크럼을 두 가지 수준으로 구분할 수 있는데 '제품 수준'과 '회사 수준'이다.

제품 수준 스크럼들의 스크럼

중요한 것은 정기적으로 스크럼들의 스크럼 회의를 실시한다는 것이다. 이 회의에선 통합 문제, 팀 간 균형 맞추기 문제, 다음 스프린트 계획회의 준비 등에 대해 논의한다.

회사 수준 스크럼들의 스크럼

이 회의는 정보를 브리핑하는 포럼이다. 토의가 거의 없이 주로 정보를 전달하는 형태로 진행된다. 회의 형식은 다음과 같다.

1. 개발 총 책임자가 새소식과 최신 정보를 전한다.
2. 제품 그룹별로 돌아가며 이야기 한다. (무엇을 했는지, 무엇을 할 것인지, 어떤 문제가 있는지)
3. 누구든지 자유롭게 정보를 보태거나 질문을 할 수 있다.

일일 스크럼 회의 엇갈리게 배치하기

팀이 모두 같은 시간에 일일 스크럼 회의를 한다면 문제를 겪게 될 것이다. 제품책임자는 하루에 한 팀의 일일 스크럼 회의만을 참석할 수 있기 때문이다.

엇갈리게 배치한다면 두 가지 장점이 있다.

1. 제품 책임자는 어떤 날이든 오전에 모든 일일 스크럼 회의에 참석할 수 있다.
2. 팀들이 다른 팀의 일일 스크럼 회의에 방문할 수 있다.

단점은 팀의 자유도가 적어진다.

소방수 팀

팀이 너무나 많은 시간을 장애 제거 활동에 소비해 스크럼을 적용할 수 없는 상황이 있다. 이런 경우 전담 소방수 팀 혹은 전담 스크럼 팀을 만들어 문제를 해결할 수 있다.

• 스크럼 팀의 임무: 시스템을 안정화하고 장애를 효과적으로 예방
• 소방수 팀의 임무: 장애 해결, 모든 종류의 방해로부터 스크럼 팀을 보호
  • 물리적으로도 스크럼 팀을 방 안쪽에, 소방수 팀은 문 앞에 위치시켜 보호할 수 있다.

제품 백로그를 나눌 것인가 말 것인가?

세 개의 모델을 평가해보자.

• 한명의 제품 책임자와 제품 백로그 하나(가장 선호하는 방법)
  • 제품 책임자가 현재 가진 최우선 관심사에 따라 팀을 구성할 수 있음
  • 제품 책임자는 벽면 하나를 '제품 백로그 벽'으로 지정하고 우선순위에 따라 스토리들을 순서 조절
  • 각 스크럼 팀은 자신들이 사용할 빈 벽면을 선택하고 스토리를 팀 간에 카드를 옮기기도 하며 팀 벽에 스프린트 백로그를 구성
• 한 명의 제품 책임자와 제품 백로그 여러 개
  • 제품 책임자가 팀에 스토리를 할당하는 것이 약점
  • 팀이 자체적으로 백로그를 할당하는 것이 낫기 때문
• 여러 명의 제품 책임자와 제품 책임자마다 제품 백로그 하나
  • 같은 코드베이스에 두 개의 제품 백로그를 두면 두명의 제품 책임자간 심각한 이해관계의 충돌 발생
  • 각 제품 백로그마다 코드 베이스를 분리하면 근본적으로 전체 제품을 작은 제품들로 나누고 각각의 제품들을 독립적으로 실행하는 것과 같음(전략 1과 동일)

코드 가지치기

여러 팀이 하나의 코드 베이스에서 작업하면 코드 가지치기를 신경써야 한다. 저자가 겪은 가장 중요한 경험 몇가지를 소개한다.

• 메인 라인을 일관된 상태로 엄격히 유지하라.
• 각 릴리스마다 식별하는 버전 태그를 달아라.
• 꼭 필요할 때만 가지를 새로 만들라.
• 가지는 주로 생명주기를 달리할 때 사용하라.
• 자주 동기화하라.

여러 팀 회고

하나의 제품에 여러 팀이 작업을 하고 스프린트 회고는 아래와 같이 진행된다.

• 팀은 각자 자기 팀방으로 이동하거나 분리된 장소에서 회고를 진행
• 스프린트 계획회의 동안 각 팀에서 팀 회고의 중요한 내용들을 요약하여 발표
• 공개 토론 이후 스프린트 회의 시작

단일 팀이 만드는 제품에 대해선 스프린트 계획회의 중에 회고 요약을 하지 않는다. 모든 사람들이 실제 회고 미팅에 참석하기 때문에 그렇게 할 필요가 없다.

지리적으로 분산되어 있는 팀 다루기

스크럼과 XP '마법'의 많은 부분들은 팀원들이 같은 곳에서 짝 프로그래밍을 하고 매일 얼굴을 마주하는 밀접한 협업에 기반한다. 재택근무 혹은 지리적 문제로 이를 할 수 없을 때, 팀원들 간에 커뮤니케이션 범위를 최대화 하기 위해 모든 수단을 사용한다.

커뮤니케이션 범위는 물리적인 통신 속도만이 아니라 아래와 같은 폭넓은 의사소통을 의미한다.

• 함께 짝 프로그래밍을 할 수 있음
• 얼굴을 마주보며 일일 스크럼 회의를 할 수 있음
• 아무 때나 얼굴을 마주보며 토론할 수 있음
• 직접 대면하고 교제할 수 있음
• 팀 전체 회의를 자연 발생적으로 할 수 있음
• 스프린트 백로그와 스프린트 번다운 차트 등을 동일한 시각으로 바라볼 수 있음

저자가 적용했었던 몇 가지 방법이다.

• 워크스테이션마다 웹캠과 헤드셋
• 웹캠, 회의용 마이크, 항상 켜져 있고 사용 가능한 컴퓨터, 데스크탑 공유 소프트웨어 등이 갖춰진 '원격 회의가 가능한' 회의실
• 원격 창. 두 부서 사이의 일종의 가상 창
• 정기적으로 각 장소의 사람들을 다른 장소로 여행시키거나 방문하도록 하는 교환 프로그램

오프쇼어링

오프쇼어링 팀과 관련해 주요 전략은 분리된 팀과 분리된 팀원이 있다.

저자의 경우 분리된 팀원, 하나의 스크럼 팀이라는 두 번째 전략을 사용했는데 이유는 아래와 같다.

1. 팀원들이 서로 잘 알기 원한다.
2. 두 지역 사이에 뛰어난 커뮤니케이션 인프라를 원하는데, 각 팀이 그것을 구축할 수 있도록 강한 동기를 부여하기 원한다.
3. 초반 오프쇼어링 팀의 규모가 너무 작아 스스로 효과적인 스크럼 팀을 구성할 수 없어서
4. 집중적인 지식 공유 기간을 갖기 위해

장기적인 안목으로 보면 '분리된 팀' 전략으로 가는게 좋다고 한다.

재택근무하는 팀원

스크럼의 기본 중 하나는 팀 전체가 물리적으로 모여 있는 것이다. 따라서 '대부분'의 시간에 물리적으로 모여있을 것을 권장하지만 때로는 집에서 일하는 것이 정말 좋을 수 있다. 이를 위해 팀들이 스스로 재택근무를 언제, 얼마나 자주 하면 좋을지 스스로 결정하도록 한다.

스크럼 마스터 체크리스트

스프린트 초기

• 스프린트 계획회의 후 스프린트 정보 페이지를 만든다.
  • 위키 상황판에 스크럼 페이지 링크를 추가한다.
  • 페이지를 출력하여 팀 앞 사람들이 지나다니는 벽에 붙인다.
• 새로운 스프린트가 시작됨을 전원에게 공지하고 메일에 스프린트 목표와 스프린트 정보 페이지의 링크를 포함시켜라.
• 스프린트 통계 문서를 갱신한다. 추정 속도, 팀 크기, 스프린트 길이 등을 추가하라.

매일

• 일일 스크럼 회의가 제때에 시작되고 마치도록 한다.
• 스프린트 일정 계획을 준수할 수 있는 만큼만 스프린트 백로그에서 스토리들을 추가/삭제 하라.
• 제품 책임자가 이런 변경사항을 알게 하라.
• 팀이 스프린트 백로그와 소멸차트를 항상 최신으로 유지하라.
• 제품 책임자와 개발 총책임자에게 문제/장애 요소들이 발견되거나 해결되었다는 것을 보고하라.

스프린트 종료

• 스프린트 데모를 실시하라.
• 하루나 이틀 전 데모가 있다는 것을 모든 사람들에게 알려라.
• 전 팀원과 제품 책임자가 함게 스프린트 회고를 실시하라. 개발 총 책임자도 초대하라. 이 사람이 팀이 얻은 교훈을 널리 전파하는데 도움을 줄 수 있을 것이다.
• 스프린트 통계 문서를 갱신하라. 실제 속도와 회고의 주요 내용들을 추가하라.