You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
이 책의 첫 초안을 작성하는 데는 단지 한 주말밖에 걸리지 않았지만, 정말 집중적인 주말이었습니다! 150% 집중력이었죠. :o)
그 주말 동안 저의 비사교성을 참아준 아내 Sophia와 아이들 Dave, Jenny에게 감사드립니다. 그리고 가족을 돌봐주러 와주신 Sophia의 부모님 Eva와 Jörgen에게도 감사드립니다.
또한 Stockholm의 Crisp 동료들과 Scrum Users Yahoo 그룹의 사람들이 교정을 봐주고 이 책을 개선하는 데 도움을 준 것에 대해 감사드립니다.
마지막으로, 지속적으로 유용한 피드백을 제공해주신 모든 독자분들께 감사드립니다. 특히 이 책이 여러분 중 많은 분들이 애자일 소프트웨어 개발을 시도하게 만들었다는 소식을 듣게 되어 매우 기쁩니다!
Jeff Sutherland의 서문
팀들은 스크럼의 기본을 알아야 합니다. 제품 백로그를 어떻게 만들고 추정하나요? 그것을 어떻게 스프린트 백로그로 전환하나요? 번다운 차트를 어떻게 관리하고 팀 속도를 어떻게 계산하나요? Henrik의 책은 팀들이 스크럼을 시도하는 것을 넘어 스크럼을 잘 실행하도록 돕는 기본 실천법들의 시작 키트입니다.
좋은 스크럼 실행은 투자 자금을 원하는 팀들에게 점점 더 중요해지고 있습니다. 벤처 캐피털 그룹의 애자일 코치로서, 저는 애자일 실천법을 잘 실행하는 애자일 기업에만 투자한다는 그들의 목표를 돕고 있습니다. 그룹의 수석 파트너는 모든 포트폴리오 회사들에게 그들 팀의 속도를 아는지 묻고 있습니다. 그들은 지금 당장은 그 질문에 대답하는 데 어려움을 겪고 있습니다. 미래의 투자 기회는 개발 팀들이 자신들의 소프트웨어 생산 속도를 이해할 것을 요구할 것입니다.
이것이 왜 그렇게 중요할까요? 팀들이 속도를 모른다면, 제품 소유자는 신뢰할 수 있는 릴리스 날짜가 있는 제품 로드맵을 만들 수 없습니다. 신뢰할 수 있는 릴리스 날짜가 없으면 회사는 실패할 수 있고 투자자들은 돈을 잃을 수 있습니다!
이 문제는 크고 작은, 신생이든 오래된, 자금이 있든 없든 모든 회사들이 직면하는 문제입니다. 최근 런던 컨퍼런스에서 구글의 스크럼 구현에 대한 토론에서, 저는 135명의 청중에게 얼마나 많은 사람들이 스크럼을 하고 있는지 물었고 30명이 긍정적으로 응답했습니다. 그런 다음 저는 그들이 노키아 표준에 따라 반복적 개발을 하고 있는지 물었습니다. 반복적 개발은 애자일 선언문의 기본입니다 - 작동하는 소프트웨어를 일찍 그리고 자주 제공하는 것입니다. 수백 개의 스크럼 팀들과 수년간의 회고를 거친 후, 노키아는 반복적 개발을 위한 몇 가지 기본 요구사항을 개발했습니다:
반복은 고정된 타임박스를 가져야 하며 6주 미만이어야 합니다.
반복이 끝날 때의 코드는 QA에 의해 테스트되고 제대로 작동해야 합니다.
스크럼을 한다고 말한 30명 중에서 절반만이 노키아 표준에 따라 애자일 선언문의 첫 번째 원칙을 충족한다고 말했습니다. 그런 다음 저는 그들이 스크럼에 대한 노키아 표준을 충족하는지 물었습니다:
스크럼 팀은 제품 소유자가 있어야 하고 그 사람이 누구인지 알아야 합니다.
제품 소유자는 팀이 만든 추정치가 있는 제품 백로그를 가져야 합니다.
팀은 번다운 차트를 가져야 하고 자신들의 속도를 알아야 합니다.
스프린트 동안 팀 외부의 누구도 팀을 방해해서는 안 됩니다.
스크럼을 하는 30명 중 오직 3명만이 스크럼 팀에 대한 노키아 테스트를 충족했습니다. 이들만이 제 벤처 파트너들로부터 미래 투자를 받을 팀들입니다.
Henrik의 책의 가치는 그가 설명하는 실천법들을 따른다면, 제품 백로그, 제품 백로그에 대한 추정치, 번다운 차트를 갖게 되고, 고도로 기능적인 스크럼을 위한 많은 다른 필수 실천법들과 함께 팀 속도를 알게 될 것이라는 점입니다. 여러분은 스크럼에 대한 노키아 테스트를 충족하고 여러분의 작업에 대한 투자를 받을 가치가 있게 될 것입니다. 만약 여러분이 스타트업 회사라면, 벤처 캐피털 그룹으로부터 자금을 받을 수도 있습니다. 여러분은 소프트웨어 개발의 미래이자 차세대 주요 소프트웨어 제품의 창조자가 될 수 있습니다.
Jeff Sutherland,
Ph.D., 스크럼의 공동 창시자
Mike Cohn의 서문
스크럼과 익스트림 프로그래밍(XP) 모두 팀들이 각 반복이 끝날 때까지 출하 가능한 작업의 구체적인 부분을 완성할 것을 요구합니다. 이러한 반복은 짧고 타임박스가 정해져 있도록 설계되었습니다. 짧은 시간 내에 작동하는 코드를 제공하는 데 중점을 두는 것은 스크럼과 XP 팀들이 이론을 위한 시간이 없다는 것을 의미합니다. 그들은 케이스 도구에서 완벽한 UML 모델을 그리거나, 완벽한 요구사항 문서를 작성하거나, 상상할 수 있는 모든 미래 변경사항을 수용할 수 있는 코드를 작성하는 것을 추구하지 않습니다. 대신, 스크럼과 XP 팀들은 일을 완수하는 데 집중합니다. 이 팀들은 그 과정에서 실수를 할 수 있다는 것을 받아들이지만, 그러한 실수를 찾는 가장 좋은 방법은 분석과 설계의 이론적 수준에서 소프트웨어에 대해 생각하는 것을 멈추고, 뛰어들어 손을 더럽히고 제품을 만들기 시작하는 것이라는 것도 깨닫습니다.
이론화보다는 실행에 초점을 맞추는 것이 바로 이 책을 차별화하는 것입니다. Henrik Kniberg가 이를 이해한다는 것은 처음부터 명백합니다. 그는 스크럼이 무엇인지에 대한 긴 설명을 제공하지 않습니다. 대신 그는 우리를 몇 가지 간단한 웹사이트로 안내합니다. 대신, Henrik은 바로 뛰어들어 즉시 그의 팀이 제품 백로그를 관리하고 작업하는 방법을 설명하기 시작합니다. 거기서 그는 잘 운영되는 애자일 프로젝트의 다른 모든 요소와 실천법들을 다룹니다. 이론화 없이. 참조 없이. 각주 없이. 필요하지 않습니다. Henrik의 책은 스크럼이 왜 작동하는지 또는 왜 이것저것을 시도하고 싶은지에 대한 철학적 설명이 아닙니다. 이것은 하나의 잘 운영되는 애자일 팀이 어떻게 작동하는지에 대한 설명입니다.
이것이 책의 부제인 "우리가 스크럼을 하는 방법"이 매우 적절한 이유입니다. 이것은 여러분이 스크럼을 하는 방식이 아닐 수도 있습니다. 이것은 Henrik의 팀이 스크럼을 하는 방식입니다. 여러분은 왜 다른 팀이 스크럼을 하는 방식에 관심을 가져야 할까요? 특히 잘하고 있는 사람들로부터 실제로 어떻게 했는지에 대한 이야기를 충분히 들으면서 스크럼을 더 잘하는 방법을 모두 배울 수 있기 때문에 관심을 가져야 합니다. 팀과 프로젝트 컨텍스트가 다른 모든 고려사항을 능가하기 때문에 스크럼 모범 사례 목록은 없고 앞으로도 없을 것입니다. 모범 사례 대신, 우리가 알아야 할 것은 좋은 사례와 그것들이 성공적이었던 맥락입니다. 성공적인 팀들과 그들이 어떻게 일했는지에 대한 충분한 이야기를 읽으면 스크럼과 XP를 사용할 때 여러분에게 던져질 장애물에 대비할 수 있을 것입니다.
Henrik은 우리가 실전에서 스크럼과 XP를 더 잘 수행하는 방법을 배울 수 있도록 필요한 맥락과 함께 수많은 좋은 사례를 제공합니다.
Mike Cohn,
『애자일 추정과 계획』과 『애자일 소프트웨어 개발을 위한 사용자 스토리』의 저자
서문: 스크럼이 효과가 있었어요!
스크럼이 효과가 있었습니다! 적어도 우리에게는 (제가 여기서 이름을 밝히고 싶지 않은 스톡홀름의 현재 고객사를 의미합니다). 여러분에게도 효과가 있기를 바랍니다! 이 문서가 그 과정에서 도움이 되기를 바랍니다.
이것은 제가 처음으로 개발 방법론(죄송합니다, Ken, 프레임워크)이 책에서 나온 그대로 작동하는 것을 본 경우입니다. 플러그 앤 플레이. 우리 모두 - 개발자, 테스터, 관리자 - 가 만족하고 있습니다. 이것은 우리가 어려운 상황에서 벗어나는 데 도움이 되었고, 심각한 시장 혼란과 직원 감축에도 불구하고 집중력과 추진력을 유지할 수 있게 해주었습니다.
놀라지 말았어야 한다고 말해야겠지만, 글쎄요, 놀랐습니다. 처음에 이 주제에 대한 몇 권의 책을 소화한 후, 스크럼은 좋아 보였지만 너무 좋아서 사실이 아닌 것 같았습니다(그리고 우리 모두는 "무언가가 너무 좋아서 사실이 아닌 것 같을 때..."라는 말을 알고 있습니다). 그래서 저는 정당하게 약간 회의적이었습니다. 하지만 1년 동안 스크럼을 수행한 후 저는 충분히 감명받았고(제 팀의 대부분의 사람들도 마찬가지입니다) 아마도 강력한 이유가 없는 한 새로운 프로젝트에서 기본적으로 스크럼을 계속 사용할 것입니다.
서문 - 2판
8년이 지났는데 이 책은 여전히 정말 인기가 있습니다. 와우! 이 작은 책이 이런 영향을 미칠 것이라고는 전혀 상상하지 못했습니다! 저는 여전히 이것을 애자일 소프트웨어 개발의 주요 가이드로 사용하는 팀, 관리자, 코치, 트레이너들을 도처에서 만납니다.
하지만 2007년 이후로 많은 것을 배웠습니다! 그래서 책을 정말 업데이트해야 합니다.
책을 출판한 이후, 저는 많은 애자일 및 린 사상가들과 함께 일할 기회를 가졌습니다. 일부는 개인 멘토처럼 되기도 했습니다. Jeff Sutherland, Mary와 Tom Poppendieck, Jerry Weinberg, Alistair Cockburn, Kent Beck, Ron Jeffries, Jeff Patton에게 특별히 감사드립니다 - 이보다 더 나은 조언자 그룹은 상상할 수 없습니다!
또한 위기에 처한 회사뿐만 아니라 더 나아지기를 원하는 매우 성공적인 회사들이 이러한 아이디어를 실제로 구현하는 데 도움을 줄 기회도 있었습니다. 전체적으로 꽤 놀라운 여정이었습니다!
이 오래된 책을 다시 읽을 때, 여전히 동의하는 것이 얼마나 많은지 놀랍습니다. 하지만 "*&€# 내가 무슨 생각을 했던 거야? 그렇게 하지 마! 훨씬 더 좋은 방법이 있어!"라고 말하며 찢어버리고 싶은 페이지들도 있습니다.
이 책은 실제 사례 연구이므로 이야기를 바꿀 수 없습니다. 일어난 일은 일어난 일입니다. 하지만 코멘트를 할 수는 있습니다!
그래서 2판은 원본의 주석이 달린 버전입니다. 감독판 같은 것입니다. 여러분이 책을 읽는 동안 제가 어깨 너머로 서서 이런저런 것에 대해 코멘트하고, 여러분을 응원하며, 가끔 웃거나 신음하는 것으로 생각하세요.
주석은 이렇게 생겼습니다. 나머지 모든 것(이 서문 제외)은 수정되지 않은 원본이며, 이 음영 처리된 상자는 2판에 대한 제 코멘트와 성찰입니다.
저는 또한 다른 회사들의 예제를 가져올 것입니다. 주로 Spotify(최근에 대부분의 시간을 보내고 있는 곳이기 때문에)와 다른 몇몇 곳들의 예제입니다.
즐기세요!
Henrik, 2015년 3월
제1부
소개
SCRUM AND XP FROM THE TRENCHES
여러분은 조직에서 스크럼 사용을 시작하려고 합니다. 또는 아마도 몇 달 동안 스크럼을 사용해 왔을 수도 있습니다. 기본을 알고 있고, 책을 읽었으며, 아마도 스크럼 마스터 자격증도 취득했을 것입니다. 축하합니다!
하지만 여전히 혼란스럽습니다.
Ken Schwaber의 말에 따르면, 스크럼은 방법론이 아니라 프레임워크입니다. 그것이 의미하는 바는 스크럼이 정확히 무엇을 해야 하는지 알려주지 않는다는 것입니다. 젠장.
좋은 소식은 제가 정확히 어떻게 스크럼을 수행하는지 고통스러울 정도로 상세하게 알려드리겠다는 것입니다. 나쁜 소식은, 음, 이것은 제가 스크럼을 수행하는 방법일 뿐이라는 것입니다. 그것이 여러분이 정확히 같은 방식으로 해야 한다는 것을 의미하지는 않습니다. 사실, 제가 다른 상황을 만나면 다른 방식으로 할 수도 있습니다.
스크럼의 강점이자 고통은 여러분이 특정 상황에 맞게 조정해야 한다는 것입니다.
제 현재의 스크럼 접근법은 약 40명의 개발 팀에서 1년간의 스크럼 실험의 결과입니다. 회사는 높은 초과 근무, 심각한 품질 문제, 지속적인 긴급 대응, 마감일 미달성 등으로 어려운 상황에 있었습니다. 회사는 스크럼을 사용하기로 결정했지만 실제로 구현을 완료하지 못했으며, 이것이 제 임무였습니다. 그 당시 개발 팀의 대부분의 사람들에게 "스크럼"은 복도에서 가끔 메아리치는 이상한 유행어일 뿐이었고, 그들의 일상 업무에는 아무런 영향을 미치지 않았습니다.
1년 동안 우리는 회사의 모든 계층에서 스크럼을 구현했고, 다양한 팀 규모(3-12명), 다양한 스프린트 길이(2-6주), "완료"를 정의하는 다양한 방법, 제품 백로그와 스프린트 백로그의 다양한 형식(Excel, Jira, 인덱스 카드), 다양한 테스트 전략, 데모를 수행하는 다양한 방법, 여러 스크럼 팀을 동기화하는 다양한 방법 등을 시도했습니다. 또한 XP 실천법들 - 지속적 빌드를 수행하는 다양한 방법, 페어 프로그래밍, 테스트 주도 개발 등 - 을 실험했고, 이를 스크럼과 결합하는 방법도 실험했습니다.
이것은 지속적인 학습 과정이므로 이야기는 여기서 끝나지 않습니다. 저는 이 회사가 계속 학습하고(스프린트 회고를 계속한다면) 특정 맥락에서 스크럼을 가장 잘 구현하는 방법에 대한 새로운 통찰력을 얻을 것이라고 확신합니다.
면책 조항
이 문서는 스크럼을 수행하는 "올바른 방법"을 나타낸다고 주장하지 않습니다! 이것은 단지 스크럼을 수행하는 한 가지 방법, 1년 동안 지속적으로 개선한 결과를 나타낼 뿐입니다. 여러분은 우리가 모든 것을 잘못하고 있다고 결정할 수도 있습니다.
이 문서의 모든 내용은 제 개인적인 주관적 의견을 반영하며, Crisp이나 현재 고객사의 공식 성명이 아닙니다. 이러한 이유로 저는 의도적으로 특정 제품이나 사람을 언급하는 것을 피했습니다.
왜 이것을 썼는가
스크럼에 대해 배울 때 저는 관련 스크럼 및 애자일 책들을 읽고, 스크럼에 대한 사이트와 포럼을 샅샅이 뒤지고, Ken Schwaber의 자격증을 취득하고, 그에게 질문을 퍼부었으며, 동료들과 많은 시간을 토론했습니다. 그러나 가장 가치 있는 정보 소스 중 하나는 실제 전쟁 이야기였습니다. 전쟁 이야기는 원칙과 실천을 실제로 어떻게 하는지로 바꿉니다. 또한 전형적인 스크럼 초보자 실수를 식별하고(때로는 피하는) 데 도움이 되었습니다.
그래서 이것은 제가 무언가를 돌려주는 기회입니다. 여기 제 전쟁 이야기가 있습니다.
이 문서가 같은 상황에 있는 여러분 중 일부로부터 유용한 피드백을 유발하기를 바랍니다. 저를 계몽해 주세요!
그런데 스크럼이 무엇인가요?
아, 죄송합니다. 스크럼이나 XP가 완전히 처음이신가요? 그렇다면 다음 링크들을 살펴보시는 것이 좋을 것 같습니다:
그것을 하기에 너무 조급하다면, 그냥 계속 읽으세요. 대부분의 스크럼 전문 용어는 진행하면서 설명되므로 여전히 흥미로울 수 있습니다.
제2부
제품 백로그를 수행하는 방법
SCRUM AND XP FROM THE TRENCHES
제품 백로그는 스크럼의 핵심입니다. 모든 것이 여기서 시작됩니다.
어, 아니요, 제품 백로그가 시작점은 아닙니다. 좋은 제품은 고객의 필요와 이를 해결하는 방법에 대한 비전으로 시작합니다. 제품 백로그는 그 비전을 구체적인 결과물로 정제한 결과입니다. 비전에서 백로그로 가는 여정은 꽤 복잡할 수 있으며, 그 격차를 메우기 위해 많은 기술이 등장했습니다. 사용자 스토리 매핑(Jeff Patton의 책을 읽어보세요, 훌륭합니다!), 린 UX, 영향 매핑 등과 같은 것들입니다. 하지만 이것을 대규모 사전 설계의 핑계로 사용하지 마세요! 제품 백로그가 다른 모든 것과 마찬가지로 반복적으로 나타나도록 하세요.
제품 백로그는 기본적으로 요구사항, 스토리, 기능 또는 무엇이든 간에 우선순위가 지정된 목록입니다. 고객이 원하는 것들이며, 고객의 용어를 사용하여 설명됩니다.
우리는 이것을 스토리 또는 때로는 단순히 백로그 항목이라고 부릅니다.
우리의 스토리에는 다음 필드가 포함됩니다:
• ID – 고유 식별자, 단순히 자동 증가하는 숫자입니다. 이는 스토리의 이름을 변경할 때 추적을 잃지 않기 위함입니다.
• 이름 – 스토리의 짧고 설명적인 이름. 예를 들어 "자신의 거래 내역 보기." 개발자와 제품 소유자가 우리가 무엇에 대해 이야기하는지 대략적으로 이해할 수 있을 정도로 명확하고, 다른 스토리와 구별할 수 있을 정도로 명확해야 합니다. 일반적으로 2-10단어입니다.
• 중요도 – 이 스토리에 대한 제품 소유자의 중요도 평가. 예를 들어 10. 또는 150. 높을수록 = 더 중요함.
저는 "우선순위"라는 용어를 피하는 경향이 있습니다. 왜냐하면 우선순위 1이 일반적으로 "가장 높은" 우선순위로 간주되는데, 나중에 더 중요한 것이 있다고 결정하면 보기 좋지 않기 때문입니다. 그것에 어떤 우선순위 등급을 줘야 할까요?
우선순위 0? 우선순위 -1?
• 초기 추정치 – 다른 스토리와 비교하여 이 스토리를 구현하는 데 필요한 작업량에 대한 팀의 초기 평가. 단위는 스토리 포인트이며 일반적으로 대략 "이상적인 인일(man-days)"에 해당합니다. 팀에게 물어보세요 "이 스토리에 최적의 인원(너무 적지도 너무 많지도 않은, 일반적으로 2명)을 투입하고, 음식이 많은 방에 그들을 가두고 완전히 방해받지 않고 작업한다면, 며칠 후에 완성되고, 시연 가능하고, 테스트되고, 릴리스 가능한 구현이 나올까요?" 대답이 "3명이 방에 갇혀 있으면 약 4일이 걸릴 것입니다"라면 초기 추정치는 12 스토리 포인트입니다.
중요한 것은 절대 추정치를 정확하게 맞추는 것이 아니라(즉, 2포인트 스토리가 2일이 걸려야 한다는 것), 상대적 추정치를 정확하게 맞추는 것입니다(즉, 2포인트 스토리는 4포인트 스토리의 약 절반의 작업이 필요해야 한다는 것).
• 데모 방법 – 이 스토리가 스프린트 데모에서 어떻게 시연될 것인지에 대한 상위 수준 설명. 이것은 본질적으로 간단한 테스트 사양입니다. "이것을 하고, 그 다음 저것을 하면, 이런 일이 일어나야 합니다."
TDD(테스트 주도 개발)를 실천한다면, 이 설명은 수락 테스트 코드의 의사 코드로 사용될 수 있습니다.
• 메모 – 기타 정보, 설명, 다른 정보 소스에 대한 참조 등. 일반적으로 매우 간략합니다.
제품 백로그 (예시)
ID
이름
중요도
추정치
데모 방법
메모
1
입금
30
5
로그인, 입금 페이지 열기, €10 입금, 내 잔액 페이지로 이동하여 €10가 증가했는지 확인.
UML 시퀀스 다이어그램 필요. 지금은 암호화에 대해 걱정할 필요 없음.
2
자신의 거래 내역 보기
10
8
로그인, "거래" 클릭. 입금하기. 거래로 돌아가서 새 입금이 표시되는지 확인.
대용량 DB 쿼리를 피하기 위해 페이징 사용. 사용자 보기 페이지와 유사한 디자인.
우리는 많은 다른 필드들을 실험했지만, 결국 위의 6개 필드만이 스프린트마다 실제로 사용한 유일한 필드였습니다.
두 가지는 이제 거의 항상 다르게 합니다. 첫째, "중요도" 열이 없습니다. 대신 목록을 정렬합니다. 거의 모든 백로그 관리 도구에는 드래그 앤 드롭 재정렬 기능이 있습니다(Excel과 Google 스프레드시트도 최고 비밀 키 조합을 배우면 가능합니다). 더 쉽고 빠릅니다. 둘째, 인일(man-days)이 없습니다. 추정치는 스토리 포인트나 티셔츠 크기(S/M/L)로 하거나, 아예 추정치가 없을 수도 있습니다. 하지만 이에 대해서는 나중에 더 설명하겠습니다.
우리는 일반적으로 공유가 활성화된 Excel 문서에서 이 작업을 수행합니다(즉, 여러 사용자가 동시에 편집할 수 있음). 공식적으로 제품 소유자가 이 문서를 소유하지만, 다른 사용자를 잠그고 싶지 않습니다. 많은 경우 개발자가 문서를 열어 무언가를 명확히 하거나 추정치를 변경하고 싶어합니다.
같은 이유로, 우리는 이 문서를 버전 관리 저장소에 두지 않습니다. 대신 공유 드라이브에 둡니다. 이것이 잠금이나 병합 충돌을 일으키지 않고 여러 동시 편집자를 허용하는 가장 간단한 방법으로 밝혀졌습니다.
그러나 거의 모든 다른 아티팩트는 버전 관리 저장소에 배치됩니다.
Excel이라고요? 와, 그때가 그리웠네요. 오늘날에는 클라우드 버전이 아닌 한 백로그 관리에 Excel을 사용하는 것을 고려하지 않을 것입니다. 제품 백로그는 누구나 쉽게 동시에 액세스하고 편집할 수 있는 공유 온라인 문서에 있어야 합니다. 사용 가능한 수많은 백로그 관리 도구(Trello, LeanKit, Jira가 인기 있음) 중 하나이거나 Google 스프레드시트(매우 실용적!)입니다.
추가 스토리 필드
때때로 우리는 제품 백로그에 추가 필드를 사용합니다. 주로 제품 소유자가 우선순위를 정리하는 데 도움이 되는 편의를 위해서입니다:
• 트랙 – 이 스토리의 대략적인 분류, 예를 들어 "백 오피스" 또는 "최적화". 이렇게 하면 제품 소유자가 모든 "최적화" 항목을 쉽게 필터링하고 우선순위를 낮게 설정할 수 있습니다.
• 구성 요소 - 일반적으로 Excel 문서에서 "체크박스"로 구현됩니다. 예를 들어 "데이터베이스, 서버, 클라이언트". 여기서 팀이나 제품 소유자는 이 스토리를 구현하는 데 관련될 기술 구성 요소를 식별할 수 있습니다. 이는 여러 스크럼 팀이 있을 때 유용합니다. 예를 들어 백 오피스 팀과 클라이언트 팀이 있고, 각 팀이 어떤 스토리를 맡을지 결정하기 쉽게 하고 싶을 때입니다.
• 요청자 – 제품 소유자는 항목을 원래 요청한 고객이나 이해관계자를 추적하여 진행 상황에 대한 피드백을 제공하고 싶을 수 있습니다.
• 버그 추적 ID – Jira와 같은 별도의 버그 추적 시스템이 있는 경우, 스토리와 하나 이상의 보고된 버그 간의 직접적인 대응 관계를 추적하는 것이 유용합니다.
제품 백로그를 비즈니스 수준으로 유지하는 방법
제품 소유자가 기술적 배경을 가지고 있다면, "이벤트 테이블에 인덱스 추가"와 같은 스토리를 추가할 수 있습니다. 왜 이것을 원할까요? 실제 근본적인 목표는 아마도 "백 오피스의 이벤트 검색 양식 속도 향상"과 같은 것일 것입니다.
인덱스가 양식이 느린 원인이 되는 병목 현상이 아닐 수도 있습니다. 완전히 다른 것일 수도 있습니다. 팀은 일반적으로 무언가를 해결하는 방법을 파악하는 데 더 적합하므로 제품 소유자는 비즈니스 목표에 집중해야 합니다.
이와 같은 기술 지향적인 스토리를 볼 때, 저는 일반적으로 근본적인 목표를 찾을 때까지 제품 소유자에게 일련의 "하지만 왜?" 질문을 합니다. 그런 다음 근본적인 목표("백 오피스의 이벤트 검색 양식 속도 향상") 측면에서 스토리를 다시 표현합니다. 원래의 기술적 설명은 메모로 끝납니다("이벤트 테이블 인덱싱이 이 문제를 해결할 수 있음").
이를 위한 오래되고 잘 확립된 템플릿이 있습니다: "X로서, 나는 Y를 원한다, 그래서 Z를 할 수 있다." 예를 들어 "구매자로서, 나는 내 장바구니를 저장하고 싶다, 그래서 내일 쇼핑을 계속할 수 있다." 2007년에 이것을 들어본 적이 없다니 정말 놀랍습니다! 매우 편리했을 텐데요. 예, 요즘에는 더 정교한 템플릿을 사용할 수 있지만, 이 간단한 템플릿은 특히 애자일에 익숙하지 않은 팀에게 좋은 출발점입니다. 템플릿은 올바른 유형의 질문을 하도록 강요하고 기술적인 세부 사항에 갇힐 위험을 줄입니다.
제3부
스프린트 계획을 준비하는 방법
SCRUM AND XP FROM THE TRENCHES
좋아요, 스프린트 계획일이 빠르게 다가오고 있습니다. 우리가 계속해서 배우는 한 가지 교훈은: 스프린트 계획 회의 전에 제품 백로그가 정상 상태인지 확인하세요.
아멘! 제품 백로그가 엉망이어서 망가진 스프린트 계획 회의를 많이 봤습니다. "쓰레기를 넣으면 = 쓰레기가 나온다"는 말을 아시죠? 정확히 그렇습니다.
그리고 그것은 무엇을 의미할까요? 모든 스토리가 완벽하게 잘 정의되어야 한다는 것일까요? 모든 추정치가 정확해야 한다는 것일까요? 모든 우선순위가 고정되어야 한다는 것일까요? 아니요, 아니요, 그리고 아니요! 그것이 의미하는 것은:
• 제품 백로그가 존재해야 합니다! (상상해 보세요?)
• 하나의 제품 백로그와 하나의 제품 소유자가 있어야 합니다(제품당).
• 모든 중요한 항목에는 중요도 등급이 할당되어야 하며, 서로 다른 중요도 등급이어야 합니다.
• 실제로, 낮은 중요도 항목이 모두 같은 값을 가지는 것은 괜찮습니다. 어차피 스프린트 계획 회의 중에 제기되지 않을 것이기 때문입니다.
• 제품 소유자가 다음 스프린트에 포함될 가능성이 조금이라도 있다고 생각하는 모든 스토리는 고유한 중요도 수준을 가져야 합니다.
• 중요도 등급은 항목을 중요도별로 정렬하는 데만 사용됩니다. 따라서 항목 A의 중요도가 20이고 항목 B의 중요도가 100이면, 단순히 B가 A보다 더 중요하다는 의미입니다. B가 A보다 5배 더 중요하다는 의미는 아닙니다. B의 중요도 등급이 21이었다면 여전히 정확히 같은 의미입니다!
• A보다 중요하지만 B보다 덜 중요한 항목 C가 나타날 경우를 대비하여 숫자 시퀀스에 간격을 두는 것이 유용합니다. 물론 C에 대해 20.5의 중요도 등급을 사용할 수 있지만, 보기 좋지 않으므로 대신 간격을 둡니다!
뭐, 목록을 정렬하면 중요도 등급을 만지작거릴 필요가 없습니다.
• 제품 소유자는 각 스토리를 이해해야 합니다(일반적으로 그가 작성자이지만, 경우에 따라 다른 사람이 요청을 추가하고 제품 소유자가 우선순위를 지정할 수 있습니다). 그는 정확히 무엇을 구현해야 하는지 알 필요는 없지만, 스토리가 왜 거기에 있는지는 이해해야 합니다.
참고: 제품 소유자 이외의 사람들이 제품 백로그에 스토리를 추가할 수 있습니다. 하지만 중요도 수준을 할당할 수는 없습니다. 그것은 제품 소유자의 독점적인 권리입니다. 또한 시간 추정치를 추가할 수도 없습니다. 그것은 팀의 독점적인 권리입니다.
우리가 시도했거나 평가한 다른 접근법:
• Jira(우리의 버그 추적 시스템)를 사용하여 제품 백로그를 보관합니다. 그러나 대부분의 제품 소유자는 너무 클릭이 많다고 생각합니다. Excel은 직접 조작하기 좋고 쉽습니다. 색상 코딩, 항목 재배열, 임시로 새 열 추가, 메모 추가, 데이터 가져오기 및 내보내기 등을 쉽게 할 수 있습니다.
Google 스프레드시트도 마찬가지입니다. 그리고 클라우드에 있습니다. 다중 사용자, 동시 편집. 그냥 말하는 거예요.
VersionOne, ScrumWorks, XPlanner 등과 같은 애자일 프로세스 지원 도구 사용. 우리는 아직 이들 중 어떤 것도 테스트하지 못했지만 아마 할 것입니다.
제4부
스프린트 계획을 수행하는 방법
SCRUM AND XP FROM THE TRENCHES
스프린트 계획은 중요한 회의이며, 아마도 스크럼에서 가장 중요한 이벤트일 것입니다(물론 제 주관적인 의견입니다). 잘못 실행된 스프린트 계획 회의는 전체 스프린트를 망칠 수 있습니다.
중요한가요? 예. 스크럼에서 가장 중요한 이벤트? 아니요! 회고가 훨씬 더 중요합니다! 잘 기능하는 회고는 망가진 다른 것들을 고치는 데 도움이 되기 때문입니다. 스프린트 계획은 다른 것들이 제자리에 있는 한(좋은 제품 백로그, 참여하는 제품 소유자와 팀 등) 꽤 사소한 경향이 있습니다. 또한 스프린팅만이 애자일한 유일한 방법은 아닙니다. 많은 팀이 대신 칸반을 사용합니다. 저는 그것에 대한 미니북도 썼습니다: "칸반과 스크럼: 둘 다 최대한 활용하기".
http://www.infoq.com/minibooks/kanban-scrum-minibook
스프린트 계획 회의의 목적은 팀에게 몇 주 동안 방해받지 않고 평화롭게 일할 수 있는 충분한 정보를 제공하고, 제품 소유자에게 그렇게 하도록 허용할 충분한 자신감을 주는 것입니다.
좋아요, 그것은 모호했습니다. 스프린트 계획 회의의 구체적인 결과물은:
• 스프린트 목표
• 팀 구성원 목록(및 100%가 아닌 경우 그들의 헌신 수준)
• 스프린트 백로그(= 스프린트에 포함된 스토리 목록)
• 정의된 스프린트 데모 날짜
• 일일 스크럼을 위한 정의된 시간과 장소
제품 소유자가 참석해야 하는 이유
때때로 제품 소유자는 팀과 함께 스프린트 계획에 시간을 보내는 것을 꺼립니다. "여러분, 저는 이미 제가 원하는 것을 나열했습니다. 여러분의 계획 회의에 참석할 시간이 없습니다." 그것은 꽤 심각한 문제입니다.
전체 팀과 제품 소유자가 스프린트 계획 회의에 참석해야 하는 이유는 각 스토리에 서로 높은 의존성을 가진 세 가지 변수가 포함되어 있기 때문입니다.
범위와 중요도는 제품 소유자가 설정합니다. 추정치는 팀이 설정합니다. 스프린트 계획 회의 동안 이 세 변수는 팀과 제품 소유자 간의 대면 대화를 통해 지속적으로 미세 조정됩니다.
일반적으로 제품 소유자는 스프린트 목표와 가장 중요한 스토리를 요약하여 회의를 시작합니다. 다음으로, 팀은 가장 중요한 것부터 시작하여 각 스토리를 검토하고 시간을 추정합니다. 이 과정에서 중요한 범위 질문이 나올 것입니다 - "이 '사용자 삭제' 스토리에는 해당 사용자의 모든 대기 중인 거래를 검토하고 취소하는 것이 포함됩니까?" 어떤 경우에는 답변이 팀을 놀라게 하여 추정치를 변경하게 할 것입니다.
어떤 경우에는 스토리의 시간 추정치가 제품 소유자가 예상한 것과 다를 수 있습니다. 이로 인해 그가 스토리의 중요도를 변경할 수 있습니다. 또는 스토리의 범위를 변경할 수 있으며, 이로 인해 팀이 다시 추정하게 됩니다. 등등.
이러한 유형의 직접적인 협업은 스크럼과 실제로 모든 애자일 소프트웨어 개발의 기본입니다.
제품 소유자가 여전히 스프린트 계획 회의에 참석할 시간이 없다고 주장한다면 어떻게 해야 할까요? 저는 일반적으로 주어진 순서대로 다음 전략 중 하나를 시도합니다:
• 제품 소유자가 왜 그의 직접 참여가 중요한지 이해하도록 돕고 마음을 바꾸기를 바랍니다.
• 회의 중에 제품 소유자 프록시로 자원하는 팀의 누군가를 구하려고 노력합니다. 제품 소유자에게 "회의에 참석할 수 없으므로 여기 Jeff가 프록시로 당신을 대표하게 하겠습니다. 그는 회의 중에 당신을 대신하여 스토리의 우선순위와 범위를 변경할 수 있는 완전한 권한을 갖게 됩니다. 회의 전에 가능한 한 그와 동기화하는 것이 좋습니다. Jeff가 프록시가 되는 것을 원하지 않으면 다른 사람을 제안해 주세요. 그 사람이 회의 전체 기간 동안 참석할 수 있는 한 말입니다."라고 말합니다.
• 경영진이 새로운 제품 소유자를 할당하도록 설득하려고 노력합니다.
• 제품 소유자가 회의에 참석할 시간을 찾을 때까지 스프린트 시작을 연기합니다. 그 동안 어떤 배송도 약속하지 않습니다. 팀이 매일 그날 가장 중요하다고 느끼는 것을 하도록 합니다.
이 섹션의 좋은 내용! <등을 토닥이며>
한 가지만 - 백로그 개선(추정, 스토리 분할 등)을 별도의 회의로 분리하여 스프린트 계획이 더 집중될 수 있도록 강력히 권장합니다. 제품 소유자 참여는 여전히 두 회의 모두에서 중요합니다.
품질이 협상 불가능한 이유
위의 삼각형에서 저는 의도적으로 네 번째 변수인 품질을 피했습니다.
저는 내부 품질과 외부 품질을 구분하려고 노력합니다:
• 외부 품질은 시스템 사용자가 인식하는 것입니다. 느리고 직관적이지 않은 사용자 인터페이스는 열악한 외부 품질의 예입니다.
• 내부 품질은 일반적으로 사용자에게 보이지 않지만 시스템의 유지 보수성에 심오한 영향을 미치는 문제를 말합니다. 시스템 설계 일관성, 테스트 커버리지, 코드 가독성, 리팩토링 등과 같은 것들입니다.
일반적으로 내부 품질이 높은 시스템도 외부 품질이 낮을 수 있습니다. 그러나 내부 품질이 낮은 시스템은 외부 품질이 높은 경우가 드뭅니다. 썩은 기초 위에 좋은 것을 만들기는 어렵습니다.
저는 외부 품질을 범위의 일부로 취급합니다. 어떤 경우에는 서툴고 느린 사용자 인터페이스를 가진 시스템 버전을 출시하고 나중에 정리된 버전을 출시하는 것이 완벽한 비즈니스 감각을 가질 수 있습니다. 저는 그 트레이드오프를 제품 소유자에게 맡깁니다. 왜냐하면 그가 범위를 결정할 책임이 있기 때문입니다.
그러나 내부 품질은 논의 대상이 아닙니다. 모든 상황에서 시스템의 품질을 유지하는 것은 팀의 책임이며 이것은 단순히 협상할 수 없습니다. 절대로.
(음, 좋아요, 거의 절대로.)
그렇다면 내부 품질 문제와 외부 품질 문제의 차이를 어떻게 구분할까요?
제품 소유자가 "좋아요 여러분, 6 스토리 포인트의 시간 추정치를 존중하지만, 마음만 먹으면 절반의 시간에 일종의 빠른 수정을 할 수 있을 거라고 확신합니다."라고 말한다고 가정해 봅시다.
아하! 그는 내부 품질을 변수로 사용하려고 합니다. 어떻게 알 수 있나요? 왜냐하면 그는 범위를 줄이는 "대가를 지불"하지 않고 스토리의 추정치를 줄이기를 원하기 때문입니다. "빠른 수정"이라는 문구는 머릿속에서 경보를 울려야 합니다....
그리고 왜 우리는 이것을 허용하지 않습니까?
제 경험상 내부 품질을 희생하는 것은 거의 항상 끔찍하고 끔찍한 생각입니다. 절약된 시간은 단기 및 장기적으로 비용에 의해 훨씬 능가됩니다. 코드베이스가 한 번 악화되기 시작하면 나중에 품질을 다시 넣기가 매우 어렵습니다.
대신 저는 토론을 범위로 유도하려고 합니다. "이 기능을 일찍 출시하는 것이 중요하므로 더 빨리 구현할 수 있도록 범위를 줄일 수 있을까요? 아마도 오류 처리를 단순화하고 '고급 오류 처리'를 미래를 위해 저장하는 별도의 스토리로 만들 수 있을까요? 아니면 이 스토리에 집중할 수 있도록 다른 스토리의 우선순위를 줄일 수 있을까요?"
제품 소유자가 내부 품질이 협상할 수 없다는 것을 배우면, 일반적으로 대신 다른 변수를 조작하는 데 꽤 능숙해집니다.
원칙적으로는 그렇습니다. 하지만 실제로는 요즘 더 실용적인 경향이 있습니다. 때로는 단기적으로 품질을 희생하는 것이 완벽한 비즈니스 감각을 가집니다. 예를 들어, 다음 스프린트 후에 이 초중요한 무역 박람회가 있거나 사용자 행동에 대한 가설을 검증하기 위한 프로토타입이 필요하기 때문입니다. 그러나 그러한 경우 제품 소유자는 왜 이렇게 하는지 명확히 하고 가까운 미래에 팀이 기술 부채를 상환하도록 약속해야 합니다(때로는 팀이 리마인더로 제품 백로그에 "정리" 스토리를 추가합니다). 높은 내부 품질이 표준이어야 하며 예외는 예외적으로 취급되어야 합니다.
끝없이 계속되는 스프린트 계획 회의...
스프린트 계획 회의에서 가장 어려운 점은:
사람들은 그렇게 오래 걸릴 것이라고 생각하지 않습니다...
...하지만 그렇습니다!
아니요, 그렇지 않습니다! 별도의 회의에서 백로그 개선을 수행한다면 말입니다. 제가 본 많은 팀들은 백로그 개선을 위해 매주 1시간씩 만나므로 스프린트 계획은 스프린트 계획에 집중할 수 있습니다! 이것은 또한 제품 소유자에게 스프린트 계획 회의 전에 제품 백로그를 논의하고 개선할 더 많은 기회를 제공하여 회의를 더 짧게 만듭니다. 지침: 스프린트 계획 회의는 일반적으로 스프린트 길이 주당 1시간 이상 걸리지 않아야 합니다(경험이 많은 팀의 경우 상당히 적게), 따라서 3주 스프린트의 경우 3시간 이하입니다.
스크럼의 모든 것은 시간 제한이 있습니다. 저는 하나의 간단하고 일관된 규칙을 좋아합니다. 우리는 그것을 고수하려고 노력합니다.
그렇다면 시간 제한이 있는 스프린트 계획 회의가 끝나가고 스프린트 목표나 스프린트 백로그의 징후가 없을 때 우리는 무엇을 할까요? 그냥 짧게 자를까요? 아니면 한 시간 연장할까요? 아니면 회의를 끝내고 다음 날 계속할까요?
이것은 특히 새로운 팀에게 계속해서 발생합니다. 그래서 무엇을 해야 할까요? 모르겠습니다. 하지만 우리는 무엇을 합니까? 오, 음, 일반적으로 저는 잔인하게 회의를 짧게 자릅니다. 끝냅니다. 스프린트가 고통받도록 합니다. 더 구체적으로, 저는 팀과 제품 소유자에게 "자, 이 회의는 10분 후에 끝납니다. 우리는 실제로 스프린트 계획이 많지 않습니다. 우리가 가진 것으로 만족해야 할까요, 아니면 내일 오전 8시에 또 다른 4시간 스프린트 계획 회의를 예약해야 할까요?"라고 말합니다. 그들이 무엇을 대답할지 짐작할 수 있습니다. :o)
저는 회의가 계속되도록 놔둔 적이 있습니다. 일반적으로 아무것도 달성하지 못합니다. 왜냐하면 사람들이 피곤하기 때문입니다. 그들이 2~8시간(또는 시간 상자가 얼마나 긴지)에 괜찮은 스프린트 계획을 만들지 못했다면, 아마도 한 시간을 더 준다고 해서 관리하지 못할 것입니다. 다음 옵션은 실제로 꽤 괜찮습니다: 다음 날 새 회의를 예약하는 것입니다. 사람들이 일반적으로 참을성이 없고 스프린트를 시작하고 싶어하며 또 다른 계획 시간을 보내고 싶어하지 않는다는 점을 제외하고는 말입니다.
아니다, 그렇지 않다! 백로그 정제(backlog refinement)를 별도의 회의에서 진행한다면 말이다. 내가 본 많은 팀들은 백로그 정제를 위해 매주 1시간씩 만나서, 스프린트 계획이 실제 스프린트 계획에만 집중할 수 있게 한다! 이는 또한 제품 책임자가 스프린트 계획 회의 전에 제품 백로그를 논의하고 개선할 기회를 더 많이 제공하여 회의를 더 짧게 만든다. 가이드라인: 스프린트 계획 회의는 보통 스프린트 길이의 주당 1시간을 넘지 않아야 한다(경험 많은 팀의 경우 훨씬 적게), 따라서 3주 스프린트의 경우 3시간 이하여야 한다.
스크럼의 모든 것은 타임박스로 되어 있다. 나는 이 하나의 간단하고 일관된 규칙을 좋아한다. 우리는 이를 지키려고 노력한다.
그렇다면 타임박스로 정해진 스프린트 계획 회의가 끝나가는데 스프린트 목표나 스프린트 백로그의 흔적조차 없을 때 우리는 무엇을 하는가? 그냥 짧게 끝내는가? 아니면 한 시간 더 연장하는가? 아니면 회의를 끝내고 다음 날 계속하는가?
이런 일은 계속해서 일어난다, 특히 새로운 팀의 경우. 그래서 당신은 무엇을 하는가? 나도 모른다. 하지만 우리는 무엇을 하는가? 아, 음, 보통 나는 무자비하게 회의를 짧게 끝낸다. 끝낸다. 스프린트가 고통받도록 놔둔다. 더 구체적으로, 나는 팀과 제품 책임자에게 말한다 "자, 이 회의는 10분 후에 끝납니다. 우리는 제대로 된 스프린트 계획이 별로 없습니다. 우리가 가진 것으로 만족해야 할까요, 아니면 내일 오전 8시에 또 다른 4시간 스프린트 계획 회의를 잡아야 할까요?" 그들이 무엇이라고 대답할지 짐작할 수 있을 것이다. :o)
나는 회의가 늘어지도록 놔둬본 적이 있다. 그것은 보통 아무것도 성취하지 못한다, 왜냐하면 사람들이 피곤하기 때문이다. 만약 그들이 2~8시간(또는 당신의 타임박스가 얼마든) 동안 괜찮은 스프린트 계획을 만들지 못했다면, 아마 한 시간 더 주어도 해내지 못할 것이다. 다음 옵션은 실제로 꽤 괜찮다: 다음 날 새로운 회의를 잡는 것. 다만 사람들은 보통 참을성이 없어서 스프린트를 시작하고 싶어하고, 또 다른 몇 시간을 계획에 쓰고 싶어하지 않는다.
스프린트 계획 회의 의제
스프린트 계획 회의를 위한 예비 일정을 갖는 것은 타임박스를 깨뜨릴 위험을 줄여준다.
다음은 우리의 전형적인 일정 예시다.
스프린트 계획 회의: 13:00-17:00 (매 시간마다 10분 휴식)
13:00-13:30 – 제품 책임자가 스프린트 목표를 설명하고 제품 백로그를 요약한다. 데모 장소, 날짜, 시간을 정한다.
13:30-15:00 – 팀이 시간을 추정하고 필요에 따라 항목을 분해한다. 제품 책임자는 필요에 따라 중요도를 업데이트한다. 항목들이 명확해진다. 모든 고중요도 항목에 대해 "데모 방법"이 작성된다.
15:00-16:00 – 팀이 스프린트에 포함될 스토리를 선택한다. 현실성 검증으로 속도 계산을 한다.
16:00-17:00 – 일일 스크럼 시간과 장소를 선택한다(지난 스프린트와 다른 경우). 스토리를 작업으로 추가 분해한다.
13:30과 15:00 사이의 부분, 그것이 제품 백로그 정제다(나는 "백로그 그루밍"이라고 부르곤 했지만 그루밍이 일부 문화권에서는 나쁜 의미를 갖는다는 것을 알게 되었다). 그것을 별도의 회의로 분리하면, 짜잔, 더 짧고 달콤한 스프린트 계획 회의를 얻게 된다. 물론 약간의 조정이 필요할 수 있지만, 대부분의 백로그 정제는 스프린트 계획 전에 이루어져야 한다.
일정은 결코 엄격하게 시행되지 않는다. 스크럼 마스터는 회의가 진행됨에 따라 필요에 따라 하위 타임박스를 늘리거나 줄일 수 있다.
스프린트 길이 정의하기
스프린트 계획 회의의 결과물 중 하나는 정의된 스프린트 데모 날짜다. 이는 스프린트 길이를 결정해야 한다는 의미다.
그렇다면 좋은 스프린트 길이는 무엇인가?
음, 짧은 스프린트가 좋다. 회사가 "민첩"해질 수 있게, 즉 자주 방향을 바꿀 수 있게 해준다. 짧은 스프린트 = 짧은 피드백 주기 = 더 자주 전달 = 더 자주 고객 피드백 = 잘못된 방향으로 가는 시간 감소 = 더 빠르게 배우고 개선하기 등.
하지만 긴 스프린트도 좋다. 팀이 추진력을 쌓을 시간이 더 많고, 문제에서 회복하면서도 스프린트 목표를 달성할 여유가 더 많으며, 스프린트 계획 회의, 데모 등의 측면에서 오버헤드가 줄어든다.
일반적으로 제품 책임자는 짧은 스프린트를 좋아하고 개발자는 긴 스프린트를 좋아한다. 따라서 스프린트 길이는 타협점이다. 우리는 이것을 많이 실험했고 우리가 가장 좋아하는 길이를 찾았다: 3주. 우리 팀의 대부분(전부는 아니지만)이 3주 스프린트를 한다. 적절한 기업 민첩성을 제공할 만큼 충분히 짧고, 팀이 흐름을 달성하고 스프린트에서 발생하는 문제에서 회복할 만큼 충분히 길다.
우리가 내린 한 가지 결론은: 초기에 스프린트 길이를 실험하라. 분석에 너무 많은 시간을 낭비하지 말고, 그냥 적당한 길이를 선택하고 한두 스프린트 동안 시도해본 다음, 길이를 변경하라.
하지만 일단 가장 좋아하는 길이를 결정했다면, 장기간 그것을 고수하라. 몇 달간의 실험 후, 우리는 3주가 좋다는 것을 발견했다. 그래서 우리는 3주 스프린트를 한다, 끝.
때로는 약간 너무 길게 느껴질 때도 있고, 때로는 약간 너무 짧게 느껴질 때도 있다. 하지만 같은 길이를 유지함으로써, 이것은 모든 사람이 편안하게 정착하는 기업의 심장박동 같은 것이 된다. 출시 날짜 등에 대한 논쟁이 없다. 왜냐하면 모든 사람이 3주마다 출시가 있다는 것을 알기 때문이다, 끝.
내가 만나는 대부분의 스크럼 팀(사실 거의 모든 팀)은 2주 또는 3주 스프린트를 한다. 1주는 거의 항상 너무 짧다("우리는 스프린트를 겨우 시작했는데, 이제 벌써 데모를 계획하고 있어! 스트레스받아! 우리는 속도를 내고 개발 흐름을 즐길 시간이 전혀 없어!"). 그리고 4주는 거의 항상 너무 길다("우리의 계획 회의는 고문이고, 우리의 스프린트는 계속 중단돼!"). 그냥 관찰일 뿐이다.
스프린트 목표 정의하기
거의 매번 일어나는 일이다. 스프린트 계획 회의 중 어느 시점에서 내가 "그래서 이 스프린트의 목표가 무엇인가요?"라고 묻으면 모두가 멍하니 나를 쳐다보고 제품 책임자는 이마를 찌푸리며 턱을 긁는다.
어떤 이유에서인지 스프린트 목표를 생각해내는 것은 어렵다. 하지만 나는 하나를 짜내는 것이 정말 가치 있다는 것을 발견했다. 반쯤 형편없는 목표라도 아예 없는 것보다 낫다. 목표는 "더 많은 돈 벌기" 또는 "상위 3개 우선순위 스토리 완성" 또는 "CEO에게 깊은 인상 남기기" 또는 "시스템을 라이브 베타 그룹에 배포할 만큼 충분히 좋게 만들기" 또는 "기본 백오피스 지원 추가" 또는 무엇이든 될 수 있다. 중요한 것은 기술적 용어가 아닌 비즈니스 용어여야 한다는 것이다. 이는 팀 외부 사람들이 이해할 수 있는 용어를 의미한다.
스프린트 목표는 근본적인 질문에 답해야 한다 "왜 우리가 이 스프린트를 하는가? 왜 우리 모두 그냥 휴가를 가는 대신?" 사실, 제품 책임자로부터 스프린트 목표를 끄집어내는 한 가지 방법은 말 그대로 그 질문을 하는 것이다.
목표는 이미 달성되지 않은 것이어야 한다. "CEO에게 깊은 인상 남기기"는 좋은 목표일 수 있지만, 그가 이미 현재 시스템에 깊은 인상을 받았다면 그렇지 않다. 그런 경우, 모든 사람이 집에 가도 스프린트 목표는 여전히 달성될 것이다.
스프린트에 포함할 스토리 결정하기
스프린트 계획 회의의 주요 활동 중 하나는 스프린트에 어떤 스토리를 포함할지 결정하는 것이다. 더 구체적으로, 제품 백로그에서 스프린트 백로그로 복사할 스토리를 결정하는 것이다.
위의 그림을 보라. 각 직사각형은 중요도에 따라 정렬된 스토리를 나타낸다. 가장 중요한 스토리가 목록의 맨 위에 있다. 각 직사각형의 크기는 해당 스토리의 크기(즉, 스토리 포인트로 표현된 시간 추정치)를 나타낸다. 파란색 괄호의 높이는 팀의 추정 속도, 즉 팀이 다음 스프린트 동안 완료할 수 있다고 믿는 스토리 포인트 수를 나타낸다.
오른쪽의 스프린트 백로그는 제품 백로그에서 가져온 스토리의 스냅샷이다. 이것은 팀이 이번 스프린트에 약속할 스토리 목록을 나타낸다.
팀이 스프린트에 포함할 스토리 수를 결정한다. 제품 책임자나 다른 누구도 아니다.
이것은 두 가지 질문을 제기한다:
팀은 어떻게 스프린트에 포함할 스토리를 결정하는가?
제품 책임자는 어떻게 그들의 결정에 영향을 미칠 수 있는가?
두 번째 질문부터 시작하겠다.
제품 책임자가 스프린트에 포함될 스토리에 영향을 미치는 방법
스프린트 계획 회의 중에 다음과 같은 상황이 있다고 가정해보자.
제품 책임자는 스토리 D가 스프린트에 포함되지 않는다는 것에 실망한다. 스프린트 계획 회의 중 그의 옵션은 무엇인가?
한 가지 옵션은 우선순위를 재조정하는 것이다. 만약 그가 항목 D에 가장 높은 중요도를 부여한다면, 팀은 그것을 스프린트에 먼저 추가해야 할 의무가 있다(이 경우 스토리 C를 제외하고).
두 번째 옵션은 범위를 변경하는 것이다 – 팀이 스토리 D가 스프린트에 맞을 것이라고 믿을 때까지 스토리 A의 범위를 줄이는 것이다.
세 번째 옵션은 스토리를 분할하는 것이다. 제품 책임자는 스토리 A의 일부 측면이 정말 그렇게 중요하지 않다고 결정할 수 있으므로, A를 서로 다른 중요도를 가진 두 개의 스토리 A1과 A2로 분할한다.
보시다시피, 제품 책임자는 일반적으로 추정 속도를 제어할 수 없지만, 어떤 스토리가 스프린트에 포함되는지에 영향을 미칠 수 있는 많은 방법이 있다.
팀이 스프린트에 포함할 스토리를 결정하는 방법
우리는 이를 위해 두 가지 기법을 사용한다:
직감
속도 계산
직감을 사용한 추정
스크럼 마스터 (제품 백로그에서 가장 중요한 항목을 가리키며): 여러분, 이번 스프린트에서 스토리 A를 끝낼 수 있나요?
리사: 당연하죠. 물론 할 수 있어요. 우리에게는 3주가 있고, 그것은 꽤 사소한 기능이에요.
스크럼 마스터 (두 번째로 중요한 항목을 가리키며): 좋아요, 스토리 B도 추가하면 어떨까요?
톰과 리사 (동시에): 여전히 식은 죽 먹기죠.
스크럼 마스터: 좋아요, 그럼 스토리 A와 B와 C는 어떨까요?
샘 (제품 책임자에게): 스토리 C에 고급 오류 처리가 포함되나요?
제품 책임자: 아니요, 지금은 건너뛸 수 있어요. 기본적인 오류 처리만 구현하세요.
샘: 그럼 C도 괜찮을 거예요.
스크럼 마스터: 좋아요, 스토리 D를 추가하면 어떨까요?
리사: 음....
톰: 할 수 있을 것 같아요.
스크럼 마스터: 90% 확신해요? 50%?
리사와 톰: 거의 90%요.
스크럼 마스터: 좋아요, 그럼 D도 포함시켜요. 스토리 E를 추가하면 어떨까요?
샘: 아마도요.
스크럼 마스터: 90%? 50%?
샘: 50%에 가까울 것 같아요.
리사: 저는 의심스러워요.
스크럼 마스터: 좋아요, 그럼 빼놓죠. 우리는 A, B, C, D에 약속할게요. 물론 할 수 있다면 E도 끝낼 거지만, 아무도 그것을 기대하지 않아야 하므로 스프린트 계획에서 제외할게요. 어때요?
모두: 좋아요!
직감은 작은 팀과 짧은 스프린트에서 꽤 잘 작동한다.
속도 계산을 사용한 추정
이 기법은 두 단계를 포함한다:
추정 속도를 결정한다.
추정 속도를 초과하지 않고 추가할 수 있는 스토리 수를 계산한다.
속도는 "완료된 작업량"의 측정치로, 각 항목은 초기 추정치에 따라 가중치가 부여된다.
아래 그림은 스프린트 시작 시의 추정 속도와 해당 스프린트 종료 시의 실제 속도의 예를 보여준다. 각 직사각형은 스토리이고, 안의 숫자는 해당 스토리의 초기 추정치다.
실제 속도는 각 스토리의 초기 추정치를 기반으로 한다는 점에 주목하라. 스프린트 중에 수행된 스토리 시간 추정치의 업데이트는 무시된다.
이미 당신의 반대 의견이 들린다: "이것이 어떻게 유용한가? 높거나 낮은 속도는 많은 요인에 따라 달라질 수 있다! 멍청한 프로그래머, 잘못된 초기 추정치, 범위 확대, 스프린트 중 계획되지 않은 방해 등!"
동의한다, 이것은 거친 숫자다. 하지만 여전히 유용한 숫자다, 특히 아무것도 없는 것과 비교했을 때. 이것은 당신에게 몇 가지 확실한 사실을 제공한다. "이유가 무엇이든, 여기 우리가 할 것이라고 생각했던 것과 실제로 한 것 사이의 대략적인 차이가 있다."
스프린트 중에 거의 완료된 스토리는 어떻게 되는가? 왜 우리의 실제 속도에서 그것에 대한 부분 점수를 받지 못하는가? 음, 이것은 스크럼(그리고 사실 애자일 소프트웨어 개발과 린 제조 전반)이 완전히, 배송 가능하게, 완료된 것을 얻는 것에 관한 것이라는 사실을 강조하기 위함이다! 반쯤 완료된 것의 가치는 0이다(사실 음수일 수도 있다). Donald Reinertsen의 Managing the Design Factory나 Poppendieck의 책 중 하나를 보면 더 자세한 내용을 볼 수 있다.
그렇다면 우리는 어떤 신비한 마법을 통해 속도를 추정하는가?
속도를 추정하는 매우 간단한 방법 중 하나는 팀의 역사를 보는 것이다. 지난 몇 스프린트 동안 그들의 속도는 어땠는가? 그런 다음 다음 스프린트에서도 속도가 대략 같을 것이라고 가정한다.
이 기법은 어제의 날씨(yesterday's weather)로 알려져 있다. 이것은 이미 몇 번의 스프린트를 수행한 팀(따라서 통계를 사용할 수 있음)과 다음 스프린트를 거의 같은 방식으로, 같은 팀 규모와 같은 작업 조건 등으로 수행할 팀에게만 실현 가능하다. 물론 항상 그런 것은 아니다.
더 정교한 변형은 간단한 리소스 계산을 하는 것이다. 4명으로 구성된 팀과 함께 3주 스프린트(15 근무일)를 계획한다고 가정해보자. 리사는 이틀 동안 휴가를 갈 것이다. 데이브는 50%만 사용 가능하고 하루 동안 휴가를 갈 것이다. 이 모든 것을 합치면...
...이번 스프린트에 50개의 사용 가능한 맨데이를 얻는다.
경고: 여기가 내가 정말 싫어하는 부분이다. 다음 몇 페이지를 찢어버리고 싶다! 하지만 호기심이 있다면 계속 읽어보고, 나중에 왜 그런지 설명하겠다.
그것이 우리의 추정 속도인가? 아니다! 왜냐하면 우리의 추정 단위는 스토리 포인트이고, 우리의 경우 대략 "이상적인 맨데이"에 해당하기 때문이다. 이상적인 맨데이는 완벽하게 효과적이고 방해받지 않는 날로, 드물다. 게다가, 우리는 스프린트에 추가되는 계획되지 않은 작업, 사람들이 아픈 것 등을 고려해야 한다.
그래서 우리의 추정 속도는 확실히 50보다 적을 것이다. 하지만 얼마나 적을까? 우리는 이를 위해 "집중 계수(focus factor)"라는 용어를 사용한다.
집중 계수는 팀이 얼마나 집중되어 있는지에 대한 추정치다. 낮은 집중 계수는 팀이 많은 방해를 받을 것으로 예상하거나 자신들의 시간 추정치가 낙관적일 것으로 예상한다는 것을 의미할 수 있다.
블라 블라 블라. 수학적 헛소리 무더기. 그냥 어제의 날씨를 사용하라(또는 데이터가 없다면 직감) 그리고 이 집중 계수 헛소리는 무시하라.
합리적인 집중 계수를 결정하는 가장 좋은 방법은 마지막 스프린트를 보는 것이다(또는 더 나은 방법으로, 마지막 몇 스프린트의 평균을 내는 것).
실제 속도는 지난 스프린트에서 완료된 모든 스토리의 초기 추정치의 합이다.
지난 스프린트에서 Tom, Lisa, Sam으로 구성된 3인 팀이 3주 동안 총 45 맨데이로 작업하여 18 스토리 포인트를 완료했다고 가정해보자. 그리고 이제 우리는 다가오는 스프린트의 추정 속도를 알아내려고 한다. 상황을 복잡하게 하기 위해, 새로운 사람인 Dave가 그 스프린트를 위해 팀에 합류한다. 휴가 등을 고려하여 다음 스프린트에 50 맨데이가 있다.
그래서 다가오는 스프린트의 추정 속도는 20 스토리 포인트다. 이는 팀이 약 20까지 더해지는 스토리를 스프린트에 추가해야 한다는 것을 의미한다.
이 경우, 팀은 총 19 스토리 포인트인 상위 4개 스토리를 선택하거나, 총 24 스토리 포인트인 상위 5개 스토리를 선택할 수 있다. 20 스토리 포인트에 가장 가까운 4개 스토리를 선택한다고 가정해보자. 의심스러울 때는 더 적은 스토리를 선택하라.
이 4개 스토리가 19 스토리 포인트를 더하므로, 이번 스프린트의 최종 추정 속도는 19다.
어제의 날씨는 편리한 기법이지만 상식과 함께 사용하라. 지난 스프린트가 팀의 대부분이 일주일 동안 아팠기 때문에 비정상적으로 나쁜 스프린트였다면, 다시 그렇게 운이 나쁘지 않을 것이라고 가정하고 다음 스프린트에 더 높은 집중 계수를 추정하는 것이 안전할 수 있다. 팀이 최근에 새로운 초고속 지속 빌드 시스템을 설치했다면, 그것 때문에 집중 계수를 높일 수 있을 것이다. 새로운 사람이 이번 스프린트에 합류한다면 그의 훈련을 고려하여 집중 계수를 줄여야 한다. 등등.
가능할 때마다, 여러 스프린트를 되돌아보고 숫자를 평균화하여 더 신뢰할 수 있는 추정치를 얻으라.
팀이 완전히 새로워서 통계가 없다면 어떻게 하는가? 비슷한 상황에서 다른 팀의 집중 계수를 보라.
살펴볼 다른 팀이 없다면 어떻게 하는가? 집중 계수를 추측하라. 좋은 소식은 당신의 추측이 첫 번째 스프린트에만 적용된다는 것이다. 그 후에는 통계를 갖게 되고 지속적으로 집중 계수와 추정 속도를 측정하고 개선할 수 있다.
새로운 팀에 대해 내가 사용하는 기본 집중 계수는 보통 70%인데, 이는 시간이 지나면서 우리의 다른 팀들이 대부분 도달한 수치이기 때문이다.
위에서 몇 가지 기법을 언급했다: 직감, 어제의 날씨에 기반한 속도 계산, 그리고 사용 가능한 맨데이와 추정 집중 계수에 기반한 속도 계산.
그렇다면 어느 기법을 사용하는가?
우리는 보통 이 모든 기법을 어느 정도 결합한다. 시간이 오래 걸리지 않는다.
우리는 지난 스프린트의 집중 계수와 실제 속도를 살펴본다. 이번 스프린트의 총 리소스 가용성을 보고 집중 계수를 추정한다. 이 두 집중 계수 간의 차이를 논의하고 필요에 따라 조정한다.
좋아, 이제 고통스러운 섹션이 끝났다. 나는 더 이상 집중 계수를 사용하지 않는다. 왜냐하면 시간이 걸리고, 정확성에 대한 잘못된 느낌을 주며, 스토리를 이상적인 맨데이로 추정하도록 강요하기 때문이다.
또한 집중 계수는 더 많은 사람 = 더 높은 속도라는 가정을 담고 있다. 때로는 맞지만, 때로는 그렇지 않다. 팀에 새로운 사람을 추가하면, 사람들이 새로운 사람을 온보딩하는 데 시간을 보내기 때문에 속도는 보통 처음 한두 스프린트 동안 떨어진다. 팀이 너무 커지면(10명 이상), 속도는 확실히 떨어진다. 또한 "집중 계수"라는 표현은 100% 미만의 값이 팀이 집중하지 못한다는 것을 의미하는데, 이는 경영진에게 매우 오해의 소지가 있는 메시지를 보낸다.
그러니 이 모든 집중 계수와 맨데이 관련 내용은 건너뛰어라. 그저 지난 몇 스프린트에서 얼마나 완료했는지 살펴보라. 스토리 포인트를 세거나, 추정치가 전혀 없다면 스토리 수만 세어도 된다. 그런 다음 이번 스프린트를 위해 대략 그만큼의 스토리를 가져가라. 스프린트에서 계획된 방해가 있다면(예: 두 명이 교육 과정에 참석) 적절하다고 느껴질 때까지 몇 개의 스토리를 제거하라. 과거 데이터가 적을수록 직감에 더 의존해야 한다.
이렇게 하면 스프린트 계획 회의가 더 짧고, 더 효과적이며, 더 재미있을 것이다. 그리고 직관에 반하게도, 계획이 더 정확해질 것이다.
스프린트에 포함될 스토리의 예비 목록이 있으면, 나는 "직감" 확인을 한다. 팀에게 잠시 숫자를 무시하고 이것이 스프린트에서 감당할 수 있는 현실적인 양인지 생각해보라고 요청한다. 너무 많은 것 같으면 스토리 한두 개를 제거한다. 그 반대도 마찬가지다.
결국, 목표는 단순히 스프린트에 포함할 스토리를 결정하는 것이다. 집중 계수, 리소스 가용성, 추정 속도는 그 목적을 달성하기 위한 수단일 뿐이다.
왜 색인 카드를 사용하는가
스프린트 계획 회의의 대부분은 제품 백로그의 스토리를 다루는 데 보낸다. 추정하고, 우선순위를 재조정하고, 명확히 하고, 분해하는 등의 작업이다.
실제로 이것을 어떻게 하는가?
기본적으로 팀들은 프로젝터를 켜고, Excel 기반 백로그를 보여주고, 한 사람(보통 제품 책임자나 스크럼 마스터)이 키보드를 잡고 각 스토리를 중얼거리며 토론을 유도했다. 팀과 제품 책임자가 우선순위와 세부사항을 논의하면서, 키보드를 잡은 사람이 Excel에서 직접 스토리를 업데이트했다.
좋아 보이는가? 그렇지 않다. 보통 형편없다. 더 나쁜 것은, 팀이 보통 회의가 끝나서 스토리 목록을 아직 다 검토하지 못했다는 것을 깨달을 때까지 이것이 형편없다는 것을 알아차리지 못한다는 것이다!
아, 고통스럽다...
훨씬 더 잘 작동하는 해결책은 색인 카드를 만들어 벽(또는 큰 테이블)에 붙이는 것이다.
이것은 컴퓨터와 프로젝터에 비해 우수한 사용자 인터페이스다:
• 사람들이 일어서서 돌아다닌다 => 더 오래 깨어있고 경각심을 유지한다.
• 모든 사람이 더 개인적으로 관여한다고 느낀다(키보드를 잡은 사람만이 아니라).
• 여러 스토리를 동시에 편집할 수 있다.
• 우선순위 재조정이 사소하다 - 그냥 색인 카드를 이동시키면 된다.
• 회의 후, 색인 카드를 바로 팀룸으로 가져가서 벽 기반 작업 보드로 사용할 수 있다(45페이지 "스프린트 백로그를 어떻게 하는가" 참조).
손으로 쓰거나 (우리가 보통 하는 것처럼) 제품 백로그에서 직접 인쇄 가능한 색인 카드를 생성하는 간단한 스크립트를 사용할 수 있다.
스크립트를 찾는 가장 쉬운 방법은 "index card generator"를 구글링하는 것이다. 그 오래된 해킹이 아직도 건재하다니 믿을 수 없다! 친절한 사람들이 Google 스프레드시트로 포팅하는 것도 도와주었다. 괜찮은 백로그 관리 도구라면 이런 인쇄 기능이 있을 것이다. 다양한 도구를 실험해보고 당신의 상황에서 가장 잘 작동하는 것을 찾아라. 다만 프로세스에 도구를 맞추고 있는지 확인하고, 그 반대가 아니어야 한다.
중요: 스프린트 계획 회의 후, 우리의 스크럼 마스터는 물리적 스토리 색인 카드에 가해진 변경사항에 대해 Excel 기반 제품 백로그를 수동으로 업데이트한다. 네, 이것은 약간의 관리적 번거로움이지만 물리적 색인 카드로 스프린트 계획 회의가 얼마나 더 효율적인지를 고려하면 완전히 수용할 만하다고 생각한다.
"중요도" 필드에 대한 한 가지 주의사항... 이것은 인쇄 시점에 Excel 기반 제품 백로그에 지정된 중요도다. 카드에 있으면 카드를 물리적으로 중요도별로 정렬하기 쉽다(보통 더 중요한 항목을 왼쪽에, 덜 중요한 항목을 오른쪽에 배치한다). 그러나 카드가 벽에 올라가면, 중요도 등급을 무시하고 대신 벽의 물리적 순서를 사용하여 상대적 중요도 등급을 나타낼 수 있다. 제품 책임자가 두 항목을 바꾸면, 종이의 중요도 등급을 업데이트하는 데 시간을 낭비하지 마라. 회의 후 Excel 기반 제품 백로그의 중요도 등급을 업데이트하는지만 확인하라.
아니면 그냥 중요도 등급을 건너뛰어라. 이런, 이미 몇 번이나 말했나. 내가 반복하고 있나? 내가 반복하고 있나?
스토리가 작업으로 분해되면 시간 추정이 보통 더 쉽고(더 정확하다). 사실, 우리는 "activity"라는 용어를 사용하는데, "task"라는 단어가 스웨덴어로는 완전히 다른 의미를 갖기 때문이다. :o) 이것도 우리의 색인 카드로 쉽고 간편하게 할 수 있다. 팀을 쌍으로 나누고 각각 하나의 스토리를 병렬로 분해하도록 할 수 있다.
물리적으로, 우리는 각 스토리 아래에 작은 포스트잇 노트를 추가하여 이를 수행하며, 각 포스트잇은 해당 스토리 내의 하나의 작업을 반영한다.
"완료"의 정의
팀이 "2개의 스토리 포인트"라고 말하든 직감으로 "우리는 3개의 항목을 약속한다"고 말하든, 팀이 말하는 "완료"가 정확히 무엇을 의미하는지에 대한 공통된 정의를 갖는 것이 중요하다.
"2개의 스토리 완료하기"가 다음을 의미하나:
(1) 모든 코드가 체크인되어 있음, 또는
(2) 모든 코드가 체크인되고 테스트 서버에 배포되어 수동 시스템 테스트에 통과함?
스크럼 문헌에서는 이를 "완료의 정의"라고 부르며 기본적으로 팀과 제품 책임자가 합의해야 하는 체크리스트다. 우리의 정의는 보통 다음과 같다:
완료란! = 모든 프로그래밍 완료 + 코드 저장소에 체크인된 모든 코드 + 모든 테스트 통과 + 수락 테스트 환경에서 테스트 및 승인 + 다가오는 출시에 병합 준비 완료
그렇다, 비교적 엄격한 편이다. 하지만 "코드가 체크인되었다"는 것이 완료를 의미한다면 "속도"는 가짜 숫자가 되어 계획 목적으로 사용할 수 없다는 것을 배웠다.
이제 그것보다 훨씬 더 간단해졌다. 간단히: 출시 가능! 실제로 "완료의 정의"보다 더 좋은 것은 없다. 너무 간단하고 중요한 질문에 초점을 맞추도록 강요하기 때문이다. "우리가 '완료'라고 말할 때, 이것을 바로 프로덕션에 출시할 수 있는가?" 아니라면, 왜 그런가? 무엇이 빠졌는가? 더 많은 테스트? 그럼 완료의 정의에 포함시켜라. 매뉴얼 작성? 완료의 정의에 포함시켜라.
간단한 "출시 가능"은 모호함이 없는 공통 목표를 생성한다. 대부분의 경우 정말로 출시할 필요는 없지만, 팀이 잠재적으로 출시 가능한 제품 증분(Scrum Guide에서 사용하는 용어)을 생성했다는 확신을 주기 위해 노력해야 한다.
플래닝 포커를 사용한 시간 추정
추정은 어려운 팀 활동이다. 팀에서 가장 낙관적인 사람이 무언가가 2시간 걸릴 것이라고 생각하고, 가장 비관적인 사람이 며칠 걸릴 것이라고 생각한다면, 차이를 어떻게 좁힐까?
플래닝 포커는 합의에 도달하기 위한 훌륭한 기법이다.
각 팀원은 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100으로 구성된 카드 덱을 받는다. 이것은 이상적인 맨데이(또는 스토리 포인트, 또는 우리가 사용하는 추정 단위가 무엇이든)를 나타낸다.
제품 백로그에서 스토리를 선택한다. 필요한 명확화 질문을 한 후, 각 팀원은 카드를 선택하여 테이블에 뒤집어 놓는다.
모든 사람이 준비되면 카드를 동시에 뒤집는다.
만약 두 팀원이 서로 크게 다른 추정치를 가지고 있다면, 그들에게 이유를 논의하도록 한다. 그들이 다른 것에 대해 이야기하고 있거나 서로 다른 가정을 하고 있을 수 있다. 토론 후 팀은 다시 추정한다.
이 과정은 합리적인 합의에 도달할 때까지 계속된다. 3회 이상 걸리는 경우는 드물다.
시퀀스가 중요하다. 이유는 이것이 대략 피보나치 수열이기 때문이다. 추정치가 클수록 불확실성이 높으므로 정확성을 떨어뜨린다. 40과 50 스토리 포인트의 차이를 논의하는 것은 의미가 없다. 둘 다 "크다"는 의미일 뿐이다.
좋아. 카드를 사는 대신 앱을 사용하라. 무료로 수백 개가 있다. 수의 시퀀스를 맞춤 설정하면 팀에 무엇이 적합한지 실험할 수 있다. 어떤 팀은 1, 2, 3, 5, 8으로만 간다. 실험해보라.
또한 추정은 선택사항이라는 것을 기억하라. 일부 팀은 같은 크기로 모든 항목을 만들고 속도를 "스프린트당 항목 수"로 측정하는 것이 생산적이라고 생각한다(그리고 일반적으로 이것이 정교한 추정보다 더 나쁘지 않다!). 일부 팀은 S/M/L 크기만 사용한다. 일부는 계획을 전혀 하지 않는다(칸반 팀과 같이). 상세한 추정(13 스토리 포인트와 같은)의 주요 목적은 유용한 학습을 생성하는 것이다 - 예를 들어 제품 책임자가 배송 날짜를 예측하거나 스토리를 더 작은 스토리로 나누도록 강요하는 것이다. 이러한 학습을 다른 방법으로 얻을 수 있다면 추정을 건너뛸 수 있다.
스토리 명확화
추정 중 가장 시간이 많이 걸리는 부분은 대개 스토리 명확화와 스토리 분해다. 대부분의 경우, 제품 책임자가 설명하는 스토리의 범위가 명확하지 않아 개발자들이 추정할 수 없다. 그래서 "스토리가 이것도 포함하나요? 저것도 포함하나요?"와 같은 질문을 한다.
예를 들어, 스토리가 "사용자는 소셜 보안 번호로 로그인할 수 있다"라면.
개발자는 "그럼 로그아웃은요?" "사용자가 잘못된 번호를 여러 번 입력하면 어떻게 되나요?" "모든 페이지에 로그인 페이지가 있어야 하나요?"와 같은 질문을 할 수 있다.
어떤 경우에는 제품 책임자가 "그래, 로그아웃이 포함되어야 해"라고 대답할 것이다. 그럼 개발자들은 이것을 고려하여 추정할 것이다. 다른 경우에는 "로그아웃이 필요하지만 별도의 스토리로 하자"라고 대답할 수도 있다. 그럼 스크럼 마스터는 "로그아웃" 스토리를 추가하고 제품 책임자에게 우선순위를 정하도록 한다. 극단적인 경우, 제품 책임자는 "아, 로그아웃이 필요 없어. 응용 프로그램을 다시 시작하면 돼"라고 대답할 수도 있다. 좋아, 정말 극단적이지만, 어쨌든...
토론을 짧게 유지하고 문제를 즉시 해결할 수 없을 때는 스토리를 두 개로 나누고, "기타" 부분을 낮은 우선순위로 설정하거나, 스토리를 다시 작성하거나, 메모를 작성하라. 사람들이 토론에 빠져 계획을 완료하지 못할 수 있다!
제품 책임자가 팀에게 그가 각 스토리를 필요로 하는 이유와 그가 상상하는 사용자의 작업 흐름에 대한 짧은 개요를 제공하면 도움이 된다. 그렇지 않으면 개발자들이 기술적으로 건전하지만 전체적으로 쓸모없는 솔루션을 구축할 위험이 있다. 예를 들어, 모든 스토리에 대해 "사용자는 항상 홈페이지에서 시작하여 '개인 프로필'을 클릭한 다음 이것저것을 한다"라고 말하는 것이다.
어쨌든, 제품 책임자가 즉시 사용할 수 있는 것은 결정적으로 중요하다. 사실, 스프린트 계획이 고통스러운 경우, 제품 책임자가 참석하지 않거나 준비되지 않았기 때문일 가능성이 높다.
스토리를 더 작은 스토리로 분해하기
스토리는 비즈니스 지향적이어야 하고 팀 전체가 이해할 수 있는 언어로 표현되어야 한다.
비즈니스 가치를 생성하지 않는 기술 지향 스토리는 피하라. 예를 들어 "DAO 계층 구축"이나 "영속성 추상화" 같은 스토리는 제품 책임자가 절대 이해하지 못할 것이며, 비즈니스 가치를 확인할 방법이 없을 것이다.
예를 들어, 스토리가 "쇼핑카트가 있는 웹샵"이고 추정치가 40 스토리 포인트라고 가정해보자. 추정 정확도를 개선하고 비즈니스 가치를 더 빨리 제공하기 위해 더 나은 솔루션은 이를 더 작은 스토리로 분할하는 것이다. 예를 들어:
• 쇼핑카트 보기
• 쇼핑카트에 책 추가
• 쇼핑카트에서 책 제거
• 결제
일반적으로, 첫 번째(쇼핑카트 보기)는 가장 어려운 스토리일 것이다. 나머지는 쉬울 것이다. 이것이 "증분" 개발의 본질이다!
이것을 "얇고 수직적인 슬라이스"라고 부른다. 그들은 매우 작고(얇고) 사용자 인터페이스에서 데이터베이스까지 걸쳐 있기 때문이다(수직적). 증분 개발은 백엔드 코드 작성으로 시작하여 점차 앞으로 나아가는 것(또는 반대로)보다 항상 훨씬 낫다. 얇고 수직적인 슬라이스는 일찍 그리고 자주 더 많은 비즈니스 가치와 피드백을 제공한다.
여기 스토리를 더 작게 만드는 몇 가지 다른 트릭이 있다.
스토리 분할은 어려운 예술이며 뛰어난 제품 책임자의 가장 중요한 기술 중 하나다. 초기에 제품 책임자가 도움을 요청하면 함께 앉아서 스토리를 분할하는 방법을 도와주라.
스토리를 작업으로 분해하기
기다려, 스토리 분해가 끝나지 않았다! 스토리를 작업(task)으로도 분해할 수 있다.
잠깐, 스토리와 작업의 차이점은 무엇인가?
차이점은 매우 간단하다:
• 스토리는 제품 책임자에게 가치 있는 것으로 제공 가능하다
• 작업은 제품 책임자에게 가치 있는 것으로 제공 가능하지 않다(단독으로)
작업은 순전히 기술적이며 팀 내에서 작업을 분할하는 방법이다. 보통 각 작업은 한 사람이 하루 이내에 완료할 수 있다.
예: "레이아웃 구축"은 보통 스토리가 아니라 작업이다. 왜냐하면 레이아웃을 완료해도 사용자가 그것을 사용할 수 없기 때문이다.
스프린트 계획에서 팀은 스토리를 가져와 작업으로 분해한다. 이렇게 하면 작업 일정을 더 쉽게 짤 수 있고 무엇을 해야 하는지에 대한 다른 사람들의 이해를 동기화할 수 있다.
우리는 보통 작업을 "TODO", "진행 중", "완료"라는 세 개의 열이 있는 벽에 업데이트한다. 57페이지의 "스프린트 백로그를 어떻게 하는가"를 참조하라.
일일 스크럼의 시간과 장소 정의하기
일일 스크럼 일정과 관련하여 한 가지 중요한 점은 모든 사람이 언제 일어나는지 알 수 있도록 고정된 시간이어야 한다는 것이다.
보통 모든 팀이 동시에(또는 스크럼 오브 스크럼이 유용하도록 시차를 두고) 일일 스크럼을 하는 것이 가장 좋다. 다음은 몇 가지 옵션이다:
아침(예: 9시)
사람들이 하루를 계획할 수 있다
늦게 오는 사람들을 발견하기 쉽다
사람들이 오전에 조금 늦게 오기를 좋아한다면 문제가 된다
점심 직전(예: 11:30)
적당한 시간 압박을 준다 - 사람들은 배고프기 때문에 일일 스크럼을 짧게 유지하려는 경향이 있다
스크럼 일정이 점심 시간을 방해할 수 있다
하루 끝(예: 16:30)
사람들이 보고하기 전에 하루 종일 일할 수 있다
더 많은 보고, 적은 계획
사람들이 일찍 집에 가고 싶어하면 문제가 된다
우리는 대부분 오전 9시나 9시 30분에 일일 스크럼을 한다. 대부분의 사람들이 그 전에 대략 출근하는 것 같다.
보고보다는 계획에 중점을 두는 것이 중요하다. 일일 스크럼은 업데이트 보고서가 아니다. 일일 스크럼은 서로를 도울 방법과 하루를 위한 최선의 계획에 대한 빠른 동기화 회의다. 따라서 특히 밤새 잠을 못 잔 경우 이른 아침이 최선의 시간이 아닐 수 있다. 개인적으로 나는 하루 중반이 일일 스크럼에 가장 좋은 시간이라고 생각한다. 그러나 어쨌든 팀에게 실험하고 그들에게 가장 적합한 것을 찾도록 하라.
선을 어디에 그을 것인가
좋아, 그래서 제품 책임자는 일일 스크럼의 시간과 장소를 설정할 권한이 없다. 이것은 팀이 결정할 일이다. 제품 책임자는 데모 날짜를 설정할 권한도 없다. 이것은 고정된 스프린트 길이에서 자동으로 나온다.
그러나 제품 책임자가 결정을 내리거나 영향을 미칠 수 있는 몇 가지 경계 사례가 있다. 예를 들어:
• 팀이 모든 높은 중요도 스토리를 스프린트에 포함할 수 없다고 판단한다. 제품 책임자는 화가 나서 그들에게 더 짧은 스프린트를 하도록 시킨다.
• 팀이 한 스프린트 동안 5개의 스토리를 끝낼 것이라고 생각한다. 그들이 세 번째 스토리까지 추정했을 때, 회의가 거의 끝나가고 제품 책임자가 그들에게 나머지 두 스토리를 추정하지 말고 그냥 처음 세 개에 전념하도록 시킨다.
• 팀이 스토리를 더 작은 스토리로 나누고 싶어한다. 제품 책임자는 "아냐, 나는 전체 스토리가 이번 스프린트에 끝나길 원해"라고 말한다.
많은 경우가 있으며 이러한 갈등을 어떻게 해결할지 일반화하기 어렵다. 어떤 팀은 제품 책임자가 자신들을 굴복시키도록 한다. 일부 팀은 제품 책임자를 거부한다. 어떤 팀은 빠른 합의점을 찾는다. 우리는 스크럼 마스터가 합의를 촉진하는 것이 중요하다는 것을 발견했다. 그는 그 과정의 목표와 우리가 누구의 제품을 구축하고 있는지에 대한 리마인더를 제공해야 한다. 만약 제품 책임자가 진정으로 터무니없는 것을 원한다면, 팀은 이에 반대할 권리가 있다. 그것은 건전한 갈등이다. 그러나 시간이 흐르면 팀과 제품 책임자는 보통 서로를 더 잘 알게 되고, 건전한 균형을 이룬다.
게다가, 팀이 항상 모든 합리적인 제품 책임자를 불행하게 만든다는 신호를 계속 보낸다면, 이는 나쁜 팀이거나 과로한 팀일 가능성이 높다.
제품 책임자가 항상 합리적인 팀을 불행하게 만든다면, 이는 나쁜 제품 책임자(또는 스프린트 길이와 맞지 않는 상황)일 가능성이 높다.
기술 스토리
다음은 기술 스토리의 예다:
• 지속적인 빌드 서버 설치
• 설계 명세서 작성
• 리팩터링 DAO 계층
• 모니터링 도구 업그레이드
이러한 스토리의 공통적인 분모는 무엇인가? 비즈니스 가치가 없다는 것이다. 적어도 직접적으로는. 간접적으로 비즈니스 가치를 제공하는데, 왜냐하면 팀이 더 빠르게 가고 더 적은 버그로 가도록 하기 때문이다. 그러나 제품 책임자는 그것을 이해하지 못할 수 있으며, 이러한 것들에 우선순위를 부여하는 방법을 알기 어렵다.
우리는 기술 스토리를 다루는 몇 가지 전략을 시도했다.
• 제품 책임자가 백로그에 추가하도록 하라. 이것이 가장 간단하고 투명한 방법이다. 그러나 많은 제품 책임자가 이것을 거부하거나 항상 가장 낮은 우선순위를 부여하여 기술 스토리가 전혀 완료되지 않는다.
• 제품 책임자가 백로그에 추가하지 못하도록 하라. 대신 팀에게 적절하다고 판단되는 대로 기술 스토리를 추가할 시간을 주라. 이것은 제품 책임자가 좋은 협력자가 아닌 경우 필요한 "핵"일 수 있다. 그렇지 않으면 이것을 피하는 것이 가장 좋다. 투명성 부족은 종종 더 많은 문제를 일으킨다.
• 제품 책임자에게 기술 스토리를 다시 표현하도록 코칭하여 제품 책임자가 비즈니스 가치를 볼 수 있도록 하라. 그러면 그가 이에 따라 우선순위를 매길 것이다. 이것은 잘 작동하지만 항상 실현 가능한 것은 아니다.
예: 제품 책임자는 더 많은 기능을 추가하기를 원하지만, 시스템이 느리고 버그가 많다고 팀이 불평한다면 - "리팩터링"을 별도의 스토리로 만드는 것은 어떨까? 제품 책임자가 비즈니스 가치를 이해하도록 돕고, 리팩터링이 더 많은 비즈니스 가치를 제공하는지, 아니면 새로운 기능이 더 많은 비즈니스 가치를 제공하는지 그가 우선순위를 정하도록 하라.
기술 스토리를 명시적으로 만드는 것이 일반적으로 좋은 것으로 나타났다. 이는 투명성을 높이고 팀과 제품 책임자 간의 좋은 토론을 생성한다. 결국 팀과 제품 책임자는 서로를 더 잘 이해하게 된다.
이것을 처리하는 가장 좋은 방법은 단순히 이런 스토리를 완전히 피하는 것이다. 가능하면 각 스토리를 끝내는 정상적인 일부로 시스템을 건강하게 유지하라.
팀은 기술 스토리를 자주 요청하는 대신 더 일찍 "아니오"라고 말하는 방법을 배울 수 있다. "아니오, 우리는 이 기능을 구축할 수 없습니다. 왜냐하면 DAO 계층이 너무 엉망이기 때문입니다. 따라서 제품 책임자님, 이 기능이 중요하다면 다음 스프린트를 DAO 계층 리팩터링에 사용하여 이 기능과 미래의 기능을 더 빠르게 구축할 수 있도록 하겠습니다."
버그 추적 시스템 대 제품 백로그
여기 매일 제품 책임자에게 발생하는 딜레마가 있다:
고객이 화가 나서 버그 보고서를 제출한다.
제품 책임자는 이 버그를 다음 스프린트에서 수정하고 싶어한다.
그러나 그는 사전 계획된 몇 가지 새로운 기능을 제외하지 않고는 버그를 맞출 수 없다.
제품 책임자가 스프린트에서 몇 가지 기능을 제외하기로 선택하면 문제가 사라진다. 그러나 종종 그는 싸우려고 하고 버그와 새로운 기능을 모두 스프린트에 압축하려고 한다.
그의 옵션은:
버그 보고서를 제품 백로그에 추가하고 (다른 스토리와 비교하여) 우선순위를 지정한다.
JIRA(버그 추적 시스템)에 버그를 남겨두고 스프린트 동안 팀이 수정하도록 한다.
우리는 처음에 #2를 많이 했다. 이것은 매우 투명하지 않았다. 제품 책임자는 팀이 얼마나 많은 시간을 버그 수정에 소비하는지에 대한 실제 제어나 통찰력이 없었고, 이는 스프린트 속도를 예측하기 어렵게 만들었다. 팀이 스프린트 중간에 끝없는 새로운 버그에 대한 보고를 받고 있다고 상상해보라.
투명성과 예측 가능한 스프린트를 유지하는 가장 좋은 방법은 #1(제품 백로그에 버그 넣기)이다.
이것이 좋은 이유는 무엇인가?
• 제품 책임자가 무엇이 더 중요한지 선택해야 한다 - 버그 A 또는 새로운 기능 B. 예산은 고정되어 있다(스프린트) 그래서 그는 우선순위를 정해야 한다.
• 버그 수정 추정치가 속도의 일부가 되므로 보다 예측 가능한 스프린트가 된다.
• 제품 백로그가 (더) 완전한 그림을 제공한다.
제품 책임자는 일반적으로 좋은 이유로 버그를 스토리보다 우선시하는 것을 좋아하지 않는다. 새로운 버그가 새로운 기능보다 중요한가? 그들이 마지막 출시 이후 얼마나 많은 고객 불만이 있었는지에 따라 다르다! 이것이 깨지기 쉬운 균형이다.
우리는 제품 책임자가 스프린트를 계획할 때 한 손에는 버그 추적 시스템을, 다른 손에는 제품 백로그를 가지고 짱글링하는 것을 발견했다. 우리는 그들이 버그를 스토리로 복사하도록 돕는 모든 종류의 도구와 심지어 Excel 플러그인을 구축하려고 시도했다. 그러나 여전히 통증이다. 선호하는 옵션:
버그 추적 시스템을 전혀 사용하지 마라. 제품 백로그가 스토리와 버그 모두에 충분하다.
JIRA(또는 사용하는 모든 것)와 같은 도구를 버그 추적 시스템과 제품 백로그 관리 시스템으로 사용하라.
별도의 시스템을 사용하라. 그러나 새로운 버그가 들어오면 제품 책임자가 제품 백로그에 스토리로 추가한다(따라서 다른 스토리에 대해 우선순위를 정할 수 있음). 버그 추적 시스템과 제품 백로그 항목 사이에 참조를 보관하라.
스프린트 계획 회의가 마침내 끝났다!
당신이 이전에 스프린트 계획 회의를 한 적이 없다면 첫 번째 회의가 매우 혼란스러울 것이다. 스프린트가 진행됨에 따라 회의가 더 원활하게 진행될 것이다. 효과적인 스프린트 계획 회의가 건전한 스프린트의 초석이므로 이를 작동시키는 데 시간을 투자할 가치가 있다.
스프린트 계획 회의는 일반적으로 스크럼 중 가장 고통스러운 회의다. 시간 제한을 유지하고, 목표를 염두에 두고, 집중을 유지하라. 휴식과 음식이 중요하다. 창문을 열거나 휴식을 취하고 활력을 되찾는다.
