생각하고 나누고 공감하기...

미투데이의 iron님의 글에서 자그마한 짝 프로그래밍 토론이 이뤄지고 있습니다.

제가 짝 프로그래밍 경험이 많은 것도 아니고 애초에 XP의 여러 프랙티스 중에서도 그리 신뢰를 하던 놈이 아니라서 열정적이지도 않습니다. 하지만, 설계 개념을 공유해야 하거나 기술을 전달해야 할 때, 또는 서로의 경험을 나눌 때에는 유용하다고 생각하여 의도적으로 지난 프로젝트에서 몇몇 사람을 붙잡고 (알게 모르게) 짝 프로그래밍을 시도해봤습니다.

결과는 상당히 긍정적이었습니다. 교육 효과도 좋았고 저 자신도 집중이 훨씬 잘 되었습니다. 오히려도움 받은 경우도 많았고요. 하지만 백일몽님의 말씀처럼 에너지 소모가 상당해서 제 경우 2시간을 넘기니 차크라가 바닥나더군요. 원인은 물론 말 때문이었습니다. 일을 하면서 계속 대화를 해야 하고 교육목적인 만큼 설계 의도를 미리 설명해줘야 부조정사가 잘 따라오는데 일을 하면서 말을 하는 것이 보통 어려운 것이 아니었습니다.

이 부분에서 예전에 시청했던 다큐멘터리의 내용이 생각나더군요. EBS의 동과서였는데 한·중·일을 중심으로 한 동양 사람과 북미를 중심으로 하는 서양사람의 사고방식이 어떻게 다른지 비교하는 내용이었습니다. 서양사람들은 자기 중심적이고 분석적인 반면 동양사람들은 관계 중심적이고 종합적이라고 하더군요. (간단한 요약이 있네요. 책으로도 나왔고요.)

다큐멘터리 내용 중 어떤 행동을 하면서 자기가 하는 일을 말로 중얼거리면서 하도록 했을 경우의 동과 서가 어떻게 다른지 비교하는 부분이 있었습니다. 서양 사람들은 자기의 행동을 말로 표현하면서 일을 했을 때 더 효과적으로 일을 할 수 있었습니다. 마치 마징가 같은 로보트 조종사가 다음에 어떤 공격을할지 말로 하는 것처럼 말이죠. ㅎㅎ

반면에 동양인은 자기 행동을 말로 표현하는데 무척 어려워했고 일 처리 능력도 현저하게 떨어졌습니다. 동양인은 자기 행동을 일일이 분석해서 말로 표현하는 일이 아주 낯선 일이라고 하더군요. 제 경험을 봐서도 이런 분석이 맞는 것 같습니다.

결국, 한국인이 짝 프로그래밍을 하는 데는 문화적인 장애가 있는 것이죠. 물론 장애는 극복할 수 있고 개인의 성향에 따라서 극복하는데 느끼는 어려움의 정도가 차이가 나리라 생각됩니다. 분명한 것은 짝 프로그래밍을 하려고 하거나 이를 보급하고 싶은 사람들은 이 점을 염두에 두고 추진해야 할 것이라 생각됩니다.

제 경우 짝 프로그래밍 수련의 방법으로 몇 가지 생각한 것은 다음과 같습니다.

1. 처음에는 짝 프로그래밍을 하루에 2시간 이상 하지 않는다.
   
2. 자기가 하는 일을 말로 표현하는 능력을 키운다.
   
3. 함축적으로 의사전달을 할 수 있는 환경을 조성한다.

1번이야 개인마다 가지는 차크라의 양이 다르니 수련 정도에 따라 알아서 할 일인듯 합니다. 최소 1주에 한두 시간은 짝 프로그램을 해서 점차 익숙해지도록 하는 것이 좋을 듯싶더군요. (물론 저는 모든 프로그래밍을 짝으로 해야한다고 믿는 수준은 아닙니다. 대략 저는 극단적인 것을 좋아하지 않습니다. ^^);;

