책/AgileSoftwareDevelopmentTheCooperativeGame

Clear message

AlistairCockburn이 지은 책.

0장. Unknowable and Incommunicable

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 는 타임 박스된 개발과 각 타임박스 이후의 우선순위 재지정을 필요로 한다.

Supporting the Values

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

The Agile Manifesto Revisited

The Declaration of Interdependence

부록B. Naur, Ehn, Musashi

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