설명
XP는 애자일 개발 방법론의 한 종류로서 1990년대 초 Kent Beck에 의해 고안되었다. 기존의 방법과는 달리 요구사항의 변경으로 인한 비용이 개발 기간에 상관없이 일정하게 유지되도록 하는 것이 핵심이다.
XP는 의사소통, 단순성, 피드백, 용기를 중시하는 개발 방법론이다. XP에서 프로그래머와 고객, 동료 프로그래머와의 의사소통을 중시하고, 설계를 단순하고 명확하게 유지하려고 하며, 비즈니스에서 가장 우선순위가 높은 것 부터 개발한다 이런 것은 고객의 요구사항과 기술의 변경에 대응할 수 있다.

XP는 2종류의 약속을 한다.
프로그래머에게 대해, XP는 프로그래머가 매일, 중요한 업무에 열중 할수 있도록 약속한다. 프로그래머는 불안한 상황에 자기 혼자만 직면하지 된다. 시스템을 성공 시키기 위해서, 자신의 힘으로 모든 할 수 있는 일을 할 수 있도록 된다. 최선을 위해서 결단을 내리고, 자신이 적임이지 않은 일에 관해서는 결정은 내리지 않는다.
고객과 매니져에 대해, XP는 매주마다 어느 프로그래밍으로부터 최고의 가치를 얻을 수 있다는 것을 약속한다. 수주간마다 골을 향해서 구체적인 진보가 보일도록 한다. 계획 외의 코스트가 생기지 않도록 하고, 개발 도중에서 프로젝트의 방향이 변하는 것이 가능하도록 한다.
다시 말해, XP는 프로젝트의 리스크를 줄이고, 비지니스 변화에 리스폰스(적응)를 개선 하고, 시스템의 가동기간(라이프)을 통해서 생산성을 향상시키고, 동시에 팀에게 소프트웨어를 만들때 기쁨을 느낄 수 있도록 약속한다.

역할
프로그래머
분석, 설계, 테스트, 코딩, 시스템 통합을 하며 업무에 대한 난이도 조정 및 시스템 관리를 한다.

관리자
고객과 프로그래머가 함께 일할 수 있도록 해준다. 프로잭트 총괄의 의미보다는 진행에 도움을 주는 역할을 한다.

고객
실제적으로 시스템에 대한 요구사항을 정의하고 우선순이를 설정한다. 고객이 필요한 범위를 결정하면 개발자는 개발을 한다.

관계도

XP의 12가지 실천사항
계획세우기: 고객이 요구하는 비즈니스 가치를 정의하고 개발자에게 필요와 어떤 부분이 지연될지 알려준다
소규모릴리즈: 작은 시스템을 만들고 단위별로 업데이트한다.
상징: 공통적인 이름 체계를 갖는다.
단순한 디자인: 현재의 요구사항에 맞는 단순한 시스템을 설계한다.
지속적인 테스팅: XP는 적합성을 중요시 여긴다.
리팩토링: 개발하는 동안 제품 설계를 향상시킨다.
짝프로그래밍: 개발자 두명이서 5분동안 번갈아가며 하나의 개발을 서로 쭉 내려가며 코딩한다.
공동 코드 소유: 누구나 코드 수정이 가능하며 그에 대한 책임도 공유한다.
지속적인 통합: 매일 여러번 소프트웨어를 통합하고 빌드한다.
주당 40시간의 업무: 피곤한 개발자가 실수를 더 많이하기 때문에 휴식을 보장한다.
현장 고객 지원: 의사소통을 향상시키고 문서양을 줄일 수 있다.
코딩 표준: 코딩 가이드라인을 작성하여 모두 가이드라인을 따른다.



좀 더 자세한 내용을 원한다면 아래 링크를 찾아가도록 하자
http://www.gpgstudy.com/gpgiki/eXtreme%20Programming%20explained

애자일 개발 프로세스의 개념
애자일 개발 프로세스란, 어느 특정 개발 방법론을 가리키는 말은 아니고, "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해주는 다양한 방법론 전체를 지칭하는 말이다. 예전에는 애자일 개발 프로세스는 "경량(Lightweight)"프로세스로 불렸다. 익스트림 프로그래밍 (XP:eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼수 있다.


애자일 개발 프로세스의 배경
애자일 프로세스의 배경에는 소프트웨어 개발 자체가 과거와 양상이 바뀌었다는 전제가 있다. 90년대 후반까지의 소프트웨어 개발은 장기간에 걸쳐 많은 사람들을 투입하고 충분한 비용을 투입하여 진행하는 것이었다. 소프트웨어 공학이나 많은 관리 방법론들이 모두 이러한 종류의 프로젝트를 대상으로 삼고 있다.

