Extreme Programming(XP)

전통적인 소프트웨어 개발 방법론과는 달리 문서를 강조하지 않고 변경을 장려하며, 개발 초기부터 테스트를 병행할 것을 강력히 권고하는 새로운 방법론이다. 1996년 켄트 백(Kent Back)과 워드 커닝험(Ward Cunningham)은 함께 다임러 크라이슬러 프로젝트를 진행하면서 새로운 소프트웨어 개발 방법을 정리하게 되는데, 그것이 XP 방법론이다. XP는 고객이 원하는 소프트웨어를 고객이 원하는 시기에 제공하는 것을 목표로 하며, 프로젝트 막바지에도 나올 수 있는 요구사항 변경에 더욱 잘 대처할 수 있도록 한다.

- XP 개발자들은 고객 및 동료 개발자들과 의사소통을 잘 해야 한다.

- 개발하는 소프트웨어에 대해 개발 첫 날부터 유닛 테스트를 통해 피드백을 받는다.

- 개발 중인 시스템을 최대한 빨리 고객한테 보여줌으로써 고객들이 원하는 변경 사항을 빨리 도출할 수 있도록 한다.

XP는 애자일 방법론(agile methodology) 가운데 하나다. 애자일 방법론은 고객에게 고객이 원하는 소프트웨어를 빨리 전달하는 것을 목표로 한다. 1~3주 내에 구현할 수 있는 수많은 요구사항(유저 스토리) 가운데 고객이 가장 중요하게 생각하는 것을 먼저 구현하며 시간이 모자라면 유저 스토리 가운데도 고객이 가장 중요시하는 과제를 먼저 구현한다.

프로젝트가 예측한 시일 안에 끝날 수 있도록 1~3주마다 진행상황을 점검하고 다음 1~3주 동안 할 일을 계획한다.(주기 계획 회의). 유닛 테스트를 통해 구현된 코드가 유저 스토리를 만족한다는 것을 확인고. 유닛 테스트를 이용함으로써 틈틈이 리팩토링을 통해 코드의 질도 높인다.

XP의 정의

- 단순성, 의사소통, 피드백, 용기 등 네 가지 가치를 매우 중요하게 생각하는 소프트웨어 개발방법론 중 하나

- 고객에게 최고의 가치를 가장 빨리 전달하도록 하는 것을 최고의 가치로 여김

XP의 출현 배경

- 현재의 SW 개발 과정에서 자주 발생되고 있는 문제점 극복 대안

- 급변하는 환경에서 SW를 빨리 개발할 필요 목적으로 설계

XP의 특징

- 다른 개발 방법론이 분석, 설계 중심의 형식적인 방법론인 반면 XP는 프로그램 개발에 모든 것을 집중

- 고객, 관리자, 프로그래머 각각의 역할에 초점을 맞춰 각 역할에 적절한 권리와 의무를 부여해 전체적인 맥락 속에서 성공적인 소프트웨어를 개발할 수 있도록 유도

- 요구사항 많거나 잦은 변화가 예상되는 위험부담이 큰 프로젝트를 하는 경우에 개발자가 소규모(10명 내외)이고 같은 공간을 사용하는 경우에 높은 효과가 있음

XP의 주요 개념

1. Pair Programming – 한 사람은 코딩을 하고 한 사람은 옆에서 로직을 보고 조언을 하며 도와주는 파트너가 됨 à 프로그램에 대한 이해도가 높아져 생산성이 향상됨

2. Small Release – 데모 수준이 아닌 실제 시스템/제품 릴리즈 기간을 최소화하도록 함

3. Refactoring – 사용하지 않는 기능을 제거하고 코드의 구조를 개선시켜나가는 과정을 수행/Code 정비를 통해서 이해 및 확장을 쉽게 함

4. Continuous Integration – 특정한 시점까지 기다리는 것이 아니라 하루에도 몇 번씩이라도 통합을 하면서 테스트를 수행

5. Test Driven Development – 개발이 들어가기 전 먼저 테스트 프로그램을 개발함 그렇게 되면 자기가 개발하게 될 프로그램의 기능이 명확해지고 빠른 개발이 가능하게 됨

