‘애자일 방법론은 대규모 프로젝트, 엔터프라이즈급 환경에는 적합하지 않다’는 잘못된 통념은 이제 사라져야 한다. 대기업이나 대규모 프로젝트에 적용하는 데 필요한 베스트 프랙티스뿐 아니라 조직이 갖춰야 할 인프라와 조직의 문화적인 측면까지 폭넓게 다루며 개발 역량을 높이기 위해 필요한 사항을 구체적으로 제시한다.


[ 추천사 ]

다년간 많은 회사들이 대규모 애자일 프로젝트 구현을 시도해 왔다. 하지만 ‘애자일은 소규모 프로젝트에만 효과가 있다’라는 ‘오해’가 애자일을 시작하려는 초보자들에게는 걸림돌로 다가왔으며, 애자일 비평가들에게는 좋은 비평거리가 됐다. 애자일에 대한 연구자료 중 애자일 방법론을 대규모 프로젝트 개발에 적용한 실무서는 지금까지 없었다. 딘 레핑웰의 책 『엔터프라이즈급 애자일 방법론』은 이 격차를 현저히 줄일 수 있을 것이다. 이 책은 아키텍처, 요구사항 개발, 다중 릴리스 계획, 팀 조직 등 대규모 프로젝트에서 빈번하고 중요하게 발생하는 문제에 대해 실무적인 가이드를 제공한다. 레핑웰의 책은 대규모 프로젝트와 조직에서 애자일 개발을 적용하는 데 반드시 필요한 지침서다.

소프트웨어의 신속한 개발과 출하, 시장 변화에 따른 유연성 확보와 제품의 안정성 유지 사이에는 팽팽한 긴장감이 감돈다. 이 책에서 저자 딘 레핑웰은 이들 간의 균형을 어떻게 유지해야 하는지 잘 보여주고 있다. 이 책에 나오는 저자의 관점과 해결책, 그리고 베스트 프랙티스에 대한 설명은 그가 겪은 모든 경험과 성취와 깨달음을 통해 우러난 것이다.


[ 소개 ]

신속한 시장 출시, 변화하는 고객 요구사항에 대한 유연한 대응, 향상된 품질 확보 등 애자일 개발 활동을 통해 많은 이익을 얻을 수 있다. 지금까지 애자일 활동은 소규모 팀을 대상으로 정의되고 추천됐다. 저자 딘 레핑웰은 드디어 이 책에서 애자일 방법론을 엔터프라이즈급 대규모 개발 프로젝트에 적용하는 방법을 공개한다.

1부에서는 보편적이고 효과적인 애자일 방법론들에 대해 개괄적으로 설명한다. 2부에서는 대규모 프로젝트에 애자일의 7가지 베스트 프랙티스들을 자연스럽게 확장하는 방법을 설명한다. 3부에서는 엔터프라이즈급 프로젝트에 애자일을 적용했을 때, 애자일의 모든 이점을 얻으려면 조직이 반드시 숙지해야 하는 7가지 능력에 대해 설명한다.


[ 추천의 글 ]

어떻게 하면 큰 조직에 애자일을 적용할까를 고민하는 사람은 생각보다 그리 많지 않다. 대다수는, 그리고 설사 자신이 큰 조직에 속하더라도 우선은 자신이 속한 소규모 팀이 어떻게 애자일을 도입하고 효과를 낼까 하는 것에 관심이 있다. 하지만 간혹 대규모 적용을 고민하는 사람들이 있다. 조직 내외의 컨설턴트나 기술에 관심 있는 경영진, 정치적 힘을 가진 PM, 혹은 그 사람들 주변의(그리고 종종 그 사람들을 설득해야 하는) 사람들이다.

원래 이런 사람들은 애자일에 별 관심이 없었다. 애자일과 대규모 조직은 그다지 잘 어울리지 않는 그림이었다. 하지만 애자일이 성공 경험을 쌓아가면서, 또 널리 전파되기 시작하면서 대규모 조직에서도 애자일에 관심을 두게 됐다. 여기에서 문제가 생기기 시작했다. 애자일을 어떻게 스케일업하는가. 안타깝게도 애자일을 대규모 프로젝트에 적용한 사례나 베스트 프랙티스가 많지 않았다.

하지만 선구자들에 의해 사례들이 쌓이기 시작했다. 심지어는 애자일의 대규모 적용(예컨대 수천 명 이상의 프로젝트)만 담당하는 컨설턴트까지 생겼고, 이 책처럼 애자일을 대규모 프로젝트에 적용하는 책들이 나오게 됐다.

『엔터프라이즈급 애자일 방법론』 우선 이 책이 우리말로 번역되어 기쁘다. 나에게 “애자일은 대규모 프로젝트/조직에 적용할 수 없어요”라는 비판을 하는 사람의 숫자가 줄어들 것 같다. 또, 어떻게 하면 좋을지 관련 자료를 요청하는 사람에게 권해줄 책이 생겨서 기쁘다. 하지만 미리 경고해 두건대 대규모 적용은 그것이 무엇이건 어렵다. 그러나 처음 시도하는 사람이거나, 아니면 이미 실패를 맛본 사람이거나 간에 이 책을 훑어보면 분명히 한두 가지 이상은 힌트를 얻으리라 생각한다.

1부에서는 애자일에 대한 요약 설명을 한다. 애자일을 잘 모르는 사람에게는 이 책이 간단한 소개서 역할도 할 수 있다는 장점이 있다. 2부와 3부에 걸쳐 총 14가지의 대규모 적용을 위한 실천법들을 소개한다. 사실 2부의 7가지 실천법은 팀 수준의 실천법인데 프로젝트 규모에 큰 상관없이 스케일업해서 적용 가능하다고 한다. 3부가 이 책의 골자라는 생각이 든다.

마지막으로 한마디. 많은 사람은 일명 풀뿌리식이라고 하는 버텀업(bottom-up)을 어떻게 해야 잘할까를 고민하지만, 대규모 적용을 고민하는 사람들은 보통 탑다운(top-down)을 어떻게 해야 잘할까를 고민한다. 남들 입장에서 보기에는 행복한 고민이다. 부사장이 애자일을 지지한다는데 뭐가 걱정이냐 이거다. 하지만 내 경험에서는 피차일반이다. 모두 성공이 간단하지 않다. 내 컨설팅 경험에서 가장 성공적인 경우는 샌드위치식(버텀업과 탑다운 겸비)으로 접근할 때였다. 엔터프라이즈 수준에서는 전략적인 탑다운식 도입과 체계적이고 발 빠른 조율을 하되, 개개인 수준에서는 애자일의 인간성 부분을 강조해서 자발적 참여가 일어나도록 동기 관리에 많은 노력을 기울일 것을 권한다.

