책/AgileSoftwareDevelopmentTheCooperativeGame

AlistairCockburn이 지은 책.

0장. Unknowable and Incommunicable

여기에서는 두 가지 질문을 던지고 있다. "지금 무엇을 경험하고 있는지 알 수 있는가?"와 "그것과 관련해서 커뮤니케이션할 수 있는가?"이다. "아니, 그럴 수 없다."라는 간단한 대답이 바로 이 책에서 시사하고자 하는 근본적이 딜레마이다.

무엇을 경험하고 있는지를 알 수 없다면 어떻게 프로젝트에 반영할 것이며, 좀더 효율적으로 일할 수 있는 권고 사항은 어떻게 작성할 것인가? 관련이 없는 요소에 시간을 투자하고, 대신 중요한 요소를 간과해 버리는 것은 바람직하지 않은 일이다. 이것이 바로 방법론자, 연구원 및 실무자 등 좀 더 효율적으로 작업하고자 하는 사람들이 직면한 극복하기 어려운 문제이다.

완벽한 커뮤니케이션이 불가능하다는 사실을 인정하면 적어도 완벽에 도달하려는 수고는 덜 수 있을 것이고, 대신 커뮤니케이션의 불완전성을 극복하는 방법을 배우게 될 것이다. 모든 사람이 이해할 수 있는 요구 사항 문서나 설계 모델을 만들려고 애쓰기보다는 독자가 의도한 바에 합당한 문서가 되면 거기서 만족해야 한다.

이 장에서는 2가지 질문을 던진 다음, 각기 다른 기술 수준을 운용하는 방법을 소개할 것이다. 초보자는 전문가와는 다르게 이를 받아들일 것이고 부연 설명을 바랄 수도 있을 것이다. 세 번째 절에서도 한 프로젝트에 참여하는 사람들의 이해 수준을 파악하는 것의 중요성에 대해 논의하고 있다.

마지막 절에서는 일상 생활과 관련된 추상적인 개념을 설명하고 있다. 아마 이 부분이 이 책에서 가장 추상적인 내용이 되리라고 본다. 추상적인 주제가 조금 어렵다고 생각되면 일단 넘어가고 다른 구체적인 장을 먼저 이해한 다음 나중에 다시 읽어봐도 좋다.

The Problem with Parsing Experience

소프트웨어 개발 프로젝트에 관여하는 사람들은 관찰하는데 실수를 하곤 한다.

우리가 경험에 기반해 생활하면서, 우리는 그것을 해석(parse) 한다. 경험을 분리된, 의미있는 청크로 쪼갠다. 그래서 나중에 다시 꺼내쓸 수 있도록. 인간의 두뇌(mind)는 우리가 원하든 아니든 그렇게 동작한다.

이렇게 경험을 조각으로 나누는 방법(패턴)은 매우 많다.

소프트웨어 개발에서도, 각 사람들은 프로젝트에 대한 자신만의 경험이 있고, 그 경험을 각자의 패턴을 사용해 해석한다. 그 사람이 소프트웨어 성공의 요인이 무엇이라고 믿는지에 따라 그 사람의 행동은 굉장히 달라지게 된다.

어떤 사람은 규정된 절차(defined process)를 잘 따르는 것이 프로젝트 성공에 중대하다고 생각할 수 있다. 이 사람은 그렇기 때문에 프로세스를 지키도록 측정하고 통제하는데 굉장한 노력을 기울일 것이다. 프로세스가 요인이라고 정말로 믿는 사람은, 프로세스를 따르는 것과 프로젝트 결과 사이에는 상관성이 없다는 것을 오랜 시간동안 알아채지 못할 것이다.

무언가 상관이 없는 것에 초점을 맞추는 것만큼 나쁜 것은, 패턴을 해석하는데 중요한 무언가를 빼먹는 것이다. 이를테면, 지자기장 실험을 하는 과학자인데, 빌딩의 벽 속에 철근이 있다는걸 모른다고 생각해보자. 이상한 값을 얻을 뿐만 아니라, 그 이상이 왜 발생했는지, 어떻게 고쳐야 할지 모를 것이다.

프로젝트에서 사람의 존재가 그러한, 중요한, 그러나 잊혀진 요소다.

사람 요소를 패턴 해석에서 고려하지 않는 사람들은, 프로젝트에서 사람들이 어떤 효과를 일으키는지 알지 못할 것이다.

현장 방법론자(field methologist)로서, 나는 사람들에게 프로젝트에서 일어났던 일을 물어본다. 그리고 그것을 재구성하여 무슨 일이 일어났던 것인지 파악한다.

우리는 아직도 소프트웨어 개발 프로젝트에서 진짜로 무슨 일이 일어나는지 이름붙이는데 미숙하다. 그 결과는 프로세스나 모델링, 수학이 아니었다. 물론 그것들이 일부의 역할을 하긴 한다. 하지만 훨씬 더 많은 결과는 기술(craft), 공동체(community), 자부심(pride), 학습(learning)에 대한 것이었다.

The Impossibility of Communication

커뮤니케이션은 불완전하다. 커뮤니케이션은 무엇이 전송되었는지가 아니라, 받아들이는 사람이 어떻게 해석했는지가 관건이다. 또한 그 정보는 수신자의 내면에서 재구성된다.

몇년간 같이 일한 프로그래머들은 공동 경험으로 겹치는 부분들이 많이 있다. 그래서 그들의 의사소통은 간결할 수 있다. 이전의 프로젝트 경험들을 공유하고 있기 때문에.

커뮤니케이션은 결코 완벽하거나 완전해질 수 없다. 가능하지도 않다. 프로젝트에서 해야할 것은 완벽한 커뮤니케이션을 하려 하는게 아니라, 우리의 커뮤니케이션의 불완전함을 관리하는 것이다.

Three Level of Listening

경청의 3단계. (following, detaching, fluent)

So, What Do I Do Tomorrow?

0.1장. Unknowable and Incommunicable: Evolution

Communication and Shared Experience

Shu-Ha-Ri

1장. A Cooperative Game of Invention and Communication

소프트웨어 개발을 설명하는 가장 효과적인 방법은 이를 창조와 커뮤니케이션의 상호 협력적인 게임으로 간주하는 것이다.

이 장 첫 번째 절에서는 "우리가 개발하고 있는 것이 소프트웨어가 아니라면, 소프트웨어를 개발한다는 것은 어떤 경험일까?"라는 질문을 던진다. 소프트웨어 개발을 조금 다른 시각에서 살펴보고자 하는 것이 이 질문의 목적이다.

두 번째 절에서는 게임이라고 하는 활동을 큰 유형별로 살펴보고 그 범위 내에서 소프트웨어 개발은 어디에 속하는가를 알아본다. 제로섬, 포지셔널, 협력적, 한정 및 무한과 같은 용어에 익숙하다면 이 장의 앞부분은 쉽게 읽고 넘어갈 수 있을 것이다. 그리고 소프트웨어 개발을 협력적 게임의 하나로 볼 수 있는 암벽 등반, 공학 및 모델 설립 등과도 비교해 본다.

세 번째 절에서는 소프트웨어 개발이 창조와 커뮤니케이션의 협력적 게임이라는 전제를 보다 자세히 살펴보기로 한다. 게임의 1차 목표, 즉 제대로 돌아가는 소프트웨어의 산출과 다음 게임의 나머지를 준비하는 2차 목표를 고찰할 것이다. 다음 게임은 시스템을 수정, 대체 또는 연결된 시스템을 생성하는 것이다.

마지막 절에서는 이러한 아이디어들을 일상 생활과 관련해 살펴보기로 한다.

Software and Poetry

Software and Games

A Second Look at the Cooperative Game

What Should This Mean to Me?

1.1장. A Cooperative Game of Invention and Communication: Evolution

The Swamp Game

Competition Within Cooperation

Other Fields as Cooperative Games

Software Engineering Reconstructed

2장. Individuals

"사람"이 소프트웨어를 개발한다는 사실이 너무나도 명백함에도 불구하고, 그 사실은 무시되어 왔다. 1969년에 작성한 Weinberg의 사람에 관한 글 이후 15년간 아무도 별다른 의견을 제시하지 않았다. DeMarco와 Lister가 Peopleware라는 책을 통해 Weinber의 글에 관한 의견을 제기하였는데, 역시 별다른 이견을 제시하는 사람이 없었다. 하지만 사람들의 특성이 소프트웨어 개발에 어떠한 영향을 미치는가를 배우기 위해 또다시 15년을 기다릴 필요는 없다.

