AlistairCockburn이 지은 책.

Contents

  1. 0장. Unknowable and Incommunicable
    1. The Problem with Parsing Experience
    2. The Impossibility of Communication
    3. Three Level of Listening
    4. So, What Do I Do Tomorrow?
  2. 0.1장. Unknowable and Incommunicable: Evolution
    1. Communication and Shared Experience
    2. Shu-Ha-Ri
  3. 1장. A Cooperative Game of Invention and Communication
    1. Software and Poetry
    2. Software and Games
    3. A Second Look at the Cooperative Game
    4. What Should This Mean to Me?
  4. 1.1장. A Cooperative Game of Invention and Communication: Evolution
    1. The Swamp Game
    2. Competition Within Cooperation
    3. Other Fields as Cooperative Games
    4. Software Engineering Reconstructed
  5. 2장. Individuals
    1. Them's Funky People
    2. Overcoming Failure Modes
    3. Working Better in Some Ways Than Others
    4. Drawing on Success Modes
    5. What Should I Do Tomorrow?
  6. 2.1장. Individuals: Evolution
    1. Strategy Balancing
  7. 3장. Communicating, Copperating Teams
    1. Convection Currents of Information
    2. Jumping Communication Gaps
    3. Teams as Communities
    4. Teams as Ecosystems
    5. What Should I Do Tomorrow?
  8. 3.1장. Teams: Evolution
    1. A Sample Office Layout Revisited
  9. 4장. Methodologies
    1. An Ecosystem That Ships Software
    2. Methodology Concepts
    3. Methodology Design Principles
    4. XP under Glass
    5. Why Methodology at All?
    6. What Should I Do Tomorrow?
  10. 4.1장. Methodologies: Evolution
    1. Methodologies versus Strategies
    2. Methodologies across the Organization
    3. Process as Cycles
    4. Describing Methodologies More Simply
  11. 5장. Agile and Self-Adapting
    1. Light But Sufficient
    2. Agile
    3. Becoming Self-Adapting
    4. What Should I Do Tomorrow?
  12. 5.1장. Agile and Self-Adapting: Evolution
    1. Misconstructing the Message
    2. Evolution of the Agile Methodologies
    3. New Methodology Topics
    4. Persistent Questions
    5. Agile Outside Software Development
  13. 6장. The Crystal Methodologies
    1. Shaping the Crystal Family
    2. Crystal Clear
    3. Crystal Orange
    4. Crystal Orange Web
    5. What Should I Do Tomorrow?
  14. 6.1장. The Crystal Methodologies: Evolution
    1. The Crystal Genetic Code
    2. Crystal Clear
    3. Stretching Crystal Clear to Yellow
  15. 부록A. The Agile Software Development Manifesto
    1. The Agile Alliance
    2. The Manifesto
    3. Supporting the Values
  16. 부록A.1. The Agile Software Development Manifesto: Evolution
    1. The Agile Manifesto Revisited
    2. The Declaration of Interdependence
  17. 부록B. Naur, Ehn, Musashi
    1. Peter Naur, Programming as Theory Building
    2. Pelle Ehn, Wittgenstein's Language Games
    3. Musashi
  18. 부록B.1. Naur, Ehn, Musashi: Evolution
    1. Naur
    2. Ehn
    3. Musashi
  19. 부록 C. 후기
    1. Agile Software Development
    2. Business as a Cooperative Game
    3. Leadership
    4. Everyone
  20. 부록D. Books and References
    1. Books by Title
    2. References by Author

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

여러 방법론들을 필요로 하는 문제를 위한 적절한 2가지 답이 있다.

...

Methodology-per-project에 접근하는 또 다른 방법은 프로젝트에서 사용된 구체적인 샘플 방법론을 모으고, 프로젝트에 참가한 사람들에게 앞 장에서 설명한 재단 기법을 사용하여 이를 다듬게 하는 것이다.

이는 JimHighsmith의 접근 방식인데, 나도 이런 방식을 따르고 있다. 우리는 출발 시점부터 사람들이 사용할 수 있는, 성공적으로 사용된 커뮤니케이션 및 공동체에 입각한 Agile 방법론의 사례를 모으고 있다.

...

Crystal 방법론의 다른 제약은 이것이 함께 있는 팀에만 해당한다는 것이다. 이전에 논의한 바와 같이 내가 보았던 분산된 offshore 개발 프로젝트도 방법론적으로는 성공하지 못하였다. 이런 프로젝트에 대해서 내가 해줄 수 있는 유일한 충고는 팀을 한 지역으로 모으라는 것이었다.

Crystal은 적합한 수준 이상이나 이하로 이동하는 것을 목표로 하지 않는다. 컴퓨터 하드웨어를 사용할 때 하드웨어를 변경하는 데에는 커다란 재정적인 결과가 뒤따르는데, 이 때문에 적절함이 주요 이슈가 된다. 방법론의 규모를 조절하여 유사한 결과를 내놓고 싶지는 않다. 4명이 일을 하다가 20명으로 규모가 커진 프로젝트에 종사하는 사람들은 "이전에 일하던 규칙을 어떻게 보존하지요?'라고 물어서는 안된다. "20명이 함께 일하기에는 어떤 방법이 좋을까요?"라고 질문하는 것이 적절하다.

Crystal의 핵심 요소

핵심적인 Crystal 철학은 소프트웨어 개발의 첫 번째 목표는 제대로 움직이는 소프트웨어를 개발하는 것이고, 두 번째 목표는 그것을 다음 게임을 준비하는 창조와 커뮤니케이션의 협력적 게임으로 본다는 것이다.

이러한 철학은 다음과 같은 2가지 결론을 도출한다. 다른 프로젝트는 다르게 운영되어야 하고, 사람들이 행해야 하는 모델링과 커뮤니케이션의 규모는 그들이 함께 게임을 진행하기 위해 필요한 규모와 같다는 것이다.

Crystal 군의 구성 요소는 다음을 공유한다.

Crystal 방법론의 본질적인 가치는 다음 2가지이다.

전자는 도구나 작업 산출물, 프로세스 등은 인적 요소를 뒷받침하는 것에 불과하다는 뜻이고, 후자는 인간의 다양한 문화를 인정한다는 뜻이다.

그렇지만 Crystal군의 관용성 내에서도 팀은 엄격한 형식이나 규율이 있는 방식으로 일할 수 있다. (예를 들어, PSP나 XP의 일부를 채택하는 것.)

4장에서 논의된 방법론의 7가지 원칙은 다음과 같이 요약할 수 있다.

다음 2가지 규칙은 Crystal군에 공통적으로 적용된다.

다음 2가지는 Crystal의 기본 기법이다.

이러한 목표를 성취하는 또 다른 방법이 있다면 이 두 기법을 얼마든지 다른 것으로 대체해도 좋다.

위의 이슈에 집중하는 것은 특별한 느낌을 준다. 누군가 말한 바와 같이, Crystal 프로젝트처럼 느끼지 않도록 하면서 Crystal 프로젝트처럼 보이는 또 다른 방법론을 만들어낼 수 있다. 성공적인 Crystal 프로젝트를 방문한 사람은 커뮤니케이션과 공동체가 활동 중이라는 것을 알아채고, 협력적 게임의 2가지 목표를 성취하는 데 있어 실용주의를 관찰할 수 있을 것이다.

다음에는 내가 지금껏 만들어서 사용해 본 3가지 Crystal 방법론을 소개한다. 이들 간의 구조적 차이는 명백하다. 공통점을 찾을 수 있는지 살펴보기 바란다.

Crystal Clear

CrystalClear는 D6 범주에 해당하는 프로젝트를 위한 방법론이다. 커뮤니케이션 및 테스팅에 대한 주의를 통하여, Crystal Clear를 E6나 D10 범주까지도 확장할 수 있어야 한다. CrystalClear는 같은 방에서 편한아게 일할 수 있는 규모 이상의 사람들을 위한 커뮤니케이션 구조를 갖고 있지 않고, 치명적 시스템에 필요한 시스템 유효성 요소가 부족하기 때문에 그 이상 확장하기는 어려울 것으로 보인다.

