비즈니스 요구에 빠른 대응의 가능한, XP(eXtreme Programming)

XP는 스크럼(Scrum)과 쌍두마차격인 애자일(Agile) 방법론이다. 비즈니스 상의 요구가 시시각각 변동이 워낙 심하다보니 기존의 개발방법론으로는 현재의 흐름을 제대로 대응하기 힘들었고, 그래서 나온 것이 XP 방법론이다. XP는 켄트 백이 1999년에 "Extreme Programming Explained - Embrace Change" 라는 저서로 발표하였고 이후 XP라는 약칭으로 알려지게 된다.

XP는 구체적인 실천 방법들을 정리해 놨고, 이 방법론은 적은 규모의 개발 프로젝트에 적용하기 좋다. 기존의 일반적인 산출물보다 소스코드를 조직적인 행동보다는 개개인의 행동과 책임 등을 중점을 둔다.

초창기에는 4가지의 가치를 추구했던 것으로 사료된다. "What Is Xp" 문서를 보면 단순성, 소통, 피드백, 용기 네가지로 가치를 추구한다고 나와있고, What Is Xp 문서 안에 있는 '마소 용어 사전 vol 2'의 내용을 보더라도 

익스트림 프로그래밍(XP)은 최근 개발방법론 중에서 급부상하고 있는 애자일 소프트웨어 개발론(Agile Software Development)의 하나로, 단순성, 상호소통, 피드백, 용기 등의 원칙에 기반해서 "고객에게 최고의 가치를 가장 빨리" 전달하도록 하는 경량 방법론이다. 요구사항 등의 변화가 자주, 많이 있거나 개발자가 소규모(10명 내외)이고 같은 공간을 사용하는 경우에 높은 효과를 볼 수 있다고 알려져 있고, 다른 규모나 원거리 XP 등의 적용이 꾸준히 시도되고 있다. --김창준

위와 같이 4가지의 가치만 나와 있다. 아마도 "존중(Respect)" 은 이후에 XP가 버전업 되면서 추가된 것으로 사료된다. 

---

Agility를 강조하는 애자일 방법론, XP의 개요

XP(eXtreme Programming) 방법론의 개념

- 짧은 주기의 Iteration을 통해 요구 변화에 신속하게 대응하여 고품질 S/W를 빠르게 전달하는 Agile 방법론

XP의 필요성

- 신속한 개발 : RUP의 산출물 부담으로 신속한 개발 불가

- Time To Market : 빠른 시장 대응 능력 향상, 적시 배포

- 유연한 대처 : 프로세스 중심의 전통 방법론으론 빠른 시장 대응 미비

XP의 특징

- 개발자, 관리자, 고객의 조화로 개발 생산성을 높인다

- 고객 요구사항 변경에 적극적이고 긍정적으로 대응한다

농담삼아, XP를 비롯한 Agile은 이미 우리가 하고 있는 방식이다라는 말을 하다. 대기업 중심적인 한국 사회에서 고객의 요구사항에 적극적이고 긍정적으로 대처를 못할 경우 '을'인 입장의 회사에서는 회사를 운영하는데 힘이 들테고, 산출물을 외국보다 적게 쓰는 한국 입장에서 애자일 방법론은 이미 예전부터 하고 있던 방식이다라는 농담까지 나올 정도이다. 단지 소통이라는 관점이 고객과는 소통이 잘 되지만 관리자와 개발자가 잘 안되고 있는 것이 문제인데 수평적인 외국의 문화가 수직적인 한국의 문화 사이에 괴리감이 있는 것은 사실이다.

XP의 개념도 및 구성요소

XP의 개념도

- User Story를 바탕으로 우선순위별 일정을 수립 후

- 일정한 단위 프로그래밍의 소규모 배포를 추구

XP의 구성요소

사용자 스토리(User Story)

- 사용자 요구 사항 / UML의 Use Case와 같은 목적 (요구사항 수집, 의사소통 도구)

- 릴리즈 계획을 작성하기 위한 단위

- 기능단위로 필요한 내용을 간단하게 기재, 필요 시 간단한 테스트 사항도 표기 가능

- 시스템을 사용하는 고객이 필요한 것이 무엇인지를 기술 → 인수테스트시 사용

아키텍처 스파이크(Architectural Spike)

- 어려운 요구사항 혹은 잠재적인 솔루션들을 고려하기 위해 작성하는 간단한 프로그램

- 사용자 스토리의 신뢰성을 증대시키거나 기술적인 문제의 위험을 줄이고자 하는데 목적

배포 계획(Release Planning)

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

