익스트림 프로그래밍

eXtreme Programming; XP; XP 방법론

애자일 방법론 중 하나로, 비즈니스 상의 요구가 시시각각 변동이 심한 소규모 프로젝트에 적합한 개발 방법론

• 12개 정도의 구체적인 실천 방법(Practice)을 정의
• 짧은 주기로 여러번 고객에게 납품 반복
• 개발 문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시
• 이름의 익스트림(eXtreme)은 코드 리뷰, 테스트, 단순한 설계처럼 좋다고 알려진 상식적인 원리와 경험을 극한까지 끌어올려 적용한다는 뜻이다
• 기존의 무거운 방법론에 비해 실용성(Pragmatism)을 강조한다. 사용자의 요구사항은 언제든 변할 수 있다고 보고, 고객과 직접 대면해 사용자 스토리(User Story)로 요구사항을 주고받는다
• 테스트를 생략하는 방법론이 아니다. 코드를 짜기 전에 단위 테스트를 먼저 작성하는 테스트 주도 개발과 고객의 인수 테스트를 반복마다 하고, 지속적 통합으로 늘 테스트를 돌린다
• 애자일 방법론에 속한다. 폭포수 모형처럼 단계별로 문서를 만들어 가는 구조적 방법론이 아니다

장단점

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

핵심 가치

출처

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

절차

사용자 스토리

User Stories

• 사용자 요구사항 / UML의 유스케이스와 다르지만, 요구사항 수집, 의사소통 도구라는 점이 공통점
• 고객과 커뮤니케이션을 이어나가기 위한 수단
• 릴리즈 계획을 작성하기 위한 단위
• 기능단위로 필요한 내용을 간단하게 기재, 필요시 간단한 테스트 사항도 표기 가능
• 시스템을 사용하는 고객이 필요한 것이 무엇인지를 기술 → 인수테스트시 사용

구조적 스파이크

Architectural Spike

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

릴리즈 계획

Release Planning

• 전체 프로젝트에 대한 배포 계획을 생성

반복

Iteration

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

인수 테스트

Acceptance Test

• 릴리즈 전의 인수 테스트. 고객이 수행
• 이터레이션 초기에 테스트를 작성한 후 코딩 작성

소규모 릴리즈

Small Release

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

12가지 실천사항

출처

• 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: 가능한 가장 간결한 디자인 상태 유지. 지금 구현하는 기능에 필요한 만큼만 설계하고, 앞으로 필요할 것 같은 기능이나 확장 지점을 미리 넣지 않는다. "언젠가 필요할 것"이라 짐작한 기능은 대개 필요 없다는 YAGNI(You Aren't Gonna Need It)가 이 실천을 가리키는 말이다
    • 그래서 "설계를 간결하게 유지해 미래의 잠재적 변경에 대비한다"는 설명은 틀린다. 미래의 변경은 미리 대비하지 않고, 실제로 필요해졌을 때 리팩토링으로 설계를 고쳐 받아들인다
  • System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 조망
• Programmer welfare
  • Sustainable Pace: 오버타임 지양

기출 문제

• 공무원 9급 전산직(전산개발)

참고 문헌

• 공식 사이트
• 위키위키웹 XP 페이지