위키백과

익스트림 프로그래밍

익스트림 프로그래밍(영어: eXtreme Programming, XP)는 켄트 백 등이 제안한 소프트웨어 개발 방법이다. 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다.Programming Explained - Embrace Change'에서 발표되었다. 애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나로 꼽히며, 약칭인 'XP'로 잘 알려져 있다.

익스트림 프로그래밍의 계획 및 피드백 루프
소프트웨어 개발 프로세스
활동과 단계
요구사항 분석 · 기능 명세
구조 · 설계
구현 · 테스팅
배치 · 유지보수
개발 모형
애자일 소프트웨어 개발 · 클린룸
DSDM · 순차점증적 개발 · 반복형 개발
RAD · RUP · 나선 모형
폭포수 모델 · 익스트림 프로그래밍
스크럼 · V 모델 · TDD
지원 활동
구성 관리 · 문서화
품질보증 · 프로젝트 관리
사용자 경험 설계
도구
컴파일러 · 디버거 · 프로파일러
GUI 디자이너 · 통합 개발 환경

10~12개 정도의 구체적인 실천 방법(Practice)을 정의하고 있어, 비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋다. 개발 문서 보다는 소스코드를, 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 두는 경향이 크다.

켄트 백은 XP를 이끄는 가치와 원칙에 대해서도 강조했다. XP에서 실천 방법에만 집중하고 가치와 원칙을 무시하면 제대로 XP를 실천하고 있다 하기 힘들 것이다. 원칙은 가치와 실천 방법을 잇는 다리 같은 것이다.

XP의 목적은 '고객이 원하는 양질의 소프트웨어를 빠른 시간안에 전달하는 것'이다. 수시로 발생하는 고객의 요구사항에 대처하고, 고객이 원하는 SW를 고객이 원하는 시간에 인도하기 위해서는 고객과 팀원간의 대화를 통해 해결한다.

다른 애자일 방법론과 구분되는 XP만의 특징에는 테스팅이 있다. XP는 프로그래머들이 코딩을 할때에 테스트 코드를 작성하도록함과 동시에 테스트를 기반으로 프로젝트를 완성시켜 나가도록 한다. 또한 이러한 테스트에 기반을둔 프로젝트 발전 과정은 애자일 방법론의 기본 개념인 "반복적으로 프로토 타입을 고객에 전달함으로써 고객의 요구사항 변화에 민첩하게 대응한다"를 실천하는데에 큰 도움을 줄 수 있다. 왜냐하면 매번 프로토 타입을 고객에 전달함에 있어서 프로토 타입 자체로써 버그가 상대적으로 적은 완벽에 가까운 데모를 경험하게 해줄 수 있기 때문이다.

가치 편집

  • 의사소통
  • 단순성
  • 피드백
  • 용기
  • 존중

원칙 편집

  • 인간성
  • 경제성
  • 상호이익
  • 자기 유사성
  • 개선
  • 다양성
  • 반성
  • 흐름
  • 잉여
  • 실패
  • 품질

실천 방법 편집

Whole Team 편집

애자일 방법론과 XP 방법론이 많이 사용되기 이전에는 팀을 기반으로한 소프트웨어 개발이 흔치 않았다. 그렇기 때문에 개발자들과 프로젝트에 참여하는 관리자 모두 이러한 방법론에 대해서 진지하게 생각을 하지 않고 있었다. 그래서 고전적인 소프트웨어 개발 방법론인 폭포수 모델과 나선 모형에서는 수많은 소프트웨어 개발의 실패를 불러오기도 했다. 하지만 애자일 방법론 및 XP 방법론이 유명세를 타기 시작하면서 팀을 기반으로한 협동적인 개발 방법론이 강조되기 시작했다. 그러므로, 첫 번째 실천 방법인 Whole Team 은 모든 프로젝트에 참여하는 팀원들을 가리키며 개개인이 각자의 역할이 있고 그들의 역할의 중요성을 이야기 한다. XP에서 말하는 Whole Team은 일반적으로 tester, interaction designers, architects, project managers, product managers, executives, technical writers, programmers and users 로 구성이 된다. 이들 중에서 가장 중요한 팀원은 사용자(user)이다. 왜냐하면 그들이 프로젝트의 키를 가지고 있는(stakeholder)일 뿐만 아니라 그들을 통해 요구사항(requirement)을 파악 할 수 있기 때문이다.