CrystalClear 개요

한 사무실 또는 인접한 사무실에 자리하고 있는 팀이 하나 있다.

이 사람들에게 필요한 역할은 다음과 같다.

이 사람들 중 한 사람은 프로젝트 조정자로서의 업무를 담당하게 될 것이다. 누군가는 비즈니스 전문가가 될 것이고, 다른 누군가는 요구사항을 모으는 역할을 하게 될 것이다.

상급 설계 프로그래머는 이 팀에서 핵심적인 인물이다. 상급 설계 프로그래머와 문제에 따라 다른 설계 프로그래머들에는 초급자와 중급자가 섞여 있을 것이다. 업무를 잘 아는 사람을 고용하면 도움이 될 것이다.

정책 기준은 다음과 같다.

제품 및 방법론 조율 워크숍은 각 증가의 시작과 중간에 개최한다.

정책 기준은 강제적이긴 하지만 Scrum work scheduling (Schwaber, 2002), XP, Adaptive Software Development (Highsmith 2000) 등이 사용된 경우에서와 같이 동등한 수준의 교체는 허용된다.

제작할 작업 산출물은 다음과 같다.

다음은 "팀 내의 문제"로 남아 팀에 의해 유지된다.

CrystalClear는 프로젝트 문서 생성을 요구한다. 단지 무엇을 생성해야 하는지를 거론하지 않았을 뿐이다. 이것은 팀의 판단에 맡긴다.

컴파일러 외에 팀이 가질 수 있는 가장 중요한 도구는 다음과 같다.

설계 문서와 회의록을 입력하는 데 드는 시간을 줄이고 사람들이 화이트보드 상의 내용을 옮겨 적지 않을 때 발생하는 상실 커뮤니케이션 비용을 절약하기 위해, 어느 프로젝트에서든 몇 개의 인쇄 가능한 화이트보드를 구입하는데 드는 비용은 얼마든지 정당화될 수 있다.

개인 역할에 의해 사용된 기법은 전적으로 개인의 자유 재량에 달린 것이다.

유사한 방법론으로부터 구성 요소를 대체하는 것도 가능하다. 예를 들어, 팀은 Scrum 또는 DSDM의 timeboxing 및 동적 우선순위 정책이나 Scrum의 일일 stand-up 회의, XP의 pair programming 등을 사용할 수도 있는 것이다.

CrystlaClear 검토

CrystalClear는 여전히 가장 관용적이고 형식적인 면이 적으며, 규모가 작은 팀의 방법론이다. CrystalClear는 내가 인터뷰했던 사람들이 성공 요인으로 꼽았던 다음과 같은 요소를 포함하고 있다.

최근에 만들어진 화이트보드 저장 소프트웨어와 같은 것을 제외하고는 어떤 하이테크 도구보다도 인쇄 가능한 화이트보드가 더 가치 있다고 결론지었다. 사람들은 대개 기록할 필요가 없다고 생각하며 토론을 시작한다. 그리고 이런 토론이 끝난 후에야 기록해 두면 유용하다는 것을 알게 된다.

CrystalClear는 XP를 시도하거나 포기할 때의 대비책이 될 수 있다. XP의 어떤 부분도 CrystalClear로 대체될 수 있는데, 이는 XP가 문서화를 제외한 모든 부분에서 CrystalClear 기준에 맞추기 때문이다. XP에서 CrystalClear로 옮기려면 문서화를 추가해야 한다. 독자가 CrystalClear보다 더 간단한 것을 얻을 수 있다거나 아직까지도 프로젝트를 성공적으로 수행하는 것 이상의 계획을 갖고 있다고는 생각하지 않는다.

Crystal Orange

CrystalOrange는 D40 범주에 속하는 프로젝트를 위한 방법론이다: 40명 이하의 사람들이 한 건물에서 임의의 비용 손실을 초래할 수도 있는 시스템에서 작업을 하는 경우.

CrystalOrange는 20명의 프로젝트에서보다는 더 많은 팀 구조와 조정을 필요로 한다. 80명의 프로젝트에 필요한 하위 팀 구조하에서는 부족하고 치명적 시스템에 사용되는 설계 및 코드 검증 작업은 결여되어 있다.

CrystalOrange에 대해서는 Surviving Object-Oriented Projects (Cockburn 1998)의 18페이지 설명에서 찾아볼 수 있다. 이것은 다음과 같은 환경에서 유용하다.

"상업적인 배경에서 중간 규모의 제작 프로젝트에 적합하다. 이런 프로젝트의 특징은,

요구사항 및 설계에 있어 완벽하고 확장된 산출물과 급속한 변화 사이에 상호 절충이 필요한 평범한 종류의 프로젝트이다. 나는 이를 유지하는 비용을 절감하기 위하여 전달물의 수를 줄였지만 반면 팀의 커뮤니케이션을 위해서는 충분히 포함하기도 하였다. 직무 할당 및 팀을 조정하여 보통 이런 종류의 프로젝트에 요구되는 유동성을 가능하게 하였다. 다른 종류의 많은 프로젝트 역시 유동성에 대한 대비가 필요하고 이러한 방법론을 이용할 수 있다."

지속되는 한 가벼울수록 좋다는 것을 생각하면, E50 형태의 프로젝트를 수행하는 팀은 80명의 구성원을 대상으로 하는 Red를 선택하기보다는 Orange를 선택하고, 추가적인 검증 테스트 요소를 추가하는 편이 나을 것이다.

CryatalOrange 개요

프로젝트의 역할은 다음과 같은 내용을 포함한다.

이것들은 다음과 같이 몇 가지 팀으로 구성할 수 있다.

더 큰 기능적인 팀은 Holistic Diversity 전략 (Cockburn 1998)을 사용하여 교차 기능적 그룹으로 나눌 수 있다. 각 그룹은 한 명의 비즈니스 분석가--설계자, 1명의 UI 설계자와 1~3명의 설계 프로그래머를 포함한다. 또한 데이터베이스 설계자와, 여러 기술이 사용되고 있는 경우에는 다른 기술의 대표자들도 포함한다. 테스터도 이 그룹에 포함될 수 있다.

특정 전문가가 부족할 경우 이에 맞추기 위해 팀의 구조는 변경되어야 한다. 교차 기능적 그룹을 갖는 이유는 산출물을 줄이고 국지적 커뮤니케이션을 확장하기 위해서이다. 사람들은 하나의 단일 그룹으로 평가되어, 그의 고유 업무뿐만 아니라 각각 필요한 곳이라면 어디서든지 기여하겠다는 목적을 가지고 있다.

작업 산출물은 다음과 같은 내용을 포함한다.

각각의 작업 산출물은 동료들이 이해할 수 있을 때까지, 또 동료들이 검토 가능한 명확성과 안정성 수준까지 개발한다.

정책 기준은 증가적인 산출 주기가 3~4개월로 다소 늘어날 수 있다는 것을 제외하고는 CrystalClear와 동일하다.

CrystalClear와 마찬가지로 정책 기준은 강제적인 것이지만, Scrum, XP, AdaptiveSoftwareDevelopment 정책 등이 사용된 경우라면 동등한 것으로의 대체도 가능하다.

작업 산출물 템플릿, 코딩 스타일, UI 기준, 회귀 테스트의 상세 내역 등은 팀의 로컬 표준으로 남고 팀은 이를 유지한다. 개인 역할에 의해 사용된 기법은 전적으로 개인의 자유 재량에 달린 것이다.

CrystalOrange 검토