이 장에서는 사람들의 일반적인 두려움, 실패 방식, 성공 방식 그리고 일반적인 작업 방식을 다음 주제에 따라 학습하게 된다.

"기상천외한 사람들"에서는 사람들이 얼마나 제각각이고 예측 불허인지를 살펴본다. 이러한 사람들에게 작업의 일반적인 규칙을 적용하는 것이 가능하긴 하지만 아무리 좋은 규칙이라 해도 인간 개성의 한계를 극복할 수 없다는 것이 이 절의 핵심 내용이다.

"실패 방식 극복하기"에서는 인간의 약점에 대해 논의한다. 사람들이 함께 작업하여 시스템을 만들어 내고자 할 때 대부분의 사람들이 실패로 여기는 태도에 의존해서는 안된다.

"다른 사람보다 효과적으로 일하는 방법"에서는 "인간의 기본 작업 방식은 무엇인가"라는 질문을 던진다. 아이디어를 적용할 때 우리는 사람들이 각각 서로 다르다는 사실을 늘 염두에 두어야 한다.

"성공 방식 만들기"에서는 실패한 모든 방식에 대해 제시한 후, 성공하기 위해 우리에게 주어진 것이 무엇인지를 질문한다. 이것이 처음에는 얼마나 모호하게 들리고, 또 나중에는 얼마나 많은 효과를 가져오는가에 대해 독자들은 사뭇 놀랄 것이다. 마지막으로 성공 방식과 더 나은 효과를 결합하는 방법을 소개하고 있다.

마지막 절에서는 이런 아이디어를 일상 생활에 접목하는 내용을 다룬다.

Them's Funky People

Overcoming Failure Modes

Working Better in Some Ways Than Others

Drawing on Success Modes

What Should I Do Tomorrow?

2.1장. Individuals: Evolution

Strategy Balancing

3장. Communicating, Copperating Teams

이 장에서는 물리적 환경의 효과, 불가피한 커뮤니케이션의 차이를 극복하기 위한 커뮤니케이션의 방식, 우호 및 갈등의 역할, 팀의 하위 문화 등을 살펴보기로 한다. 이러한 주제들을 통해, 프로젝트에서는 중요한 사안을 인지하고, 인지한 것에 대해 다른 사람들과 커뮤니케이션할 수 있고 또한 커뮤니케이션하고자 하는 사람들을 필요로 한다는 사실을 알 수 있을 것이다.

"정보 전달 흐름"에서는 정보의 움직임을 열과 기체의 분산과 비교해 본다. 이러한 비교를 통해 정보 전달의 에너지 비용, 삼투적 커뮤니케이션, 정보를 발산하는 주체, 정보 전달 도구 등 여러 가지 유용한 사실을 알아낼 수 있을 것이다.

"커뮤니케이션의 차이 극복하기"에서는 긍정적 또는 부정적인 커뮤니케이션 채널을 통한 아이디어 전달 시의 효율성을 검토해 보기로 한다. 정보에 "고정성(stickness)"을 더하는 아이디어에 대해 살펴보고 시간을 초월한 정보 전달과의 연관성을 살펴보기로 한다.

"공동체로서의 팀"에서는 우호 및 갈등, 팀 구축에서의 작은 팀 승리의 역할, 프로젝트에 관련된 하위 문화의 역할 등을 살펴본다. 이러한 것들로부터 다양한 문화 가치가 조직에 유용함과 동시에, 팀이 이것을 다루기 어렵다는 사실을 알게 될 것이다.

"생태 시스템으로서의 팀"에서는 소프트웨어 개발 팀을 물리적 구조, 역할, 타인에게 영향을 미치는 독특한 개성을 지닌 개개인으로 구성된 생태 시스템으로 설명한다. 모든 프로젝트는 독특한 생태 시스템을 생성하기 때문에 방법론 설계 활동이 더욱 어렵게 된다.

Convection Currents of Information

Jumping Communication Gaps

Teams as Communities

Teams as Ecosystems

What Should I Do Tomorrow?

3.1장. Teams: Evolution

A Sample Office Layout Revisited

4장. Methodologies

이 장에서는 방법론 설계 게임의 규칙과 게임 방법을 명백히 알 수 있도록 방법론에 관한 주제를 토론하고 요약하기로 한다.

"방법론 개념"에서는 방법론을 설계하고 비교하는 데 필요한 기본적인 단어와 개념을 설명한다. 여기에는 역할, 기법, 기준과 같은 당연한 용어들은 물론 무게, 형식, 명확성, 안정성, 관용과 같은 다소 생소한 용어도 포함되어 있다. 17페이지의 "듣기의 3단계"에서 설명한 청중 수준은 대부분 1단계 독자들을 대상으로 한다. 나중에 소개하는 더 발전된 개념을 이해하는 데 필요한 부분이다.

"방법론 설계 원칙"에서는 방법론을 설계하는데 필요한 7가지 원칙에 대해서 설명한다. 더 무거운 방법론을 사용하는데 드는 비용은 물론, 이러한 비용을 감당할 시점에 초점을 맞출 것이다. 또한 작업 산출물 안정성을 사용하여 얼마나 많은 동시 개발을 사용할 것인가를 결정하는 방법을 알려줄 것이다.

"XP under Glass"에서는 이러한 원칙을 적용하여 기존의 Agile 방법론을 분석한다. 또한 다소 다른 상황에 따라 XP를 수정하는데 이러한 원칙을 어떻게 사용할 것인가에 대해서도 이야기하고 있다.

"도대체 왜 방법론인가?"에서는 선행한 토론의 관점에서 주요 질문을 다시 고찰하고 방법론에 대한 각기 다른 활용을 설명하기로 한다.

An Ecosystem That Ships Software

Methodology Concepts

Methodology Design Principles

XP under Glass

Why Methodology at All?

What Should I Do Tomorrow?

4.1장. Methodologies: Evolution

Methodologies versus Strategies

Methodologies across the Organization

Process as Cycles

Describing Methodologies More Simply

5장. Agile and Self-Adapting

우리는 지금까지 다음과 같은 퍼즐 조각을 살펴보았다.

• 창조와 커뮤니케이션의 상호 협력적 게임
• 예측 불가이지만 주변을 둘러보는 것, 스스로 하는 것, 일대일 대면과 같이 비형식적인 커뮤니케이션에는 익숙한 사람들
• 각기 다른 상황에 맞는 다양한 기준을 가진 팀이 채택한 일련의 기준으로서의 방법론
• 신속하게 개발할 수 있지만 팀 규모가 커지면 무거워지는 가벼운 방법론
• 독특한 생태 시스템으로서의 프로젝트와 프로젝트 생태 시스템에 맞는 프로젝트 방법론의 필요성

모든 것이 깔끔하게 잘 들어맞지만 예외가 하나 있다. 어떤 프로젝트에 얼마만큼의 가벼움이 적절하며 현재 우리의 프로젝트에서 이렇게 할 수 있는가가 그것이다.

"가볍지만 충분하"에서는 어느 정도의 가벼움이 적절하며, 특히 "너무 가볍다"는 말이 의미하는 것에 대해서 살펴본다. 여기서는 가벼움과 충분함을 조율하는데 그 목적이 있다.

"Agile"에서는 특정 프로젝트의 sweet spots에 대해 논의한다. 배치, 사용자와 근접함, 숙련된 개발자 등, 프로젝트가 그러한 sweet spots에서 멀어질 때 덜 민첩한 메커니즘이 사용된다. sweet spots에서 특히 멀리 떨어진 가상의 팀에 있어서 민첩한 개발은 더 어렵다.

"스스로 적응하기"는 가볍지만 충분하고 개인 방법론 프로젝트가 빠르게 프로젝트에 유용하도록 전개하는 기술을 설명한다. 일이 잘 이루어졌는지, 무엇을 변경해야 하는지에 대해 몇 주마다 검토해 보아야 한다는 것이 주요 내용이다.

Light But Sufficient

Agile

Becoming Self-Adapting

What Should I Do Tomorrow?

5.1장. Agile and Self-Adapting: Evolution

Misconstructing the Message

Evolution of the Agile Methodologies

New Methodology Topics

Persistent Questions

Agile Outside Software Development

6장. The Crystal Methodologies

이 장에서는 방법론 설계에 관련된 딜레마들을 해결하는 방법에 대해 설명할 것이다. 커뮤니케이션의 어려움, 방법론 내에서 인적 자원이 되는 사람들의 필요성, 다양한 방법론의 필요성 등.

