IT산업의 활성화에 따라 여기저기서 IT 프로젝트들이 수십개씩 새롭게 쏟아져나오고 있다. 이 프로젝트들은 보통 크고 작은 팀을 이루어서 진행하게 되는데, 프로젝트를 개발하고 진행하는 과정에도 이론이 있는 법이다.

이 책은 흔히 말하는 IT 프로젝트의 개발 방법론이라고 할 수 있는 책인 것 같다.

개인적으로 개발자이면서도 개발 방법론에 대해서는 그다지 깊게 알고 있는 바 없이,시키는대로 작업을 해오기 일쑤였기에(대개의 프로젝트에서 초급 개발자의 역할은 별 생각없이 PM이 짜 준 스케쥴대로 개발진행하는 것이 일반적이므로...) 이 책을 통해서 개발에 대한 새로운 인식이 생겨나는 느낌을 얻을 수 있었다.

두명씩 짝을 지어 코딩을 하는 방법이나, 완벽한 설계에 집착하기 보다는 소규모로 단위테스트를 신속하게 진행하여 수행할 프로젝트를 보다 더 빠르게 가시적으로 확인할 수 있도록 개발을 진행하는 방식은 굉장히 획기적인 것이라고 한다.(그래서 '익스트림'이라는 표현을 썼다고도 하는데...)

이 방법론으로 진행한 프로젝트 개발에서 여러 성공사례를 확인한 사람들은 요즘 적극적으로 이 XP(익스트림 프로그래밍의 약어)를 도입하고 있다고 한다.

그러나 개인적으로 이 책을 감명깊게 읽었던 이유는 단순한 개발 방법론만을 이론적으로 제시한 책이 아니라, 개발과 관련된 근본적인 철학을 함께 제시하고 있기 때문이다.

인간성, 상호신뢰, 반성, 책임, 개선...개발의 가장 기초가 되는 것은 바로 이러한 인간적인 덕목이라고 이 책은 설명하고 있다.

그래서 머리로 개발 방법에 대한 지식을 새기기 위한 책일 뿐아니라, 개발자로서 지켜야할 자세를 가슴에 새기기 위한 책이기도 하다.

XP를 통해 개발자가 지켜야 할 자세와 성공적인 개발을 위한 효율적인 방법을 함께 배워보자~

익스트림 프로그래밍의 창시자 켄트 벡이 직접 저술한 익스트림 프로그래밍(이하 XP)의 바이블 같은 책입니다.

이 책과 더불어 유명한 책인 익스트림 프로그래밍 인스톨드(이하 XPI)와는 달리 원론적인 이야기들이 많이 기록되어 있습니다. 따라서 처음 XP를 접하거나 XP를 처음 시작한 지 얼마 되지 않은 분들이 보기에는 살갑게 다가오지 않는 면들이 조금 있습니다.

오히려 처음 접하는 분들은 이 책 대신 론 제프리가 저술한 XPI를 먼저 읽어보시길 권유해 드립니다. 어느 정도 XP에 대해 실천적인 면들이 익숙해진 후에 이 책을 읽으면 XP의 본질과 철학, 그리고 탄생에 대해 더 깊은 이해를 가지게 될 것입니다.

익스트림 프로그래밍 : 변화를 포용하라 2판.

2007.03.18에 구입해서 시간이 좀 흐른후 읽기 시작했는데

다 읽은 날은 2008.07.27. ㅋㅋㅋ 약 1년을 읽었나부다.

CMMI 포럼 세미나 갔다가 agile 방법론과 김창준 대표에게

확~ 반해서 바로 구입한 책이었는데

이상하게 손이 잘 안가서 읽다 말다 읽다 말다...

다 읽었는데 너무 오래되서 앞부분 내용이 기억이 안난다. ^^;;;

책을 좀 규모 있게 읽게 있어야 겠다.

agile 방법론과 XP 에 관한 이야기를 듣고 들은 생각은

오... RUP 과 유사한데 가볍게 나왔구나.

이렇게 생각한 이유는 iteration 때문이었다.

근데 iteratin은 agile이나 XP의 특징이라고 보기 어렵다.

고로 내가 잘못생각한거징. ㅋㅋ

XP에 관한 기본서로 딱 좋은 책이다.

pair programming, story, incremental, iteration..

책의 자세한 내용이나, XP, Agile에 관한 내용은

