익스트림 프로그래밍: Difference between revisions
From IT위키
No edit summary |
(→인수 테스트) |
||
(7 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
[[분류:소프트웨어 공학]][[분류:프로젝트 관리]] | [[분류:소프트웨어 공학]][[분류:프로젝트 관리]][[분류:애자일]] | ||
;eXtreme Programming; XP; XP 방법론 | ;eXtreme Programming; XP; XP 방법론 | ||
;[[애자일]] 방법론 중 하나로, 비즈니스 상의 요구가 시시각각 변동이 심한 소규모 프로젝트에 적합한 개발 방법론 | ;[[애자일]] 방법론 중 하나로, 비즈니스 상의 요구가 시시각각 변동이 심한 소규모 프로젝트에 적합한 개발 방법론 | ||
* | * 12개 정도의 구체적인 실천 방법(Practice)을 정의 | ||
* 짧은 주기로 여러번 고객에게 납품 반복 | * 짧은 주기로 여러번 고객에게 납품 반복 | ||
* 개발 문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시 | * 개발 문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시 | ||
Line 24: | Line 24: | ||
== 절차 == | == 절차 == | ||
[[파일:익스트림 프로그래밍 절차.png]] | |||
=== 사용자 스토리 === | === 사용자 스토리 === | ||
; User Stories | ; User Stories | ||
* 사용자 요구사항 / UML의 유스케이스와 | * 사용자 요구사항 / UML의 유스케이스와 다르지만, 요구사항 수집, 의사소통 도구라는 점이 공통점 | ||
* 고객과 커뮤니케이션을 이어나가기 위한 수단 | |||
* 릴리즈 계획을 작성하기 위한 단위 | * 릴리즈 계획을 작성하기 위한 단위 | ||
* 기능단위로 필요한 내용을 간단하게 기재, 필요시 간단한 테스트 사항도 표기 가능 | * 기능단위로 필요한 내용을 간단하게 기재, 필요시 간단한 테스트 사항도 표기 가능 | ||
Line 63: | Line 52: | ||
; Acceptance Test | ; Acceptance Test | ||
* 릴리즈 전의 인수 테스트. 고객이 수행 | * 릴리즈 전의 인수 테스트. 고객이 수행 | ||
* 이터레이션 초기에 테스트를 작성한 후 코딩 작성 | |||
=== 소규모 릴리즈 === | === 소규모 릴리즈 === | ||
Line 73: | Line 63: | ||
[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: 오버타임 지양 | ||
== 기출 문제 == | |||
* [http://q.fran.kr/문제/8141 공무원 9급 전산직(전산개발)] | |||
== | == 참고 문헌 == | ||
* [http://www.extremeprogramming.org 공식 사이트] | * [http://www.extremeprogramming.org 공식 사이트] | ||
* [http://wiki.c2.com/?ExtremeProgramming 위키위키웹 XP 페이지] | * [http://wiki.c2.com/?ExtremeProgramming 위키위키웹 XP 페이지] |
Latest revision as of 16:31, 21 December 2020
- eXtreme Programming; XP; XP 방법론
- 애자일 방법론 중 하나로, 비즈니스 상의 요구가 시시각각 변동이 심한 소규모 프로젝트에 적합한 개발 방법론
- 12개 정도의 구체적인 실천 방법(Practice)을 정의
- 짧은 주기로 여러번 고객에게 납품 반복
- 개발 문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시
장단점[edit | edit source]
- 장점
- 문서 작성 최소화로 개발 효율 증가
- 의사소통과 빠른 피드백을 통한 소프트웨어 품질 향상
- 단점
- 대규모 프로젝트엔 적용 어려움
- 참여하는 개인의 성향에 따라 프로젝트의 품질 차이 발생
핵심 가치[edit | edit source]
- 용기: 문서로 변명하기 보단 진실되고 용기있게 개발
- 존중: 개발자의 역량을 존중하고 충분한 권한과 권리 부여
- 의사소통: 이해관계자 모두가 팀원이라는 생각으로 모든 사항 공유
- 피드백: 의사소통에 따른 즉각적인 피드백
- 단순성: 필요한 것은 하지만 더이상은 하지 않음
절차[edit | edit source]
사용자 스토리[edit | edit source]
- User Stories
- 사용자 요구사항 / UML의 유스케이스와 다르지만, 요구사항 수집, 의사소통 도구라는 점이 공통점
- 고객과 커뮤니케이션을 이어나가기 위한 수단
- 릴리즈 계획을 작성하기 위한 단위
- 기능단위로 필요한 내용을 간단하게 기재, 필요시 간단한 테스트 사항도 표기 가능
- 시스템을 사용하는 고객이 필요한 것이 무엇인지를 기술 → 인수테스트시 사용
구조적 스파이크[edit | edit source]
- Architectural Spike
- 어려운 요구사항 혹은 잠재적인 솔루션들을 고려하기 위해 작성하는 간단한 프로그램
- 사용자 스토리의 신뢰성을 증대시키거나 기술적인 문제의 위험을 줄이고자 하는데 목적
릴리즈 계획[edit | edit source]
- Release Planning
- 전체 프로젝트에 대한 배포 계획을 생성
반복[edit | edit source]
- Iteration
- 하나의 반복을 1에서 3주 정도로 나누고 반복들을 프로젝트 전반에 균일하게 유지
- XP의 반복은 프로세스의 평가와 계획을 단순하고 신뢰성 있게 만드는 핵심 항목 → 반복 계획 미팅
- 사용자 요구사항 변경, 기술적인 문제 등 상황에 따라 릴리즈 및 반복 계획 수정 가능
인수 테스트[edit | edit source]
- Acceptance Test
- 릴리즈 전의 인수 테스트. 고객이 수행
- 이터레이션 초기에 테스트를 작성한 후 코딩 작성
소규모 릴리즈[edit | edit source]
- Small Release
- 작은 배포는 XP 주기의 마지막 단계
- 소규모로 빈번하게 배포하면 고객에게 여러 가지 이득을 조기 제공
- 프로그램은 빠른 피드백을 제공 받음
12가지 실천사항[edit | edit source]
- 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: 오버타임 지양