이 책을 통해 국내에서 대규모 애자일 성공 사례들이 많아지기를, 그리고 이를 통해 국내 IT 업계가 더 인간적이고 생산적인 곳이 되기를 진심으로 기원한다.



[ 이 책의 구성 ]

1부. 소프트웨어 애자일 방법론 소개
이 책은 세 부분으로 구성된다. 1부는 애자일 방법론에서 가장 많이 쓰이는 XP, 스크럼, 애자일 방식을 적용한 반복적이고 점진적인 방법론인 RUP에 대해 이야기하고, 애자일 역사에 대해 간단히 알아본다. 더불어 애자일 방법론을 지원하는 린 소프트웨어 개발, 동적 시스템 개발방법론(DSDM), 기능 주도 개발방법론 등도 간략히 살펴본다.

2부. 애자일을 확장 적용하는 7가지 팀단위 애자일 활동
2부는 각 장마다 팀 규모에서 적용하는 7개의 애자일 활동을 예로 들어 애자일의 기본 개념에 대해 이야기한다. 각 활동은 직간접적으로 애자일 방법론의 필수 요소를 보여준다. 애자일을 처음 들어본 사람이나 애자일 방법론이 어떻게 구현되는지에 관심이 있는 대규모 조직이라면 2부에 나오는 예제들을 통해 애자일 방법론이 얼마나 간단하게 적용되는지 살펴볼 수 있을 것이다. 더불어 현재 조직 상황에 맞춰 애자일 방법론을 수정하고 적용하는 방법도 배울 수 있다.

3부. 엔터프라이즈 환경에 맞는 애자일 방법론
애자일 방법론을 엔터프라이즈 환경에 적용하려면 좀더 많은 작업이 필요하다. 3부에서는 엔터프라이즈 환경에 맞는 애자일에 대해 설명한다. 3부에서는 조직이 애플리케이션과 시스템 규모에 관계없이 애자일 방법론을 적용하는 데 필요한 능력과 지침, 원칙, 활동들을 보여준다. 여기서 다루는 예제들은 실제로 엔터프라이즈 환경에 직접 애자일 방법론을 적용해본 결과에서 나온 것들로서, 다국적 개발자와 외주 용역 40~50명 정도로 구성되어 이전 기술에 구애받지 않고 완전히 새롭게 시작하는 소규모의 ‘그린 필드’ 프로젝트부터, 하나의 목표 아래 1,000명 정도가 팀을 이뤄 팀원들 간의 조화가 필요한 대규모 조직까지 전반적으로 다룬다. 3부의 원칙 중에는 분명히 생소할 내용도 있을 것이다. 이 중 몇 가지는 애자일을 적용하는 과정에서 각 팀이 수정하고 발전시킨 경험들이다.

이 책이 애자일 방법론을 활용해 소규모 팀에서 효과를 본 것만큼 대규모 조직에도 200퍼센트 향상된 생산성과 품질 제고에 도움이 되었으면 한다. 그리고 생산성과 품질 향상을 통해 대기업들이 좀더 빠른 제품 출시와 개발, ROI 향상, 사용자 만족도 증가를 이룰 수 있기를 바란다. 더불어 애자일 방법론을 통해 무형의 이익도 기대할 수 있다. 팀 스스로 애자일 방법론을 사랑하고 여러 가지 시도로 더욱 강해지며 조직에 맞는 그들만의 방법론을 만들어서 지속적으로 프로세스를 발전시킬 것이다. 그리고 지속적으로 프로세스를 발전시키면서 프로젝트 결과, 사람, 전문성 그리고 업무에 대한 만족도까지 함께 향상될 것이다. ‘새로운 것에 도전하는 기업’은 언제나 가치가 있다.


[ 서문 ]

애자일 프로세스라는 용어에 익숙하지 않은 사람이라면 두려움과 의심을 느끼면서 이 책을 펼쳤을지도 모르겠다. 하지만 그건 여러분 탓이 아니다. 애자일 프로세스를 배우다 보면 질주(스프린트, sprint), 속력(velocity), 스크럼(scrum, 럭비게임의 기본 대형?), 익스트림 프로그래밍(extreme programming, 스노보드로 벼랑 끝에서 점프하는?), 사용자 스토리(user stories), 서사(에픽, epic)와 전설(saga, 소설에 나오는 이야기?), 불가사의한 사회적 의례(weird social rituals), 짝 프로그래밍(pair programming), 사용자 회고(user retrospectives), 허들(huddles), 일일 스탠드업 미팅(이제 서로 껴안아줘야 하나?) 등과 같은 기이한 표현들을 자주 접하게 될 것이다. 또 애자일팀들은 엄청나게 많은 포스트잇과 명함 만한 인덱스카드를 벽에다 마구 붙이면서 무질서하게 일을 하는 것처럼 보이기도 한다. 그리고 이런 행동들은 마치 스콧 애덤스의 만화 딜버트(Dilbert)에나 나오는 이야기처럼 보인다. 그러나 착각하지 않길 바란다. 애자일 소프트웨어 개발 프로세스는 제프리 무어가 말한 것처럼 ‘큰 차이를 극복하는 것(Crossing the Chasm)’이라 할 수 있다. 이제 애자일은 단순히 흥미를 끄는 유행어를 넘어선, 효과적이고 생산적이며 측정 가능한 개발방법론이다. 애자일 개발방법론을 받아들여 성공의 길로 들어서느냐 아니면 그냥 이대로 낙오하느냐는 모두 여러분에게 달렸다.

애자일 개발방법론은 ‘계획적인 개발’ 방법론과는 차이가 있다는 말을 어디선가 들어봤을 것이다. 어떻게 생각하면 애자일 방법론은 매우 무질서하며 그동안 알고 있던 체계적이고 계획적인 소프트웨어 개발방법들과는 많이 다르다고 느꼈을 것이다. 하지만 계획을 세우는 방법이 다를 뿐, 애자일 프로젝트도 매우 주의 깊게 계획된다. 다만 여타 개발방법론에 비해 좀더 자주 정제되고 재계획된다는 점에서 차별된다고 할 수 있다. 애자일 방법론은 7~12명으로 구성된 소규모 팀이 2~9개월 동안 진행하는 단기 프로젝트에는 높은 효율을 보이지만 전 세계에 퍼져 있는 대규모 팀이 진행하는 장기 프로젝트에는 적합하지 않다고 알려졌다. 그렇다고 이 책을 덮을 필요는 없다. 전 세계에서 진행되는 대부분 프로젝트처럼 애자일 프로세스도 그 경계를 넓혀나가면서 생산성이 높은 고품질 소프트웨어를 만들어 가고 있다.