XP Practices

• 제인 안쪽에 있는 원은 개인의 실천사항을 표현

• 중간의 원인 팀원간의 실천사항을 표현

• 제일 바깥의 원은 전체 프로젝트에서 일어나는 실천사항을 표현

1. 계획 세우기(Planning Game) – 우선순위와 기술사항 고려 범위 결정

2. 작은 시스템 릴리즈(Small Release) – 짧은 사이클로 버전 발표

3. 은유(Metaphor) – 전체 시스템에 대한 은유 공유

4. 단순한 설계(Simple Design)

5. 테스팅(Customer Tests) – 단위 테스트를 계속 작성

6. 리펙토링(Refactoring)

7. 페어 프로그래밍(Pair Programming) – 가장 좋은 구현 방법 고민, 전략적인 방법 고민

8. 공동 소유(Collective Code Ownership) – 누구나 코드 수정

9. 지속적 통합(Continuous Integration)

10. 1주에 40시간 작업(40-Hour Work)

11. 고객도 한자리에(On-site Customer)

12. 표준에 맞춘 코딩(Coding Standard)

XP 프로젝트 진행 단계

유저 스토리

- 유저 스토리는 일종의 요구사항(requirement)

- 폭포수 모델이나 나선형 모델에서 ‘Requirements Process’나 ‘Software Requirements’ 단계를 거치는 것과 비슷하다.

- 유저 스토리는 UML(Unified Modeling Language)의 유스 케이스와 같은 목적으로 만들어지지만 형식이 없고(informal) 고객에 의해 작성된다는 것이 다르다. 유저 스토리는 시스템이 고객을 위해 해야 하는 일들을 담고 있고, 유저 인터페이스 외의 요구사항도 포함할 수 있으며, 개발자의 말이 아니라 고객의 말로 쓰여야 한다.

- 유저 스토리를 가지고 개발 일정(release plan)을 잡게 되고, 뒤에 설명할 승인 테스트(acceptance test)를 만드는 토대가 된다.

- 유저 스토리가 전통적인 소프트웨어 개발 방법론의 요구사항 명세(requirement specification)와 크게 다른 것은 유저 스토리에는 요구사항 명세처럼 세세한 것까지 적지 않는다는 것이다.유저 스토리에는 그것을 구현할 때 얼마나 걸릴 것인가를 예측할 수 있을 정도로만, 그것의 구현에 있어 주요한 어려움(risk)이 어떤 것이 있을지를 살펴 볼 수 있을 정도로만 적는다. 구현하기 위해 필요한 세부사항은 해당 유저 스토리를 구현할 때 고객을 만나 다시 듣는다.

스파이크 솔루션

- 유저 스토리가 만들어지면 그 가운데 어려워 보이는(risky) 문제에 대해 스파이크 솔루션(spike solution)을 만든다.

- 스파이크 솔루션은 기술적 또는 설계상의 어려운 문제를 해결하기 위한 것이다. 스파이크 솔루션은 숨어 있을 수 있는 문제를 찾아내기 위한 아주 간단한 프로그램이다.

- 처리해야 하는 문제 외의 다른 조건들은 모두 무시하고 프로그램을 만든다.

- 스파이크 솔루션을 만드는 목적은 기술적인 문제를 줄이고 유저 스토리를 가지고 추정한 개발 일정에 대한 신뢰도를 높이는 것이다.

주기 계획

- 각 주기가 시작될 때마다 주기 계획 회의(iteration planning meeting)를 한다.

- 각 주기는 1~3주 정도로 잡는다.

- 고객에게 가장 가치 있는 부분을 가장 먼저 만들기 위해 각 주기에 처리할 유저 스토리는 고객이 고른다.

- 처리할 유저 스토리는 이를 구현하기 위한 프로그램 과제(programming task)로 나누고. 유저 스토리를 고객의 말로 적는 데 비해 과제는 개발자의 말로 적는다.

- 각 과제를 개발자에 할당하고 소요기간을 예측하게 되는데, 같은 일이라도 소요기간은 사람마다 다를 수 있기 때문에 예측은 반드시 담당 개발자가 한다.