수많은 블로그에 이미 요약이 참 잘되어 있으니까

구지 내가 요약할 필요는 없을거 같다.

다만, 한번 XP를 적용한 프로젝트에서 일해보고 싶다.

몸으로 행동하는 것 만큼 강하게 느끼고 접해볼 수 있는건 없으니까

그 유명한 켄트 벡의 역작 중 하나!

리팩토링, 유닛 테스트, 게임 등 코딩, 프로그래밍 개발에 있어 모든 좋은 것들을 가장 쉽게 확인하고 즐기게 해주는 프로그래밍 "라이프 스타일"에 관한 책이다. 물론 모든 사람들이 이 스타일에 맞을 수 없지만 프로그래머라면 한번 쯤 알아둘만하다. 단점이라면 켄트 벡이 워낙 강력하게 특정 유형의 개발자가 되라고 요구하기 때문에 맞지 않는다면 거부감이 강하게 들 수 있다는 것과 책이 조금 지루할 수 있다는 것.

소프트웨어 엔지니어링이 전산학의 한 분야로 올라오게 된 가장 큰 원인은 바로 "소프트웨어의 위기"의식 때문이었습니다. 

사실, 소프트웨어의 위기라는 것이 절대적인 개념으로서 존재하는 것이 아니라, 하드웨어의 성장과 비교해봤을때 위기라는 것이었지요. 

60년대 중반 "무어의 법칙" 같은 것들이 이야기 되면서, 하드웨어는 눈부신 성장 속도를 보여주고 있었지만, 그에 비해 소프트웨어는 이전과 별 변함없이 개발되고 사용되었습니다. 

그래서, "왜 소프트웨어는 하드웨어처럼 발전하지 못하는가?"에 대한 의문에 대한 답변으로 소프트웨어 엔지니어링을 연구하기 시작했지요. 

초창기에는 기존 공학분야에서 사용되는 개발 방법론을 잘 차용해서 소프트웨어 개발에 적용시키려고 했었습니다. 

그 대표적인 방법이 "폭포수 모델"로 전 공학 분야에서의 프로젝트 진행의 기본 모델로 사용되고 있습니다. 

- 요구사항 분석 -＞ 설계 -＞ 개발 -＞ 테스트 및 디버깅 -＞ 설치 -＞ 유지보수

의 과정은 건축, 기계 설비, 제품 생산, 소프트웨어 개발을 비롯한 모든 공학 분야에서의 결과물 도출 과정이기도 합니다. 

하지만, 소프트웨어에서만큼은 이 방법이 제대로 동작하지 못했지요. 

그 근본적인 원인은 바로, 이 순차적인 과정이 실제로는 순차적으로 진행되지 않는다는 것, 즉 프로젝트 진행의 불확실성이 유독 소프트웨어에서는 심하기 때문이었습니다. 

건물에 뼈대를 올리는 와중에, "어이, 설계도가 변경되었으니, 지금까지 했던거 부수고 다시 만들자!" 라는 말을 하는 사람은 없지만, 

소프트웨어를 개발하는 와중에 "아, 그 기능 필요없으니까 빼고, 새로 이 기능 넣도록 하자" 라는 말은 수도 없이 들려오지요. 

이 변화, 실제 소프트웨어가 완성되기 직전까지 계속해서 바뀌는 요구사항들을 관리하기 위해, 폭포수 모델을 기반으로 여러 다른 방법들이 제시되었습니다. 

가령, 나선형 모델, 프로토타입 모델, 카오스 모델, V 모델, 에자일 모델.. 등등이 그렇지요. 

이 책은 에자일 방법론의 대표적인 실천 방법으로서의 익스트림 프로그래밍 방법을 설명하고 있습니다. 

그렇다면, 에자일 방법이 무엇인지 먼저 알아봐야겠지요. 

에자일 방법은 폭포수 모델의 실패 원인인 "끊임없는 요구사항의 변화"를 회피해야 하는 요소로 생각하지 않고, 그것을 적극적으로 응대하기 위한 방법입니다. 

즉, "프로젝트가 종료되기 전까지 계속해서 변하는 것은 당연하다. 그렇기에, 처음에 미리 전체 프로그램에 대한 설계를 완성시키고 그것으로 개발하는 것은 당연히 실패할 수 밖에 없다." 라는 가정위에서 탄생한 개발방법론입니다. 