이 책에서 딘 레핑웰이 이야기하고 싶어하는 것은 다음과 같다. 익스트림 프로그래밍(XP), 스크럼(Scrum), 린(Lean), 동적 시스템 개발방법론(DSDM, Dynamic System Development Method), 기능 주도 개발방법론(FDD, Feature Driven Development), 유니파이드 프로세스(Unified Process)와 같은 애자일 프로세스 사이에 발생하는 문제들에 대해 상호 간에 어떤 공통점이 있는지를 먼저 설명한다. 그러고 나서 저자는 이런 장점이 있는 다양한 방법론보다 애자일 접근 방법이 더욱 월등한 이유를 열띤 논조로 이야기하고 있다. 저자는 이 책에서 기존 방법론들과 새로운 애자일 프로세스를 이야기하려는 것이 아니라, 기존 애자일 실례와 새로운 예제를 통해 고수준의 기술과 관리 방법을 설명하고자 한다. 저자는 기존의 베스트 프랙티스에서 볼 수 있었던 내용뿐만 아니라 좀더 큰 애자일 프로젝트 관리에 초점을 맞춰 설명하고 있다. 예를 들어 이제까지는 많이 언급되지 않았던 릴리스 계획법, 대규모로 분산된 팀들을 다루는 법, 프로젝트 사업 목표 수립법, 장기 프로젝트 수행법 등을 다룬다.

저자는 그저 탁상공론을 논하는 학자가 아니며 자신이 주장하는 방법론을 주입시키기 위해 어림짐작으로 이야기하지도 않는다. 저자가 이 책에서 충고하는 내용은 수많은 회사와 다양한 프로젝트(생명의학용 소프트웨어부터 놀이공원과 놀이기구에 필요한 거대한 IT 인프라 애플리케이션까지)에서 직접 겪은 오랜 경험을 바탕으로 하고 있다. 나는 래셔널(Rational) 사와 랠리(Rally) 사에서 저자와 10년 동안 함께 일해왔기 때문에 누구보다도 잘 알고 있다.

이 책에 대한 몇 가지 충고를 덧붙이자면, 이 책을 읽은 후 책의 내용을 그대로 따라 한다고 해서 모든 프로젝트가 곧바로 성공할 거라 기대하면 안 된다. 부동산 업자들이 위치(location)를 중요하게 생각하는 것처럼 새로운 소프트웨어 개발 예를 적용하는 것의 핵심은 컨텍스트(context)라고 말할 수 있다. 여러분이 처한 컨텍스트, 즉 상황을 잘 이해한 다음, 저자가 주장하는 내용과 비교해보고, 프로젝트의 목표와 범위, 크기, 조직 문화 등을 비교해 저자가 추천하는 방법들을 여러분의 조직에 적용하길 바란다. 고려하고 있는 상황은 다양한 요소로 구성되어 있을 것이다. 예를 들어 조직의 도메인(어떤 일을 하는 산업인지), 개발하고자 하는 시스템의 규모, 팀의 경력, 각 팀원의 경험과 교육수준과 학력, 사용하고 있는 기술, 시스템의 엄격도, 심지어는 여러분의 조직과 나라의 문화까지도 포괄한다. 이 책에서 저자는 기업가, 소프트웨어 개발 관리자, 경영진, 방법론자, 컨설턴트 등 다양한 경험을 바탕으로 자신이 정립해둔 가치와 기준, 자신이 처했던 여러 상황을 설명하고 있다. 물론 여러분의 경험은 저자와는 다를 것이다. 책을 읽으면서 조금이라도 의구심이 든다면, 특정 용어와 방법에 연연하지 말고 애자일의 기본 개념을 떠올려보길 바란다.

문서화가 되어 있든, 사람들의 머릿속에만 존재하든 간에 ‘애자일 프로세스’는 프로세스 자체가 기민하거나 민첩하게 변화하는 것이 아니라, 사람이나 팀, 조직 등이 민첩하게 변화하는 것이다. 단순히 애자일 프로세스를 따라만 하기보다는 애자일 자체가 여러분이나 여러분이 속한 조직에 녹아 있어서 ‘애자일’의 속성이 여러분 몸에 깊이 배어들어야 한다. 여러분이 속한 그룹이나 여러분 자체가 애자일화되지 않고 단순히 애자일 프로세스에서 제공하는 몇 가지 방법들만 적용하려고 한다면, 이유를 알지 못한 채 실패할 것이며 어느 책에선가 나쁜 선례로 언급될지도 모른다. 이 차이를 극복하려면 저자나 다른 사람들이 말하는 것을 그대로 따라 하거나 애자일 방법론을 그대로 받아들이는 것을 넘어 그 이상으로 열심히 노력해야 할 것이다. 쉽진 않겠지만 마음가짐이나 태도 자체가 변화해야 한다. 마음가짐이나 태도라는 건 단순히 책을 읽는다거나 교육과정을 통해 수업을 듣는다고 해서 저절로 바뀌는 게 아니다. 애자일 프로세스에서 이익을 얻으려면 여러분과 여러분이 속한 조직이 애자일의 기본 원칙을 받아들여 새로운 시도를 반복, 또 반복해야 한다. 그리고 여러분의 경험을 평가해보고 그 경험을 살려, 새로운 시도를 통해 어떤 것을 얻고 얻지 못했는지를 검토하고 얻어낸 교훈을 다시 적용해 봐야 할 것이다. 거듭 말하지만, 이 책을 읽었다고 해서 애자일 방법론을 모두 배웠다고 생각하지 않길 바란다. 이 책을 통해 생각하고, 느끼고 변화해야만 진정한 애자일이 무엇인지 알게 될 것이다.

만일 여러분이 애자일에 대해 잘 알고 있고, 1970년대 천공카드를 쓸 때부터 애자일 프로세스가 몸에 배어 있는 사람이라면 이 책에서 무엇을 얻을 수 있을까? 답부터 말하자면, 그래도 배울 게 아주 많을 것이다. 개인적으로 이 책을 검토하는 동안 그동안 내가 겪어온 경험과 실례들을 돌이켜볼 수 있었으며 많은 것을 배울 수 있었다. 사실 저자가 말한 모든 의견에 동의하는 건 아니다. 내가 처했던 상황과 경험은 그와는 약간 차이가 있기 때문이다. 하지만 저자와 나는 몇몇 특정 용어와 방법을 제외하고는 전체적으로는 이 책의 모든 내용이나 기본적인 원칙과 전략에 대해서는 서로 동의하고 있다(얼마 전 그에게 들은 바대로 우리는 각자의 의견을 서로 나누며 토론 자체를 즐겼다. 토론을 통해 우리가 지닌 핵심 원칙을 시험해보고 서로 생각을 알아보기도 했다). 이런 관점에서 볼 때, 여러분이 이미 애자일을 많이 경험했더라도 이 책에서 더욱 가치 있는 교훈을 얻고 지식을 한층 강화할 수 있을 거라 믿는다.