- 각각의 과제는 하루에서 사흘까지로 분리하고 하루가 안 걸리는 과제는 몇 개를 묶어서 하나로 만들고, 사흘보다 더 걸리는 과제는 더 잘게 나눈다.

- 각 주기에 할 일이 너무 적거나 너무 많으면 처리할 유저 스토리를 더하거나 뺀다.

- 유저 스토리를 가지고 예측했던 소요시간은 과제를 가지고 예측한 것으로 보완한다.

- 계획에 포함되어 있지 않는 기능을 추가하려고 하면 안 된다. 추가하고 싶은 기능이 있으면 그에 대한 유저 스토리를 추가하고 다음 주기에 포함시킨다.

주기 개발

- 각 주기의 길이를 비슷하게 유지하는 것이 좋다. 각 주기의 길이가 일정하면 프로젝트 진행에 대한 측정과 계획이 쉽다.

- 프로그램 과제를 미리 스케줄링 하면 안 된다. 각각의 주기에 해야 할 일은 해당 주기가 시작될 때 주기 계획 회의를 통해 결정한다. 고객의 요구사항은 계속 바뀌기 때문에 미리 계획해두지 않는 것이 좋다.

- 주기 데드라인을 엄수한다. 주기 중 진척상황을 확인해서 데드라인을 넘길 것 같으면 주기 계획 회의를 다시 소집해서 일부 과제를 뺀다. 다른 과제를 구현 안된 채로 남기더라도 고객이 고른 가장 중요한 과제에 집중한다.

승인 테스트

- 주기가 시작되면 주기 계획 회의에서 골라진 유저 스토리를 가지고 승인 테스트를 만든다. 여기서도 고객이 참여해 구현될 코드를 검사할 시나리오를 만든다.

- 승인 테스트는 블랙박스 테스트다. 고객은 승인 테스트가 올바르게 만들어졌는지를, 그리고 실패한 테스트의 중요도를 확인한다. 승인 테스트는 또한 나중에 리그레션 테스트(regression test)로도 쓰인다.

- 승인 테스트를 통과해야 유저 스토리에 대한 처리가 완료된다. 승인 테스트를 자동화해서 자주 테스트하는 것이 좋다.

유닛 테스트

- XP에서는 집단 코드 소유(collective code ownership)라고 하는데, 필요하면 누가 어떤 코드든지 고친다는 뜻. 이렇게 하기 위해서는 유닛 테스트(unit test)가 필요.

- 유닛 테스트는 XP의 초석(cornerstone) 가운데 하나. 유닛 테스트는 자주 실행할 수 있도록 자동화돼야 하고(JUnit과 같은 유닛 테스트 프레임워크를 이용), 모든 모듈을 테스트할 수 있도록 만들어져야 한다.

- 코드를 작성하기 전에 유닛 테스트를 작성하는 것이 좋다.

- 유닛 테스트는 코드와 함께 코드 저장소(code repository)에 저장된다.

- 자동화된 유닛 테스트는 문제점을 찾아내는 데 있어서 훨씬 더 많은 시간을 절약해 준다.

다른 방법론과 XP와의 관계

- 구조적 방법론은 시스템이 하는 작업을 중심으로 시스템을 나누어 분석, 설계, 구현하는 방법론으로 데이터의 흐름을 중요시며. 주로 데이터 흐름 다이어그램, 구조 차트 등을 써서 분석과 설계를 진행한다.

- 객체지향 방법론은 각각의 시스템을 이루는 객체와 그들의 역할을 찾아내는 방식으로 시스템을 분석, 설계, 구현하며. 객체는 일종의 추상 데이터 타입으로 생각될 수도 있는 만큼 데이터의 흐름보다는 데이터와 그 데이터와 관련되는 연산을 더 중요시하게 된다. 객체지향 방법론에서는 E-R 다이어그램 또는 클래스 다이어그램, 상태 챠트, 시퀀스 다이어그램 등을 써서 분석과 설계를 진행한다.

- XP 방법론은 나선형 모델을 좀더 극단적으로 적용한 것으로 생각할 수도 있으며, 객체지향 방법론으로 설계/구현되는 시스템에 적용할 수 있다.