책/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 는 타임 박스된 개발과 각 타임박스 이후(중반이 아니라)의 우선순위 재지정(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 을 인용하는 것을 좋아한다:

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

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

부록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