자, 이제 충분히 이야기한 것 같다. 이것으로 서문을 마치고 페이지를 넘겨 본론으로 들어가 보자. 책을 읽는 동안 즐겁게 배우면서 ‘애자일’을 몸소 실천하길 바란다.

[ 저자 서문 ]

소프트웨어 방법론 경력 1단계: 레라와 리퀴짓 사

나는 업무를 통해 소프트웨어 공학과 소프트웨어 개발 관리에 대한 기술을 익히고 발전시켜왔다. 목표는 항상 일정했지만, 소프트웨어 개발 경험은 크게 3단계를 통해 발전한 것 같다. 첫 번째는 다른 업체 수주를 받아 소프트웨어를 개발해주던 레라Rela 사(社)의 CEO로서 출발했다. 레라는 놀이동산의 놀이기구부터 생명의학 장치까지 다양한 분야에 걸쳐 사용되는 소프트웨어 애플리케이션을 개발하는 회사였다. 레라의 소프트웨어는 고객에게 수주해 진행하는 것이었기 때문에, 회사의 목표는 언제나 “고객이 원하는 것을 제대로 만들자(build the right thing)”였다. 회사의 모든 역량은 주어진 문제의 해결책은 무엇인지, 그 해결책을 적용하는 가장 효과적인 방법은 무엇인가를 연구하고 고객에게 설명하는 것에 집중됐다.

그래서 폭포수 방법론(waterfall method)에 기반을 둔 엄격한 방법론을 사용했다. 실제로 몇몇 고객과 식품의약국(FDA) 같은 주요 규제 조직에서는 폭포수 방법론을 원했고, 우린 고객이 원하는 대로 폭포수 방법론을 따랐으며, 필요한 경우 약간의 수정을 가해 적용하기도 했다. 폭포수 방법론을 사용하는 동안 우리가 알아낸 사실은 폭포수 방법론이 과거 프로젝트 중 일부를 기반으로 발전시키고 산출물을 중요시한다는 점이다. 당시 내 주관심사는 요구공학 프로세스(Requirement Engineering Process)에 있었는데, 이는 프로젝트에 큰 영향을 미치는 심각한 문제점을 찾을 수 있으며, 문제의 해결책에 대한 정의가 이뤄지고, 계약의 밑바탕이 되기 때문이었다.

이런 경험을 바탕으로 나는 요구공학 솔루션 프로그램인 리퀴짓프로(RequisitePro)를 만든 리퀴짓(Requisite) 사의 창립자이자 CEO가 될 수 있었다. 리퀴짓 사에서는 요구사항 정의에 필요한 사례와 제품을 개발하고 발전시킬 수 있었으며, 이런 경험 덕분에 소프트웨어 개발 사이클 전반부에 대한 많은 경험을 갖게 됐다. 1997년 리퀴짓은 래셔널 사에 인수되었고, 나는 소프트웨어 개발 프로세스 인생의 두 번째 전기를 맞게 된다.

소프트웨어 방법론 경력 2단계: 래셔널 사

나는 래셔널(Rational) 사의 고위 경영층으로서 UML(Unified Modeling Language)과 RUP(Rational Unified Process) 배포에 조력하고 있었다. 래셔널 사에서 그래디 부치(Grady Booch), 이바 야콥슨(Ivar Jacobson), 제임스 럼바우(James Rumbaugh), 워커 로이스(Walker Royce), 필립 크루첸(Philippe Kruchten)과 같은 당대 석학들과 함께 일할 좋은 기회를 얻을 수 있었다. 그리고 이때 돈 위드릭(Don Widrig)과 함께 Addison-Wesley 출판사에서 『Managing Software Requirements』(2000)라는 책을 집필, 출간했다.

생각할 수 있는 모든 개념은 객체지향(Object Orientation)에 바탕을 뒀는데, 객체지향 사고방식을 통해 개발방법론은 유연성이 높아지고 소프트웨어를 더욱 탄력적으로 작성할 수 있었다. 또 폭포수 모델과는 달리 반복 점진적인 소프트웨어 개발이 가능해졌다. 이렇게 하면 주기마다 객관적으로 평가할 수 있는 소프트웨어를 만들어낼 수 있었고, 이런 방식은 폭포수 모델을 사용할 때보다 좀더 애자일스러웠다. 폭포수 모델을 사용할 때와는 달리, 문서나 디자인 리뷰와 같은 중간 산출물들이 독립적으로 존재할 필요가 없었고 측정, 평가도 가능했다.

래셔널 사는 래셔널 유니파이드 프로세스(RUP)란 이름으로 이 모든 과정들을 집대성해 문서화했다. 그리고 시장에 출시하고 산업체에 적용해 좋은 성공 스토리를 만들었다. 뿐만 아니라 이 프로세스와 래셔널 사의 제품군을 개발에 적용했고, 4개국에 걸쳐 800명의 팀원이 있는 조직에도 적용했다. 매년 두 번씩 유기적으로 연결된 래셔널 제품군을 출시했다. 그 후 래셔널 사는 IBM에 합병됐고 이제는 RUP란 이름으로 IBM의 래셔널 소프트웨어 부서가 판매하고 있으며, 현재 수백, 수천 명의 개발자가 이를 사용하고 있다.

소프트웨어 방법론 경력 3단계: 본격적인 애자일, 랠리 사

래셔널을 떠나서 독립 컨설턴트로서 소프트웨어 각 개발 단계에 대해 조언을 하게 됐다. 사업 전략에 대해 지도를 하고, 몇몇 새로운 벤처 업체에는 소프트웨어 개발방법론을 가르쳤다. 이때 XP나 스크럼 같은 좀더 혁신적이고 가벼운 방법을 적용해 볼 수 있었고 소규모 팀들이 이 방법론을 통해 제품의 생산성과 질을 어떻게 향상시키는지를 두 눈으로 직접 확인할 수 있었다.

