Editing 익스트림 프로그래밍

[[분류:소프트웨어 공학]][[분류:프로젝트 관리]]
;eXtreme Programming
;[[애자일]] 방법론 중 하나로, 비즈니스 상의 요구가 시시각각 변동이 심한 소규모 프로젝트에 적합한 개발 방법론

* 10~12개 정도의 구체적인 실천 방법(Practice)을 정의
* 짧은 주기로 여러번 고객에게 납품 반복
* 개발 문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시

== 장단점 ==
* 장점
** 문서 작성 최소화로 개발 효율 증가
** 의사소통과 빠른 피드백을 통한 소프트웨어 품질 향상
* 단점
** 대규모 프로젝트엔 적용 어려움
** 참여하는 개인의 성향에 따라 프로젝트의 품질 차이 발생

== 핵심 가치 ==
[http://www.extremeprogramming.org/values.html 출처]
* '''용기''': 문서로 변명하기 보단 진실되고 용기있게 개발
* '''존중''': 개발자의 역량을 존중하고 충분한 권한과 권리 부여
* '''의사소통''': 이해관계자 모두가 팀원이라는 생각으로 모든 사항 공유
* '''피드백''': 의사소통에 따른 즉각적인 피드백
* '''단순성''': 필요한 것은 하지만 더이상은 하지 않음

== 절차 ==
{| class="wikitable"
|   User Stories
|   ▶
| rowspan="2" |   Release Planning
| rowspan="2" |   ▶
| rowspan="2" |   Iteration
| rowspan="2" |   ▶
| rowspan="2" |   Acceptance Test
| rowspan="2" |   ▶
| rowspan="2" |   Small Release
|-
|   Architectural Spike
|   ▶
|}
=== 사용자 스토리 ===
; User Stories
* 사용자 요구사항 / UML의 유스케이스와 같은 목적(요구사항 수집, 의사소통 도구)
* 릴리즈 계획을 작성하기 위한 단위
* 기능단위로 필요한 내용을 간단하게 기재, 필요시 간단한 테스트 사항도 표기 가능
* 시스템을 사용하는 고객이 필요한 것이 무엇인지를 기술 → 인수테스트시 사용

=== 구조적 스파이크 ===
; Architectural Spike
* 어려운 요구사항 혹은 잠재적인 솔루션들을 고려하기 위해 작성하는 간단한 프로그램
* 사용자 스토리의 신뢰성을 증대시키거나 기술적인 문제의 위험을 줄이고자 하는데 목적

=== 릴리즈 계획 ===
; Release Planning
* 전체 프로젝트에 대한 배포 계획을 생성

=== 반복 ===
; Iteration
* 하나의 반복을 1에서 3주 정도로 나누고 반복들을 프로젝트 전반에 균일하게 유지
* XP의 반복은 프로세스의 평가와 계획을 단순하고 신뢰성 있게 만드는 핵심 항목 → 반복 계획 미팅
* 사용자 요구사항 변경, 기술적인 문제 등 상황에 따라 릴리즈 및 반복 계획 수정 가능

=== 인수 테스트 ===
; Acceptance Test
* 릴리즈 전의 인수 테스트. 고객이 수행

=== 소규모 릴리즈 ===
; Small Release
* 작은 배포는 XP 주기의 마지막 단계
* 소규모로 빈번하게 배포하면 고객에게 여러 가지 이득을 조기 제공
* 프로그램은 빠른 피드백을 제공 받음

== 12가지 실천사항 ==
[http://wiki.c2.com/?ExtremeProgrammingCorePractices 출처]
* '''Fine scale feedback'''
** Pair Programming: 하나의 컴퓨터에 2명의 프로그래머가 모든 코드를 코딩과 리뷰 역할을 바꿔가며 공동작업 진행
** Planning Game: 게임처럼 선수와 규칙, 목표를 두고 기획에 임하라
** Test Driven Development: 실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드 작성
** Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴
* '''Continuous process'''
** Continuous Integration: 상시 빌드 및 배포가 가능한 상태로 유지
** Design Improvement: 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행
** Small Releases: 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 함
* '''Shared understanding'''
** Coding Standards: 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성
** Collective Code Ownership: 시스템에 있는 소스코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정 가능함
** Simple Design: 가능한 가장 간결한 디자인 상태 유지
** System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 기술
* '''Programmer welfare'''
** Sustainable Pace: 일주일에 40 시간 이상 작업 금지, 2주 연속 오버타임 금지

== 관련 링크 ==
* [http://www.extremeprogramming.org 공식 사이트]
* [http://wiki.c2.com/?ExtremeProgramming 위키위키웹 XP 페이지]]