1. XP 정의하기
XP는 4개의 부분, 가치, 원칙, 활동, 기법으로 구성된다. XP는 별도로 고안되었다기 보다는 협동, 작업의 흐름, 시스템 속에서 나타났다고 하는 편이 옳을 것이다. 이런 소프트웨어 개발의 유기적인 관점을 유지하면서 XP는 가치와 원칙들에 기반하여 만들어져서 그로부터 기법과 활동을 고안해냈다.
1) 가치
XP는 개발을 위한 공통의 가치(value)에 의해서 이끌어 진다.
| 가치 | 설명 |
| 단순성 |
XP에서 단순성은 "동작하는 최대한 단순한 작업을 하는 것"으로 정의된다. 당장의 문제를 가급적 단순하게 해결하고 이후의 문제는 그 때 해결될 것이라고 믿는 것이다. 보통의 방법론들은 어느 정도 앞날을 대비한 계획을 세우고 고객은 전체 시스템에 대해서 예상해 보게 된다. 이런 방법론에 깔린 생각은 이후의 수정이 불가능하지는 않더라도 어려울 것이라는 것이다. XP는 당장 고객이 원하는 것을 하는 것으로 관점을 달리한다. XP 그룹들에서 하는 이야기가 있다. "아마 그건 필요 없을껄" 이것이 의미하는 것은 개발팀은 단순한 생각을 갖고 고객이 필요할 것 같은 것이 아니라 고객이 당장 필요로 하는 것을 구현해야 한다는 것이다. 왜 앞으로 필요할 것 같은 기능에 대해서 미리 디자인하는 걸까? 그것은 이후 수정이 일어날 경우 그 비용이 너무 높기 때문이다. 요약하자면, 단순한 시스템이 커뮤니케이션 비용이 적게 들고 통합이 용이하며 더 나은 확장성을 가지고 있다. |
| 커뮤니케이션 |
모든 방법론은 내부적으로 커뮤니케이션 과정을 가지고 있지만 XP에서는 특별히 핵심 가치로 존재한다. 커뮤니케이션의 초점은 문서나 보고서, 계획서에 있지 않고 대화에 있다. 모든 팀 구성원간의 커뮤니케이션이 없이는 협업은 약해지고, 결국은 실패할 것이다. XP에는 작업에 커뮤니케이션을 요구하는 짝 프로그래밍 같은 기법을 사용한다. 1장 "XP 가 나오게 된 배경"에서 '이해'가 소프트웨어 개발에 얼마나 커다란 어려움인지에 대해서 이미 이야기했다. XP는 이를 인정하고 팀 멤버간의 장벽을 허물기 위해 노력한다. XP 에서 모든 문서는 사람들간의 커뮤니케이션을 돕는 데 쓰인다. |
| 피드백 |
XP 에서는 모든 시스템에 대한 계속되는 질문에 대한 대답이 지속적이고 구체적인 피드백에 의해 이루어진다. 제품은 시행착오를 거쳐서만이 검증 될 수 있다. 이것은 엄연한 사실이기 때문에 개발팀은 소프트웨어를 빨리 만들어낸 후, 고객에게 데모를 해야 한다. |
| 용기 |
용기는 빨리 작업하고, 필요시 다시 개발하겠다는 자신감이다. XP 에서의 용기는 다른 세 가지 가치들과 하나의 문맥에서 생각해 보아야 한다. 그만큼 중요한 것이다. 하지만 XP의 용기는 강력하고 자동화된 테스트에 기반한 대단함이지 모르는 것에 대한 무모한 노력은 아니다. |
2) 원칙
XP의 핵심 가치를 바탕으로 소프트웨어 개발에 지침이 될 다섯 개의 주요 원칙(Principle) 이다.
| 원칙 | 설명 |
| 피드백은 신속히 |
신속한 피드백은 개발자가 짧은 단위로 고객의 피드백을 받아서 고객의 요구를 잘 반영하고 있는지 확인하는 것을 의미한다. |
| 단순함을 전제 |
단순함을 전제하는 것은 문제를 대할 때 간단히 문제가 풀릴 것이라 생각하라는 것이다. 또 그것은 현재 문제에 집중해서 작업하고 미래의 일에 대해서는 걱정하지 말라는 것을 의미한다. |
| 점진적인 수정 |
문제를 풀 때의 과정을 작은 교정의 연속이라고 생각하라. 이것은 계획, 개발, 디자인에 모두 적용된다. 예를 들어 고객이 이미 웹 사이트를 가지고 있고, 거기에 JSP를 포팅하고 할 경우 XP 팀은 한번에 완성해서 끝내는 것을 목표로 하기 보다는 사업부에서의 요구에 따라서 여러 차례 소규모의 출시를 할 것이다. |
| 변화의 인정 |
현존하는 문제를 풀면서 옵션의 여지가 있는 방법을 택하라. |
| 고품질의 작업 |
작업의 품질은 타협의 대상이 아니다. XP는 테스트 위주 프로그래밍으로 그 무엇보다 코드와 테스트의 중요성을 강조한다 |
3) 활동
지금까지 가치와 원칙들에 대해 알아보았는데, 그렇다면 실제 XP에서 하는 일은 어떤 것 인가? 몇 가지 XP 사이클에서의 활동(Activity)에 대해 알아보자.
| 활동 | 설명 |
| 듣기 |
XP는 능동적인 듣기를 요구한다. 형식적인 문서에 대한 의존도가 늦은 대신에 고수준의 구두 커뮤니케이션이 요구된다. 단순히 개발자가 고객의 말에 귀기울여야 한다는 것 이상으로 XP는 보다 나은 커뮤니케이션을 지향한다. 문서에 대한 의존 없이 XP 사용자들은 다른 형태의 구두 의사소통을 익히고 능숙해져야 한다. |
| 테스트 |
XP에서의 테스트는 고객에게 출시하기 전에 하는 작업이 아니라 개발 전 과정에 걸쳐 일어나는 공정의 일부이다. 심지어 개발자는 코드를 작성하기 전에 테스트를 먼저 작성할 정도이다. XP 테스트는 정확성이나 결점을 측정하는 데 국한되는 것이 아니라 제품의 성능이나 적응도까지 점검한다. 코드를 짜기 전에 테스트를 만드는 것은 개발자에게 생각의 전환을 요구한다. 그 결과로 코드는 비용이 많이 드는 개발의 후반부에 별도의 디버깅 과정 없이 그 자체로 높은 품질을 지니게 된다. |
| 디자인 |
문서화된 디자인이 적은 대신 XP 개발자는 코드를 작성할 때 의도적으로 그 의미를 표현하려 한다. 소스 코드를 읽는 것만으로 다른 팀의 멤버들은 논리와 알고리즘, 흐름을 이해할 수 있다. 여기서 이야기하는 것은 주석에 대한 이야기가 아니라 소스 코드 그 자체가 커뮤니케이션의 수단이 된다는 것임에 주의하기 바란다. 소스코드는 실제 제품에 우리가 가장 가까이 접근할 수 있는 것 이다.
XP의 기초 아이디어 중 하나는 디자인이 프로젝트 전체에 걸쳐서 발전해 나간다는 것이다. 디자인은 멈추어 있거나 특정 단계에서 이루어지는 것이 아니라 팀 기반의 동적인 것이다. 어떤 면에서 소프트웨어는 언제나 디자인 중이라고 이야기할 수도 있다. 디자인 단계를 제한해서 이런 점들을 무시하는 대신 XP는 자연스런 시스템의 발전을 수용한다.
|
4) 기법
그렇다면, 어떻게 XP의 활동들을 실행에 옮길 수 있을까? XP는 이들 활동들을 12개의 핵심적인 기법(Practice)으로 표현한다. 이 기법들이 XP팀들이 매일 현장에서 시스템을 개발하는 데 사용하는 것들이다.
| 번호 | 기법 | 설명 |
| 1 |
계획 짜기 게임 |
계획 짜기 게임의 역할은 빠른 시간 안에 다음의 출시 계획이나 일정을 빨리 세우기 위한 것이다. |
| 2 |
짧은 릴리즈 |
XP 개발 사이클은 사업적 가치를 달성하기 위해 짧은 릴리즈로 이루어진다. |
| 3 |
메타포 |
메타포는 프로젝트를 표현하는 데 쓰이는 시각적인 것, 단어, 언어이다. |
| 4 |
단순한 디자인 |
디자인은 반드시 단순해야 한다. XP에서의 단순함의 의미는 동작하는 것 중에서 가장 단순해야 한다는 것이다. |
| 5 |
테스트 |
XP 개발의 핵심은 자동화된 테스트이다. 개발시에는 가장 먼저 테스트부터 작성해야 하고 테스트 툴에 의해서 사용된다. |
| 6 |
리팩토링 |
리팩토링은 시스템 외적 동작의 변화 없이 기존 코드의 디자인을 향상시키는 작업이다. |
| 7 |
짝 프로그래밍 |
짝 프로그래밍은 두 명의 개발자가 한 컴퓨터 앞에 앉아서 같이 개발작업을 진행하는 것이다. |
| 8 |
공동 소유 |
공동 소유는 언제, 누구라도 코드를 수정해서 더 좋게 만들 수 있게 해준다. |
| 9 |
지속적인 통합 |
시스템의 부분은 하루에도 수 차례 통합 작업을 거친다. |
| 10 |
주당 40시간 근무 |
초과근무가 많은 곳에서는 일괄적인 품질의 유지가 어려워진다. XP는 품질을 위해서 일반 업무시간의 준수를 요구한다. |
| 11 |
현장의 고객 |
고객이 현장에 있고 개발팀에 참가한다. |
| 12 |
코딩 표준 |
코딩 표준은 모든 개발자가 개발시 지키기로 합의한 약정이다. |
아 빡시다. 계속 써놔야한디. 아나ㅋㅋ 언제 다하지...