Diff for "책/AgileSoftwareDevelopmentTheCooperativeGame"

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, RobertCMartin, StephenJMellor, KenSchwaber, JeffSutherland, DaveThomas 가 그들이다. (만약 Object Technology International의 DaveThomas도 그 미팅에 참석할 수 있었더라면, 두 명의 DaveThomas가 서명할뻔 했다!)

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

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

The Manifesto

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