< 요약 > 이 책에는 스크럼의 공동 창시자인 켄 슈와버가 제시하는 스크럼의 근본 원칙들과 여러 실제 사례들이 담겨 있으며, 애자일 프로젝트 관리를 수행했던 많은 회사에 대한 저자의 다양한 코칭 경험과, 성공과 실패에 대한 살아있는 교훈이 있다. 이 책은 복잡함을 해결하는 스크럼의 새로운 역할, 기존 조직을 설득하고 타협해가는 지혜, 프로젝트를 성공시키는 팀웍과 경험들을 이야기로 들려주면서, 더 가치 있는 소프트웨어를 더 빠르게 만드는 방법을 책 전반에 제시한다. < 소개 > "슈와버가 기록을 또 하나 세웠다. 우리가 모든 애자일 방법론의 핵심 기법과 개념을 이해하도록 이 책을 써준 것이다." - 로버트 C. 마틴(엉클 밥) / 오브젝트 멘토 사의 사장이자 창립자 "이 책을 통해 켄은 전 세계의 스크럼 팀을 멘토링하고, 공인 스크럼 마스터를 가르치며 쌓은 경험을 확실히 보여준다. 소프트웨어를 개발하는 방법을 향상시키고자 하는 모든 이에게 훌륭한 지침서다." - 마이크 콘 / 공인 스크럼 마스터이자 애자일 얼라이언스 이사 “이야기를 들으며 배울 수도 있나요? 저는 그래요. 진짜 애자일이 무엇인지 이야기로 풀어 쓴 완전한 책을 마침내 얻을 수 있었어요. 놀라워요.” - 브라이언 매릭 / 프리랜서 복잡한 프로젝트를 관리하는 간단한 체계인 스크럼에 대한 규칙과 실천방안은 간결하고 직설적이며 배우기도 쉽다. 하지만 구체적 방안이 없는 스크럼의 간결함 때문에, 많은 전문가가 오래된 프로젝트 관리 습관이나 도구로 다시 돌아가 좋지 않은 결과를 얻기도 한다. 스크럼의 공동 창시자이자 전도자인 켄 슈와버는 이 책에서 제시하는 여러 실제 사례를 통해, 애자일 프로젝트 관리를 수행했던 여러 회사에 대한 수많은 코칭 경험을 바탕으로 성공과 실패에 대한 살아있는 교훈을 들려준다. 독자는 이 교훈을 통해, 스크럼으로 복잡한 문제를 해결하고, 더 빠르고 더 가치 있는 소프트웨어를 만드는 방법을 이해할 수 있을 것이다. 스크럼 이론과 실천사항을 이해하면, ■ 아주 복잡하고 다루기 힘든 프로젝트라도 통제할 수 있다. ■ 드러나지 않았거나 변하는 제품 요구사항을 효과적으로 관리할 수 있다. ■ 스스로 관리하는 개발팀을 통해 명령체계를 단순화할 수 있다. ■ 고객으로부터 명확한 요구사항과 피드백을 받을 수 있다. ■ 프로젝트 계획수립에 필요한 시간과 도구를 획기적으로 줄일 수 있다. ■ 제품을 30일 주기로 개발, 배포하므로 고객은 제품을 더 신속하게 인수할 수 있다. ■ 주기적으로 제품 검사, 보고 및 세심한 조율을 통해 실수를 피할 수 있다. ■ 지리적으로 분리된 대규모 프로젝트를 함께 수행하는 다수 팀을 지원할 수 있다. ■ 투자 대비 효과를 극대화한다. ★ 추천의 글 Ⅰ ★ 새로 온 상관이 이상한 사람은 아니었지만, 그 당시에는 그렇게 보였다. 그때 우리는 회사의 대용량 콜 센터에 적용할 새로운 소프트웨어를 개발하는 중이었다. 개발 기간이 12개월 정도 소요될 것이라고 보고했지만 상관은 겨우 4개월만 허락했다. 물론 4개월 후에 바로 새 소프트웨어를 사용해야 할 필요는 없었지만, 그때부터 상관이 해준 일이라고는 실행일 30일 전이라는 통보뿐이었다. 처음 4개월이 지난 후부터는 소프트웨어를 30일 내에 배포할 수 있도록 유지해야 했다. 상관은 4개월 후에 모든 기능이 완성되지 않으리란 걸 알고 있으면서도 가능한 한 빨리 많은 것을 얻고 싶어했고, 나는 그 일을 가능하게 해줄 프로세스를 찾아야 했다. 가능한 모든 소프트웨어 개발 프로세스를 찾아보다가, 마침내 스크럼과 켄 슈와버의 초창기 저서를 접할 수 있었다. 첫 번째 스크럼 프로젝트를 수행한 이후 수년간 나는 상업 제품, 내부용 소프트웨어, 컨설팅 프로젝트, 그리고 ISO 9001 요구사항을 갖춰야 하는 프로젝트에까지 스크럼을 사용해왔다. 프로젝트 하나하나가 다 독특했지만 긴급하고 중요한 프로젝트라는 점에 있어서는 모두 같았다. 스크럼은 조직에 중요한 긴급한 프로젝트에서 그 진가를 발휘한다. 또한 요구사항이 알려져 있지 않거나, 요구사항 자체를 알 수 없거나, 혹은 요구사항이 변하는 경우에 효과적이며, 팀이 뛰어난 능력을 발휘하게 해주는 데도 탁월하다. 이 책에서 켄 슈와버는 스크럼이 어렵다고 정확히 지적한다. 우리가 하는 일 때문에 어려운 것이 아니라 하지 않는 일 때문에 어렵다고 한다. 프로젝트 관리자라면 스크럼에는 전통적인 도구가 몇 가지 빠져 있음을 쉽게 알 수 있다. 스크럼에는 간트 차트가 없고, 보고 시간도 없고, 프로그래머에게 작업을 할당하지도 않는다. 대신 스크럼이 가진 몇 가지 단순한 규칙을 배우고, 좀 더 중요한 소프트웨어를 더 빨리 만들어내기 위해 상황을 자주 점검하고 조정하는 법도 배워야 한다. 켄 슈와버는 스크럼 초기부터 활동해왔다. 켄은 제프 서덜랜드와 함께 스크럼의 창시자이며 지금까지도 최대 지지자다. 켄이 지금까지 참여해온 여러 스크럼 프로젝트에 대해, 이 책을 통해 읽어볼 수 있다. 켄은 산업 관련 컨퍼런스에 빈번하게 출연하는 인기 강사인데, 혹시 그의 강연을 듣는다면 그가 필요 없는 말을 부풀려 하지 않는다는 사실을 알 수 있다. 이 책도 마찬가지다. 켄은 과거의 스크럼 프로젝트 중에서 성공한 프로젝트와 실패한 프로젝트 모두를 제시한다. 켄의 목표는 프로젝트를 성공시키기 위한 방법을 가르치는 것이므로, 우리가 따라 할 수 있는 예제는 물론, 피해야 할 반례도 제시한다. 이 책은 지금까지 스크럼 팀을 멘토링하고, 전 세계에서 공인 스크럼 마스터 과정을 가르쳐온 켄의 경험을 반영한다. 이 책에 담긴 많은 이야기를 통해 켄은 혼자서 터득한 수많은 교훈을 우리에게 나눠준다. 소프트웨어 개발 방법을 향상시키고자 하는 모든 사람에게 훌륭한 가이드임이 분명한 이 책을 강력히 추천하는 바다. - 마이크 콘 / 공인 스크럼 마스터이자 애자일얼라이언스 이사 ★ 추천의 글 Ⅱ ★ 스크럼은 왜 통하는가? 내가 비행기를 타고 시카고에서 보스턴으로 여행하고 있다 치자. 비행 전이나 비행 중 조종사는 항공관제센터에서 지시를 받는다. 명령에 따라 이륙하고, 정해진 루트를 따른다. 항공상에서는 컴퓨터가 보스턴에 언제 착륙할지 분(分) 단위까지 예측해준다. 대기가 불안정한 경우처럼 변경사항이 생기기라도 한다면, 조종사는 고도를 달리할 수 있도록 관제센터에 허락을 구한다. 공항에 접근하면 조종사는 어느 활주로에 착륙할지, 그리고 몇 번 게이트로 가야 하는지도 지시받는다. 하지만 내가 자동차로 보스턴을 간다면, 내가 원하는 루트로 내가 원하는 때에 갈 수 있다. 정확히 언제 도착할지 모르고, 어떤 경로를 택할지, 숙박은 어디서 할지 전혀 계획하지 않을 수도 있다. 하지만 가는 도중 나는 교통법규를 따라야 한다. 빨간 불에는 멈추고, 정해진 규칙에 따라 교통흐름에 합류하고, 그 흐름에 맞춰 속력을 유지해야 한다. 자동차 안에서는 내가 독립적인 주체이므로, 운전이라는 게임의 규칙에 따라 내 관심사에 최대한 맞춰 의사결정을 한다. 중앙 통제나 배차 서비스 없이도 단순한 교통 규칙에 따라 수천 수만 명의 사람들이 목적 달성을 위해 매일 차로 이동하고 있다는 사실은 경이로운 일이다. 물건을 보내고자 할 때도 택배회사의 웹사이트에 접수 요청을 하면 택배기사가 내가 정한 시간에 우리 집 문 앞에 도착한다는 것도 놀라울 따름이다. 택배기사가 각 가정에 배치되어 있진 않지만, 주소와 배달 시한이 지속적으로 갱신되는 목록을 받는다. 하지만 모든 배송 물품을 제시간에 접수할 수 있도록 경로를 정하는 것은 택배기사의 몫이다. 일이 복잡해질수록, 중앙 통제와 배차 시스템은 허물어진다. 누군가는 좀 더 엄격히 적용해 통제 시스템이 작동하도록 노력을 기울일 수도 있고, 그렇게 해서 시스템이 한시적으로 작동하게 만들 수도 있다. 하지만 결국에 승리하는 사람은 바로 적절한 규칙하에 운영되는 독립적인 체계로 변환시키는 방법을 알아내는 사람이다. 하루 일과의 시작 시간에 기사의 루트를 계획해주는 배차 시스템이 있다면 당일 배송도 가능하다. 하지만 고객이 언제라도 원하는 접수 시간을 요청할 수 있다면 물품 접수 루트를 미리 계획하는 일은 훨씬 더 어려워진다. 그래서 택시회사는 주로 중앙통제센터에서 관리를 하고, 택배회사는 해당 지역을 담당하는 기사에게 접수 요청을 한 후, 기사가 현재 상황과 기타 요구사항을 토대로 최상의 노선을 스스로 결정하게 한다. 시스템이 복잡할수록, 중앙 통제 시스템이 허물어질 확률은 높다. 이런 이유로 기업은 분산을 택하고 정부는 규제를 철폐한다. 독립적 조직으로 통제권을 이양하는 것은 복잡함을 다루는 전통적인 접근 방법이다. 스크럼은 통제권을 중앙 일정 관리와 권한 분배에서, 현업의 개별 팀에게 이양하는 방법을 통해 이미 잘 다져진 경로를 밟아간다. 프로젝트가 복잡할수록, 현업에 가까운 독립적 조직에게 의사결정권을 이양하는 일이 더 필요하다. 스크럼이 통하는 또 다른 이유는 고객과 개발자, 요구사항과 구현, 투자와 투자수익률 간의 피드백 주기를 현저하게 줄여주기 때문이다. 다시 말하자면, 복잡함이 그 사이에 존재한다는 의미다. 시스템이 단순할 때는 무엇을 해야 할지 미리 알기가 그리 어렵지 않다. 하지만 항상 변화하는 시장 경제와 정체되지 않은 기술을 다룰 때는, 짧은 주기 발견을 통해 배우는 것이 시도를 통해 알아가는 적극적인 문제 해결 방법이다. 우리 모두 이 사실을 알고 있다. 그래서 다양한 마케팅을 실시해보고 어떤 방법이 효과가 있는지 파악해낸다. 자동차를 설계할 때는 자동차 보닛의 최상의 곡선과 최상의 무게 배분을 알아내기 위해 자동차 움직임을 시뮬레이션해본다. 거의 모든 프로세스 향상 프로그램은 문제를 조사하고, 해결방안을 시도해보고, 결과를 측량하고, 검증된 향상 방법을 수용하는 데 데밍(Deming) 주기를 사용한다. 우리는 이와 같은 방법을 사실에 근거한 의사결정법이라 하는데, 이 방법이 미리 예측하는 방법보다 훨씬 효과가 있다는 사실도 잘 알려져 있다. 스크럼은 완전한 비즈니스 개념을 구현하는 30일 학습 주기에 기초해 만들어졌다. 모든 것을 알고 있고, 알아야 할 게 아무것도 없다면 스크럼을 사용할 필요가 없다. 하지만 무엇인가 배워야 한다면, 비즈니스 가치를 점진적 결과로 배포하는 것을 강조하는 스크럼은 신속하고 완전한 배움이 이뤄지는 데 도움을 준다. 완전한 점진적 결과가 중요한 이유 중 하나는 불완전한 답은 실제 자세히 살펴보면 접근법이 효과가 없는데도 마치 그 접근법이 효과가 있는 것처럼 착각을 불러일으키기 때문이다. 소프트웨어를 테스트하고, 통합하고, 생산을 위해 배포하기 전까지 해당 소프트웨어가 목적하는 비즈니스 가치를 가져다줄 것인지 누구도 확신할 수 없다. 스크럼은 우리가 만든 것을 테스트하고, 통합하고, 제품을 출시하도록 권장하므로 30일마다 완전한 학습 주기가 이뤄진다. 스크럼은 비즈니스 가치의 점진적 결과가 무엇이든 그것을 전달하는 데만 중점을 두는 게 아니라, 고객이 정의한 최고 우선순위의 비즈니스 가치를 전달하는 데 초점을 맞춘다. 제품 책임자와 팀이 정의된 요구사항이 무엇인지 상의하고, 팀은 최우선순위의 비즈니스 가치를 전달하기 위해 30일 내에 무엇을 할 수 있는지 결정한다. 그러면 짧은 피드백 주기는 비즈니스 피드백 주기가 된다. 스크럼은 테스트를 일찍 수행하고, 개발 중인 시스템이 가치를 만들어낼 것인지, 그리고 그 가치가 정확히 어떤 형태로 나타날지 점검한다. 스크럼은 그 가치를 제대로 이해하는 데 도움을 줄 뿐만 아니라, 이해한 상태 그대로의 가치를 전달하기 위한 체계를 형성한다. 스크럼이 통하는 또 다른 이유는 한 가지 문제에 여러 사람의 두뇌를 촉발시키기 때문이다. 문제가 생기면 문제가 있다는 사실을 아는 누군가가 있겠지만 어찌된 영문인지 이들의 생각은 종종 무시된다. 예를 들어, 우주비행선이 재돌입 시점에 폭파됐을 때 이 재앙의 원인을 여러 가지로 보고한 해석에 따르면, 문제가 생길 수도 있음을 간파한 엔지니어가 있었지만 그 엔지니어에게는 문제를 심각하게 피력할 능력이 없었다는 사실을 알 수 있다. 완성해야 할 업무에 가장 근접해 있는 사람의 경험과 생각, 그리고 관심사를 활용하기 위해 어떤 관리 시스템을 사용할 수 있을까? 켄터키 주재 도요타 자동차 공장의 사장인 개리 콘비스(Gary Convis)에 따르면, 건전하고 번영하는 업무 환경에 있는 관리자의 역할은 “의견이나 명령의 힘이 아니라, 본보기와 지도, 그리고 다른 이들의 목표를 이해하고 성취할 수 있도록 도와줌으로써 조직의 틀을 형성하는 것”이라고 했다. 스크럼은 소규모 팀을 스스로의 운명을 책임지는 관리자로 바꿔준다. 보스턴으로 가는 경로를 스스로 선택하는 책임감을 갖는다면 목적지로 도달하는 길을 찾게 될 것임을 우리는 알고 있다. 상황에 따라 의사결정을 하고, 다른 운전자의 판단에 맞춰가며, 공사현장은 우회하고, 출퇴근 시간대는 피해간다. 이와 마찬가지로, 스크럼 팀은 문제를 받아들이고 문제를 해결할 방법을 파악해서, 중앙통제와 배차센터로는 계획할 수도 없는, 창의적인 방법으로 장애물을 우회해간다. 팀의 모든 멤버가 참여하도록 서로를 격려하고, 팀원이 스스로의 운명을 책임질 수 있다고 느낀다면 개인의 경험과 생각, 그리고 관심사를 억압하는 대신, 이들을 활용할 수 있다. 팀원 모두가 믿음을 갖고 공통의 목적을 서로 공유한다면 모두 목적을 성취할 방법을 함께 찾아낼 것이다. 팀이 고객의 비즈니스 가치를 이해하고 이를 전달하고자 노력하고, 태스크를 수행할 방법을 스스로 찾고, 필요한 자원을 배정받는다면, 팀은 성공할 것이다. 개리 콘비스는 도요타의 지속적인 성공이 ’밑바탕에 깔려 있는 서로 맞물린 세 가지 요소, 즉 철학적 토대, 관리 문화, 기술적 도구;로부터 나온다고 했다. “철학적 토대는 협력하고, 고객을 위하고, 사람을 중시하며, 지속적인 향상을 위한 노력을 하고… 관리 문화는... 여러 요소에 뿌리를 두는데, 팀워크, 모두에게 공정하고 평등한 대우, 마지막으로 사실에 근거한 의사결정과 장기적인 사고에 영향을 받는 사람을 참여시키는 일을 통해, 신뢰를 쌓고 유지하는 일을 말한다.” 스크럼은 이와 같은 이유로 성공적으로 적용할 수 있다. 철학적 토대는 개발팀에게 권한을 부여하고 고객을 만족시키는 데 중점을 둔다. 관리 문화는 목표를 달성하도록 남을 돕는 데 근거한다. 기술적 도구는 학습 과정을 통해 사실에 기반한 의사결정을 중시한다. 이와 같은 모든 요소가 준비됐다면, 스크럼이 실패하는 일은 쉽게 일어나지 않을 것이다. - 메리 포펜딕 / 포펜딕.LLC ★ 저자 서문 ★ 여러분에게 복잡한 프로젝트를 관리하기 위한 당혹스럽고도 역설적인 프로세스, 스크럼을 제안한다. 한편으로 스크럼은 단순 명쾌하다. 프로세스, 실천방안, 산출물, 규칙 등이 적고, 간단하며 배우기 쉽다. 2001년 마이크 비들(Mike Beedle)과 함께 나는 스크럼을 설명한, 짧지만 쉬운 책 『Agile Software Development with Scrum』(Prentice Hall) 한 권을 집필한 바 있다. 하지만 스크럼의 단순함은 기만일 수도 있다. 스크럼은 규정에 의한 프로세스가 아니므로, 모든 상황에 대해 해야 할 일을 일일이 서술하지는 않는다. 스크럼은 앞으로 일어날 일이 예상하기 힘든, 복잡한 상황에 주로 사용한다. 단지 모든 일을 가시화하기 위한 프레임워크와 실천방안을 스크럼은 제공할 뿐이다. 이런 특성들 때문에, 스크럼 실무자는 현재 상황을 정확히 파악하면서, 프로젝트가 정한 목표를 제대로 찾아가도록 빠르게 조치를 취할 수 있다. 상식은 경험과 훈련, 겸손, 재치, 그리고 지성의 조합이다. 스크럼을 사용하는 실무자는 업무가 원하는 항로에서 벗어날 때마다 상식을 적용한다. 대부분 사람은 이와 반대로, “이것 해라, 저것 해라.”라고 지시하는 권위적 프로세스에 익숙하기 때문에 상식을 무시하고 지시를 기다리도록 배워왔다. 나는 실무자가 복잡한 문제를 다룰 때, 스크럼 활용 방법을 이해하는 데 도움을 주고자 이 책을 썼다. 하지만 스크럼 프레임워크와 실천방안을 설명하기보다는, 복잡한 문제를 해결하면서 복잡한 작업을 수행하는 스크럼 활용에 대한 다수의 사례를 제시했다. 이 중 몇 가지 사례에서는 실무자가 스크럼을 제대로 사용해서, 문제가 많았던 프로젝트의 목적을 달성시킨다. 또 다른 사례에서는 실무자가 스크럼 때문에 고생하고, 프로젝트도 제대로 성공시키지 못한다. 실패한 사람들에게는 스크럼이 직관적인 방법론이 아니다. 나는 그 동안 어떻게 이런 다양한 결과가 나타날 수 있는지 이해하려고 노력해왔다. 결과적으로 보면 스크럼은 복잡한 프로젝트를 관리하는, 매우 단순한 프로세스다. 프로젝트 관리에 관한 전통적 접근과 비교해보면 스크럼은 매우 쉽다. 최소한 나는 그렇게 생각했었다. 대부분의 프로젝트 관리자는 세부적인 계획과 간트 차트, 그리고 작업 스케줄을 사용하는 결정론적인 프로젝트 관리 방식을 배워왔겠지만, 스크럼은 완전 그 반대다. 프로젝트의 자연발생적인 타성에 부딪히는 전통적 접근과는 달리, 스크럼은 프로젝트 진행에 따라 전개되는 최적의 코스를 따라 어떻게 프로젝트를 관리하는지 보여준다. 학습곡선은, 모든 것을 단계적으로 생각해야 하는 시점에서 시작해서 그 문제를 무의식적으로 수행할 수 있는 시점에서 끝난다고 들은 적이 있다. 이 말은 스크럼에도 해당되는 것으로, 전통적인 관리법에 젖어 있는 사람이라면 먼저 많은 것을 잊어버려야 한다. 최근 어느 소프트웨어 개발 회사에 스크럼 적용하는 일을 도왔다. 처음에 그 회사는 12개월에 걸친 두 번의 릴리스를 계획했었다. 하지만 스크럼 적용의 성공으로, 5개월 만에 두 번 릴리스의 대부분 기능을 준비시킬 수 있었다. 그러나 내가 처음 엔지니어링 조직을 방문했을 당시, 그곳 직원은 릴리스에 더 많은 기능을 포함시키기 위해 밤낮은 물론 주말까지 일하고 있었다. 개발 조직은 나름 대단한 성공을 이뤘지만, 마케팅 팀은 약속한 것에 부응하지 못했고, 제대로 된 상품을 인도하지 못했다는 이유로 엔지니어를 질책했다. 개발 참여자는 마케팅 팀에서 필요하다고 언급한 모든 것을 해내지 못했다는 죄책감을 가졌고, 마케팅 팀에서 요구한 부분을 해내기 위해 개인 생활까지 망치고 있었다. 한 번의 릴리스에 할당된 시간 안에 두 번의 릴리스에 해당하는 업무를 이미 완료했는데도 불구하고, 이런 병적인 현상은 계속 지속됐다. 오래된 관행은 사라지기 어려운 법인가 보다. 스크럼이 일으키는 또 다른 변화는 집을 어떻게 짓는지를 생각해보면 잘 이해할 수 있다. 집을 구매한 사람일지라도 집이 다 완성되기 전까지는 그 집으로 이사할 수 없다. 건축에도 점진적이고 반복적인 접근법이 있다고 가정해보자. 그 접근법을 사용하면 집은 방 하나씩 완성될 것이다. 첫 번째 방의 배관, 전기, 인프라를 완성한 후 다른 방으로 확대해가면 된다. 구매자는 충분한 수의 방이 완성됐다는 생각이 들면 바로 입주할 수 있다. 구매자의 필요에 따라 방을 추가할 수도 있다. 스크럼을 통해 구매자는 이와 같은 방식으로 만들어진 소프트웨어를 얻을 수 있다. 인프라가 배포되는 동안, 구매자 조직이 개발주기 초기부터 시스템의 일부를 사용할 수 있도록 기능 일부를 먼저 인도할 수 있다. 일부 시스템을 경험해본 구매자는, 어떤 순서로 시스템의 각 부분을 구축할지 결정할 수 있고, 해당 부분이 완성됨에 따라 각 기능을 사용할 수 있다. 구매자가 처음에 생각했던 전체 기능의 일부분만으로도 만족한다면 전체 시스템을 다 구축하지 않을 수도 있다. 예전에는 스크럼 이론과 실천방안, 그리고 규칙을 가르쳤지만, 요즘은 스크럼이 구현될 때의 느낌을 가르치고, 일이 제대로 될 때와 그렇지 않을 때 프로젝트를 다시 구성하는 방법을 가르친다. 스크럼이 어떤 느낌인지 직접 경험해보는 연습과 토론을 진행한다. 다른 사람의 입장에 서보지 않고는 그 사람이 되는 것이 어떤 기분일지 진정으로 알 수 없듯이, 스크럼을 직접 구현해보지 않고는 스크럼을 완전히 이해할 수 없다. 하지만 이 책을 읽으면 스크럼이 어떤 것인지 이해하기 시작할 것이고, 조직에서 스크럼을 사용한다는 게 어떤 것인지 느낄 수 있을 것이다. 본질적으로 스크럼에 관한 사례로 이뤄진 이 책을 어떻게 읽어야 할까? 각 사례에 관한 배경 설명을 주고, 주어진 상황에서 어떻게 스크럼을 활용하는지, 그리고 스크럼 사용을 통해 배울 수 있는 교훈을 이 책에 제시했다. 사례는 주제별로 정리해서 편하게 볼 수 있게 했다. 각 장 주제는, 1장 ‘배경: 스크럼의 과학’, 2장 ‘관리자의 새로운 책임’, 3장 ‘스크럼 마스터’, 4장 ‘혼돈 속에서 질서 찾기’, 5장 ‘제품 소유자’, 6장 ‘스크럼 프로젝트 계획수립’, 7장 ‘프로젝트 보고활동: 가시성 확보’, 8장 ‘팀’, 9장 ‘스크럼을 사용한 프로젝트 규모조정’이다. 가끔 해당 사례 배경을 앞 장에 이미 언급했다고, 주지시키기도 했다. 부록 A는 ‘규칙’으로, 여러 스크럼 수행과 회의에서 사용하는 규칙을 열거했다. 규칙은 스크럼을 하나로 묶어준다. 스크럼 자체는 익숙하지만, 제대로 이해하지 못한 용어가 있다면 부록 B ‘용어 정의’를 찾아보면 된다. 스크럼에 아직 익숙하지 않다면 스크럼 이론, 흐름, 실천방안, 산출물, 역할, 회의를 간략하게 설명한 1장 ‘배경: 스크럼의 과학’을 반드시 읽어보 바란다. 부록 C ‘참고자료’는 스크럼을 한층 더 깊게 이해하고자 할 때 필요한 자원 목록이다. 부록 D ‘가격과 날짜가 확정된 계약’과 부록 E ‘CMM’은 이 책의 미운 오리 새끼다. 이들 부록은 이 책의 본론 부분의 사례에서 설명하지 않은, 특이한 상황에서 스크럼을 사용할 때 도움이 되는 자료를 담고 있다. ★ 옮긴이의 말 ★ 90년대 들어, CORBA나 DCOM 기반의 국내 프로젝트를 수행할 때까지만 해도 주로 UP를 적용했었다. 애자일을 처음 경험한 건 1999년 J2EE 기반 금융투자 시스템을 만들 때였다. 그 당시 젊은 미국 여자 PM과, 나이 많은 캐나다 아키텍트, 그리고 소련과 인도 등 다양한 지역에서 온 개발자들과 함께 프로젝트를 했다. 지속적인 통합과 빌드 체계 속에 다양한 XP 프랙티스를 경험했다. 그 이후 증권사 차세대를 포함한 많은 프로젝트에 팀 수준 프랙티스로 애자일 경험을 부분적으로나마 적용해왔다. 최근에는 SOA를 위한 비즈니스 서비스와 기술 프레임워크를 만든 후, 이들을 활용한 애플리케이션을 국내외에 구축하는 프로젝트에 스크럼과 TDD를 적용했다. 큰 프로젝트에 애자일을 적용하는 일은 쉽지 않다. 커다란 프로젝트에는 국내외의 변화하는 시장 상황, 이사회까지 거쳐야 하는 예산 승인, 다양한 조직 간 이해관계 등 기술적으로 풀 수 없는 문제가 많으며, 차세대 프로젝트는 기업 전반의 가치 흐름과 기업 간의 가치 사슬까지도 이해하고 있어야 하기 때문이다. 이는 도전적이기는 하지만, IT에 몸담고 있는 사람에게는 매우 다양한 가치를 만들 수 있는 새로운 기회일 수 있다. 그런데 커다란 프로젝트를 애자일로 할 수 있을까? 당연히 가능하다. 다만, 기존의 커다란 프로젝트를 성공적으로 수행해본 경험과 기술을 바탕으로 애자일을 적용해야 한다. 특히 스크럼 마스터나 제품 소유자는 전사적 수준의 프로젝트 성공 경험이 반드시 있어야 한다. 하지만 그런 경험이 없다면? 이 책은 여타 책들과는 달리, 저자가 경험한 프로젝트 이야기를 많이 들려준다. 마치 성문법이 아닌 관습법처럼, 이 세상의 규칙을 설명하기보다는 몇 개의 근본 원리를 바탕으로 저자의 경험을 들려주면서 독자 스스로 생각을 진화시키게 하는 느낌을 준다. 마치 바둑의 간단한 원리를 설명하고, 다양한 기보를 통해 바둑이라는 것을 소개하는 책처럼. 크고 작은 거의 모든 프로젝트에서 나는 항상 부족함을 느낀다. 이 책이 부족함에 대한 모든 갈증을 채워주는 것은 아니지만, 저자의 소중한 경험을 일부나마 느끼게 해준다. 저자는 경험을 표현하고 싶고, 나누고 싶어한다. 올바른 것, 상황에 맞는 것을 적용하는 방법을 공유하고, 함께 좋은 것을 만들어가고 싶어한다. 나도 그의 생각에 전적으로 동의한다. 서로 경험과 지식을 나누고, 함께 좋은 것을 만들어가고 싶다. 그것이 이 책을 번역한 동기이며, 부족하지만 내가 그간 책을 계속 써온 이유이기도 하다. 저자의 소중한 경험을 이 책을 통해 조금이라도 느껴보기 바라며, 작은 프로젝트만이 아닌 커다란 프로젝트에 대한 성공 경험도 쌓아, 독자 여러분도 서로에게 소중한 경험을 전달할 수 있기를 바란다. - 박현철