얼마 지나지 않아 나는 애자일의 매력에 푹 빠져서 이제는 애자일 방법론을 알지 못하는 팀이나 사업가와 함께 일을 하기 싫을 지경에 이르렀다. 그렇지 않으면 사업에 대한 위험이 너무 컸기 때문이다. 하지만 동시에 애자일 방법론에 대한 한계가 보이기 시작했다. 팀이나 애플리케이션의 규모가 점점 더 커질수록 코드를 만드는 능력은 감소했고, 요구사항을 좀더 명확하게 정의할 필요가 있었으며, 폭주하는 설계방식에 뭔가 변화를 줘야 할 필요성을 느꼈다. 이때를 즈음해 랠리(Rally) 소프트웨어 사에서 소프트웨어 개발방법론자로서 컨설팅을 시작했고, 분산 애자일 기반 솔루션 개발에 많은 조언을 했다. 랠리 사에서는 라이언 마틴즈(Ryan Martens), 켄 슈와버(Ken Schwaber), 짐 하이스미스(Jim Highsmith), 마이크 콘(Mike Cohn), 톰과 메리 포펜딕 부부(Tom and Mary Poppendieck), 제프 서덜랜드(Jeff Sutherland) 같은 애자일 전문가들과 함께 일하면서 많은 영향을 받았다.

엔터프라이즈급 프로젝트에서의 애자일 경험

앞에서 언급한 다양한 직무 경력을 통해, 개인적으로는 많은 기업으로부터 엔터프라이즈급 프로젝트에 애자일 방법론을 도입할 수 있게 해달라는 협조 요청을 받았다. 약간 두려움이 앞서긴 했지만, 몇 년간 각 지역에 산재한 수백 명의 개발자가 대규모 애플리케이션을 개발하는 BMC 소프트웨어에 애자일의 핵심 원리와 내 업무 경험을 적용하는 데 성공했다.

애자일 방법론을 가르치는 동안 기업에 큰 가치를 부여하는 베스트 프랙티스들을 발견할 수 있었다. 하지만 이런 베스트 프랙티스들을 대규모 팀에 적용하는 건 그리 수월한 일이 아니었다. 그래서 엔터프라이즈 조직에 맞는 애자일 방법론을 좀더 연구해 보기로 했다. 하지만 엔터프라이즈급 회사에 맞는 애자일 방법론을 다룬 책들은 찾아보기가 어려웠고 결국 책을 한 권 집필하기로 했다. 이 책을 읽고 배운 내용을 조직에 맞게 적용하고 더 좋은 품질과 생산성을 얻게 되기를 희망한다. 세상에 많은 소프트웨어가 있지만 산업과 경제를 도약시킬 만한 소프트웨어 방법론을 찾기란 쉽지가 않다.


[ 저자 소개 ]

딘 레핑웰
유명한 소프트웨어 개발방법론자이자 저자이며, 소프트웨어팀이 목적을 성취하는 데 도움을 주는 컨설턴트로 일하고 있다. 리퀴짓(Requisite) 사의 창립자이고 리퀴짓프로(RequisitePro)를 만들었으며, 래셔널(Rational) 사의 부회장직을 지내면서 RUP의 상용화를 이끌었다. 최근 5년간 독립적으로 활동하는 한편, 랠리 사에 소속된 컨설턴트이자 방법론자로 일하며 자신의 경험을 바탕으로 다국적 기업으로서 전 세계에 분산되어 있는 대규모 조직에 애자일 방법론을 적용하는 데 힘썼다. 이 책은 저자의 다양한 경험에서 우러나온 이야기를 담았다. 레핑웰은 『Managing Software Requirements, Second Edition: A Use Case Approach』(Addison-Wesley, 2003)의 저자이기도 하다.


[ 옮긴이의 말 ]

이 책을 읽는 독자라면 이제 애자일이란 용어가 아주 낯설게 느껴지지는 않을 것이다. 서점에 나가도 애자일을 다룬 서적이 이미 많이 나와 있으니 말이다. 내가 처음 애자일이란 용어를 접한 것은 5년 전쯤 익스트림 프로그래밍(XP, Extreme Programming)에 대한 교육을 받을 때였다. 교육을 신청한 이유도 단순히 제목이 참 흥미로웠기 때문이었다. 당시만 해도 ‘애자일=XP’라는 아주 단순한 생각을 하고 있었으며, 처음 ‘애자일’ 이란 용어를 접했을 때에도 매우 낯설어 사전에서 ‘기민한, 민첩한’이란 뜻을 찾아냈지만 정확히 무슨 의미를 뜻하는지 그 느낌이 쉽게 다가오지 않았다.

그 뒤 회사에서 SE 업무를 시작하게 됐고 애자일 방법론의 여러 가지 활동들을 접하게 되면서 몇 가지 베스트 프랙티스들은 지금 하는 현업에 직접 적용해 볼 수도 있겠다는 아이디어가 떠올랐다. 점점 더 애자일 방법론에 대해 알아갈수록 이 방법론은 많은 개발 경험이 있고, 프로세스가 어느 정도 내재화되어 있는 팀에서 충분히 적용 가능하다는 생각이 들었다. 하지만 현실적으로 개발자들에게 가장 매력적으로 다가가는 애자일 방법론의 장점은 개발 도중에 끊임없이 만들어내야 하는, 그리고 도대체 왜 필요한지 동감할 수 없는 ‘문서’가 없다는 점일 것이다. 그래서 ‘애자일 개발 = 애드혹 개발’이라는 오해를 받기도 한다. 이 책 첫머리에 나오는 이야기지만 ‘애자일은 소규모 프로젝트에만 효과가 있다’라는 통념 때문에 애자일 방법론에 대해 약간은 부정적인 시각을 갖고 있었다.

하지만 이 책의 번역 의뢰를 받았을 때 선뜻하겠다고 나선 이유는, 책 제목에서도 알 수 있듯이 애자일 방법론을 엔터프라이즈급 회사에 적용해본다는 새로운 시각, 그리고 애자일 방법론에 대한 기본 이론을 먼저 설명한 후 이를 점차 확장시켜 가면서 고려해야 할 여러 사항을 저자의 경험을 토대로 다양한 사례를 들어가며 상세히 설명하고 있기 때문이었다. 번역을 진행하면서 애자일 방법론에 대해 좀더 체계적으로 알 수 있었고, 현업 적용에 대한 아이디어를 많이 떠올릴 수 있게 됐다.

매번 만족하지는 못하지만, 항상 번역을 하면서 고민하게 되는 것은 어떻게 하면 저자가 말하고자 하는 바를 왜곡 없이 100% 독자들에게 전달할 수 있을까였다. 그래서 가능한 용어는 이미 출간된 여러 책을 참조해 독자들이 무리 없이 읽을 수 있게 하고 전체적으로 저자의 의도를 최대한 살리도록 노력했다.

수많은 애자일 방법론에 대한 책이 출간됐지만, 엔터프라이즈급 대규모 프로젝트에 확장 적용하는 애자일 기법과 사례를 충실히 그리고 생생하게 익힐 수 있는 이 책이 애자일 방법론 확장에 좀더 기여할 수 있게 되길 바란다.