나는 방법론군을 구조화하기로 하고 이들을 조율하는 방법도 같이 만들어 냈다. 이는 독자의 고유 프로젝트에 조립해서 쓸 수 있는 방법론 부분들의 kit가 아니라 상황에 맞게 조정할 수 있는 일련의 샘플이다.

Crystal은 이러한 방법론군의 이름이다. 지질학상의 Crystal처럼, 프로젝트의 규모와 중요성에 따라 색과 굳기는 서로 다르다: Clear, Yellow, Orange, Orange Web, Red, Magenta, Blue 등.

각각은,

• 인간 및 커뮤니케이션 중심이다.
• 특정 설정에 맞게 조정된다.
• 프로젝트 관용 수준 및 병목 작업으로부터 프로젝트 생태 시스템에 맞는 해답을 도출한다.

이 장에서는 Crystal 군 중 실제 사용된 적이 있는 3가지 방법론을 소개한다. CrystalClear, CrystalOrange, CrystalOrangeWeb이 그들이다. 이들에 대해 나는,

• 이런 방법론이 적합한 프로젝트 특성을 설명하였다.
• 방법론 자체를 설명하였다.
• 방법론의 구조를 반영하였다.

이 장을 포함한 이유는 방법론 설계를 둘러싼 문제와 원칙을 제대로 이끌어 나가는 방법을 보여 주고, 독자가 자신의 프로젝트를 시작할 때 응용, 변경하여 사용할 수 있도록 하기 위해서이다.

Shaping the Crystal Family

Crystal Clear

Crystal Orange

Crystal Orange Web

What Should I Do Tomorrow?

6.1장. The Crystal Methodologies: Evolution

The Crystal Genetic Code

Crystal Clear

Stretching Crystal Clear to Yellow

부록A. The Agile Software Development Manifesto

The Agile Alliance

그 모임은 유타주의 Snowbird에서 2001년 2월에 일어났다.

17명의 사람들이 있었고, KentBeck, MikeBeedle, Arie-vanBennekum, AlistairCockburn, WardCunningham, MartinFowler, JamesGrenning, JimHighsmith, AndrewHunt, RonJeffries, JonKern, BrianMarick, RobertMartin, StephenJMellor, KenSchwaber, JeffSutherland, DaveThomas 가 그들이다. (만약 Object Technology International의 DaveThomas도 그 미팅에 참석할 수 있었더라면, 두 명의 DaveThomas가 서명할뻔 했다!)

각 사람들은 자신의 관점으로 그 모임을 바라봤다. 이 부록에 적힌 것은 내 관점이다 (하지만 이 내용을 그들에게 미리 공유했다).

우리가 만난 이유는, 다양한 경량 방법론들 사이에서 공통적으로 일어나고 있는 무언가를 조명하기 위해서였다: AdaptiveSoftwareDevelopment, eXetremeProgramming, SCRUM, Crystal, FeatureDrivenDevelopment, DSDM, 그리고 PragmaticProgramming.

KentBeck, WardCunningham, RonJeffries, JamesGrenning, RobertMartin 은 XP의 관점을 가져왔다. 뿐만 아니라 고려할만한 그들의 다른 경험과 그들 개인의 바람들도 있었다.

MartinFowler는 XP와 일반적인 방법론들에 대한 평가, 이렇게 둘 모두를 가지고 왔다.

JimHighsmith는 AdaptiveSoftwareDevelopment 와 복잡하고 적응적인 시스템 emergent properties에 관한 아이디어를 대표했다.

나는 거기에 프로젝트마다의 방법론(methodology-per-project)과 적시 방법론 구성(just-in-time methodology construction)에 대한 관심을 가지고 갔다.

JeffSutherland, KenSchwaber, MikeBeedle 은 SCRUM을 대표했다.

TogetherSoft 의 JonKern 은 FeatureDrivenDevelopment를 대표했다. Java Modeling in Color with UML에 설명된 방법이다.

Arie-vanBennekum 은 네덜란드에서 왔는데, DSDM을 대표했다.

AndyHunt 와 DaveThomas 는, 실용주의 프로그래머의 저자로서, 어느 한 방법론에 속하지 않은 경험 있는 프로그래머에 대한 관심사를 대표했다.

BrianMarick 은 소프트웨어 테스팅 관점을 대표했다.

StephenMellor 는 model-driven 개발에 대한 그의 관심사를 가져왔다. 아마도 그는 자신이 말하고 서명한 선언문과 원칙들에 대해 스스로 동의할 수 있었다는 사실에 그 자리에서 가장 놀란 사람이었을 것이다.

그 자리에 초대받은 다른 사람들이 있었고, (참석할 수 있었다면?) 아마도 분명히 기여하고 서명했었을 것이다. 하지만 여기 거명된 사람들은 토론(argue)하고, 정교하게 만들고, 선언문에 서명한 사람들이다.

We hoped against hope that we would actually agree on something.

우리 중 아무도 실천법들을 합쳐서 소위 "Unified Light Methodology" (ULM) 라는 것을 만드는 것에는 관심이 없었다. 그 방에서의 개인주의를 보자면, 우리가 뭔가에 동의했다는게 참으로 놀랍다.

우리는 네 가지 사항에 동의했다:

• 우리는 변화에 대해 반응할 필요가 있다는, 첫 번째 수준(level)에 동의했다. 우리는 agile이 우리의 의도를 반영한다는 것에 동의했고, 더 크고 life-critical한 프로젝트를 위한 heavier-agile 방법론에 대한 논의를 하기로 했다.

• 두 번째 수준에 동의했는데, 선언문에 나온 네 가지 핵심 가치에 대해서였다.
• 세 번째 수준에 (간신히) 동의했는데, 이 네 가지 가치들을 구성하는 12개의 더 자세한 문장들에 대한 것이었다.
• 우리가 네 번째 수준에 동의하지 못할 것이 명백했는데, 자세한 프로젝트 전략에 대한 것이었다. 우리는 이것이 산업에 있어 건강한 것이고, 우리는 혁신하고 아이디어의 세계에서 경쟁하는걸 계속해야 하며, 더 큰 애자일 소프트웨어 실천방법들을 발견해야 한다는 것에 동의했다.

이러한 동의와 agile이라는 용어 채택을 바탕으로, 17명의 사람들은 AgileAlliance 를 만들었다.

The Manifesto

see also AgileManifesto

선언문을 좀 더 자세히 살펴보자.

"우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다."

우리 (그 그룹의 사람들)는 소프트웨어 개발 실천가들이다. 단지 다른 사람들을 위해 규칙을 만드는 구경꾼이 아니라. 우리는 실천방법들을 발명하기보다는 '발견했다'라고 느끼고 있었고, 말하는 것 만큼이나 도와줌으로써 이 작업을 계속해나갈 것임을 분명히 하고자 했다.

"이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다..."

그 아이디어들은 진공 상태에서 도착한 것이 아니라, 우리의 직접적인 경험들과 그 경험에 대한 성찰의 결과로 나온 것이었다.

네 가지 선택들을 나열하기 전에, 내용을 건너 뛰어서 마지막 문장을 살펴보자:

"이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다."

우리는 소프트웨어 개발 전체를 무너뜨리려는 것이 아니었다. 우리는 도구, 프로세스, 문서, 계약, 그리고 계획이 가치를 가지고 있다는 것을 인지했다. 우리가 표현하고자 했던 것은, 상황이 나빠질 때는 (종종 그렇게 되지만), 해결책이 필요하다는 것이다. 우리는 오른쪽편 선택을 고집하는 사람들은 그만큼 왼쪽편 선택을 고집하지 않을거라고 느꼈다.

우리는 또한 어떤 사람들은 우리가 선택한 한 가지, 또는 모든 것에 동의하지 않을거라는 것을 알기 원했다. 한 사람은 우리 목록을 보고 말하길: "네개 중 세 개는 동의할 수 있네요"라고 말했다. 우리는 그러한 종류의 비동의가 건설적인 대화를 이끌 수 있다는데 동의했다.

agile methodology의 "반대편"은 없다. 마치 "뱅갈 호랑이"의 반대편이 없는 것처럼 말이다. 그들 자신의 가치 시스템이 있는 애자일의 대안들이 있다: 반복가능한, 근면한, 신중한, 예측가능한, 심지어는 변덕스러운 방법론들.