그래서, 짧은 결과물 도출 시스템을 기반으로 (요구사항의 변경이 발생하기 이전에, 이미 결과물을 하나 만들자, 그러면, 그 결과물에 기반해서 요구사항의 변화를 조절할 수 있고, 그렇게 되면, 기 완성한 부분을 폐기해야 하는 경우를 줄일 수 있다는 개념입니다) 전체 프로젝트를 작은 단위(스토리 단위)로 나눠, 팀 구성원을 하나의 유기체로서 같이 개발해 나가는 식으로 동작합니다. 

익스트림 프로그래밍(XP)는 이를 위한 하나의 실천 방법론으로, 에자일 모델이 지향하는 

1)팀원들 사이의 의사소통, 

2)결과물의 단순성(추후 유지보수를 위함)

3) 피드백 (동적으로 발생하는 요구사항 변화에 능동적으로 대처하기 위함) 

4)용기 (생소한 기법이라도 적극적으로 도입하고, 프로젝트 수행시 발생하는 위기 상황에 좌절하지 않기 위함)

와 같은 가치들을 실제 프로젝트 진행과정 속에서 얻어내기 위한 방법들로 이루어져 있습니다. 

XP의 대표적인 방법들은 

1) 함께 앉기

2) 짝 프로그래밍

3) 스토리 단위의 요구사항

4) 짧은 주기별 반복 개발 (이터레이션 이라고도 하죠)

5) 10분 빌드

6) 지속적 통합

7) 테스트 우선 프로그래밍

8) 점진적 설계

// 중복되는 내용에 대해서는 과감하게 생략했습니다 

등이 있고 이외에 보조 실천방법으로 

1) 진짜 고객 참여

2) 점진적 배치

3) 팀 지속성 및 팀의 크기 줄이기

4) 코드 공유

5) 코드와 테스트

6) 단일 코드 기반

7) 매일 배치

8) 범위 협상 계약

등등의 방법들이 있습니다만, 중요한 것은 이들을 그대로 사용한다고 XP를 적용했다는 것이 아니라는 것입니다. 

이 실전 방법들은, 이전에 말했던 에자일 방법의 4가지 가치를 실제 개발 환경에서 드러내도록 하기 위한 수단일 뿐이지요. 

프로젝트를 진행함에 있어서, 1)팀 구성원들 사이의 인간적인 관계, 2) 프로젝트의 경제성 (프로젝트의 성공 및 적절한 품질에 대한 책임), 3) 참여자들 사이의 상호 이익, 4) 실패 속에서 배우고 성장하기 (이를 위한 반성과 신뢰) 등을 잃지 않는다는 원칙에 따라서, 주어진 가치를 실현하기 위해 노력하다 보니, 제시된 XP 실천 방법들이 효과적이었다는 것이지, 이 실천 방법을 따르면 당연히 이런 가치들이 원칙 안에서 드러나는 것은 아니라는 것이지요. 

200페이지를 겨우 넘는 이 책이 XP와 에자일 방법에 대한 모든 것을 설명해주지는 않습니다만, 다만 XP가 가지고 있는 이상에 대해서는 충분히 잘 설명하고 있다고 생각됩니다. 

프로젝트에 실패하고, 왜 실패했을까를 고민하는 사람들에게 추천할 만한 책이라고 생각됩니다. 

재미있기도 하고요. 

하지만, 혹시 입으로만 컨설팅 하는 가짜 전문가에게 당한 적이 있는 사람이라면, 이 책은 나쁜 기억만을 들추지 않을까 싶기도 합니다. 

어떻게 보면 이 책은 에자일 모델과 그 실행 방법으로서의 XP에 대한 소개이며 에자일이 제시하는 소프트웨어 위기의 해결 방법에 대한 뜬구름 같은 이야기일 뿐이기도 하기 때문입니다. 

개발방법에 대한

책은 지금까지 참 많이 읽은거 같다.

예전엔 이렇게 하는게 있구나 하고 읽었었고..

어느정도 경험이 쌓인 후엔

이론적인 내용으로 생각을 했었다.

[우리나라와는 맞지 않다고 생각햇으므로..]

이번에 읽으면서는

왜 해외에서 넘어오기만 할까 하는 생각을 하게 되었다.

우리나라 상황에 맞는 개발방법론이 분명 있을텐데..

혹은

이러한 XP 사상을 따르는