CrystalOrange는 단 10명 정도의 그룹에 초점을 맞춘 구조가 아니다. 이것은 훨씬 더 무겁지만 3~4가지 기술로 작업하는 40명의 프로젝트에서는 매우 가볍게 느껴진다. HolisticDiversity 기능 그룹 및 사용자들의 잦은 대면 속에서 밀접한 커뮤니케이션을 통해 서로 유지할 수 있다.

이 방법론은 성공적으로 사용되었다. 이런 경험은 Surviving Object-Oriented Projects (Cockburn 1998)의 Winifred 프로젝트 보고서에 자세히 설명되어 있다.

이 방법론의 기본적인 것은 기꺼이 사용하겠지만, 기술은 변하고 프로젝트에 참가하는 전문가들도 그때와 다르게 일하며, 그들의 작업 산출물 및 상호 작용에 대한 요구도 다를 것이다. 또한 다음 프로젝트에서의 병목은 Winifred 프로젝트의 것과 다를 것이다.

새로운 프로젝트에서는 CrystalOrange를 기본 방법론으로 채택하고, 이전에 설명한 방법론 조율 기법을 사용하여 이를 재구성할 것이다.

Crystal Orange Web

CrystalOrangeWeb은 계속적으로 웹상에 코드를 만들어내는 eBucks.com이라는 회사를 위해 만든 방법론이다. 이 방법론은 단일 프로젝트를 다루는 것이 아니라 프로그래밍을 필요로 하는 연속적인 결정이 이어지고, 각기 결정한 결과는 공통으로 사용하는, 증대하는 코드 기준과 통합된다는 점에서 CrystalOrange와 다르다.

이 방법론은 아직 시험 운용 중이나 나는 다음과 같은 이유로 이것을 포함시켰다.

eBucks.com의 상황은 두 번째 측면에서 흥미로운 것이었다. 이 회사는 이미 Web을 구축하고 있었다. 이는 더 이상 time-to-market 전략으로 추진되지 않았고, 결정에 따른 비용 증감에서 오는 압박을 서서히 느끼고 있었다. 기하급수적으로 늘어나는 고객의 전화는 수익 한계를 쉽게 무효로 만들어 버릴 수 있었다. 따라서 회사는 우선순위를 생산성에서 오류 없음으로 전환하였다.

이 상황에서는 50명의 사람을 통제해야 했다: 전문가, 비즈니스 인력, 관리자, 분석가, 프로그래머 및 테스터, 나는 이것을 E50 상황으로 규정하였다.

이 그룹은 상대적으로 새로운 것이었기 때문에 어떤 프로세스 정의는 누가 어떤 결정을 내리고, 누가 어떤 정보를 누구에게 전달하는지 명시할 필요가 있었다. 그렇지 않더라도 사람들은 일반적으로 업무를 마치기 위해 누구와 이야기하는지 정도는 알고 있었다.

방법론 조율 기법에서 언급한 것처럼 나는 인터뷰를 수행하였다. 마케팅부터 테스팅, 시스템 운영 부분까지 각 직무에 있는 사람들을 인터뷰하였다. 이 인터뷰를 통해 다음 사항들을 알 수 있었다.

CrystalOrangeWeb의 개요

방법론은 그룹이 동의한 일련의 규율이라는 아이디어에 기초하여 방법론을 5개의 카테고리로 나누어 일련의 규율로 기록하였다.

1. 학습을 통한 정기적 핵심 도출 회의

이 카테고리의 목적은 "여기서는 어떻게 일을 해나갈까"라는 질문에 대한 피드백을 얻는 핵심적인 절차를 설립하고, 이를 숙고하고 개선할 수 있는 시간을 갖기 위함이다. 각 주기의 마지막에 이루어지는 검토 위크숍을 제외한 모든 회의는 검토 위크숍의 결과로 교체될 수 있다.

  1. 2주간의 개발 주기. 전반적인 제작은 2주로 고정된 개발 주기 내에서 이루어진다. 각 산출 이후 각 팀은 팀이 산출할 수 있는 것에 따라서 다음 산출을 2주 또는 4주로 선택할 수 있다. 각 팀은 매 4주마다 무언가 유용한 것을 산출해야 한다.
  2. 주기 사후 검토 워크숍을 갖고, 제안은 눈에 띄도록 게시한다. 매 주기를 마치고 나서 무엇이 잘 되었고, 무엇이 잘못 되었는지, 다음에 시도해 볼 것에 대해 회의를 갖는다. 회의의 산출물은 지켜야 할 것들의 리스트이다.

2. 기본 프로세스

이 카테고리의 목적을 누가 어떤 부분의 작업을 생성하고 누가 의사 결정을 하는지를 잘 조직화해서 노력이 중복되거나 서로 차이가 나지 않게 하고, 잠재적으로 문제가 내재하고 있는 지점을 미리 파악하기 위함이다. 프로세스는 비즈니스 결정을 협상에 전달하는 것을 목표로 한다.

  1. 사업주는 비즈니스 유스케이스 및 시스템 유스케이스 요약을 작성한다 (Cockburn 2001c). 무언가 잘못되어갈 때 이를 일깨울 수 있는 매뉴얼 비즈니스 프로세스에 특별히 주의를 기울인다. 비즈니스 유스케이스는 운영 중 제안된 새로운 시스템 특징을 묘사한다.
  2. 요약은 기술 그룹이 특성을 생성하는 데 관련된 작업을 추정할 때 사용된다. 비즈니스 중역은 비즈니스 유스케이스, 기술 추정, 심화된 작업을 위해 동의한 결과 등을 검토한다. UI 설계자는 마케팅 및 상세 비즈니스 분석가와 함께 이러한 특징들을 전반적인 사이트 흐름에 통합하여 화면 설계와 화면에 대한 XML을 생성한다.
  3. 상세 비즈니스 분석가는 상세한 유스케이스 및 데이터 설명을 작성하는데, 이는 UI 설계자, 서버 프로그래머, 서블릿 프로그래머 등에게 전달된다. 서블릿 프로그래머는 UI의 XML, 유스케이스, 데이터 설명, 서버 인터페이스를 통해서 서블릿을 제작한다. 서버 및 서블릿 프로그래머는 코드 및 동료 검토 테스트 케이스에 대한 회귀 테스트도 생성한다. 테스트 사례가 훌륭하다고 생각되고, 코드가 테스트를 통과하면 개발자가 주요 이식 전에 발견한 오류를 모두 고치도록 통합 테스터에게 코드가 전달된다.
  4. 통합 테스터는 새로운 릴리스상의 변화를 내부 그룹에게 게시하고 또한 콜 센터에도 알려준다.
  5. 살아 있는 코드를 위해 콜 센터는 특별 SWAT 팀에게 버그를 보고한다. SWAT 팀의 유일한 목적은 제작상의 문제를 수정하는 것이다. 이 팀은 매 두 주기마다 교체하는 것을 기준으로 하여 개발팀으로부터 선정된다.

3. 최대의 진척, 최소의 혼란

이 카테고리의 목적은 사람들이 회사의 최대 가치 선상에서 일을 하고 업무에 집중하여 일을 진척할 수 있는 시간을 갖도록 하는 것이다.

  1. 주요 결과를 우선순위로 매기고 매 2주 제작 주기에 대하여 이를 잘 보이도록 게시한다. 개개인에게 이를 할당하여 모든 사람이 해당 주기 내에서 자신이 최고로 우선시하는 2~3가지를 인식하게 한다.
  2. 2주 주기에서 실행하고 테스트할 수 있는 수준으로 작업을 분할하며, 1~3일 안에 수행될 수 있는 부분으로 더 상세히 분할한다. 하나의 결정 사항 이상에 관련하여 작업하고 있는 사람은 적어도 연속 2일간은 또 다른 업무를 할당 받지 않고, 이 업무 중 하나에만 집중할 수 있어야 한다.
  3. 개발자는 주어진 주에 수행하기로 계획한 작업의 현재 상태를 보여 주는 내용을 사무실 밖의 화이트보드에 게시한다. 매일 아침 개발자는 현재 작업의 결정자인 사업주를 만난다. 현재 작업 상태, 작업의 최우선순위 등을 결정하고 기타 필요한 내용을 의논하기 위해 짧은 회의를 할 수도 있다. 그 외의 시간에는 사업주라도 작업의 현재 상태에 대해 물을 수 없다. 오전 10~12시를 "집중" 시간으로 선언하여 아무런 회의도 갖지 않고 모두가 전화조차 꺼버리도록 한다.