[ 옮긴이 소개 ]

제갈호준
아이오와 주립대 컴퓨터 사이언스 박사과정에 재학 중이다. 삼성전자 가전연구소 S/W Lab에서 임베디드 시스템 소프트웨어 개발을 했으며, 벤처기업에서 애플리케이션 개발을 하고 삼성 멤버십에서 활동한 경험도 있다.

이주형
현재 카이스트 소프트웨어 대학원 과정에 있으며, 삼성전자 가전사업부 SE 파트에서 선임연구원으로 재직 중이다. 주요 관심분야는 소프트웨어 테스팅, 요구공학이다.

김택구
서강대 컴퓨터학과 졸업 후 3년간 LG전자 MC 사업본부에서 소프트웨어 엔지니어로 근무했으며, 지금은 ICU-CMU의 MSE(Master of Software Engineering) 과정에 재학 중이다. 관심분야는 소프트웨어 아키텍처와 소프트웨어 프로세스다.

목차

• 1부 소프트웨어 애자일 방법론 ● 35
  
• 01장 애자일 방법론 소개 ● 39
  • 소프트웨어 경쟁에서 앞서 나아가기 ● 39
    • 소프트웨어 개발방법론 발전 ● 40
  • 애자일 방법론으로 들어가기 ● 40
  • 엔터프라이즈급 애자일 ● 41
  • 애자일 방법론을 바라보는 시선 ● 43
    • 애자일 선언문 ● 43
  • 애자일 도입 경향 ● 46
  • 비즈니스에서 애자일 소프트웨어의 장점 ● 46
    • 생산성 향상 ● 47
    • 품질 향상 ● 48
    • 팀의 사기와 업무 만족도 향상 ● 48
    • 제품 출시 앞당기기 ● 48
  • 익스트림 프로그래밍, 스크럼, RUP ● 49
    • 익스트림 프로그래밍 ● 49
    • 스크럼 ● 50
    • RUP ● 51
  • 정리 ● 52
    
• 02장 폭포수 모델이 적합하지 않은 이유 ● 53
  • 폭포수 모델의 문제점 ● 55
  • 폭포수 모델에 기반한 가정 ● 56
    • 가정1: 요구사항을 잘 이해하고, 제대로 정의하려면 시간을 투자해야만 한다 ● 57
    • 가정2: 변경사항은 많지 않을 것이고 수용 가능할 것이다 ● 58
    • 가정3: 시스템 통합은 순조로울 것이다 ● 59
    • 가정4: 일정에 맞게 완료할 수 있다 ● 59
    • 결론 ● 63
  • 애자일 방법론을 통한 제대로 된 작업의 시작 ● 64
    
• 03장 XP의 핵심 요소 ● 67
  • XP란? ● 67
  • XP의 논쟁거리 ● 68
  • XP의 무엇이 그토록 익스트림한 요소일까? ● 69
  • XP의 기본 원리 ● 70
  • XP의 가치와 원칙, 활동 ● 72
    • XP의 5가지 핵심 가치 ● 72
    • 기본 원리 ● 73
    • XP의 12가지 주요 활동 ● 74
    • 짝 프로그래밍에 대한 메모 ● 78
  • XP 프로세스 모델 ● 79
  • 방법론의 적용성 ● 80
  • 더 읽을거리 ● 81
    
• 04장 스크럼의 핵심 요소 ● 83
  • 스크럼의 정의 ● 83
  • 스크럼에서의 역할 ● 84
  • 스크럼의 철학적 뿌리 ● 85
  • 스크럼의 가치와 원리, 활동 ● 86
  • 스크럼의 핵심 활동 ● 87
  • 스크럼의 기본 원리: 경험적 프로세스 제어 ● 88
  • 스크럼의 프로세스 모델 ● 90
  • 스크럼과 조직의 변화 ● 92
  • 스크럼 방법론의 응용 ● 92
  • 더 읽을거리 ● 93
    
• 05장 RUP의 핵심 요소 ● 95
  • RUP란? ● 95
  • RUP의 주요 특성 ● 96
  • RUP의 뿌리 ● 97
    • RUP의 원리와 실제 ● 98
    • 반복: RUP의 기본 개념 ● 100
    • 아키텍처 기반과 유스케이스 중심 ● 101
    • RUP의 프로세스 모델 ● 102
    • 시간 축 ● 102
    • 분야 축 ● 103
    • RUP 반복의 종류 ● 104
  • 애자일 RUP 변형판 ● 106
    • 오픈 유니파이드 프로세스(OpenUP) ● 106
    • 애자일 유니파이드 프로세스 ● 107
  • 방법론의 적용성 ● 107
  • 더 읽을거리 ● 108
    
• 06장 린 소프트웨어, DSDM, FDD ● 109
  • 린 소프트웨어 개발 ● 109
    • 린 소프트웨어 개발의 더 읽을거리 ● 111
  • 동적 시스템 개발방법론 ● 112
    • 배경 ● 113
    • 기본 원리 ● 113
    • DSDM의 핵심 활동 ● 115
    • DSDM 상세 정보 ● 117
  • 기능 주도 개발 ● 117
    • FDD의 베스트 프랙티스 ● 118
      
• 07장 애자일의 핵심 요소 ● 123
  • 애자일로 무엇을 바꾸려고 하는가? ● 123
    • 성공의 새로운 척도 ● 124
    • 관리 문화의 차이 ● 125
    • 요구사항, 아키텍처, 설계에 대한 접근법의 차이 ● 126
    • 수정된 코드와 구현 활동 ● 126
    • 테스트와 품질보증 활동에 대한 변화 ● 127
    • 계획과 스케줄 작성의 새로운 방법 ● 128
    • 가장 큰 변화: 개발 범위 대 일정 - 일정의 승리 ● 129
  • 애자일의 심장: 짧은 타임박스 내에서 동작하는 코드 만들기 ● 130
    • 1. 타임박스 내에서 일하기 ● 131
    • 2. 작은 덩어리로 개발하기 ● 132
  • 정리 ● 134
    
• 08장 애자일 확장에의 도전 ● 135
  • 애자일 방법론이 직면하는 장벽 ● 136
    • 소규모 팀 ● 136
    • 고객의 밀접한 참여 ● 137
    • 한 공간에서 일하기 ● 137
    • 서서히 드러나는 아키텍처 ● 138
    • 요구사항 분석과 문서화된 명세의 부족 ● 138
    • 업무 문화와 물리적 업무 환경 ● 138
  • 엔터프라이즈의 장애물 ● 139
    • 프로세스와 프로젝트 관리 조직 ● 139
    • 형식화된 기존 정책과 절차 ● 140
    • 기업 문화 ● 140
    • 고정된 일정과 고정된 기능의 강요 ● 141
    • 개발팀과 사용자/고객 대변팀과의 마찰 ● 141
    • 제품 라인2이 아닌 분야별로 조직된 구성원 ● 142
    • 여기저기 흩어진 조직 ● 142
  • 정리 ● 143
    