당연하게도, 이 모든 것을 이해하는 것은 실천방법들의 성공적인 버전을 의미한다(?). 아마도 더 나은 용어는, would-be-agile, would-be-predictable, would-be-repeatable 개발일 것이다.

이런 부분들에 대해 비동의할 여지를 남겨놓는 것은, 개인적으로 내게 중요하다. 우리 산업은 아직도 무엇이 성공적인 소프트웨어 개발에 핵심적인지에 대해 의견 일치를 하지 못했다. The best approach for the time being is simply to say what one stands for. Evidently, this point is important to the other signatories, too.

이러한 것들을 염두에 두고, 네 가지 선택을 살펴보자:

*개인과 상호작용*을, 프로세스와 도구보다.

첫번째 가치는, 팀의 사람들에 주의를 기울인다. 프로세스 차트 안의 역할로 보기보다는. 물론 집단의 사람들이 시작하게 하기 위해서는 프로세스 설명이 필요하지만, 사람들은, 우리가 보아왔듯이, 교체 가능한 존재가 아니다.

두 번째로 조명된 선택은, 개인들간의 상호작용에 주의를 기울이는 것이다. 새로운 솔루션과, 옛날 솔루션의 결함은 사람들간의 논의를 통해 활기를 띈다. 상호작용의 질이 관건이다.

실제로, 향상된 커뮤니티는, 혼란스러운(chaotic) 개발이 그러한 만큼이나 프로세스 중심 개발에 도움이 된다.

이 첫 번째 가치가 표현하는 것은, 우리는 좋은 상호작용을 가진 문서화되지 않은 프로세스를 사용하는 것이, 적대적인 상호작용을 가진 문서화된 프로세스를 사용하는 것보다 낫다는 것이다.

*작동하는 소프트웨어*를, 포괄적인 문서보다.

작동하는 소프트웨어는 팀이 무엇을 만들었는지 당신에게 말해주는 유일한 것이다. 작동하는 코드는 무자비하게 정직하다.

요구사항, 분석, 설계, 화면 흐름, 오브젝트 상호작용 시퀀스 차트 같은 것들은 참고사항이다. 팀원들은 그것들을 자신의 경험을 반영하고 미래가 어떻게 될지 추측하는데 도움이 되는 자료로 사용한다. 문서는 게임에서 마커로 작용한다. 신뢰할 수 없는 미래의 이미지를 구축하는데 사용된다.

반면에, 요구사항 수집, 설계, 코딩, 소프트웨어 디버깅 등의 복합 작업은, 개발팀, 개발 프로세스 및 해결해야 할 문제의 특성에 대한 정보를 드러낸다. 그러한 것들과 동작하는 최종 결과는, 팀의 속도, 그룹의 단점들, 팀이 실제로 구축해야 하는 것을 엿볼 수 있는 유일한 신뢰할 수 있는 척도를 제공한다.

문서는, 우리가 본 것처럼, 매우 유용할 수 있지만, "충분하다" 및 "거의 충분하지 않음"이라는 단어와 함께 사용해야 한다.

*고객과의 협력*을, 계약 협상보다.

세 번째 가치는 소프트웨어가 구축되기를 원하는 사람들과 소프트웨어를 구축하는 사람들 사이의 관계를 설명한다. 그 차이점은, 적절하게 형성된 애자일 개발에서는, "우리"와 "그들"은 없고, 오직 "우리"만 있다는 것이다.

협력은 공동체, 우호, 공동 의사결정, 의사소통의 속도 및 개인 상호작용에 대한 연결에 대한 것이다. 고객 협력에 대한 관심은 전문 분야와 조직 경계를 넘어선 우호적인 관계(3장에서 설명했듯 충돌을 배제하지 않는)를 나타낸다. "우리만 있다"라고 말하는 것은 좋은 소프트웨어를 생산하기 위해서는 둘 모두가 필요하다는 것을 의미한다.

계약이 유용할 때도 있지만, 협업은 계약이 체결된 경우나 아직 계약이 없는 경우 모두에서 개발을 강화한다. 좋은 협력은 위험에 처한 계약 상황을 구할 수 있다. 좋은 협력은 때때로 계약을 불필요하게 만들 수 있다. 어느 쪽이든, 협업이 승리의 요소이다.

*변화에 대응하기*를 계획을 따르기보다.

마지막 가치는, 급격한 프로젝트 변경에 따라 조정하는 것에 대한 것이다.

계획을 세우는 것은 유용하고, 각 애자일 방법론에는 구체적인 계획 활동들이 포함되어 있다. 또한 변화하는 우선순위를 처리하기 위한 메커니즘도 포함되어 있다.

SCRUM, DSDM, AdaptiveSoftwareDevelopment 는 타임 박스된 개발과 각 타임박스 이후(중반이 아니라)의 우선순위 재지정(XP는 타임박스 중반의 우선순위 재지정을 허용한다)을 필요로 한다. 타임 박스 기간은 2~4주 범위이다. 타임박싱은 팀이 동작하는 소프트웨어를 개발할 시간과 마음의 평화를 가질 수 있도록 보장한다. SCRUM은 "스프린트"라고 부르는, 상대적으로 짧은 개발 단계는, 프로젝트 스폰서들이 그들의 필요에 부합하도록 우선순위를 변경할 수 있도록 해준다.

계획을 세우는 것은 유용하다. 계획을 언급하는 것은, 그것이 현재 상황에서 너무 멀어지기 전까지 유용하다. 오래된 계획에 매달리는 것은 유용하지 않다.

선언문에 대한 고찰

다양한 상황에서 다양한 작업 방식에 대한 필요성은 선언문에 나와있지 않지만, JimHighsmith 와 나는 항상 요점을 염두에 두고자 한다.

'애자일함'은 10명 프로젝트와 100명 프로젝트가 다르다. 100명 프로젝트에서의 애자일은 10명 프로젝트 애자일보다 더 무거운 방법론을 사용한다. 이는 4장에 제시된 방법론 설계 원칙과 부합한다.

물론, 방법론 설계 원칙을 가지고, 100명 프로젝트에서 90명을 제외하고, 최고의 10명을 남겨운 채, 같은 시스템을 같은 시간에 민첩한 10명 프로젝트로 가동하는 것도 가능할 것이다.

요점은, 방법론이 한두개가 아니라 수십개이며, 각각은 상황과 프로젝트에 맞게 조정되고, 각각은 애자일하다는 것에 동의한다. 이 생각은 선언문에 표현되어 있지 않다.

회의실에 있던 일부 사람들은 기본적으로는 높은 유동 상황에 애자일 방법론을 권했다. 내 경험에 따르면 안정된 프로젝트에서조차도 낯선 충격은 불쑥 튀어나온다. 나는 아직도 애자일 가치들이 적절하지 않은 경우를 보기 위해 기다리고 있다.

Supporting the Values

우리 17명은 가치에는 빠르게 동의했다. 다음 단계의 선언문을 개발하는 것은, 그 모임에 남은 시간에 우리가 마칠 수 있는 것보다 더 많은 것을 증명했다. 이 섹션에 포함된 가치들은 현재 동작하는 것들을 구성한다.

이 항목들은 우리가 우리의 말에 대한 사람들의 인식에 대해 파악하고, 우리가 더 정확한 단어를 스스로 생각해 낼 때까지 계속 발전해야 한다. 이 특정 버전이 책이 출판된 이후에 낡아지지 않는다면 나는 놀랄 것이다. 최신 버전은 http://www.agilealliance.org 를 확인하라.

우리는 다음 수준의 권장사항에 동의할 것을 기대하지 않는다. 이는 프로젝트 전술에 관계된 것들인데: 아키텍처를 얼마나 많이 어느 시점에 개발해야 하는지, 어떤 도구를 사용하거나 피해야 하는지 등이다. 우리 각자는 여전히 자신의 경험, 두려움, 소원, 철학을 가지고 있고, 이는 우리의 실천법과 권장사항의 특징이다. 우리는 권장의 구체성을 다르게 할 것이다.?

이것들이 우리가 동의한 문장들이다. 그리고 각각에 대한 내 해설이다.

1. 우리의 가장 우선순위는 가치있는 소프트웨어를 일찍, 그리고 자주 전달하여 고객을 만족시키는 것이다.

우리는 그 자신의 목적에 부합하는 소프트웨어를 전달하는 것에 관심이 있다. 이상하게도, 내가 방문했던 몇몇 회사들은 실제로는 소프트웨어를 전달하는 것에 가치를 두지 않는 것처럼 보였다. 애자일 개발은 전달에 초점을 둔다.