4. 최대한 결점 없게

이 카테고리의 목적은 "지금 버그를 없애자!"라는 문화를 형성하는 것이다.

  1. 모든 서버와 서블릿 클래스에는 프로그래머가 JUnit, HttpUnit 또는 비슷한 것을 사용해서 그 자신의 코드를 위해 생성한, 자동화된 회귀 단위 테스트 집합이 있다. 프로그래머들은 테스트가 동료 개발자의 정밀한 조사를 통과하면 코드를 통합 테스트에 릴리스한다. 통합 테스터는 따라서 코드, 테스트 사례, 테스트의 품질을 보증한다는 다른 프로그래머의 기록을 받게 된다.

  2. 서버는 loopback 알고리즘을 포함하여 통합 테스터가 나름의 테스트 데이터베이스를 운용할 수 있도록 한다. (다른 사람들도 이를 사용할 수 있다.)
  3. 비즈니스 인력은 업무용 언어를 사용하여 샘플 비즈니스 처리를 구조화하고 기대하는 응답을 명명할 것이다. 이러한 작은 언어를 통해, 통합 테스터, 사업주, 서블릿 작성자는 테스트 시나리오를 구조화하고 이를 테스트 데이터베이스에 추가할 수 있을 것이다.
  4. 콜 센터로부터 화면 클릭 통계를 받아 잘 보이는 장소에 게시하여 모든 사람이 이를 보고 어느 부분에서 대중들이 문제를 겪고 있는지를 알 수 있게 한다 (네이게이션의 어려움 또는 프로그램의 결점에 따른 어려움이 있을 것이다).

5. 대화 속에서 연합한 공동체

이 카테고리의 목적은 회사가 목적으로 하는 장기적인 타깃을 가리키는 것이다.

  1. 결국 프로그래머, UI 설계자, 테스터, 사업주, 마케팅 인력 등은 특정 경계를 넘어 의도한 결과를 산출하는 데 있어 대화의 효과를 극대화하고 다른 그룹에 대한 소문의 효과를 최소화하기 위하여, 여러 직능의 인력이 함께 모여 있는 팀을 구성하여 배치해야 한다. 이는 배치 수준이나 공간의 필요성 등에 따라 조정되어야 할 것이다.

CrystalOrangeWeb 검토

이 방법론에 관해서는 2가지 정도가 떠오른다.

첫째는 방법론을 표현하는 데 있어 프로세스 및 작업 산출물의 축소된 역할이다. 나타나긴 하지만 언제나 이들에게 허용되던 비중의 일부만을 점하고 있을 뿐이다.

두 번째는 내가 가장 좋아하는 개발 속도 향상 기법인 동시 개발의 일반적인 부재이다. 동시 개발이 시스템의 병목 때문에 없어진다.

프로그래머는 많은 미처리 작업과 여분의 역량 부족으로 계속 업무를 중단하게 되었다. 사람들은 소프트웨어를 개발하는 것과 비즈니스 영역 모두에 충분한 경험이 없었다. 이 2가지 사실은 프로그래머가 중복 개발을 수행할 수 없고, 요구 사항을 구두만으로는 간직할 수는 없다는 사실을 시사하였다. 그들은 정보를 고정하기 위해 무언가 기록해야 할 필요가 있었다.

시간과 함께 이것은 변할 것이다. 그래서 나는 문서 작업을 줄이고 대화를 늘리기를 바란다. 동시에 종이도 필요하다.

6개월 후

나는 이 방법론이 선발 방법론으로 제작되었기 때문에 이것을 제출하였다. 우리는 시간이 흐름에 따라 어떤 동향을 볼 수 있기를 기대했는데, 사람들은 새로운 작업 방식은 물론, 규율이 엄격한 실무로부터 멀어지기를 바라고 있었다.

eBucks.com의 대표인 Michael Jordaan은 6개월 후 그룹의 작업 습관에 대하여 다음과 같이 언급하였다.

"당신이 떠났을 때 몇 가지 원칙은 그대로 있었지만 나머지는 그렇지 못했습니다."

"그대로 남은 것 중에는 주의 깊게 계획된 2주간의 핵심 도출 회의가 포함되었는데, 이로써 개발자와 사업주는 계획할 수 있고, 테스터는 엄격하게 테스트할 수 있으며, 고객은 예정된 업그레이드에 대해 미리 알 수 있었습니다."

"3주간의 핵심 도출 회의를 논의하기도 했지만 이는 너무 길다고 생각되었습니다. 2주 이내에 해결할 수 있는 것 이상의 복잡한 사안은 핵심 도출 회의를 2번(4주) 운영하여 해결할 수 있지만, 우리는 여전히 증가적인 롤아웃(rollout)을 장려합니다."

"사후 핵심 도출 회의는 엄격히 실행되고 있고, 내가 팀원 전체를 대상으로 말할 수 있는 몇 안되는 회의이기도 합니다. 성공적인 업그레이드를 수행한 사람들에게는 찬사를 아끼지 않습니다. 이런 공개 석상에서의 인정이 동기 부여에 도움이 되기를 바라는 마음에서입니다. 매 회의마다 우리가 창조한 학습 문화를 지지함으로써 범해 온 실수를 토론하고 개선을 위한 제안을 합니다."

"테스트 팀이 거부권을 가지고 있어서 틀린 코드가 살아 있는 것을 방지해주므로, 출시된 코드의 품질은 크게 향상되었습니다."

"살아 남은 버그를 제거하는데 주력하는 SWAT 팀은 또한 고객 및 콜 센터를 상대하는데 큰 진보를 이루었습니다."

"집중하는 시간은 여전히 지켜지고 있습니다(우리는 여전히 매일 아침 10시에 벨이 울리게 합니다). 만약 하루라도 이런 시간을 갖지 않으면 그날은 혼란스럽기까지 합니다. 집중 시간은 아주 유용하다고 생각합니다."

"보드 위에 우선순위 및 작업 진도를 게시하는 습관은 이제는 지켜지지 않습니다. 사람들이 집에서 일하거나 사업주와 개발자 간의 관계가 전보다 안정되었기 때문에, 지금은 방해라는 것이 그다지 큰 이슈가 되지 않습니다. 사람들은 단지 좀 게으를 뿐입니다."

"마지막 처리 과정 업무를 담당하는 2명의 주요 개발자를 제외하고는 대부분의 개발자들이 주어진 시간 내에 최대한 3가지 업무를 수행할 수 있습니다. 이 2명은 아마도 각각 15개의 리스트를 갖게 되기 쉽습니다. 게다가 이들은 아직도 당면한 문제로 방해 받곤 하는데, 이 때문에 업무의 완수를 방해받고, 다른 개발자나 비즈니스 전문가 때문에 낙담하기도 합니다."

"문제는 숙련된 자원이 부족하다는 것입니다. 도와줄 인력을 훈련하는 것은 아주 오래된 문제지만, 이것이 스스로 하는 것보다 더 많은 시간을 소요한다는 것은 분명한 사실입니다."

위에서 언급한 것 중 내가 만족할 만하다고 판단한 것은 팀이 아직도 프로세스의 핵심 요소를 사용하고 있다는 사실이다. 배움을 통한 핵심 도출 회의, 그리고 핵심 돌출 회의가 요구에 맞지 않는 상황에서도 수정하는 방법을 찾는 것이다.