• 2부 애자일을 확장 적용하는 7가지 팀단위 애자일 활동 ● 145
  
• 09장 정의/빌드/테스트 컴포넌트팀 ● 151
  • 정의/빌드/테스트 컴포넌트팀의 의미? ● 152
    • 단순한 스토리의 생명주기 ● 152
  • 기능 사일로의 제거 ● 154
  • 애자일 컴포넌트팀의 역할과 책임 ● 156
  • 자체적으로 조직, 관리되는 정의/빌드/테스트팀 ● 160
    • 적합한 인재를 보유하고 있는 팀(버스) ● 161
    • 관리하지 않고 이끌어가면 되는 팀 ● 162
    • 미션을 이해하고 있는 팀 ● 163
    • 끊임없이 대화하고 협업하는 팀 ● 163
    • 자신의 결과에 책임을 지는 팀 ● 164
  • 지리적으로 떨어진 팀 ● 165
    
• 10장 두 단계 계획과 추적 ● 167
  • 일반화된 애자일 프레임워크 ● 168
    • 반복이란? ● 169
    • 반복의 구조 ● 169
    • 릴리스란? ● 170
    • 릴리스의 해부 ● 171
    • 릴리스 계획하기 ● 171
    • 요구사항을 릴리스에 분배하기 ● 171
    • 전반적인 릴리스 계획 ● 172
  • 정리: 두 단계 계획 ● 172
    
• 11장 반복 숙달하기 ● 175
  • 애자일의 심장, 반복 ● 175
  • 2주? 반복의 표준 주기? ● 175
  • 반복의 계획과 실행 ● 177
  • 반복 작업 계획하기 ● 178
    • 반복 계획 회의 준비 ● 179
    • 참가자 ● 179
    • 반복 계획 회의 ● 180
    • 결과: 반복 계획 ● 181
    • 반복 계획 지침 ● 181
    • 분산된 팀의 반복 계획 ● 182
  • 반복 수행 ● 183
    • 책임 수반 ● 184
    • 개발 ● 184
    • 스토리 출하 ● 185
    • 스토리 완료 선언 ● 185
    • 반복 수용 ● 185
  • 반복의 추적과 조정 ● 186
    • 일일 스탠드업 미팅을 통한 추적 ● 187
    • 일일 스탠드업 미팅 지침 ● 187
    • 반복의 진행 상태 추적 ● 188
    • 번다운 차트로 추적하기 ● 189
  • 반복 리듬 달력 ● 189
    
• 12장 짧고 빈번한 주기의 릴리스 ● 193
  • 짧은 릴리스 주기의 장점 ● 193
  • 릴리스의 정의와 스케줄 ● 195
    • 일정 주도형 릴리스 ● 196
    • 가장 단순한 모델: 고정된 주기의 릴리스 일정 ● 196
    • 기능 셋 추정 ● 198
  • 릴리스 계획 ● 199
    • 참여자 ● 200
    • 준비하기 ● 200
    • 릴리스 계획 프로세스 ● 201
    • 결과: 릴리스 계획 ● 202
    • 릴리스 계획에 대한 추가 지침 ● 203
  • 릴리스 추적 ● 203
    • 릴리스 현황 리뷰 준비 ● 204
    • 릴리스 현황 리뷰 미팅 ● 204
    • 결과물/문서화 ● 205
  • 릴리스 로드맵 ● 205
  • 미리 살펴보는 애자일 확대 적용: 대규모 조직에서의 릴리스 계획과 추적 ● 206
    • 대규모 조직에 적용 가능한 애자일 만들기 ● 206
    • 복수 팀에 대한 릴리스 계획 ● 210
    • 릴리스 추적 ● 211
      
• 13장 동시 테스트 ● 213
  • 애자일 테스트 개요 ● 213
    • 시작부터 테스트 가능한 시스템 만들기 ● 214
  • 애자일 테스트 원칙 ● 214
  • 단위 테스트 ● 216
    • 반복 안에서의 단위 테스트 ● 217
    • 단위 테스트와 테스트 주도 개발 ● 218
  • 인수 테스트 ● 219
    • 자동화된 인수 테스트 예제: FIT 접근 방식 ● 219
  • 컴포넌트 테스트 ● 221
  • 시스템 테스트와 성능 테스트 ● 222
  • 정리: 애자일 테스트 전략에 대한 요약 ● 223
    • 반복과 릴리스 테스트 패턴 ● 223
      
• 14장 지속적인 통합 ● 227
  • 지속적인 통합이란? ● 227
    • 불연속적 통합: 마이크로코즘에서의 문제점 ● 228
  • 지속적인 통합 ● 229
  • 지속적인 통합으로 향하는 3단계 ● 230
    • 소스코드 통합 ● 231
    • 자동화된 빌드 관리 ● 232
    • 자동화된 빌드 검증 테스트 ● 233
  • 지속적인 통합의 성공이란? ● 235
    
• 15장 정기적인 반성과 적응 ● 237
  • 반복 회고 ● 238
    • 반복 회고의 형식 ● 238
    • 정량적 분석 ● 238
    • 정성적 분석 ● 241
    • 해야 할 일 ● 241
  • 릴리스 회고 ● 242
    • 정량적 분석 ● 242
    • 정성적 분석 ● 244
    • 릴리스 회고를 통해 조직 장애물 드러내기 ● 244
      
• 3부 엔터프라이즈 환경에 맞는 애자일 방법론 ● 247
  
• 16장 계획된 아키텍처 ● 253
  • 소프트웨어 아키텍처란? ● 254
  • 애자일과 아키텍처 ● 256
    • 익스트림 프로그래밍: 아키텍처는 서서히 드러난다 ● 256
    • 스크럼 ● 257
    • 기능 주도 개발방법론 ● 258
    • RUP: 아키텍처 중심 ● 259
  • 리팩토링과 시스템 규모 ● 261
  • 무엇을 만드는가? ● 261
  • 엔터프라이즈급 시스템에 대한 애자일 아키텍처 접근 ● 262
    • 컴포넌트 기반 시스템: 아키텍처를 따르는 조직 ● 263
  • 아키텍처 런웨이 만들기 ● 264
    • 변경되기 쉽고 임시적인 아키텍처의 특성 ● 267
    • 아키텍처 런웨이 확장 ● 268
    • 제품 백로그를 활용한 리팩토링 ● 269
    • 아키텍처 런웨이의 확장: 반복과의 동기화 ● 269
    • 아키텍처 런웨이 확장: 린, 풀 기반 접근 방식 ● 271
      