일찍 전달하는 것은 빠른 승리와, 요구사항, 팀, 프로세스에 대한 이른 피드백을 가능하게 한다. 이 책 전반에 걸쳐 봐왔듯이.

자주 전달하는 것은 팀이 계속적으로 승리하는 것, 신속한 피드백, 프로젝트 중반에 프로젝트 방향성과 우선순위를 변경하는 것을 가능하게 한다.

전달되는 기간은 프로젝트마다 협의할 필요가 있다. 일간 혹은 주간으로 전달하는 것은 사용자에게 장점보다는 방해가 될 수도 있기 때문이다. 사용자가 3개월마다 있는 시스템의 변경 주기를 소화하지 못한다면, 프로젝트 팀은 피드백을 받을 다른 방법을 찾을 필요가 있고, 프로세스가 항상 테스트와 통합이 되면서, 동작한다는 것을 확실히 해야 한다.

이 문장은 고객에게 최대의 가치를 가져다주는 요소들을 전달할 것을 강조한다. 고객의 기분 변화, 압박적인 경쟁, 시장의 변화 등으로 인해, 1년 혹은 그 이상 되어야 전달되는 프로젝트가 매출을 내는 것을 보장하기란 거의 불가능하다.

이 문장은 가치가 일찍 전달되는 것에 대해 말한다. 그럼으로서 스폰서가 펀딩을 잃더라도, 약속들로 가득찬 서류 더미만을 가지게 되는 대신, 구매자에게 뭔가 가치있는 것을 전달할 수 있는 동작하는 소프트웨어를 가질 수 있다.

2. 작동하는 소프트웨어를 자주 전달하라. 몇 주에서 몇 개월로 하되, 짧은 기간을 선호하라.

절반에 해당하는 이 '일찍, 그리고 자주' 하는 전달은, 작업 주기의 길이에 대해 이야기한다. 내가 겪었던 어떤 프로젝트는, 4개월 주기의 점진적인 개발로 돌아갔지만, 대부분은 1개월에서 3개월 주기를 사용했다. 더 짧은 주기는 드문데, 사용자가 그보다 더 잦은 변화를 감당하기 어려워하곤 하기 때문이다.

Winifred 프로젝트에서는, 고정비용 계약이었고, 50명이 18개월간 일했다. 우리는 사용자에게 전달하는 주기를 3개월로 정했다. 이게 피드백을 기다리기에는 너무 길다는 것을 알게 되면서, 우리는 매 주기마다 몇몇 전문가 사용자들이 와서 2가지씩의 변화를 보고 동작하는 소프트웨어를 리뷰하게 했다. 그 두 명의 사용자 리뷰의 스케쥴은 유동적이었는데, 대개 6주에서 8주 사이였다.

만약 사용자가 매달 변화하는 것을 받아들인다면, 개발팀은 변화에 대한 현재 진행형의 요청을 매치할 수 있고, 짧은 피드백 주기일수록 더 낫다.

3. 작동하는 소프트웨어가 진척의 주요한 척도이다.

이것은 작동하는 소프트웨어에 대한 세번째 언급이다. 이 원칙은: 동작하는 코드를 통해 도출되는 결과에 정직하게 의존하는 것이, 계획과 문서 등의 형태로 적힌, 기대되는 종이들에 의존하는 것보다 낫다는 것을 확고히 해준다. 당연히 진척에 대한 다른 측정들을 사용해도 된다. 하지만 작동하는 코드는 의지할 단 한 가지이다.

애자일 방법론들은 무언가를 일찍 만들고 동작시켜서 시간에 걸쳐 진화시키는 것을 중요하게 여긴다. 모든 프로젝트가 작은 진화적인 단계들을 받아들일 수 있는 것은 아니다. 대규모 프로젝트의 거대 아키텍처를 점진적으로 구축하고 테스트 할 수있는 작은 조각으로 분할하는 방법을 결정하려면 약간의 작업이 필요하다. 그러나 할 수 있으며 노력할만한 가치가 있다.

Stephen Mellor는 모델 기반 개발에서 두 가지 작업 코드가 시연되어야 한다는 점을 주의 깊게 지적한다. 하나는 실행모델로, 사용자 요구에 맞는지 평가된다. 시연할 다른 작업 코드는 최종 코드를 생성하는 매핑 알고리즘이다. 이것은 더 쉽게 간과된다. 많은 프로젝트에서 멋진 실행 가능 모델을 만들었으나, 코드 생성 알고리즘이 제때 제대로 작동하지 못했다.

4. 개발의 후반부일지라도 변화를 환영하라. 애자일 프로세스는 변화를 통해 고객의 경쟁력에 도움이 되게 한다.

애자일 프로세스는 늦게 변경되는 요구 사항을 정확하게 처리할 수 있다. 실행 중인 소프트웨어의 조기 및 빈번한 제공, 반복주기 및 타임 박싱 기법, 아키텍처에 대한 지속적인 관심, 설계를 기꺼이 업데이트하고자 하는 의지를 통해.

당신의 회사가 신속하게 전달하고 최신 정보에 대응할 수 있고, 당신의 경쟁사는 그럴 수 없다면, 당신은 소프트웨어 측면에서 경쟁 업체를 능가할 수 있다. 이것은 종종 시장에서 큰 차이로 해석된다.

모든 애자일 방법론에는 이미 논의한 바와 같이 요구사항의 최신 변경 사항을 통합하는 몇 가지 메커니즘이 있다. 세부사항은 방법론에 따라 다르다.

5. 비즈니스 쪽의 사람들은 프로젝트 전반에 걸쳐 날마다 함께 일해야 한다.

업계는 스폰서가 무엇을 필요로 하는지 확실히 하는데 시간을 할애하지 않은 프로젝트로 가득 차있다. Frakes와 Fox는 사용자와 프로젝트 성공 또는 실패 사이에 강한 상관관계를 보여준다는 연구를 보고했다.

최고의 연결은 선언문에서 요구하는, 현장에 나와있는 비즈니스 전문가와 일일 토론들을 통한 것이다. "매일"이라는 단어는 토론이 진행되고 요청시 발생하는 최적의 지점을 나타낸다. 대부분의 프로젝트에서 일일 토론은 실용적이지 않다. 이는 프로젝트가 최적의 위치에 있지 않다는 것을 의미한다. 선언문은 개발자로부터, 그리고 개발자에게 정보를 얻는데 시간이 오래 걸릴수록 프로젝트에 더 많은 피해가 발생할 것임을 말한다.

6. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고, 그들이 일을 끝내리라고 신뢰하라

우리는, 동기가 부여되지 않은 개인이 사용하는, 잘 정의된 프로세스보다, 의사 소통을 잘하고 프로세스를 전혀 사용하지 않는, 동기 부여되고 숙련된 사람들을 보고 싶다. 초기 VISA 시스템에 대한 Dee Hock의 이야기는 이에 대한 극단적인 예를 제공한다.

개인들이 프로젝트를 작동시킨다. 그들의 동기는 프로젝트 업무에 대한 자부심, 우호, 커뮤니티에 있다.

나는 매우 성공적인 회사인 Object Technology International의 사장인 DaveThomas와의 프로젝트 인터뷰에서 위의 진술을 처음 접했다. 그는 "우리도 좋은 사람들을 고용하고 그들에게 일을 완수할 수 있도록 도구와 교육을 제공하고, 그들을 놔둔다."라고 말했다. 나는 그의 조언을 뒷받침하는 증거를 계속 찾고 있다.

7. 정보를 전달하는 가장 효율적이고 효과적인 수단은 면대면 대화이다

이것은 책의 3장과 4장에 바로 나온다. 여기서 논의와 주의사항을 반복하지 않겠다. 지금 책을 읽고 있다면 해당 장을 검토하라.

8. 최고의 아키텍처, 요구사항, 설계는 자기조직적인 팀에서 창발한다

우리는 이 원칙에서 어떤 단어를 사용할지 몇몇 토론을 했다. 우리는 얼마나의 자기조직화를 의도하는가: 완전한 자기조직화인가, 아니면 단지 프로젝트에 참여하는 사람으로부터 좋은 아이디어를 얻을 수 있도록 허용하는가? 신비하게 드러나는가, 아니면 시간이 지남에 따라 작은 단계로 드러나는가, 팀이 사용하는 인간-중심 규칙의 논리적 결과로 드러나는가?