1장 배경: 스크럼 과학 ___경험주의적 프로세스 제어 ___복잡한 소프트웨어 개발 ___스크럼의 구조와 핵심 ___스크럼 내의 역할 ___스크럼의 흐름 ___스크럼 산출물 ______제품 백로그 ______스프린트 백로그 ______제품 기능 증가분의 출시 가능성 ___정리 2장 관리자의 새로운 책임 ___메타에코의 스크럼 마스터 ______메타에코 상황 ______실전에서의 스크럼 마스터 ______스크럼 마스터의 가치 ___메가에너지의 제품 소유자 ______메가에너지 상황 ______실전에서의 제품 소유자 ______제품 소유자의 가치 ___서비스퍼스트 팀 ______서비스퍼스트 상황 ______실전에서의 팀 ______팀의 가치 ___결론 3장 스크럼 마스터 ___트레이 리서치의 훈련 안 된 스크럼 마스터 ______무엇이 문제인가 ______교훈 ___리트웨어의 훈련 안 된 스크럼 마스터 ______무엇이 문제인가 ______교훈 ___콘토소 닷컴의 과욕 ______옳은 것이 전부는 아니다 ______교훈 ___메가펀드의 늑대들 ______늑대의 습격 ______교훈 ___결론 4장 혼돈 속에서 질서 찾기 ___서비스퍼스트 상황 ______스크럼 적용 ______교훈 ___트리 비즈니스 출판사 상황 ______스크럼 적용 ______교훈 ___랩색 상황 ______스크럼 적용 ______교훈 ___결론 5장 제품 소유자 ___고객과 팀의 협업 ___서비스퍼스트 경영진의 현장 복귀 ______스프린트 검토 회의 ______교훈 ___메가펀드의 엑스플로우 문제 해결 ______문제 제기 ______교훈 ___테크코어의 목표 ______스크럼이 테크코어를 어떻게 도왔나 ______교훈 ___메가뱅크 이체 시스템의 목표 ______스크럼이 FTS 프로젝트를 어떻게 도왔나 ______교훈 ___결론 6장 스크럼 프로젝트 계획수립 ___메가뱅크의 현금 관리 ______2일간 스프린트 계획수립 회의 ______교훈 ___투자회수율에 관한 공인 스크럼 마스터의 시각 ______MLBTix ______각기 다른 팀 반응 ______교훈 ___결론 7장 프로젝트 보고: 가시성 확보 ___메가에너지 타이틀 프로젝트를 위한 새로운 프로젝트 보고 ______문제 해결 ______교훈 ___메가뱅크에서 더 많은 정보 얻기 ______문제 해결 ______교훈 ___서비스퍼스트의 모든 것이 가시적이지는 않다 ______현실 ______교훈 ___결론 8장 팀 ___서비스퍼스트의 팀 형성 ______누가 책임자인가: 전환 ______관리 잘하는 법 배우기: 전환 ______자기조직화 배우기: 전환 ______업무량 추정하기: 전환 ______일하면서 즐기는 법 배우기: 전환 ___웹뉴사이트팀에게 기회 부여하기 ______배경 ______교훈 ___결론 9장 스크럼을 사용한 프로젝트 규모확장 ___메가펀드의 확장 ______접근법 ______교훈 ___스크럼 확장 ___메드신소프트의 확장 ______접근법 ______버그 수정 ______교훈 ___결론 부록 A 규칙 ___스프린트 계획수립 회의 ___일일 스크럼 회의 ___스프린트 ___스프린트 검토 회의 ___스프린트 회고 회의 부록 B 용어 정의 부록 C 참고자료 부록 D 가격과 날짜가 확정된 계약 ___경쟁우위 차지하기 ___경쟁우위 무시하기 부록 E CMM ___메가펀드의 CMM ___SEI, CMM, 그리고 스크럼