익스트림 프로그래밍 편집하기
IT위키
편집을 취소할 수 있습니다. 이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 게시해주세요.
최신판 | 당신의 편집 | ||
1번째 줄: | 1번째 줄: | ||
[[분류:소프트웨어 공학]][[분류:프로젝트 관리 | [[분류:소프트웨어 공학]][[분류:프로젝트 관리]] | ||
;eXtreme Programming; XP; XP 방법론 | ;eXtreme Programming; XP; XP 방법론 | ||
;[[애자일]] 방법론 중 하나로, 비즈니스 상의 요구가 시시각각 변동이 심한 소규모 프로젝트에 적합한 개발 방법론 | ;[[애자일]] 방법론 중 하나로, 비즈니스 상의 요구가 시시각각 변동이 심한 소규모 프로젝트에 적합한 개발 방법론 | ||
* 12개 정도의 구체적인 실천 방법(Practice)을 정의 | * 10~12개 정도의 구체적인 실천 방법(Practice)을 정의 | ||
* 짧은 주기로 여러번 고객에게 납품 반복 | * 짧은 주기로 여러번 고객에게 납품 반복 | ||
* 개발 문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시 | * 개발 문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시 | ||
24번째 줄: | 24번째 줄: | ||
== 절차 == | == 절차 == | ||
{| 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 | ; User Stories | ||
* 사용자 요구사항 / UML의 유스케이스와 | * 사용자 요구사항 / UML의 유스케이스와 같은 목적(요구사항 수집, 의사소통 도구) | ||
* 릴리즈 계획을 작성하기 위한 단위 | * 릴리즈 계획을 작성하기 위한 단위 | ||
* 기능단위로 필요한 내용을 간단하게 기재, 필요시 간단한 테스트 사항도 표기 가능 | * 기능단위로 필요한 내용을 간단하게 기재, 필요시 간단한 테스트 사항도 표기 가능 | ||
52번째 줄: | 63번째 줄: | ||
; Acceptance Test | ; Acceptance Test | ||
* 릴리즈 전의 인수 테스트. 고객이 수행 | * 릴리즈 전의 인수 테스트. 고객이 수행 | ||
=== 소규모 릴리즈 === | === 소규모 릴리즈 === | ||
63번째 줄: | 73번째 줄: | ||
[http://wiki.c2.com/?ExtremeProgrammingCorePractices 출처] | [http://wiki.c2.com/?ExtremeProgrammingCorePractices 출처] | ||
* '''Fine scale feedback''' | * '''Fine scale feedback''' | ||
** Pair Programming: 하나의 | ** Pair Programming: 하나의 컴퓨터에 2명의 프로그래머가 모든 코드를 코딩과 리뷰 역할을 바꿔가며 공동작업 진행 | ||
** Planning Game: 게임처럼 선수와 규칙, 목표를 두고 | ** Planning Game: 게임처럼 선수와 규칙, 목표를 두고 기획에 임하라 | ||
** Test Driven Development: | ** Test Driven Development: 실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드 작성 | ||
** Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 | ** Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴 | ||
* '''Continuous process''' | * '''Continuous process''' | ||
** Continuous Integration: 상시 빌드 및 배포가 가능한 상태로 유지 | ** Continuous Integration: 상시 빌드 및 배포가 가능한 상태로 유지 | ||
** Design Improvement: | ** Design Improvement: 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행 | ||
** Small Releases: | ** Small Releases: 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 함 | ||
* '''Shared understanding''' | * '''Shared understanding''' | ||
** Coding Standards: 표준화된 관례에 따라 | ** Coding Standards: 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성 | ||
** Collective Code Ownership: 시스템에 있는 소스코드는 팀의 모든 프로그래머가 언제라도 수정 | ** Collective Code Ownership: 시스템에 있는 소스코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정 가능함 | ||
** Simple Design: 가능한 가장 간결한 디자인 상태 유지 | ** Simple Design: 가능한 가장 간결한 디자인 상태 유지 | ||
** System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 | ** System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 기술 | ||
* '''Programmer welfare''' | * '''Programmer welfare''' | ||
** Sustainable Pace: 오버타임 | ** Sustainable Pace: 일주일에 40 시간 이상 작업 금지, 2주 연속 오버타임 금지 | ||
== | == 관련 링크 == | ||
* [http://www.extremeprogramming.org 공식 사이트] | * [http://www.extremeprogramming.org 공식 사이트] | ||
* [http://wiki.c2.com/?ExtremeProgramming 위키위키웹 XP 페이지] | * [http://wiki.c2.com/?ExtremeProgramming 위키위키웹 XP 페이지] |