나는 세 가지 선택 중 가운데를 선호한다. Highsmith는 세 가지 중 마지막을 선호한다. 우리 중 누구도 첫 번째를 의도하지 않았다. 그 첫번째는 "행운"이라는 단어에 대한 오해에서 비롯되었다. 우리의 공통점은 시스템 설계의 세부 사항은 가장 경험이 많은 디자이너조차도 놀라게 한다는 것이다.

우리는 요구사항과 프로세스가 하는 것처럼, 아키텍처가 시간이 지남에 따라 조정될 수 있다고 주장한다. 너무 일찍, 너무 단단히 잠긴 아키텍처는 구현 중에 드러나는 불가피한 놀라움과 변화하는 요구사항에 적응할 수 없다. 단계적으로 성장하는 아키텍처는 팀의 변화하는 지식과 사용자 커뮤니티의 변화하는 희망을 따를 수 있다.

9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

깔끔하고 잘 캡슐화된 설계는 변경하기가 더 쉬우며, 이는 프로젝트의 민첩성을 높여준다. 따라서 민첩성을 유지하려면 설계자는 처음부터 좋은 설계를 만들어야 한다. 또한 정기적으로 설계를 검토하고 계선하여, 시간이 지남에 따라 설계를 더 잘 이해하고, 단기 목표를 달성하기 위해 초석을 놓을 때부터 정리해야 한다.

방 안에 존재하던 깊은 경험을 감안할 때, 짧은 시간 척도, 가벼운 문서 및 사람에 대한 관심 뿐 아니라 설계 품질에 대한 관심을 보는 것이 흥미롭다는 것을 알았다.

상반되는 힘은 당면한 지식이 허용하는 것만큼 설계하고 점진적으로 설계함으로써 해결된다.

(기술 부채 관리)

WardCunningham 은 때로 설계 정리와 부채 상환을 비교한다. 더 나아가, 그는 프로젝트의 기술적 부채 관리에 대해 논의한다.

시스템에 서둘러 추가하는 것은 미래에 대한 차입과 부채를 지는 것과 같다. 설계를 정리하는 것은 부채를 갚는 것과 같다.

때로, 그는 기회를 이용하기 위해 빚을 지고 성급하게 변경하는 것이 적절하다고 지적한다. 그러나 부채가 이자를 축적하고 시간이 지남에 따라 증가하는 것처럼, 성급한 설계 변경을 정리하지 않는 프로젝트 비용도 마찬가지이다.

그는 빚을 지고 싶을 때 설계의 초석을 잘라내고 이자가 너무 높아지기 전에 빚을 갚기 위해 설계를 정리할 것을 권한다.

10. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.

이 문장에는 두 가지 측면이 있다. 하나는 사회적 책임과 관련이 있고, 다른 하나는 프로젝트 효과성과 관련이 있다. 회의에 참석한 모든 사람이 사회적 책임 플랫폼에 서명하는 것에 관심이 있는 것은 아니지만, 우리 모두 효과성 문제에는 동의했다.

사람들은 오랜 시간을 보내면서 지친다. 초과 근무 시간 뿐 아니라 정규 근무 시간 중에도 진행 속도가 느려진다. 작업에 실수가 더 많아진다. 초과 근무는 결과물을 점점 줄게 한다. 이것은 인간 구성 요소의 비선형성의 일부이다.

경각심을 갖고 참여감을 가진 직원은, 모든 사회적 책임 문제를 제쳐주고 피곤하고 지루한 직원보다 더 민첩하다. 오랜 (근무) 시간은 프로젝트 레이아웃에 문제가 있음을 나타낸다.

11. 단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.

단순성은 필수적이다. 이것은 동의하기 쉽다. 그러나 단순성이라는 개념은 너무 주관적이어서 유용한 것을 말하기가 어렵다. 따라서 우리 모두가 이 성명을 지지할 수 있다는 사실을 알게 되어 기뻤다.

개발 프로세스 설계에서, 단순성은, 수행하지 않으면서도 수행하고, 좋은 소프트웨어를 만들면서도 하지 않는 일을 최대화하는 것이다. JonKern 은 Pascal의 다음과 같은 말을 상기시킨다: "이 편지는 내가 원하는 것보다 깁니다. 더 짧게 만들 시간이 없었기 때문입니다." 그 의견은 일을 단순하게 만드는 것이 어렵다는 것을 보여준다. 번거로운 모델은 제작하기 쉽다. 변화를 효과적으로 처리할 수 있는 단순한 설계를 만드는 것은 더 어렵다.

방법론과 사람 측면에서, JimHighsmith 는 DeeHock 을 인용하는 것을 좋아한다:

"단순하고, 명확한 목적과 원칙은 복잡성과, 지능적인 행동을 낳는다"

"복잡한 규칙과 규정은 단순하고 어리석은 행동을 유발한다."

12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

우리가 시작한 곳에서 끝나는 것이 적절하다. 어느 프로젝트를 위해 얼마나 가벼운 것이 적절한가? 거의 충분하지 않고, 당신이 예상한 것보다 더 가볍다.

당신의 프로젝트에서 이것을 어떻게 하나? 당신이 하고 있는 것에 대해 성찰해보라. 팀이 격주로 한 시간씩 함께 작업 습관을 성찰한다면, 방법론을 민첩하고 효과적이며 적합하도록 발전시킬 수 있다. 만약 그렇게 할 수 없다면... 당신은 당신이 있는 곳에 머물 것이다.

이면의 원칙들에 대한 성찰

17명의 사람들이 어떤 단어들의 모음에 동의하도록 하는 것은 어렵다. 조언이 더 상세할수록, 사람들의 배경과 철학들의 차이점이 대두되었다.

우리는 네 개의 이끄는 가치들과 12개의 이면의 원칙들이 당신 자신의 애자일 업무 습관을 만드는데 충분한 정보를 줄 것이라고 기대한다.

부록A.1. The Agile Software Development Manifesto: Evolution

애자일 소프트웨어 개발 선언문의 중요성이 커짐에 따라, 사람들은 소프트웨어 개발 외부의 프로젝트에 아이디어를 적용하고, 관련된 일반 관리 원칙을 추출하는 방법을 알고 싶어했다. 십수명의 소프트웨어 업계 안팎의 제품, 프로젝트 관리 전문가가 6개월간 만나며 애자일 선언문의 조금 더 일반적인 애자일 리더십 버전을 작성했다. 2005년 1월에 완성되었으며 그들은 상호의존 선언(Declaration of Interdependence: 독립 선언을 풍자하여), DOI이라고 불렀고, 애자일 프로젝트 리더십 네트워크를 시작했다.

다음 섹션에서는, 애자일 선언문 작성을 검토하고 DOI에 대해 더 자세히 논의한다.

The Agile Manifesto Revisited

애자일 소프트웨어 개발 선언문의 작성은 분수령의 순간이었다. 물론 그 그룹에는 다작의 저자들이 많았지만, 그 당시에는 몰랐다. 전 세계 사람들이 웹사이트에 있는 선언문에 서명한 속도는 나를 놀라게 했다. 더욱 놀라운 것은 6개월도 되지 않아 컨퍼런스들에서 그 주제에 대한 패널 토론이 있었다는 것이다. 2006년에, 나는 두 대기업 간의 공동 출자 계약에 "애자일 접근법이 필요함"이라는 문서를 보았고, Software Engineering Institutde (SEI)는 심사관들이 애자일 프로젝트를 평가하는데 도움이 되는 방법을 개발하고 있었다.

많은 사람들이 선언문을 작성하는 것이 어땠는지, 특히, 회의 과정이 어땠는지 묻는다. 나는 그 회의에 대한 개인적인 관찰, 왜 그것이 특별했는지, 아마 그것이 왜 효과가 있었는지에 대해 알려줄 것이다. 아주 자세하게 설명할 필요나 장소가 없기 때문에, 이후의 경험에 비추어볼 때 흥미로왔던 것들을 선별하겠다.