Planning Game 편집

XP에서 계획을 세우는데에는 중요한 2가지가 있다. 첫 번째, 이번 반복(iteration)에는 어떤 개발 과정을 끝마칠 것인가. 두 번째, 그 이후 개발 반복(iteration)에서는 무엇을 할것인가이다. XP는 일반적으로 2주를 주기로 계획을 세우고 프로토 타입을 만들어서 최종 사용자 혹은 프로젝트를 의뢰한 의뢰인과 함께 무엇이 얼만큼 개발이 되었는지 혹은 알맞은 방향으로 개발이 진행이 되어가고 있는지 검사 혹은 회의를 한다. 그렇기 때문에 그 기한안에 프로젝트 혹은 프로토 타입은 반드시 개발이 완료가 되어야 하며, 그렇지 못해서 기한을 연장하게 되면, 그에따른 추가 비용및 시간적 손실이 발생하게 된다. 또한, 이를 통해서 소프트웨어 개발의 투명성을 확보 할 수가 있다. 기업의 입장에서 좋은 점은 그들의 실력및 가능성을 보여줄수 있는 기회로 사용될 수 있으며, 사용자 혹은 의뢰인 입장에서는 더욱 큰 금전적 손실이 발생하기 전에 프로젝트를 취소하고 다른 개발팀을 찾아 볼 수 있는 기회로 사용될 수도 있다.

Customer Tests 편집

가장 흔히 발생하는 소프트웨어 개발 실패중 하나는 개발이 끝난 제품 혹은 소프트웨어가 처음 사용자 혹은 의뢰인이 원했던것과 다르다는 것이다. 그렇기 때문에 XP에서는 반복적으로 커스토머 테스트를 거친다. 그리고 이를 통해서 그들이 잘못 이해하고 있었던 부분에 대해서 수정을 거치기도 하며 더욱더 의뢰인 혹은 최종 사용자의 요구에 부합하는 소프트웨어를 만들어 내게 된다.

Small Releases 편집

이 실천 방안을 통해서 개발자는 주기적으로 프로토 타입을 의뢰인에게 보여준다. 그리고 이를 통해서 의뢰인은 제한된 기능을 가지고 있지만 실제로 작동이 되는 데모 모델을 볼 수가 있으며 추가 사항을 요구할 수도 있다. 기존의 혹은 과거의 소프트웨어 개발 과정에서 개발이 끝나기 이전에 어떤 소프트웨어가 만들어질지 알 수 없었던 것과 비교해서 가장 차이점을 만들어내는 실천 방안이다. 또한 개발자에게 있어서는 현재까지의 개발 상황이 올바른 길로 가고 있음을 알 수 있다.

Simple Design 편집

보통의 프로젝트 개발 혹은 코딩의 경우 기능이 더해지면 더 해질 수록 복잡해 지기 마련이다. 그렇게 되면, 새롭게 충원되는 개발자의 경우에 현재까지의 개발 상황을 이해하는데 오랜 시간이 걸리게 된다. 또한 버그가 발생할 경우에도 쉽게 처리를 하지 못하고 오랜 시간이 걸리게 된다. 그렇기 때문에 XP에서 모든 코딩을 가능한 간단하게 할 것을 강조한다. 이러한 추세 혹은 트렌드는 KISS 원칙 원리와도 함께 한다고 할 수 있다.

Test-Driven Development 편집

테스트를 기반으로한 개발은 XP에서 가장 중요한 실천 방안중 하나이다. 테스트를 거치고 코딩을 하며 프로젝트를 개발해 나간다.

Pair Programming 편집

두명 혹은 그 이상의 프로그래머가 함께 코딩을 하는 것을 말한다. 두명의 프로그래머가 함께 코딩을 하고 테스트를 통해서 개발을 할 수도 있고, 한명은 코딩을 하고 한명은 Quality Assurance 역할 통해서 테스트에만 집중을 할 수도 있다.

출처 편집

외부 링크 편집

 
위키미디어 공용에 관련된
미디어 분류가 있습니다.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=익스트림_프로그래밍&oldid=32940708"