재능과 기술에 대한 논의가 프로젝트에 있어서 아주 중요함을 알았고, 이것들이 방법론상의 장식으로부터 동떨어져 있음을 알았다.

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) 라는 것을 만드는 것에는 관심이 없었다. 그 방에서의 개인주의를 보자면, 우리가 뭔가에 동의했다는게 참으로 놀랍다.

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

이러한 동의와 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 사람들은 당연히 인덱스 카드를 가지고 있었기 때문에 즉시 일부를 꺼내서 쓰기 시작하여 바닥 중앙에 던졌다. 갑자기 인덱스 카드를 바닥에 던지는 사람들이 엄청나게 많았다. 나머지는 그들이 생각했던 것이 무엇이든, 같은 행동을 하기 시작했다. 아이디어가 떨어지고 바닥에 인덱스 카드 더미가 쌓일 때까지 말이다.

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

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

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

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

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

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

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

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

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

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

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

그러자 누군가가, "그래요, 우리는 이제 단어 하나를 선택했습니다. 그 뒤에는 무엇이 있나요?" 그 다음에 일어난 것은 흥미로웠다. 점심을 먹었고, 다양한 사람들이 화이트보드 앞에서, 아이디어를 논의하며 앉아있었다. 화이트보드 앞의 공간은 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를 두 개의 컬럼 형식으로 읽는 것을 좋아한다. 왼쪽 열은 우리가 성취하고자 하는 것을 나타내고, 오른쪽 열은 우리가 성취하고자 하는 방법을 나타낸다. 이 형식으로 생각해보라:

목표

이것을 함으로써

ROI를 높인다

"가치의 흐름"에 초점을 맞추고("노력을 추적"하는게 아니라), 지속적인(한 단위의) 흐름이면 더 좋다.

신뢰할 수 있는 결과

잦은 의사소통과 공동 소유권을 통해 고객을 대면한다.

불확실성을 관리

반복주기, 예측, 적응 (미리 생각하기, 계획, 반복, 전달, 성찰, 적응)

창의성과 혁신을 이끌어냄

개인이 가치의 궁극적인 가치의 원천이라는 것을 인식. 개인들이 차이점을 만들어낼 수 있는 환경을 조성.

퍼포먼스를 높임

집단 책임감 또는 결과 (전체 그룹이 단독으로 책임을 지며, 팀 내 비난 없음); 팀 효과성에 대한 공동 책임.

효과성과 신뢰성을 개선

상황에 맞는 전략, 프로세스, 실천법.

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

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

프로그래밍 언어 구문 표기 기준 "Backus-Naur Form(BNF)"의 저자 중 한 사람으로 널리 알려진 PeterNaur는 1985년에 "이론 구축으로서의 프로그래밍"을 저술하였다. 이것은 그의 논문집 Computing: A Human Activity (Naur 1992)에서 찾아볼 수 있다.

나는 이 논문이 프로그램 설계와 코딩에 대한 가장 정확한 자료라고 확신하고 있다. 얼마나 많은 문서를 만들어야 하며, 어떻게 무언의 지식을 다루어야 하는지, 그리고 XP의 은유--세팅(metaphor-setting) 실습에 대한 가치를 논할 때마다 이를 언급하곤 한다. 또한 방법론의 경제 구조에 대한 연구에도 도움이 된다.

이 논문에서는 설계 프로그래머의 작업 품질이, 문제와 해결법에 대한 그의 이론과의 일치와 관련이 있음을 밝히고 있다. 또한 후배 프로그래머의 작업 품질은, 그 자신의 이론과 선배 프로그래머의 이론 사이의 일치와 관련 있다는 사실도 주시하고 있다.

Naur의 아이디어를 이용하면, 설계자의 업무란 "설계"를 해나가는 것이 아니라 설계를 관리하는 "이론"을 만들어 가는 것이다. 이때 후자가 더 유용하고 적합하다고 볼 수 있다. 또한 소유에 있어서 이론에 대한 지식은 무언의 것이기 때문에 이론을 만들어 나갈 때에는 명쾌함과 동시에 무언의 지식을 따르는 것이 필요하다는 사실에 초점을 맞추고 있다.

이제부터 PaterNaur가 언급한 방식을 살펴보도록 한다.

이론 구축으로서의 프로그래밍

개요

이 논의는 프로그래밍이 무엇인지 이해하는 데 도움이 될 것이다. 여기서는 프로그래밍을 프로그래머가 가까운 장래의 문제에 대한 견해, 또는 이론을 형성하거나 얻는 것에 의한 활동으로 간주해야 한다고 제안하고 있다. 이런 제안은 프로그래밍이란 말을 프로그램 제작이라는 말과는 확실히 다른 뜻으로 간주하므로 일반적인 개념과는 다소 차이가 있기도 하다.

여기에 설명하는 견해의 배경이 되는 것은, 프로그램과 이를 다루는 프로그래머 팀에 실제로 발생하는 사건, 무엇보다 예기치 못한 상황과 잘못된 프로그램 실행, 반작용, 프로그램을 수정하는 경우 등을 관찰하면 발견할 수 있다. 이러한 관찰을 프로그래밍 제작 측면에 수용하는 데 어려운 점은, 이러한 관점이 오해의 소지가 있다는 사실이다. 이론 구축 관점은 선택적인 것으로 보아야 한다.

프레젠테이션에 대한 보다 일반적인 배경은 바로 프로그래밍이 무엇인지 제대로 이해하는 것이 중요하다는 확신이다. 제대로 된 이해가 없으면 작업 중 일어나는 어려움을 제대로 이해할 수 없고 이를 극복하기 위한 노력 때문에 갈등과 좌절을 겪게 될 것이다.

결정적인 배경 경험에 대한 현재의 논의에서는 우선 간단히 윤곽부터 잡아보기로 한다. 이론 구축 관점을 나타내는, 프로그래밍이 무엇인가에 대한 이론 설명이 뒤따를 것이다. 그리고 이후의 절은 이론 구축 관점의 결과에 대해 다루고 있다.

프로그래밍과 프로그래머의 지식

여기서는 프로그래밍이라는 것을 모든 설계 및 프로그램화된 해결 행위를 의미한다는 전제 하에 사용하도록 하겠다. 나의 관심사는 실제 생활 속에서 행위의 특정한 부분과 단면을 컴퓨터상에서 조작할 수 있는 형식적 상징으로 표현하는 활동에 관한 것이다. 이러한 개념에서 볼 때 내가 논의하는 프로그래밍 행위는 프로그램 실행에 대응하는 실제 행위의 변화에 맞추어 가는 개발을 포함해야 한다. 즉, 이것은 프로그램 수정을 뜻한다.

이런 점에서 프로그래밍은 근본적으로 프로그래머의 특정 지식의 구축이며 일시적인 소유물이고, 문서화됐다 하더라도 보조적이고 부차적인 것임에 틀림없다.

다음 절에서는 이런 견해를 좀더 면밀히 다듬게 되는데, 이 장의 나머지 부분에서는 그러한 문제를 생각할 때마다 점점 더 크게만 느껴지는 대형 프로그램을 다루었던 실제 경험에 대하여 이야기할 것이다. 이 경험들은 내가 겪은 것이거나 그렇지 않으면 관련 인물을 직접 만나 보고 전해 들은 이야기이다.

