-
XP - 익스트림 프로그래밍공부 2017. 3. 13. 15:29
XP - 익스트림 프로그래밍이란?
비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법입니다. 이 방법은 애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나로 꼽히며, 약칭인 ‘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에서는 반복적으로 customer tests를 거칩니다. 그리고 이를 통해서 그들이 잘못 이해하고 있었던 부분에 대해서 수정을 거치기도 하며 더욱 더 의뢰인 혹은 최종 사용자의 요구에 부합하는 소프트웨어를 만들어 내게 됩니다.
Small Releases
이 실천 방안을 통해서 개발자는 주기적으로 프로토 타입을 의뢰인에게 보여줍니다. 그리고 이를 통해서 의뢰인은 제한된 기능을 가지고 있지만 실제로 작동이 되는 데모 모델을 볼 수가 있으며 추가 사항을 요구 할 수도 있습니다. 기존의 혹은 과거의 소프트웨어 개발 과정에서 개발이 끝나기 이전에 어떤 소프트웨어가 만들어질지 알 수 없었던 것과 비교해서 가장 차이점을 만들어내는 실천 방안입니다. 또한 개발자에게 있어서는 현재까지의 개발 상황이 올바른 길로 가고 있음을 알 수 있습니다.
Simple Design
보통의 프로젝트 개발 혹은 코딩의 경우 기능이 더해지면 더해질수록 복잡해 지기 마련입니다. 그렇게 되면, 새롭게 충원되는 개발자의 경우에 현재까지의 개발 상황을 이해하는데 오랜 시간이 걸리게 됩니다. 또한 버그가 발생할 경우에도 쉽게 처리를 하지 못하고 오랜 시간이 걸리게 됩니다. 그렇기 때문에 XP에서 모든 코딩을 가능한 간단하게 할 것을 강조합니다. 이러한 추세 혹은 트렌드는 KISS 원칙원리와도 함께 한다고 할 수 있습니다. (KISS 원칙이란 디자인에서 간단하고 알기 쉽게 만드는 편이 좋다는 원리를 말합니다.)
Test-Driven Development
테스트를 기반으로한 개발은 XP에서 가장 중요한 실천 방안중 하나입니다. 테스트를 거치고 코딩을 하며 프로젝트를 개발해 나갑니다.
Pair Programming
두명 혹은 그 이상의 프로그래머가 함께 코딩을 하는 것을 말합니다. 두명의 프로그래머가 함께 코딩을 하고 테스트를 통해서 개발을 할 수도 있고, 한명은 코딩을 하고 한명은 Quality Assurance 역할 통해서 테스트에만 집중을 할 수도 있습니다.