RobertMartin 은 회의에 전화를 걸어서, "우리 중 많은 사람들이 똑같이 들리는 말을 하는건 우연일까요?"라고 말했다. 그는 선언문 작성에 관심이 있다고 덧붙였다. (나는, 선언문을 작성하는데 전혀 관심이 없었기 때문에, 선언문에 대한 반응이 그보다 더 놀랐을 것이다.) Bob은 회의에 멋진 사람들을 초대했다. "경량 프로세스" 관점의 지지자 뿐만 아니라 다른 일부들도. 우리는 사람들이 북미에서만 왔다는 것을 알고, 영국에 기반을 둔 DSDM 컨소시엄에 대표자가 참석할 것을 요청했다. ArivanBennekum 은 회의를 위해 네덜란드에서 날아왔다. 우리는 XP, SCRUM, Crystal, Adaptive, FeatureDrivenDevelopment, DSDM 및 일반적으로 가볍고 실용적인 개발(AndyHunt, DaveThomas, BrianMarick)을 대표하는 대표자들과 함께했다.

"안녕하세요; 나는 누구일까요?" 라운드 이후에, 우리는 모여 앉아서 1분 동안 서로를 쳐다봤는데, 누군가가 "어떻게 아젠다를 만들까요?"라고 물었다. 누군가 인덱스 카드에 아젠다 항목을 작성하자고 제안했고, 방에 있던 XP 사람들은 당연히 인덱스 카드를 가지고 있었기 때문에 즉시 일부를 꺼내서 쓰기 시작하여 바닥 중앙에 던졌다. 갑자기 인덱스 카드를 바닥에 던지는 사람들이 엄청나게 많았다. 나머지는 그들이 생각했던 것이 무엇이든, 같은 행동을 하기 시작했다. 아이디어가 떨어지고 바닥에 인덱스 카드 더미가 쌓일 때까지 말이다.

누군가 물었다. "이 카드들을 어떻게 안건으로 정리할까요?". 누군가 (아마 당신은, 내가 이미 누가 무엇을 제안했는지 알아차릴 수 있는 능력을 잃어버렸다는 것을 눈치챘을 것이다), "안건의 순서에 관심이 있는 모든 사람들은 그것을 분류하고, 나머지 분들은 맡겨울 수 있습니다" 나는 주제의 순서에 씬경쓰지 않았기 때문에, 휴식을 취했다. 내가 돌아왔을 때, 인덱스 카드가 벽에 테이프로 붙어 있었다.

나중에, 누군가가, "방금 또 다른 안건이 생각났어요. 어떻게 하면 좋을까요?"라고 물었다. 누군가가 대답했다. "원하는 안건이 있는 곳을 찾아서 그곳에 두세요."

이것들을 설명한 이유는, 이 그룹에서 두 가지 점이 내게 충격을 주었기 때문이다:

• 존경(respect). 그 방의 각 사람들은 서로에 대한 엄청난 신뢰가 있었다. 아무도 회의를 가로채려고 하지 않았다; 모두는 다른 사람의 말을 매우 주의갚게 들었고, 그 사람이 말하는 것에 항상 큰 신뢰를 주었다.
• 자기조직화(self-organizing). 이것은 최고 수준의 자기조직화였다. 내가 겪었던 다른 상황들에서는, 한 사람, 더 심하게는 여러 사람들이, 회의를 "운영(run)"하려고 시도했다. 연장자가 방에 있으면, 서로를 잘 모르는 사람들이 많이 있다면, 첫 몇분 동안은 권력 투쟁이 나타나기 쉽다. 그러나 그런 일이 일어나지 않았다.

우리는 소개 이후에 "나는 무엇을 권장하고, 무엇을 지지하는가?"라는 라운드에 시간을 가졌다. 나는, 우리의 각 프로세스들을 단지 15분만에 설명하려 하니, 다른 사람들에게는 매우 이상하게 보였을 것이라는걸 알아챘다.

우리는 우리 권장 사항들이 매우 비슷하게 들리고, 그 유사성의 기저에는 뭔가가 있으며, 그것이 무엇인지 발견해야 한다는 것을 빠르게 결정했다. 이것을 언급해야 하는 중요한 이유는, 그 당시 우리가 프로젝트를 매일, 분 단위로 실행하는 방법에 동의하지 않았고, 여전히 동의하지 않기 때문이다. 이러한 의견 불일치에도 불구하고 당시에는 우리의 견해를 다른 많은 사람들과 구분짓는 매우 강력한 공통점이 있다.

누군가 말하길, "저는 '경량'이라는 단어가 마음에 들지 않습니다; 우리가 진지하지 않은 것처럼 들리거든요."라고 말했다. 다른 누군가도 말했다, "경량이라는건 무언가에 대한 반응입니다. 저는 무언가를 상징하는 단어를 원합니다.". 그래서 우리는 우리가 추구하는 것을 포착하기 위해 태그 단어를 검토하는데 한 시간을 보냈다.

나는 그 단어 검색을 하는 과정이 흥미로웠다:

• 첫번째로, 20-30개의 이름을 브레인스토밍하여 적었다.
• 두번째로, 우리는 몇 가지 이름을 골라서 왜 우리가 그것을 좋아하지 않았는지에 대해 논의했다.

후자의 전술은 우리가 옹호하는 것과 반대하는 것을 이해하는데 도움이 되었다. 우리가 단어를 좋아하지 않는 이유를 적어도 단어를 탈락시키지 않았다; 단지 우리 머릿속에 무엇이 있는지 이해하는데 도움을 주었을 뿐이다.

예를 들어, 한 마디로, 한 이의 중에는, "나는 그 말을 하려면 분홍색 타이즈를 입어야 해요. 나는 분홍색 타이즈는 입지 않겠습니다."라는게 있었다. 우리는 무사시의, "어떤 방어를 채택하든, 그것을 방어하는 것으로 생각하지 말라; 공격의 일부로 생각해라"라고 말한 것과 부합하는 강력한 단어를 찾고 있었다.

애자일 개발은 필요한 것을 적극적으로 제공한다. 단순히 서류 작업을 필요하는 것이 아니다. 따라서 이 책의 표지로 체조 선수나 댄서가 아닌 벵골 호랑이를 선택했다. 나의 또 다른 애자일 마스코트는, 한 티셔츠에서 찾은 사악해보이는 심해 괴물이다.

호랑이와 심해 괴물 둘 모두 저녁을 먹을 것처럼 생겼다. 그들은 단지 서류 작업을 피하거나 유연성을 연습하는 것이 아니다.

• 세번째로, 생각을 명확히 한 후, 우리는 상위 3개 단어에 투표하고 순위를 매겼다.

• 상위의 두 단어는, agile과 adaptive였다. 우리는 애자일이라는 단어를 두고 토론하고 최종 투표를 했다. 내가 먼저 언급했듯이, adaptive는 물론 장점이 있지만, agile이 그 당시에 우리가 찾고 있는 그 단어였다. 오늘날, 우리는 우리의 방법론이 agile하고 adaptive한, 두 가지 모두가 되길 원한다.

그러자 누군가가, "그래요, 우리는 이제 단어 하나를 선택했습니다. 그 뒤에는 무엇이 있나요?" 그 다음에 일어난 것은 흥미로웠다. 점심을 먹었고, 다양한 사람들이 화이트보드 앞에서, 아이디어를 논의하며 앉아있었다. 화이트보드 앞의 공간은 17명 모두에게는 너무 좁아서, 사람들이 점심을 먹으면서 왔다갔다 이동했다. 줄 어딘가에서, 누군가 누군가 이것과 대조를제안했고, 가치의 비교가 나타났다. 다른 누군가는 사람들이 한 번에 하나의 가치에 대해 의미있게 동의하지 않을 수 있도록 다소 공정한 가치 비교여야 한다고 제안했다.

모양을 갖추자, 우리는 화이트보드 앞에 앉아 단어를 다듬었다. 누구든이 특정 표현을 지지할 수 없는 이유를 말할 수 있었고, 누군가가 더 나은 표현을 찾을 때까지 그들의 견해를 이해하기 위해 노력했다. 끝마쳤을 때, 우리 각자는 의구심 없이 전체 선언문에 서명할 수 있었다.

애자일이라는 이름과 네 가지 가치 선언문을 가지고, 우리는 12가지 원칙을 만드는데 착수했다. 이 단계에서 각 개인들의 차이가 나타나기 시작했고, 일들이 무너지기 시작했다.

예를 들어, 고객 또는 사용자가 매일 거기에 있어야 하는가? 아니면 주간이면 충분한가? 아니면 일주일에 몇 시간과 몇 가지 질문의 혼합이어야 하나? 시스템이 매일, 매주, 매월, 분기별로 배포된다고 써야 하나? 자기 조직화가 접근 방법의 핵심인가? 아니면 경영진이 행동해도 되나?