반복(Iteration)

- 하나의 반복을 1에서 3주 정도로 나누고 반복들을 프로젝트 전반에 균일하게 유지

- XP의 반복은 프로세스의 평가와 계획을 단순하고 신뢰성 있게 만드는 핵심 항목 → 반복 계획 미팅

- 사용자 요구사항 변경, 기술적인 문제 등 상황에 따라 릴리즈 및 반복 계획 수정 가능

승인 테스트(Acceptance Test)

- 릴리즈 전의 인수 테스트. 고객이 수행

소규모 배포(Small Release)

- XP 주기의 마지막 단계

- 소규모로 빈번하게 배포하면 고객에게 여러 가지 이득을 조기 제공

- 프로그램은 빠른 피드백을 제공 받음

기립회의(standup meeting)

- 전체 팀원들 사이의 의사소통으로 현재의 문제점 해결책 등을 논의하고 팀이 초점을 잃지 않도록 하기 위해 사용

XP의 핵심가치 및 실천 사항

가. 5가지 핵심가치 

• 용기(Courage) : 고객의 요구사항 변화에 능동적인 대처
• 단순성(Simplicity) : 부가적 기능, 사용되지 않는 구조와 알고리즘 배제
• 커뮤니케이션(Communication) : 개발자, 관리자, 고객 간의 원활한 의사소통
• 피드백(Feedback) : 지속적인 테스트와 통합, 반복적 결함 수정, 빠른 피드백
• 존중(Respect) : stakeholder는 팀원의 기여를 존중하여 SW 개발 생산성과 인간성을 동시 개선

나. 실천 사항

1) Fine Scale Feedback

Test Driven Development

- 개발자 먼저 단위 테스트, 실제 코드를 작성하기 전에 먼저 작성함으로써 자신이 무엇을 해야 하는지 스스로 깨우침

- 고객은 기능 테스트를 작성하여 요구사항이 모두 반영되었는지를 확인

Planning Game

- 사용자 스토리를 이용해서 다음 릴리즈의 범위를 빠르게 결정, 비즈니스 우선순위와 기술적 평가가 결합

Whole Team

- 개발 효율성을 위해 고객을 프로젝트에 상주시킴

- 고객은 스토리를 명확하게 해주고, 중요한 비즈니스 결정사항에 대해 명확한 답을 제공해주는 역할

Pair Programming

- 두 사람이 함께 프로그램(Driver/Partner)

- 모든 프로그래밍은 하나의 컴퓨터에 2명의 프로그래머가 같이 공동작업 진행

2) Continuous Process

Continuous Integration

- 컴포넌트 단위로 혹은 모듈 단위로 나누어서 개발된 소스코드들은 하나의 작업이 끝날 때 마다 지속적으로 통합되고 동시에 테스트된다.

Design Improvement

- 프로그램 기능은 변경 없이 중복/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 통해 시스템 재구성

Small Release

- 필요한 기능들만 갖춘 간단한 시스템을 빠르게 릴리즈, 고객이 소프트웨어가 어떻게 돌아가는지 아주 짧은 (2주) 사이클로 볼 수 있도록 자주 새로운 버전 배포 유지

3) Shared Understanding

Simple Design

- 당장 필요하지 않은 디자인 배제

- 항상 가능한 가장 간결한 디자인 상태 유지

System Metaphor

- 공통의 name system (의사 소통 및 공통 개념 공유)

- 전체 개발 프로세스에 걸쳐서 시스템의 동작에 대한 전체 그림을 표현하는 것으로, 이해하기 쉬운 스토리로 이루어짐

Collective Code Ownership

- 팀의 모든 프로그래머가 소스코드에 대해서 공동 책임을 지는 것으로, 시스템에 있는 코드는 누구든지 언제라도 수정 가능함

Coding Standard

- 팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화된 관례에 따라 작성되어야 함

4) Programmer Welfare

Sustainable Pace

- 일주일에 40 시간 이상을 일하지 말도록 규칙으로 정하고 2주를 연속으로 오버타임 하지 않도록 함

5) Coding

• 고객은 항상 이용할 수 있음
• 단위 테스트를 먼저 수행
• 한 번에 한 쌍만 코드를 통합
• 마지막까지 최적화 유지
• 초과 근무 없음

6) Test

• 모든 코드에는 단위 테스트가 존재 해야 함
• 모든 코드는 출시되기 전에 단위 테스트를 통과해야 함
• 버그가 발견되면 버그가 해결되기 전에 테스트 생성
• Acceptance Test가 자주 실행되고 결과를 게시

