[Agile] XP란?

XP는 eXtreme Programing의 약자로 애자일 소프트웨어 개발 방식의 하나이다. 보통 개발조직 기반의 중소규모 팀에 적합한 경량화된 개발방식임. 다른 애자일 개발 방식과 마찬가지로 '방법론'이라 불리는데 이견이 있을 수 있다.
특히나 XP는 테스트 주도 개발 (Test Driven Development), 일일 빌드 (Daily Build), 지속적인 통합 (Continous Integration) 등 개발 테크닉과 연관된 부분이 많기 때문에 종종 '방법론'으로 규정 짓는 것에 대해 논란이 되곤 한다. 팀의 개발 문화가 제대로 정립되어 있지 않거나, 계획 및 관리 중심으로 프로젝트를 유지하던 팀의 경우 XP 도입 초기에 난관이 존재하기도 한다.
최근에는 XP만 사용하기보다 스크럼등 보완적 애자일 개발 방식과 함께 사용하는 경우가 많다.
XP는 기본적으로 가치(value) 와 그 가치를 이루기 위한 실천법(practice), 이 두개를 큰 축으로 놓고 원칙(principle)을 세워서 그 둘 사이에 균형을 맞추는 것을 권장한다.

기원

1990년대 후반 켄트 백을 중심으로 여러 엔지니어들이 프로젝트를 진행하며 얻은 교훈을 기반으로 효과적이라 생각되는 개발 기법을 모아 방법론으로 정립함.

XP의 가치

1. 의사소통
   팀 활동을 하는 대부분의 조직이 발전적인 방향으로 존속하는데 있어 가장 중요한 점이 '의사소통'이라 할 수 있다. 이는 팀 원 각자가 겪는 문제에 대해 서로 인지하고, 문제가 반복하지 않도록 도우며, 문제가 감추어진 상태로 진행되다가 결국 걷잡을 수 없는 규모로 악화되지 않도록 하기 위해 매우 중요한 요소입니다. 의사소통을 잘 해야 한다는 점을 안다고 해서 쉽게 의사소통이 가능해 지는건 아니다. 이를 위해서는 개개인에게 의사소통시 발생하는 두려움과 마주할 때 필요한 개개인의 '용기'가 필요하다.
2. 용기
   SW개발 하는 것은 곧잘 커다란 미지의 두려움과 마주해야 하는 일상의 연속이다. 낯선 기수로가 모르는 사람들, 마찬가지로 알 수 없는 (고객을 포함) 타인의 감정과 대면했을 때 많은 경우 우리는 용기를 버리고 '속임', '회피', '분노' 혹은 '비난'을 선택하게 된다. 이를 극복하고 나아가기 위한 용기가 필요하다. 모르는걸 모른다 말할 수 있는 용기, 먼저 손을 내어 도움을 주고 도움을 요청할 수 있는 용기가 필요하다. 이 용기를 통해 우리는 성공적인 SW개발의 필수 요소인 '피드백'이라는 중요한 가치를 얻을 수 있게 된다
3. 피드백
   피드백은 SW개발 및 의사소통의 핵심이다. 좋은 팀은 의사소통과 피드백이 멈추지 않고 순환되는 분위기를 유지한다. SW 개발이 시작되면 가급적 빠른 시일 내에, 자주, 고객으로 부터 피드백을 받는 것이 좋다. 때로는 더 자주 더 많이 새로운 요구사항이 만들어진다는 점 때문에 피드백의 간격을 늘이거나 횟수를 줄이려는 경우가 많다. 이는 결과적으로 개발팀과 고객 모두에게 만족스럽지 못한 결과를 가져온다.
   피드백을 자주 받고 새로운 요구사항을 제대로, 어렵지 않게 반영하기 위해서 유지해야하는 중요한 가치가 있다. 바로 '단순함'이다
4. 단순함
   SW개발은 어려운 문제를 해결하기 위해 점점 더 복잡해져가고 있다. 우리가 SW개발에 있어 직면하고 있는 큰 아이러니 중 하나는 복잡한 업무를 해결하기 위해 그 만큼이나 복잡한 방식으로 SW를 만들고 있다는 점이다. SW가 비용을 줄여주고 생활을 편리하게 만들어주는 것은 사실이지만, 복잡한 SW는 고장나기 쉽고, 문제를 일으키기 쉽고, 결국 버려지기 쉽게 변해버린다. 의사소통을 극대화하고 용기를 내서 적극적으로 피드백을 받는다 해도 SW가 간결하게 유지되지 않는다면 어려움은 해결되지 않을 것이다.
