익스트림 프로그래밍

위키백과, 우리 모두의 백과사전.
이동: 둘러보기, 검색
소프트웨어 개발 프로세스
활동과 단계
요구사항 분석 · 기능 명세
아키텍처 · 설계
구현 · 테스팅
배치 · 유지보수
개발 모형
애자일 소프트웨어 개발 · 클린룸
DSDM · 순차점증적 개발 · 반복형 개발
RAD · RUP · 나선 모형
폭포수 모델 · 익스트림 프로그래밍
스크럼 · V 모델 · TDD
지원 활동
구성 관리 · 문서화
품질보증 · 프로젝트 관리
사용자 경험 설계
도구
컴파일러 · 디버거 · 프로파일러
GUI 디자이너 · 통합 개발 환경
v  d  e  h

익스트림 프로그래밍(영어: eXtreme Programming, XP)는 켄트 백 등이 제안한 소프트웨어 개발 방법이다. 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다. 1999년 켄트 백의 저서인 'Extreme Programming Explained - Embrace Change'에서 발표되었다.

이 방법은 애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나로 꼽히며, 약칭인 ‘XP’로 잘 알려져 있다.

이 방법은 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 역할 통해서 테스트에만 집중을 할 수도 있다.

출처[편집]

  • Agile Software Development. 13 September 2012. 13 September 2012.
  • Artem, Marchenko. Agile Software Development.com. 16 November 2007. 18 September 2012. <http://agilesoftwaredevelopment.com/xp/practices/continuous-integration>.
  • Chaplin, Dave. XP Reflections-Test Driven Development. 16 September 2004. 10 September 2012. <http://www.byte-vision.com/XPReflectionsTestDrivenDevelopmentArticle.aspx>.
  • Code Refactoring. 4 September 2012. 18 September 2012.
  • EPF Wiki. 24 July 2007. 18 September 2012. <http://epf.eclipse.org/wikis/xp/xp/guidances/concepts/simple_design_63BCA71E.html>.
  • "Extreme Programming." 13 September 2012. Wikipedia. 13 September 2012.
  • "Extreme Programming and Agile Software Development Methodologies." 2003. xprogramming.com. 15 September 2012.
  • Industrial XP. 2004. Website. 2012.
  • James, Shore. The Art of Agile Development. O'Reilly Media, 2007.
  • Kent, Beck and Andres Cynthia. Extreme Programming Explained: Embrace Change, Second Edition. Addison Wesley Professional, 2004.
  • Pair Programming. 29 August 2012. 10 September 2012.
  • Robert, Martin C. Agile Principles, Patterns, and Practices in C#. Prentice Hall, 2006.
  • Ron, Jeffries, Anderson Ann and Hendrickson Chet . Extreme Programming Installed. Addison Wesley, 2000.
  • Small Releases. n.d. 23 September 2012.

외부 연결[편집]