스크럼과의 비교

XP와 스크럼은 둘다 애자일을 대표하는 방법론으로 자주 비교되는 대상이다.

구분	SCRUM	XP
형태	- 개발 프로세스를 위한 프레임워크 - 관리 및 조직적 실천법에 집중	- 엔지니어링 방법에 초점 - 프로그램 실천법에 집중
개발주기	4~6주	1~2주
요구사항 변경	- Sprint 내의 요구사항 변경은 수용 불가 - 변화를 빨리 발견하며 처리하는 관점	- 리팩토링을 통하여 요구사항 변경을 수용 - 요구사항 변경은 당연히 발생한다는 개념
우선 순위 결정	- Team이 개발 우선순위 결정	- Customer가 개발 우선순위를 결정

- 둘다 Agile 방법론으로서 짧은 개발 주기로 반복적으로 개발하는 공통점을 가지고 있음

기존 개발방법 문제점 해결방법 및 고려사항

기존 개발방법의 문제점 해결을 위한 XP 전략

구분	내용
관리측면	결정은 분산화, XP관리도구로 메트릭 이용, 코칭/트래킹/조정
계획측면	팀이 개발한 SW의 가치를 최대화, 임베디드 소프트웨어 가능한 적게 투자하고, 빠르게, 가장 가치 있는 기능 부여
설계측면	의사소통을 통하여 설계, 중복된 코드가 없을 것 -> 가장 단순하게 개발 가능한 클래스와 메소드 들은 적게 만들 것 -> 변경에 유연
개발측면	지속적인 통합, 수정, 테스트, 배포 복잡한 코드 제거, Pair 프로그램으로 완벽한 코딩
테스트측면	각 테스트는 다른 부분과 관련이 없어야 함 -> 테스트 자동화 테스트 프로그램 만드는 주체는 프로그래머
기타	계획세우기, 작은 시스템 릴리즈, 메타포 등 12가지 실천사항 병행

도입시 고려사항

구분	고려사항	대응방안
재무관점	- 요구사항이 빈번히 변경되어 프로젝트의 전체 규모와 예산 수립이 어려움	- 소규모 릴리즈가 반복되므로 사용자 스토리당 개발기간 예측 및 관리 필요
고객관점	- 공감대 형성이 부족할 경우 개발 생산성 저하	- 구동하는 S/W를 고객에게 자주 전달하여 고객의 요구사항 신속 적용으로 고객만족, 결함감소
내부관점	- 대규모 프로젝트 수행이 어려움	- 중소형 프로젝트나 대규모 프로젝트 일 경우 서브 프로젝트나 태스크 단위로 선택 적용
학습 및 성장	- S/W 품질수준이 낮고, 산출물의 범위 변경이 불가능한 경우 적용이 어려움	- 사용자나 개발자가 정확한 요구사항 도출이 힘들 때 적용, 잠재적 가치 생성
	- 개발자에게 Refactoring, Design Pattern 등 기술요소에 대한 높은 숙련도 요구	- 구성원들의 XP에 대한 충분한 이해와 공감 - PM의 적극적인 방법론 실행 의지 필요

XP의 적용방안 및 활용분야

XP의 적용방안

- TDD (Test Driven Development)와 결합하여 품질 향상 및 고객의 요구사항 만족도 향상

- 초기 고객 거부감을 고려 조직문화와 성격에 따라 변형 사용

- 프로젝트 전반부는 RUP로 중반부는 XP를 따르는 Hybrid가 효율적

XP 활용분야

- 모바일 시장과 쇼핑몰처럼 사용자의 변화에 따라 단기간에 민첩하게 변화되어야 하는 분야

- 개발자가 소규모(10명 내외)이고 같은 공간을 사용하는 경우에 높은 효과 발생.

- 요구사항 변경이 잦거나 신기술 도입, 또는 요청된 최종 형태가 명확하지 않은 경우

참고문헌

What Is Xp

https://en.wikipedia.org/wiki/Extreme_programming

https://www.researchgate.net/figure/Extreme-Programming-Project-process-flow-chart-1_fig1_267865511

https://blogs.msdn.microsoft.com/jmeier/2014/06/06/extreme-programming-xp-at-a-glance-visual/

연관 토픽 및 문서

SDLC, 애자일(Agile), 스크럼(Scrum), 칸반(Kanban)

소프트웨어 공학의 패러다임, SDLC

Sprint를 활용한 대표적인 Agile 방법론, 스크럼(SCRUM)

적시 개발(Just In Time)을 지원하는 칸반(Kanban) 방법론