첫 번째 사례는 컴파일러에 관한 것이다. L 언어를 사용하고 X 컴퓨터에 능숙한 A 그룹이 이것을 개발하였다. 이제 또 다른 그룹 B는 Y 컴퓨터를 위한 L 언어에 맞는 확장 형식인 L+M 언어를 위한 컴파일러를 사용하는 업무를 실행한다. B 그룹은 A 그룹이 개발한 L을 위한 컴파일러가 설계를 시작하는 데 적절하다고 결론짓고, 주석을 단 프로그램 텍스트, 좀더 추가된 작성 설계 논의 그리고 개인적 충고 등을 담은 문서를 전해줄 A 그룹과 접촉하게 된다. 그 합의는 효과적이었으며 B 그룹은 그들이 원하는 컴파일러를 개발해 낸다. 현재 상황에서 중요한 문제는 어떻게 M을 확장시키느냐 하는 문제에 관하여 A 그룹으로부터 충고가 필요하다는 사실이다. 설계 단계에서 B 그룹은 확장에 사용할 방법을 결정하고, A 그룹의 검토를 받고자 제출하게 된다. A 그룹은 몇 가지 중요한 사례에서 B 그룹이 제안한 해결책이 기본적으로 기존의 컴파일러 고유의 구조는 물론, 문서화의 길이에 있어서도 편의성 측면에서는 별 효용이 없으며, 오히려 성능과 단순성을 저해하는 패치 형태의 구조를 사족으로 댓붙이고 있다는 사실을 밝혀냈다. A 그룹의 구성원들은 이러한 문제를 발견하고 곧바로 기존 구조에 잘 맞는 단순하면서도 효율적인 솔루션을 제안하였다. 전체적인 프로그램 텍스트와 추가 문서만으로는 A 그룹의 구성원들이 가진 앞선 설계 이론과 통찰력의 수준으로 동기 부여의 정도가 높은 B 그룹을 끌어올리기에는 상당히 부족하다는 것을 보여주는 사례이다.

수년이 지난 후, B 그룹은 자신들이 개발한 컴파일러를 A 그룹의 지도 없이 같은 조직의 다른 프로그래머들에게 전수해 주었다. 결과적으로 A 그룹이 수정한 원래의 유용한 컴파일러 구조를 발견할 수 있긴 했지만, 전체적인 과정에서 보면 효율성은 분명 떨어지는 작업이었던 것이다. 그러므로 프로그램 텍스트와 그 문서화는 몇 가지 가장 중요한 설계 개념의 산출물로서 불충분함이 다시 입증되었다.

두 번째 사례는 공장 생산 활동을 관리하기 위한 대규모 실시간 시스템을 설치하고 결점을 진단했던 프로젝트이다. 이 시스템은 생산자가 판매하였고, 각각의 시스템은 센서의 특정 환경과 출력 장치에 맞게 조정한 후 공급되었다. 설치 프로그램의 크기는 대략 20만 라인이다. 이런 시스템을 다루는 데 관련된 경험은 설치 및 결점 확인 프로그래머 집단의 업무 역할과 방식에 관계된다. 첫째, 이런 프로그래머들은 시스템의 설계 단계부터 몇 년 동안 고정적으로 시스템에 밀접하게 연관되어 있었다. 둘째, 걸점을 진단할 때 이 프로그래머들은 오로지 시스템에 관한 직접적인 지식과 주석이 달린 프로그램 텍스트에 의존하며, 이 작업에 유용한 어떤 추가 문서도 받아들이기 어렵다. 셋째, 시스템의 특정 설치 작업을 담당하기 때문에 제작자로부터 시스템 관련 문서와 시스템 사용헤 대한 전반적인 안내를 받은 다른 프로그래머 그룹 그리고 결점 환인 프로그래머들은 문서를 제대로 이해할 수는 없지만 설치와 결점 확인 프로그래머들이 이를 쉽게 해결해줄 수 있다.

이와 같은 형태의 대형 프로그램에서 계속적인 적용, 수정 및 내재된 오류 수정 작업은 이 프로그램과 밀접하고 지속적으로 관련된 프로그래머의 지식에 의존한다는, 너무도 당연한 결론을 내릴 수밖에 없다.

Ryle의 이론 개념

프로그래머의 지식 구축을 프로그래밍의 필수적인 부분으로 인정하고 나면 다음 문제는 지식을 보다 상세히 특성화하는 것이다. 여기서 고려할 것은 프로그래머들의 지식을 이론으로 간주해야 한다는 것이다. Ryle(1949)의 관점에서 볼 때 이러한 이론을 가진 개인은 특정 업무의 실행 방법을 알고 있으며, 설명, 정당화, 질문에 대한 답변을 통해 실제 업무를 지원할 수 있다는 것이다. Ryle의 이론 개념은 K. Popper(Popper, and Eccles, 1977)가 구체화되지 않은 세계의 3객체라 칭한 사례로 나타나며, 그것으로 변론 가능한 철학적인 위치를 지니고 있다.

Ryle(1949)은 이론에 대한 개념을 지적 활동의 근본 분석의 일환으로 전개하였다. 특히, 지적 활동에서의 방식은 단지 지적이기만 한 활동과는 다르거나 혹은 그 이상이다. 지적 행위를 통해서 개인은 어떤 사실에 대한 특정한 지식이 아니라, 농담을 하고 즐기는 것, 문법에 맞게 이야기하는 것 또는 낚시와 같이 특정한 일을 하는 능력을 보여 주는 것이다. 더 나아가 이를 잘 실행하는 인간은 특정 기준에 따라 지적 실행을 부분적으로 특성화하기도 한다. 하지만 이런 기준을 적용하여 과실을 감지하고 수정하며 다른 사례로부터 배우는 능력을 보여 주기도 한다.

지식에 대한 이런 의견은 지적 행위가 개인의 규칙, 처방과 수단 등에 대한 추구와 고수에 따른다는 개념과는 별 관계가 없다는 사실을 알 수 있다. 반대로 규칙에 충실한 행동은 더욱 지능적일 수도 혹은 그다지 지능적이지 않을 수도 있다. 만일 지식 실천이 규칙 준수에 의해 좌우된다면 규칙 준수법과 같은 또 다른 규칙이 필요했을 것이다. 이는 엄청난 퇴보이며 낭비라고 할 수 있다.

무언가 지적인 행동을 하기 위해서 뿐만 아니라 그 행동을 설명하고 그에 대한 질문에 대답하며 또 이에 대한 논쟁을 위해 반드시 지니고 있어야 하는 것으로 지식을 간주할 때, 그저 지적이기만 한 행동 이상인 지적 행동을 특징짓는 것은, 개인이 이론을 구축하고 이를 소유하는 것이며, 이론을 쌓는 동안 그것을 소유하고자 노력하는 것이다.

여기서 사용하는 이론에 대한 개념은 전문 분야의 정교한 구조뿐만 아니라, 교육을 받은 개인이 특정한 상황에서 참여하게 될 활동에도 똑같이 적용된다. 가구를 어떻게 배치하고, 어떤 교통 수단을 이용하여 목적지까지 갈 것인가와 같은 평범한 일상 생활에서조차 이런 이론화 작업은 발생하게 된다.

여기서 사용하는 이론의 개념은 통찰력의 가장 일반적이거나 추상적인 부분으로 제한되어 있지 않다. 예를 들어, 뉴턴의 역학 이론을 여기서 말한 바와 같이 습득하려면, 힘은 질량과 속도의 곱이라는 것과 같은 기본적인 법칙을 이해하는 것만으로는 충분하지 않다. Kuhn이 상세히 기술한 것처럼, 이론을 갖춘 개인은 기본적인 법칙을 특정 상황에 적용하는 법을 이해하여 유사한 상황에서 이를 인식하고 적용할 수 있어야 한다. 이런 식으로 뉴턴의 역학 이론을 갖춘 개인은 이것을 진자와 행성의 운동에 적용하는 법칙도 이해해야 하고, 실생활에서의 유사한 현상에 대해서도 수학적으로 표현된 이론 규칙을 활용할 수 있도록 인식해야만 한다.

이론이 실생활에서 상황과 사건 사이의 유사성의 종류를 파악하는 데 종속되어 있다는 사실은, 왜 이론을 가진 사람이 지식을 규칙과 관련하여 설명할 수 없는지를 말해 주는 대목이다. 그렇기 때문에 이론을 가진 사람은, 사람의 얼굴, 선율, 와인 맛 등 다른 많은 종류의 객체 유사성만 표현할 수 있다.