2번은 Subversion이나 CVS 같은 SCM에 변경사항을 반영할 때 자기가 한 일을 잘 표현하는 실력부터 키우는 것이 좋을 것 같았습니다. CVS 같은 경우는 파일 단위로 관리가 되기 때문에 변경 작업을 파일 수준에서 표현하면 되지만 Subversion은 프로젝트 전체에서 자신의 작업이 어떤 의미가 있는지 표현할 수 있어야 하기 때문에 많이 도움이 되는 듯합니다.

3번은 패턴이나 개발 표준이 유용할 듯합니다. 디자인 패턴이나 구현 패턴같이 이미 발표된 것을 스터디하거나 개발팀 고유의 패턴을 도출해서 이를 공유한다면 더 적은 수의 어휘를 사용해서 정확히 의도를 전달할 수 있기 때문에 짝 프로그래밍을 할 때에 신경을 덜 쓰고 할 수 있을 것 같더군요. 개발 표준은 말할 필요도 없겠죠.

OpenUP를 한눈에 볼 수 있는 메트릭스를 한번 만들어 봤습니다.

OpenUP를 간단히 설명하면 Agile 선언의 정신을 반영한 Open Source 개발 방법론입니다. IBM에서 연구해서 이클립스 프로세스 프레임웍(EPF)를 통해 발표했습니다.

http://www.eclipse.org/epf/

OpenUP의 네가지 철학은 다음과 같습니다.

* Balance competing priorities to maximize stakeholder value / 고객의 가치를 극대화 하기 위해 경쟁하는 우선순위간의 균형을 맞춘다.
* Collaborate to align interests and share understanding / 관심사를 조정하고 이해를 공유하기 위해 협업한다.
* Focus on the architecture early to minimize risks and organize development / 리스크를 줄이고 개발을 체계적으로 하기 위해 초기부터 아키텍쳐에 촛점을 맞춘다.
* Evolve to continuously obtain feedback and improve / 지속적으로 피드백을 얻고 개선시키기 위해 진화한다.

위의 철학에서 애자일 선언을 어떻게 OpenUP의 언어로 표현했는지 한번 비교해 보시는 것이 좋을 듯 합니다.

OpenUP가 XP나 스크럼 보다 공부에 도움이 되는 것은 구체적인 프로세스와 산출물을 정의하고 있다는 것입니다. 이 프로세스들은 부족한 부분 없이 완전한 구성을 이루면서도 최소한의 구성 요소 만으로 되어 있고 필요에 따라 수정 할 수 있습니다.

openup_matrix.pdf

왼쪽에는 UP 특유의 네 반복이 있습니다. 물론 이들은 필요한 만큼 반복될 수 있습니다.
반복 안에는 활동(Activity)들이 있고 그 안에는 작업(Task)들이 있습니다.

또 상단 중간부는 UP에서 정의하고 있는 역할(Role)이 있습니다.
상단 오른쪽에는 UP에서 정의하고 있는 산출물이 있습니다.

이 메트릭스는 각 작업들이 어떤 역할과 산출물에 연관되는지를 보여줍니다.

Task와 'P' 관계인 역할은 이 작업을 주도해야 합니다.
'a' 관계인 역할은 해당 Task를 지원해야 합니다.

Task와 산출물의 관계에서 '<'는 필수 입력을 '>'은 출력을 '('는 선택 입력을 뜻합니다.

애자일 선언을 위키백과와 애자일 선언 홈페이지의 내용을 참고하여 번역해 올립니다.

http://en.wikipedia.org/wiki/Agile_Manifesto
http://agilemanifesto.org/

---------------