이러한 복잡함들을 더해, 사람들이 비행기를 타러 갈 시간이 되었다 (무엇보다, 우리는 이틀간의 예산만 책정했었다). 사람들이 떠나기 시작했을 때, 우리는 세분화된 권장 사항에 대해 종결할 수 없다는 것을 깨달았다. 이것이 실제로 일어난 일이다.

누군가는, 우리 모두가 여전히 개발 방법을 모색하고 있었기 때문에, 세부 수준에서 동의하지 않을 수 있기를 원한다고 지적했다. 정밀도라는 용어를 사용하자면, 우리는 정밀도 레벨 0의 캐치 프라이즈 agile이라는 용어에 서로 동의했다. 우리는 정밀도 레벨 1의 네 가지 가치에 대해 동의했다. 우리는 정밀도 레벨 2의 12가지 원칙들에 (간신히) 동의했다. 우리는 그 다음 레벨의 정밀도에 대해서는 동의하지 않는걸 허용하기로 동의했다.

마지막으로, 우리는 왜 그렇게 빨리 많은 영역을 다룰 수 있었는지 검토했다. 대답은 우리 바로 앞에 있었다: 우리는 개인과 상호작용에 주의를 기울였고, 직접 대면했고, 공동으로 작업했으며, 제품에 집중했다. 다시 말해, 우리는 우리가 기록했던 그대로 살았다. (행동했다)

The Declaration of Interdependence

선언문의 중요성이 커지면서, 사람들이 물어본다:

• 비-소프트웨어 제품 개발에 대응하는 버전은 무엇인가요?
• 경영에 대응하는 원칙과 가치는 무엇인가요?

JimHighsmith 는 단순히 소프트웨어가 아닌 제품에 대한 애자일 선언문을 이해하려면 선언문에서 소프트웨어라는 단어를 단어로 바꾸면 된다고 언급했다. 그러면 선언문은 여전히 명확하고 정확하다:

• 작동하는 제품이, 포괄적인 문서보다;

실제로, 이것은 이 책에서 이미 논의된, 소프트웨어 외부에서 애자일 가치와 원칙을 무수히 적용한 것으로 입증된다. 특히 MikeCollins 의 사이드바를 다시 읽고, 린 제조 방식이 이미 우리가 말하고 싶은 것을 어떻게 예상했는지 확인하라.

관리 측면에서, 많은 사람들이 애자일 선언문을 소프트웨어 외부의 프로젝트 관리 및 제품 개발로 확장하는데 관심을 표명했다. 우리는 2004년의 Agile Development Conference에서 이 주제를 탐구하기 위한 첫 번째 회의를 열었다. 이 그룹은 두 번 더 만났고, 마침내 2005년 2월 1일에, 여섯 가지 항목을 가진 상호 의존성 선언 (DOI)을 작성했다.

• 우리는 가치의 지속적인 흐름에 초점을 맞춰, 투자 대비 수익을 높인다.

• 우리는 빈번한 상호작용과 공동 소유권에 고객을 참여시켜 신뢰할 수 있는 결과를 전달한다.

• 우리는 반복, 예측, 적응을 통해 불확실성을 관리한다.

• 우리는 개인이 가치의 궁극적인 원천임을 인식하고 그들이 변화를 일으킬 수 있는 환경을 조성함으로써 창의성과 혁신을 이끌어낸다.

• 우리는 결과에 대한 집단 책임과 팀 효과성에 대한 공동의 책임감을 통해 퍼포먼스를 높인다.

• 우리는 상황에 맞는 전략, 프로세스 및 실천법을 통해 효과성과 신뢰성을 개선한다.

DOI의 서명자는 DavidAnderson, SanjivAugustine, ChristopherAvery, AlistairCockburn, MikeCohn, DougDeCarlo, DonnaFitzgerald, JimHighsmith, OleJepsen, LowellLindstorm, ToddLittle, KentMcDonald, Polly-annaPixton, PrestonSmith, RobertWysocki 이다.

이 명단의 사람들은 프로젝트 관리에서 제품 개발, 애자일 소프트웨어 개발, 라인 관리, 팀워크 전문가에 이르기까지 광범위한 전문 지식으로 유명하다.

다음으로, 나는 이 선언에 대한 나의 생각을 자세히 설명한다.

DOI를 이해하기

6개의 문장은 두 개의 절로 구성되는데, "우리는 저것을 함으로써 이것을 달성한다"라고 이루어진다. 다시 말해, 우리가 그렇게 하는 것을 볼텐데, 우리가 이것에 관심을 갖는 이유는 이것을 이루려고 하기 때문이다.

개인적으로, 나는 DOI를 두 개의 컬럼 형식으로 읽는 것을 좋아한다. 왼쪽 열은 우리가 성취하고자 하는 것을 나타내고, 오른쪽 열은 우리가 성취하고자 하는 방법을 나타낸다. 이 형식으로 생각해보라:

주의 깊은 독자는 이 선언에는 프로젝트 관리에만 고유한 점은 거의 없다는 것을 알아챘을 것이다. 항목들은 모든 관리, 심지어 자기조직적인, 자기 관리 팀에 적용된다.

DOI에 문제가 하나 있다면, 이 여섯 개의 항목들이 진부한 것처럼 들린다는 것이다. 아마도 그것은, 애자일 선언과는 달리, DOI는 나쁜 녀석을 지칭하지 않기 때문일 것이다. 원인과 결과 관계만을 나타낸다. 항목을 적용하려고 할 때만 놀라움이 나타난다.

다음은 몇 가지 놀라운 사실이다:

• "... 가치의 지속적인 흐름..."

린 제조는 배치 사이즈가 작아질수록 프로세스가 개선된다는 것을 가르쳐줬다. (O.L.Tanner의 Lean Manufacturing 323 페이지를 봐라). 소프트웨어를 개발할 때, 인벤토리 단위는 검증되지 않은 결정이다. 모든 서면 요구사항, 아키텍처 결정 또는 문서, 설계 도면 또는 결정 및 작성된 코드는 통합 및 테스트될 때까지 인벤토리로 간주된다!

이들 각각을 하나의 단위 또는 연속적인 흐름으로 축소하는 것은 소프트웨어 개발을 위해 고려해야 할 확장 목표이다. 이는 요구사항, 아키텍처, 디자인 또는 코드에 관계없이 모든 결정을 단일 단위로 구현, 통합 및 테스트해야 함을 의마한다. 아직 그렇게 하기에는 부6족하지만 목표의 중요성은 이해한다.

부록B. Naur, Ehn, Musashi

PeterNaur와 PelleEhn은 소프트웨어의 발전에 관하여 가장 훌륭하고 정확한 보고서를 만들어 냈다. 그러나 이 두 보고서는 그 중요성에 비해 널리 알려지지 않았고, 그나마 Ehn의 책은 절판되었다. 이런 이유로 그들의 글을 더 많은 독자에게 소개할 수 있게 되었음을 기쁘게 생각한다.

PeterNaur의 "이론 구축으로서의 프로그래밍"은 소프트웨어 창조라는 정신적 활동을 깔끔하게 묘사하고, XP에서의 "은유 구축(metaphor building)" 활동에 대하여 논의하고 있다.

PelleEhn은 Wittgenstein의 언어 게임(language game) 이론이 소프트웨어 발전에 대해 시사하는 바를 담은 Work-Oriented Design of Software Artifacts라는 훌륭한 책을 저술하였다.

17세기 일본의 사무라이 전사인 미야모토 무사시는 소프트웨어에 대해 저술하지 않았다. 그가 살던 시대, 칼을 무기 삼아 전투하던 무사들의 무리는 오늘날의 방법론 학자들만큼이나 고민을 했던 것 같다. 그는 사람들에게 도구나 계파에 빠지지 말고, 다양한 순간에 다양한 도구를 사용하여 일격을 가하고, 어떻게든 "상대의 팔을 잘라내"라고 충고하였다. 이런 권고는 소프트웨어 발전에 직접적으로 적용할 수 있다 - 상대해야 할 맞수는 바로 옆에 앉은 동료가 아니라 "문제" 자체라는 것을 깨닫게 된다면 말이다.

Peter Naur, Programming as Theory Building

Pelle Ehn, Wittgenstein's Language Games

Musashi

부록B.1. Naur, Ehn, Musashi: Evolution

Naur

Ehn

Musashi

부록 C. 후기

Agile Software Development

Business as a Cooperative Game

Leadership

Everyone

부록D. Books and References

Books by Title

References by Author

---

CategoryBook CategoryAgile