프로그래머가 구축해야 할 이론

이론에 관한 Ryle의 개념에 따르면, 프로그래머가 구축해야 하는 것은 실생활의 특정 사건이 컴퓨터 프로그램에 의해 어떻게 처리(또는 지원)되는가에 대한 이론이다. 프로그래밍의 이론 구축 관점에서, 프로그래머가 구축한 이론은 프로그램 텍스트, 사용자 문서, 시방서와 같은 추가적 문서 및 기타 제작물보다 우위에 있다.

이론 구축 관점에 대한 논쟁에서의 기본적인 문제는, 프로그래머들이 본질적인 방법으로 소유한 지식이 어떤 방식으로 문서화된 기록을 뛰어넘는가를 증명하는 것이다. 이에 대한 해답은 프로그래머의 지식이 최소한 다음에 열거된 3가지 분야에서 문서화된 지식보다 앞선다는 사실이다.

  1. 프로그램에 대한 이론을 갖춘 프로그래머는 해결 방법이 실생활에서 발생하는 사건과 어떤 관련성이 있는지 설명할 수 있다. 이러한 설명은 포괄적 특성과 세부 사항에 있어서 실생활에서 발생하는 사건을 프로그램 텍스트 및 추가 문서로 표현하는 방법과 관련되어야 한다. 따라서 프로그래머는 프로그램 텍스트의 각 부분과 전체적인 구조 특성에 대해 말할 때, 실생활의 어떤 상황이나 행동이 이에 해당하는지 설명할 수 있어야 한다. 반대로 프로그래머는 실세계의 어떤 상황이나 행동에 대해서도 프로그램 텍스트로 매핑하는 법을 제시할 줄 알아야 한다. 물론, 너무 엄청난 상황이나 행동은 당연히 프로그램 텍스트 범위 이상의 것이므로 배제되어야 할 것이다. 세상의 일부만 관련 있는 결정이라 해도 세상 모두를 이해하는 사람만이 결정을 내릴 수 있다. 프로그래머는 이러한 이해에 기여해야 한다.
  2. 프로그램 이론을 갖춘 프로그래머는 프로그램의 각 부분이 무엇인지 설명할 수 있다. 즉, 어떤 종류의 정당화를 통해 실제 프로그램 텍스트를 지원할 수 있다. 정당화의 최종 기준은 항상 프로그래머의 직접적이고 직관에 의한 지식이나 평가이다. 정당화 과정에서 설계 규칙의 응용, 정량 평가, 대안과의 비교 등을 통해 추론을 이용할 때에도 원칙과 규칙의 선택, 현재 상황과 관련된 결정은 최종 분석에서 프로그래머의 직관적 지식의 문제로 남는다.
  3. 프로그램 이론을 갖춘 프로그래머는 실생활에서 발생하는 사건을 지원하는 프로그램의 수정에 대한 모든 요구에 새로운 방식으로 건설적인 대응을 할 수 있다. 기존의 프로그램에 어떻게 수정 사항이 잘 조화되도록 하는 가는 프로그램상에 이미 구축되어 있는 프로그램의 운영 편의성과 새로운 요구 사이의 유사성을 인지하는 데 달려 있다. 인지하는 유사성의 종류는 세상의 여러 측면 사이에 놓여 있다. 이는 실생활에 대한 지식을 가진 대리인, 즉 프로그래머에 의해서만 가능한 것이며, 위에서 설명한 프로그램의 정당성을 낮출 수 없는 것과 같은 맥락에서 어떤 기준이나 규칙의 제약으로 축소할 수 없다.

지금 논의하는 것이 프로그래밍의 이론 구축 관점을 채택하는 것에 대한 몇 가지 기본적인 근거를 보여 주고 있지만, 관점에 대한 평가가 어느 정도까지 프로그래밍 및 프로그래밍 문제의 논리적인 이해에 기여할 수 있는지 고려해야 한다.

프로그램 수정의 문제점과 비용

프로그래밍의 이론 구축 관점을 제안하는 가장 큰 이유는 프로그램 수정에 대한 온전한 이해를 뒷받침하기에 적합한 통찰력을 확립하는 데 있다. 따라서 이런 질문은 분석을 위한 첫 단계가 될 것이다.

대부분의 사람들은 소프트웨어가 수정된다는 사실에 동의할 것이다. 프로그램이 일단 실행되고 나면 머지않아 이것이 주어진 문제에 대한 해결책의 일부분에 불과하다고 느끼게 될 것이다. 또한 프로그램을 사용하다 보면 앞으로 프로그램이 제공해야 할 더 나은 서비스가 무엇인지 생각날 것이다. 그렇기 때문에 수정을 처리하는 방법이 필요한 것이다.

프로그램 수정 문제는 프로그램 비용과 밀접한 관련이 있다. 프로그램 운용에서 변화의 필요성에 직면한 사람은 새로운 프로그램을 구축하기보다는 기존 프로그램의 수성을 통해 비용을 절감할 수 있기를 바란다.

적은 비용으로 프로그램을 수정하는 것이 가능하리라는 기대에 대해서는 좀더 세밀한 분석이 필요하다. 첫째, 다른 사람이 만들어 낸 복잡한 구조물을 고치는 것으로부터 유추할 수 없다는 사실에 실망하게 된다는 것을 알아야 한다. 예를 들어, 건물의 경우 자주 고치게 되면 비용이 많이 들어간다. 사실 어떤 경우는 기존 건물을 완전히 허물고 아예 새로 짓는 것이 더 경제적일 수도 있다. 둘째, 적은 비용으로 프로그램을 수정할 수 있다는 가능성을 기대하는 것은 프로그램이 쉽게 편집될 수 있는 텍스트라는 단순한 생각에서 비롯된 것일 수도 있다. 비용의 대부분이 텍스트 수정에 관한 것이라면 이러한 생각이 옳을지도 모른다. 이것은 프로그래밍이 텍스트 제작이라는 개념과 일치하는 생각이다. 하지만 이론 구축 관점에서 이러한 주장은 전적으로 잘못된 것이다. 이런 관점에서는 저비용으로 프로그램을 수정하는 것이 불가능하다.

이 문제는 프로그램의 유연성과 좀더 밀접한 관련이 있다. 당장 필요하지는 않지만 곧 필요할 것이라고 판단하는 특정 운영상의 편의를 덧붙여 프로그램을 유연하게 하는 것이다. 이렇게 유연한 프로그램은 수정 없이도 외부 환경의 특정 변화를 처리할 수 있다.

변화하는 환경에 쉽게 적응할 수 있도록 유연성을 고려하여 프로그램을 설계해야 한다는 주장이 자주 등장하고 있다. 그와 같은 권고는 유연성이라는 것이 쉽게 얻을 수 있는 것이라면 일리가 있다. 하지만 일반적으로 유연성을 얻는 데에는 상당한 비용이 들어간다. 모든 아이템은 그것이 다루어야 하는 환경과 조절해야 하는 매개변수의 종류에 따라 설계되어야 하고, 그러고 나서 구현되고, 테스트되고, 기술되는 것이다. 그 유용성의 비용은 프로그램 특성을 얻는 데서 발생하는데, 그 유용성은 완전히 미래에 일어날 일들에 달려 있다. 내재된 프로그램의 유연성이 변화하는 환경에 프로그램을 적응시키고자 하는 일반적인 요구 사항에 대한 답이 아닌 것은 분명하다.