애자일 선언은 애자일 소프트웨어 개발의 토대를 강화하는 원칙을 발표한 것이다. 초안은 2001년 2월 11일에서 13일까지 유타의 워새치산맥에 있는 스노우버드 스키 리조트 라운지에서 만들어졌다. 여기에서 기존의 무거운 방법론보다 가벼운 대체방법론들의 필요성에 대해 토의하고자 Extreme Programming, Scrum, DSDM, AdaptiveSoftware Development, Crystal, Feature Driven Development, Pragmaticprogramming 같은 다양한 새 방법론의 대표자들이 만났다.

---------------

Manifesto for Agile Software Development
애자일 소프트웨어 개발을 위한 선언

We are uncovering better ways of developing software by doing it and helping others do it.
우리는 소프트웨어를 개발하는 더 나은 방법을, 그것을 실천하고 다른 이들이 이것을 하도록 도우면서 밝혀내 가고 있다.

Through this work we have come to value:
이 작업을 하는 동안 우리는 다음을 가치있게 여기게 되었다.

Individuals and interactions over processes and tools
프로세스나 도구에 앞서 개인과 상호 협력을

Working software over comprehensive documentation
종합적인 문서화에 앞서 작동하는 소프트웨어를

Customer collaboration over contract negotiation
계약 협상에 앞서 고객과의 협력을

Responding to change over following a plan
계획 준수에 앞서 변화에 대한 대응을

That is, while there is value in the items on the right, we value the items on the left more.
우리는 왼쪽 항목의 가치를 인정하면서도 오른쪽 항목을 더 중요하게 여긴다.

Kent Beck, Mike Beedle, Arie van Bennekum,
Alistair Cockburn, Ward Cunningham, Martin Fowler,
James Grenning, Jim Highsmith, Andrew Hunt,
Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber,
Jeff Sutherland, Dave Thomas

-----------------------------------------------------------------------------------
Principles behind the Agile Manifesto
애자일 선언의 배경 원칙들

We follow these principles:
우리는 다음 원칙들을 따른다:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
가치있는 소프트웨어를 조기에 그리고 지속적으로 인도하여 고객을 만족시키는 것이 우리가 가장 우선시 하는 것이다.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
개발 후반이라고 해도 요구사항의 변경을 환영한다. 애자일 프로세스는 변경을 고객의 경쟁적 우위로 삼는다.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
작동하는 소프트웨어를 수 주에서 수 개월의 주기로 자주, 가능한 더 짧은 기간에 인도한다.

Business people and developers must work together daily throughout the project.
프로젝트 기간 내내 업무 전문가와 개발자가 매일 함께 일해야 한다.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
동기부여된 개인을 중심으로 프로젝트를 구축하라. 그들에게 필요한 환경과 지원을 제공한다. 그리고 업무를 완수하도록 그들을 신뢰한다.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
개발팀에게 그리고 팀 내에서 정보를 전파하는 가장 효율적이고도 효과적인 방법은 얼굴을 대면하는 것이다.

Working software is the primary measure of progress.
작동하는 소프트웨어는 진도를 측정하는 제1 척도이다.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
애자일 프로세스는 지속할 수 있는 개발을 장려한다. 후원자들과 개발자들과 사용자들은 일정한 보폭을 끝까지 유지 할 수 있어야 한다.

Continuous attention to technical excellence and good design enhances agility.
기술적 탁월함과 좋은 설계에 대한 끊임없는 관심은 기민성을 강화시킨다.

Simplicity--the art of maximizing the amount of work not done--is essential.
단순함, 안 해도 되는 일은 최대한 안 하게 하는 기교, 이것이 핵심이다.

The best architectures, requirements, and designs emerge from self-organizing teams.
최고의 아키텍쳐와 요구사항과 설계는 자율적인 팀에서 나온다.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
팀은 정기적으로 어떻게 하면 더 효과적이 될 수 있을지 숙고하고 그에 따라 자신의 행동을 조율하고 수정한다.

--------

2009/3/11 : Toby님의 지적에 따라 잘못된 번역을 수정하고 몇몇 문장을 손 봤습니다.
2009/4/2 : 문서가 망가져서 일부 다시 번역했습니다.