5. 존중
   위 가치를 추구하는 과정에서 반드시 유지되어야 하는 것은 바로 존중이다. 개개인에 대해 상호간의 '존중'이 없으면 팀은 결국 와해되어 버리거나 수준 높은 SW를 함께 개발하는 것이 불가능하게 된다.

소프트웨어 개발에서 생산성과 인간성을 동시에 개선하려면, 팀에 속한 모든 개인의 기여를 존중해야 한다. 나도 중요한 사람이고, 당신도 중요한 사람이다.

켄트 백

XP의 기본 실천 방법들

1. 함께 앉기: 팀 전체가 들어가기에 충분할 정도로 크고 열린 공간에서 진행한다
2. 전체 팀: 프로젝트가 성공하기 위해 필요한 기술과 시야를 지닌 사람은 전부 팀에 포함시키다
3. 정보를 제공하는 작업 공간: 작업 공간을 작업에 대한 것들로 채워라
4. 활기찬 작업: 생산적으로 일할 수 있는 정도의 시간만, 그리고 일의 활력을 유지할 수 있는 정도의 시간만 일해라
5. 짝 프로그래밍: 제품으로 출시할 프로그램을 두 사람이 컴퓨터 한 대에 앉아 작성해라
6. 스토리: 고객에게 가치를 줄 수 잇는 최소한의 기능을 단위로 계획하라
7. 일주일별 주기: 한 번에 일주일 분량의 일을 계획하라
8. 분기별 주기: 한 번에 한 분기 분량의 일을 계획하라
9. 여유: 어떤 계획이든, 일정에 뒤쳐질 경우 포기할 수 있는 비교적 급하지 않은 업무를 포함시켜라
10. 10분 빌드: 10분만에 자동으로 전체 시스템을 빌드하고 모든 테스트를 돌려라
11. 지속적인 통합: 변경한 것은 두 세시간만에 통합하고 테스트하라
12. 테스트 우선 프로그래밍: 코드를 한 줄이라도 변경하기 전에, 자동화된 테스트를 먼저 작성하라
13. 점진적인 설계: 시스템의 설계에 매일 투자하라

XP의 원칙

1. 인간성: 소프트웨어는 인간이 개발한다
2. 경제성: 이 모든것에 누군가는 돈을 지불한다는 경제성의 원칙을 인정한다
3. 상호이익: 모든 활동은 그 활동에 관련된 모든 사람들에게 이익이 되어야 한다
4. 자기 유사성: 어떤 해결책의 구조를 다른 맥락에도 적용해 보라
5. 개선: 소프트웨어 개발에서 '완벽하다'란 없다. '완벽해 지기 위해 노력한다'만 있다
6. 다양성: 팀에는 비록 갈등의 요소가 될 수 있을지라도 다양성이 필요하다
7. 반성: 좋은 팀은 실수를 숨기지 않고 오히려 실수를 드러내어 거기에서 배운다
8. 흐름: 개발의 모든 단계를 동시에 진행함으로써 가치 있는 SW를 물 흐르듯 끊임없이 제공해야 한다
9. 기회: 가끔은 생각을 전환해 문제를 기회로 보는 방법을 배운다
10. 잉여: SW개발에서 핵심적이고 해결하기 어려운 문제는 해결 방법을 여러 개 만들어 놓는다
11. 실패: 성공하는데 어려움을 겪는다면 실패하라
12. 품질: 품질을 희생하는 것은 프로젝트 관리의 수단으로 삼기에 효과적이지 않다
13. 책임 소재: 어떤 일을 하겠다고 선언한 사람이 그 일의 책임도 가진다
14. 아기 걸음: 단계를 작게 쪼갤때 걸리는 부하가, 큰 변화를 시도했다가 실패해서 돌아갈 때 드는 낭비보다 훨씬 작다는 사실을 인정하자