Extreme Programming. 줄여서 XP(eXtreme Programming).
1999년 켄트 벡이 발표한 막장프로그램 개발 방식으로, 빠르게 고객과 소통하며 개발할 수 있는 방법이다. 의사소통, 단순성, 피드백, 용기를 가치로 내세우고 있다.
1 기본 원칙
기본 원칙은 다음과 같다.
1. 조금씩, 하지만 자주 발표한다.
2. 사이클을 반복해서 돌리면서 개발한다.
3. 스펙에 없는 것은 절대 집어넣지 않는다.
4. 테스트 코드를 먼저 만든다.
5. 야근은 하지 마라. 항상 정규 일과 시간에만 작업한다.
6. 기회가 생기는 족족 언제 어디서든 코드를 개선한다.
7. 모든 테스트를 통과하기 전에는 어떤 것도 발표하지 않는다.
8. 조금씩 발표하는 것을 기반으로 하여 현실적인 작업 계획을 만든다.
9. 모든 일을 단순하게 처리한다.
10. 두 명씩 팀을 편성하고 모든 사람이 대부분의 코드를 알 수 있도록 돌아가면서 작업한다.
근데 말이 좋아 이런 거지, 극단적으로 보면
1. 짜증나게 자주 업데이트한다.[1]
2. 셔틀 돌린다.
3. 말한 것만 짠다.
4. 코드 짜기도 전에 테스트한다.
5. 근로기준법을 준수하라!
6. 시도때도 없이 고친다.
7. 허들 넘기
8. 안 될 계획은 아예 세우지도 않는다
9. 단순
10. 파트너와 함께
……계속하다간 백괴사전처럼 될 것 같다.
아무튼 이러한 이유로 처음 등장했을 때 충격과 공포를 안겨주었지만 현재는 프로그래머들 사이에서 큰 인기를 얻고 있다. 어느 IT 강국은 예외지만
2 성공 이유
우선, 기본적으로 프로그래머는 프로그래밍을 좋아한다. 비프로그래머를 위해 설명하자면 프로그래밍도 일종의 창작 과정이기 때문에 그 결과를 얻을 때 희열을 얻는 것은 마찬가지다. 작가가 시 한편을 써 낸 후의 기쁨을 생각해보면 쉬울 듯? XP는 이런 성향을 이용해 프로그래머가 프로그래밍의 압박과 고통보다는 희열과 기쁨을 더 누릴 수 있게 했다.
또한 정신적으로 강도 높은 노동인 코딩을 하는 동안 다른 한 사람이 아이디어도 주고 알고리즘도 찾아 보고 하는 것 역시 효율적이다.
의문의 '테스트 코드를 먼저 만든다.' 부분은, 먼저 출력이 어떻게 되어야 할 지 테스트 코드를 쓴 다음 그것을 만족하게 프로그램을 만든다는 것이다. 테스트를 통과하면 이제 다시 테스트 코드를 개선한다. 이런 식으로 반복한다. 이 방법은 테스트 주도 개발이라는 다른 개발 방법론으로 넘어간다.- ↑ 적어도 하루 1회, 심하면 3~4회의 발표를 하루 내에 하는 경우도 있다. 아예 원탁에 둘러 앉아 서로 바라보면서 끊임없이 의사소통을 하는 팀들도 있다!