그러나 지금의 소프트웨어는 개발기간이 짧고 적은 비용을 투입한다. 게다가 매우 복잡하고 개방적이다. 또한, 사회의 상황이나 시장의 변동에 따라 변화가 심하고 요구사항도 시시각각 변해가고 있다. 그래서 이미 고전적인 소프트웨어 공학이나 관리 기법 만으로는 대처할수 없게 되었다.

이런 문제에 대한 기술적인 해결책으로 "객체지향(OO:Object Oriented)"이 있다. 객체지향 기술은 그동안의 개발 문제를 적절하게 대처해 주었다. 그리고, 객체지향 개발을 하기 위해서는 그에 적합한 개발 프로세스가 필요했다. 그래서 수많은 애자일 개발 프로세스가 이러한 필요에 따라 만들어졌다. 따라서, 애자일 개발 프로세스의 상당수는 객체지향 기술을 기반으로 한다.

애자일 개발 프로세스는, 제한된 시간과 코스트 안에서 정보는 불완전하고 예측은 불가능 하다는 전제를 가진다.그리고 그 전제아래에서 합리적인 답을 내도록 하는 것이 애자일 개발 프로세스이다.


애자일 개발 프로세스와 전통적인 개발 프로세스와의 차이
전통적인 개발 프로세스들은 폭포수 모델과 계획 기반 개발을 따르는 반면, 애자일 개발 프로세스는 그에 반한다는 점에서 가장 큰 차이를 가진다.
폭포수 모델과 계획 기반 개발 기법들은, 일련의 차례와 탄탄한 계획을 기반으로 하여 개발을 진행시킨다. 이것은, 이해하기도 쉽고 사용하기도 쉬운 바람직한 기법이기도 하지만, 이로 인해서 많은 부작용이 생길 수 있다. 가장 큰 부작용이 발생할 때는, 계획대로 진행되지 않을 경우이다. 이럴경우에는 다음과 같은 부작용이 발생하게 된다.

• 납기일 전 철야
• 철야에도 불구하고 납기일 지연
• 지연에 따른 비난과 스트레스가 개발자에게 향하여 에너지 소진
• 결국 납기된 솔루션은 고객의 요구를 충족하지 못함

이런 부작용은 근본적인 개발 프로세스 접근법의 차이에서 나타난다. 전통적인 개발 프로세스들은 공업에서 사용하는 정형적 프로세스 제어 모델을 따르고 있다. 정형적 프로세스 제어모델은, 동일한 입력에 대해서 동일한 결과가 기대 될 경우에 적합하다. 하지만, 소프트웨어를 포함한 IT의 개발은 경험적 프로세스 제어 모델로 접근할 필요가 있다. 경험적 프로세스 제어 모델은 항상 불확실성을 수반하고 포용하고 있다. 애자일 개발 프로세스는 경험적 프로세스 제어모델로 개발을 관리한다.


애자일 개발 프로세스의 종류
애자일 개발 프로세스로 불리우는 개발 방법론에는 다음과 같은 것들이 있다.

• 익스트림 프로그래밍, XP - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.

• 스크럼 - 30일마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.

• 크리스탈 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스탈 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.

• Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.

• Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용적으로는 다른 방법론들과 유사하지만, 합동 어플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는것이 조금 다르다.

• 익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 다만, 여타 모델링 방법들과는 달리, 항상 실행가능 하고 검증가능한 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.

Unified Software Development Process는 내가 본 책에서는 Lifecycle에서 다루고 있다. 어떤 곳에서는
Unified Software Development Process Model이라고 말한다.
범주로 보면 USDP는 객체지향 방법론 중 하나이다.

설명

USDP는 Jacobson, Booch, Rumbaugh에 의해 1999년에 개발되었다. 이 방법론은 소프트웨어 개발이 여러번 반복을 거쳐 수행된다. 근데 이 반복 안에는 요구사항 분석, 설계, 구현, 테스트 및 평가과정을 포함하고 있어서 자체로서 하나의 개발주기를 이룬다. 그렇기 때문에 큰 범위로는 개발방법론이며 작게는 Lifecycle로 표현하는 것 같다. 이런 반복적인 개발 방법에서는 반복마다 실행 가능한 릴리즈가 산출되고, 반복이 거듭될 수록 향상되어 최종 시스템으로 발전된다.

개발순서
Inception
고객과의 준비적 상호 작용 단계다. 요구사항 분석, 원형에 대한 설계, 구현이 이루어지는 단계이다.

Elaboration
요구사항 분석 및 아키텍처 확정 단계이다

Construction
기본 기능만 가진 제품 산출 단계로 주요 설계 및 구현을 수행한다.

Transition
제품 릴리즈 완성 단계로 구현 및 테스트를 수행한다.

장점
반복적인 개발 방법은 위험 요소를 초기에 발견할 수 있고 아키텍처에 대한 정의를 중요한 요소로 삼고 개발하기 때무에 이해가 쉽고 변경에 대한 관리가 용이하다.