우리나라에 맞는 방법들도 많을텐데..

하는 생각들이 든다.

항상

프로젝트를 다니다보면

외국에서 유명하다는 개발방법론을..

우리나라 상황에 맞추려고는 하지 않고

그중 괜찮다는것만 짜집기해서

무슨 방법론 이라고 이름까지 지어가지고 하는 경우가 종종 있었다.

예전에 CBD 개발방법론이 무슨 마술인것처럼 떠들썩할때는..

개발기간이 9개월중 1개월이 개발이었다.

8개월이 문서작업으로 일정이 잡혀있는걸 보고 어찌나 놀랐던지

좋다는 방식은 다 집어넣고 개발기간은 오히려 줄여버린거다.

-_-;;

어쨋든

여러 개발방법론들이 있지만

그 주된 목적은 프로젝트의 성공적인 결말에 있고

그에 따른 여러가지 상황에 맞는 방법들이 있다고 생각한다.

우리나라 현실과 맞아떨어지는 기본 틀이 있을것이고

그 기본틀에 상황에 따라 상황에 맞는 방식을 사용하면

그게 좋은 방법론이 아닐까 싶다.  

이 책 또한 그러한

방법들 중 xp 방법론 에 대한 책이고

이 책에서도

XP 의 줄기에서 상황에 따른 유연성을

얘기하고 있다.  

저자는 오래전에 XP 방법론에 대해서 다루고

그 XP 방법론으로 지금까지 해온 경험을 바탕으로

다시 XP 방법론에 대해서 다시 바라보며

이 책을 썼다고 한다.

물론 팀에서의 개발방법에 대해서 도 좋겠지만

개인적인 개발을 할때에도 좋은 방법들이 아닌가 싶다.

다른 여타 방법론에 대한 책들이

방법론에 대해서 강조하는 내용이 많은데 반해

이 책은 XP 방법론에 대한 내용도 있지만

그에 따른 사상도 볼 수 있어

좋았던거 같다.

XP의 주창자인 켄트벡이 쓴 익스트림 프로그래밍 개정판이다.

애자일 기법의 하나인 익스트림 프로그래밍에 대해 태동부터 발전과정, 실 적용사례등에 대해 특별한 형식없이 두서없이 적어놓은 책이다.

이 책은 제1부 XP 탐험하기와 제2부 XP의 철학이라는 두 파트로 구성되어 있는데, 제 2부는 익스트림 프로그래밍 실무에 관한 설명이라기 보다는 익스트림 프로그래밍이 탄생할 수 있도록 저자에게 영감을 준 이론적인 토대에 대한 내용이 장황하게 적혀있다.

흔히들 XP를 얘기할때 짝 프로그래밍, 테스트 주도개발, 점진적 설계등을 얘기하는데 이 책에서 그 각각에 대한 구체적인 실천 방법을 배우기에는 무리가 있을것이다.

저자의 설명대로 애자일 기법, 특히 익스트림 프로그래밍에 관해서 만큼은 어느것이 정답이라는 명확한 정답이 없기 때문이다.  각 프로젝트의 특징에 맞게 XP의 철학을 적용하는 능력, 이것이야 말로 저자가 주창하는 XP의 실체가 아닐까 한다.

개인적으로는 무척 지루하게 읽었던 책이다.

여러 전문가들의 극찬에도 불구하고 웬지 앙꼬없는 찐빵을 먹었다는 느낌을 지울 수 없었다.

요즘 스크럼에 재미를 붙여서 그런건지는 몰라도 일단 스크럼과 별다른 차이점을 느낄수가 없었고, 짝 프로그래밍이나 테스트 우선 프로그래밍 같이 바로 실무에 활용할 수 있는 XP의 특징들에 대한 설명에 실무적인 깊이가 없었다고 할까..

시간이 좀 넉넉할때 천천히 음미하면서 읽게되면 좀 다른 향기가 나는 그런 유형의 책이 아닐까??

저도 컴퓨터 업계에 종사하는 입장에서 항상 아쉬운 점이 있습니다.

번역의 질인데. 마찬가지로 번역서인 만큼 한국어로 번역하는 부분이 매끄럽지

못한것같습니다. 원래 영어로 된것을 한국어로 옮기다 보니 힘드점도 많지만,

항상 아쉽군요.

중간에 의역부분을 읽고 이해못하는 부분이 많군요...쩝.