프로그램 수정에 있어서, 기존의 프로그램 솔루션은 해당되는 실생활의 변화에 맞도록 바뀌어야 한다. 수정 시 가장 중요한 것은 기존 솔루션과 수정 요구와의 대립이다. 이런 대립을 통하여, 기존 솔루션의 수용력과 새로운 요구 사항 간의 유사성의 정도와 종류를 결정해야 한다. 이론 구축 관점의 장점은 이런 유사성 결정의 필요성을 통해 나타난다. 유사성을 결정할 때, 어느 정도의 통찰력을 가진 개인들의 직접 참여 요구를 무시하는 관점은 결국 취약점으로 확연히 드러난다. 이를 판단할 기준이 공식화되어 있지 않기 때문에 규칙에 의해 걸정될 수 있는 범위에서 완전히 벗어나 있다 하더라도 프로그램 이론을 갖춘 사람들은 인식해야 할 유사성에 쉽게 접근할 수 있다. 프로그래머는 새로운 요구와 프로그램에 이미 흡족한 이들 사이의 유사성에 대한 통찰을 통해 수정에 필요한 텍스트 변화를 설계할 수 있다.

어떤 면에서는 이론 수정에 대해서는 의문이 없고 프로그램 수정에 대한 의문만 갖게 될 것이다. 다시 말해, 이론을 갖춘 개인은 벌써 그런 요구에 대응할 준비가 되어 있으므로 프로그램 수정만 필요할 것이다. 이런 관찰을 통해, 프로그램 수정의 문제는 프로그래밍을 이론 구축 활동의 산물로 인식하는 것이 아니라 프로그램 텍스트 제작으로 이루어진다는 가정에서 발생한다는 중요한 결론에 도달할 수 있다.

이론 구축 관점에서 보면, 프로그래머들이 기초 이론에 대한 제대로 된 이해 없이 프로그램을 수정한 결과 프로그램 텍스트가 쓸모 없게 되어버리는 현상을 이해할 수 있을 것이다. 사실, 단순하게 프로그램 텍스트의 변화나 실행의 외적 행동 변화로만 본다면, 주어진 수정 요구는 다양한 방법으로 모두 정확하게 이루어질 수 있다. 동시에 프로그램 이론과 관련하여 본다면 이러한 방법들은 서로 다르게 보여서 일부는 다른 나머지 이론에 완전히 모순되는 반면, 나머지는 이론에 순응하거나 자연스러운 방법으로 확장될 것이고 프로그램의 주요 부분에 통합되지 않은 부분적인 성격을 띨 것이다. 다양한 변화 특징의 차이는 프로그램 이론을 소유한 프로그래머만이 이해할 수 있다. 동시에, 프로그램 텍스트에 더해지는 변화의 특징은 프로그램이 얼마나 오래 살아남느냐 하는 문제에 부딪히게 된다. 프로그램의 품질을 유지하려면 모든 수정은 반드시 이론에 기초해야 한다. 단순성과 뛰어난 구조 등 품질의 의미는 프로그램 이론에 의해서만 이해될 수 있는데, 이는 품질이 동일한 실행 결과를 얻기 위해 작성된 다른 프로그램 텍스트와 연관된 실제 프로그램 텍스트를 특성화하기 때문이다. 하지만 이것은 프로그래머의 이해가 선행되어야만 가능하다.

프로그램 존속, 소멸 그리고 재생

프로그래밍의 이론 구축 관점의 주요 주장은 모든 프로그램의 핵심이 되는 부분을 도저히 표현할 수는 없지만 이것이 인간과 복잡하게 얽혀 있다는 것이다. 프로그램 상태를 기술할 때, 이론을 가진 프로그래머들이 이를 담당하는 정도의 표시가 중요하다는 것이다. 이러한 상황을 강조하는 방법으로, 프로그램 구축의 개념을 존속, 소멸 그리고 재생의 개념으로 확장하기도 한다. 프로그램 구축은 프로그래머 팀에서 프로그래머 팀이 이론을 구축하는 것과 같다. 프로그램의 존속 기간 동안 이 이론을 소유하는 프로그래머 팀은 프로그램의 적극적인 조정을 유지하고, 무엇보다 모든 수정에 대한 영향력을 갖게 된다. 프로그램의 소멸된 프로그래머 팀이 보유하고 있는 이론을 해제할 때 발생한다. 또한 소멸될 프로그램이 컴퓨터에서 계속 실행될 수도 있으며 유용한 결과를 낼 수도 있다. 프로그램 수정을 위한 요구에 지적으로 응답하지 않을 때 사실적 소멸 상태는 가시화된다. 프로그램의 재생은 새로운 프로그램 팀에 의한 이론의 재구축을 말한다.

이러한 개념에 따르면 프로그램 존속의 연장은 프로그램 이론을 새로운 세대의 프로그래머에게 인계하는 데 달려 있다. 새로운 프로그래머들이 기존 프로그램 이론을 갖기 위해서는 프로그램 텍스트나 다른 문서에 익숙해질 기회를 얻는 것만으로는 불충분하다.

정말 필요한 것은 새로운 프로그래머가 이론을 가진 이전의 프로그래머와 긴밀한 접촉을 통해 일할 수 있는 기회를 얻어, 실생활의 상황과 관련된 보다 넓은 문맥에서 프로그램 위치에 익숙해지고, 어떻게 프로그램이 작동하여 프로그램 이론 내에서 어떻게 비정상적인 프로그램 반응과 프로그램 수정을 처리하는지 그 방법에 관한 지식을 습득할 수 있게 하는 것이다.

기존 프로그램 이론에서 이러한 새로운 프로그래머들에게 실시되는 교육의 문제는 글을 쓰거나 악기를 연주하는 것 같은 특정 활동을 어떻게 실행할 것인가 하는, 지식이 특정 지식에 영향력을 행사하는 여타의 활동에서 발생하는 발생하는 교육적인 문제와 비슷하다. 가장 중요한 교육 활동은 학생들이 적절한 감독과 지도하에서 관련된 일을 실행하는 것이다. 프로그램의 경우, 프로그램과 실제 세계와 관련된 현상과 활동의 관계, 프로그램에 의해 다루어지는 실생활의 제약에 대한 논의 등을 포함해야 한다.

이론 구축 관점의 가장 중요한 결론은 문서만으로는 프로그램 이론을 재정립하는 프로그램 재생이 결코 이루어질 수 없다는 사실이다. 이런 결론에 부합하여, 완전히 소멸한 프로그램을 재생해야 한다는 필요성은 거의 언급되지 않는다. 그 이유는 원래의 팀이 가지고 있던 이론에 대해 최소한의 지식도 없는 새로운 프로그래머가 재생을 맡기란 불가능하기 때문이다. 비록 그것을 할 수 있다 해도 이론 구축 관점에서 볼 때, 프로그램 재생은 비용이 많이 들어간다는 사실을 분명히 인식하고, 극히 예외적인 상황에서 시도해야 하며, 프로그램의 저자가 원래 갖고 있던 것과는 다른 이론으로 재생될 수 있기 때문에 프로그램 텍스트와 모순될 수도 있다.

이론 구축 관점은 프로그램 재생 시 먼저 기존의 프로그램 텍스트는 버리고 새로운 프로그래머 팀이 새로운 문제를 해결할 수 있는 기회를 갖도록 해야 한다고 주장하고 있다. 그런 과정은 프로그램의 단순한 재생보다 좀더 실용적인 프로그램을 적은 비용으로 생산할 수 있게 해준다. 중요한 것은 기존 프로그램 텍스트에 마도록 뒷받침할 수 있는 이론을 세우는 것이 어렵고 그 결과는 실망스러우며 상당한 시간이 필요한 활동이라는 사실일 것이다. 새로운 프로그래머들은 불분명하고 약점이 남아 있더라도 기존 프로그램 텍스트에 대한 충실도와, 더 낫든 아니든 자신이 구축한 새로운 이론과 원래 이론의 차이점 사이에서 갈팡질팡할 것이다.

프로그래머 개개인의 능력과 경험의 차이로 인해, 특히 팀이 구성원을 어쩔 수 없이 대체한 경우 비슷한 문제가 프로그램 팀 내에 계속적으로 발생할 수 있다.

방법과 이론 구축

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

책/AgileSoftwareDevelopmentTheCooperativeGame (last edited 2024-11-18 16:25:47 by 정수)