• 17장 린 요구공학: 비전, 로드맵, 적시 정교화 ● 273
  • 개요: 요구사항 피라미드 ● 274
    • 이해관계자의 요구 ● 275
    • 솔루션 기능 ● 275
    • 소프트웨어 요구사항 ● 275
    • 기존 요구사항 접근법 ● 276
  • 애자일의 요구사항은 어떤 점이 다른가? ● 278
    • XP에서의 요구사항 ● 278
    • 스크럼, 제품 책임자, 제품 백로그 ● 280
    • RUP에서의 요구사항 ● 282
  • 대규모 시스템에 대한 애자일 요구사항 접근법: 비전, 로드맵, 적시 정교화 ● 283
    • 1. 비전 ● 284
    • 2. 로드맵 ● 287
    • 3. 적시 정교화 ● 289
    • 사용자 스토리로 정교화 ● 291
    • 유스케이스로 정교화 ● 294
    • 인수 테스트 케이스로 정교화 ● 296
  • 정리 ● 296
    
• 18장 대규모 시스템과 애자일 릴리스 기차 ● 297
  • 애자일 컴포넌트 릴리스 일정 ● 298
    • 애자일 기차에서 얻을 수 있는 교훈 ● 301
    • 애자일 릴리스 기차의 원칙 ● 302
  • 애자일 릴리스 기차 ● 303
    • 기차는 동기화돼야 한다 ● 303
    • 비전, 주제, 유스케이스에 의해 동작하는 기차 ● 304
    • 기차가 궤도를 이탈하지 않고 일정을 준수하도록 유지하기 ● 305
    • 진행 측정과 속도 ● 305
    • 시스템 수준 패턴 관찰하기 ● 306
    • 상호 의존성 관리하기 ● 307
  • 릴리스 기차 회고 ● 308
    
• 19장 분산 개발의 관리 ● 309
  • 애자일 확장 시 모든 개발은 분산 개발이다 ● 309
  • [사례 연구 1] 핑 아이덴티티 사: 흩어져 있는 정의/빌드/테스트 컴포넌트팀 ● 311
    • 핑 아이덴티티 사의 배경 ● 311
    • 교훈 ● 314
  • [사례 연구 2] BMC 소프트웨어 : 분산도가 높은 대규모 엔터프라이즈에서의 애자일 ● 315
    • 배경 지식 ● 315
    • IMD에서의 애자일 전환 ● 316
    • 결과 ● 316
    • 파일럿에서 프로그램으로: 엔터프라이즈급 애자일 도입 ● 317
    • 교훈: 큰 조직 간에 걸친 애자일 활동 확장 ● 319
    • 다음 단계: 애자일 성공 첫해, 그 후 ● 321
  • 의사소통의 강화 ● 323
    • 직접 교류 지원 ● 323
    • 의사소통 도구 ● 324
  • 엔터프라이즈 애자일을 위한 도구 ● 326
    • 소스코드 관리 ● 329
    • 네트워크 인프라 ● 329
    • 초기 반복에서 인프라의 구현 ● 330
  • 정리 ● 331
    
• 20장 고객과 조직에 미치는 영향 ● 333
  • 애자일 도입을 통해 영업과 마케팅에 돌아가는 이익 ● 334
  • 제품 마케팅/제품 관리에 대한 효과 ● 336
  • 짧고 빈번한 주기의 릴리스 ● 337
    • 짧고 빈번한 주기의 릴리스에 대한 도전 ● 338
  • 애자일 릴리스 프로세스 최적화하기 ● 339
    • 릴리스 선택사항 1: 애자일 무시하기 ● 340
    • 릴리스 선택사항 2: 애자일 따라가기 ● 341
    • 릴리스 선택사항 3: 외부 릴리스로부터 개발 릴리스를 분리해 최적화하기 ● 342
  • 영업과 마케팅 관리자가 제기하는 애자일에 관한 오해 ● 347
    
• 21장 조직 변화 ● 351
  • 개요 ● 351
  • 왜 애자일은 조직적인 변화가 있어야 하는가? ● 352
    • 1. 경험적 프로세스 채택과 계획 기반 프로세스 채택 비교 ● 353
    • 2. 스크럼 정신: 장애물을 제거하고, 팀은 맡은 바 임무를 다할 것이다 ● 354
    • ba: 스크럼의 핵심 ● 355
    • 3. 방임: 덜 예측 가능하지만 더 좋은 결과물 ● 356
  • 스크럼과 애자일 준비하기 ● 358
    • 소프트웨어 프로세스와 조직 모두 ‘스크럼 짜기’ ● 359
    • 경영진은 조직 변화를 위한 스크럼 마스터 ● 359
    • 주의사항: 변화는 많은 노력을 필요로 한다 ● 360
  • 소프트웨어 생산성에 대한 장애 요소 제거하기 ● 361
  • 경영진을 위한 애자일 모델 ● 363
    • 애자일 적용의 지원 ● 365
    • 어떤 것을 권고할지 연습하기: 경영진 활동으로서의 애자일 ● 366
  • 대규모 조직에서 스크럼/애자일 수행 ● 368
    • 개괄, 평가, 파일럿 준비 ● 369
    • 파일럿 프로젝트 ● 371
    • 조직 내 확장 ● 372
    • 효과 달성 ● 373
    • 측정, 평가, 조정 ● 374
    • 확장, 성공 ● 375
  • 정리 ● 375
    
• 22장 비즈니스 성과 측정 ● 377
  • 애자일 평가: 주요 차이점 ● 378
  • 팀 성과 측정 ● 378
    • 애자일 프로젝트 측정 지표 ● 379
    • 애자일 프로세스 측정 지표 ● 379
    • 결과 분석 ● 383
  • ‘프로세스 정책’ 측정 지표와 팀 자체 평가 ● 384
  • 조직 생산성 확대: 균형성과기록표 접근 방법 ● 385
    • 효율성 ● 386
    • 품질 ● 387
    • 가치 조달 ● 388
    • 애질리티 ● 388
  • 확장 단계에서의 애자일 측정 지표 ● 389
    • 1단계: BSC 항목 수치화 ● 389
    • 2단계: 알파벳 점수로 변환 ● 390
    • 3단계: 제품 라인, 비즈니스 부서, 대기업에 대한 결산 ● 391
      
• 결론: 애자일 확대 적용 ● 393
• 참고문헌 ● 397

[ p163 저자주 4 마지막 행]
나느 → 나는