1) The Planning Process (sometimes called "Planning Game")
고객(Customer)과의 다양한 스토리카드(Story)를 통한 계획/기획을 작성한다. XP 방법론에서는 고객을 개발팀의 일부로 배치하여 고객과 개발자간의 끊임없는 의사소통을 중요시한다. 기획단계의 효과가 프로젝트를 성공으로 이끈다고 볼수있다. 이 단계를 "Planning Game"이라고 지칭하기도 한다.
2) Small Releases
제품을 심플하게 작고 빠르게 그리고 자주 릴리즈한다.
3) Metaphor메타포 : 은유, 비유법을 자주 사용한다. 마치 철학자처럼 ? XP 가 아주 재미있는 게임임을 나타내는 특징중 하나로 볼수있다.
4) Simple Design
요구에 충족되는 가장 간단한 설계, 미래를 위해 많은것을 투자하지 않는다. 현재의 비지니스적인 가치에 집중해야 한다.
물론 좋은디자인을 했다고 확신하는것이 중요하다.
어디까지나 XP 는 "refactoring" 을 통해 발전하니까 ..
5) Testing
항상 소프트웨어를 검증해야한다.
TFD (Test-First Development) 먼저 테스트를 수행하여 검증받은 코드로 작성해나간다.
이는 애플리케이션 작성후 테스트를 거치는 기존의 패러다임을 뒤엎는 발상이다.
고객은 접근성 테스트를 통하여 원하는 기능을 요구하고 개발자는 요구조건을 수정해 나아가는 점진적인 개발을 진행한다.
6) Refactoring
전체개발기간동안 시스템의 디자인을 개선해 나간다. 끊임없는 의사소통을 통해 심플하고 중복되지 않게 유지하며 재생산해 나간다.
Martin Fowler 아저씨의 "Refactoring" http://www.refactoring.com
이란 책에서 refactoring 이란 무엇인지 시스템 디자인을 개선하는것이 어떤것인지 알 수 있다.
시중에 번역서도 출간되어 있으니 XP 에 관심있는 사람뿐만 아니라 개발자라면 당연히 읽어야할 필독서
7) Pair Programming
다른 방법론에서는 찾아볼수 없는 XP 만의 가장 독특한 개발방법이다. 말 그대로 2명이 짝을 이뤄 한프로그램을 둘이서 코딩하는것이다.
XP 방법론에서 의견교환의 중요성을 가장 극명하게 보여주는 대목이자 가장 독특한 특징이라 하겠다.
8) Collective Ownership
모든코드는 모든프로그래머들이 숙지하여 변경이 필요할시 누구나 지체없이 변경할수 있어야 한다. 앞서 언급한 Pair Programming 의 결과라고 할수 있다.
9) Continuous Integration
하루에도 여러번 통합하고 빌드하라. 지속적인 통합작업으로 각각의 개발자들이 up-to-date 한 개발환경을 유지하도록 한다.
10) 40-hour week
주당 40 시간 근무
충분한 휴식후 맑고 건강한 상태로 최고의 효율을 발휘하여 프로그램을 작성하란 말이 되겠다.
개인적으로 가장 마음에 드는 항목이다 ;)
11) On-site Customer
개발과정에 고객을 적극적으로 개입시킨다. 고객위주의 프로그래밍을 할것이며 그들의 의견을 적극적으로 반영한다. 개발자입장에서는 가장 짜증나는 항목이지만 품질을 높이기 위해서는 필수불가결한
요소이다.
12) Coding Standard
항상 표준을 준수하며 깔끔하고 규칙적으로 코딩한다. 훌륭한 개발자라면 당연히 지켜야할 의무이자 기본원칙이다.
고객(Customer)과의 다양한 스토리카드(Story)를 통한 계획/기획을 작성한다. XP 방법론에서는 고객을 개발팀의 일부로 배치하여 고객과 개발자간의 끊임없는 의사소통을 중요시한다. 기획단계의 효과가 프로젝트를 성공으로 이끈다고 볼수있다. 이 단계를 "Planning Game"이라고 지칭하기도 한다.
2) Small Releases
제품을 심플하게 작고 빠르게 그리고 자주 릴리즈한다.
3) Metaphor메타포 : 은유, 비유법을 자주 사용한다. 마치 철학자처럼 ? XP 가 아주 재미있는 게임임을 나타내는 특징중 하나로 볼수있다.
4) Simple Design
요구에 충족되는 가장 간단한 설계, 미래를 위해 많은것을 투자하지 않는다. 현재의 비지니스적인 가치에 집중해야 한다.
물론 좋은디자인을 했다고 확신하는것이 중요하다.
어디까지나 XP 는 "refactoring" 을 통해 발전하니까 ..
5) Testing
항상 소프트웨어를 검증해야한다.
TFD (Test-First Development) 먼저 테스트를 수행하여 검증받은 코드로 작성해나간다.
이는 애플리케이션 작성후 테스트를 거치는 기존의 패러다임을 뒤엎는 발상이다.
고객은 접근성 테스트를 통하여 원하는 기능을 요구하고 개발자는 요구조건을 수정해 나아가는 점진적인 개발을 진행한다.
6) Refactoring
전체개발기간동안 시스템의 디자인을 개선해 나간다. 끊임없는 의사소통을 통해 심플하고 중복되지 않게 유지하며 재생산해 나간다.
Martin Fowler 아저씨의 "Refactoring" http://www.refactoring.com
이란 책에서 refactoring 이란 무엇인지 시스템 디자인을 개선하는것이 어떤것인지 알 수 있다.
시중에 번역서도 출간되어 있으니 XP 에 관심있는 사람뿐만 아니라 개발자라면 당연히 읽어야할 필독서
7) Pair Programming
다른 방법론에서는 찾아볼수 없는 XP 만의 가장 독특한 개발방법이다. 말 그대로 2명이 짝을 이뤄 한프로그램을 둘이서 코딩하는것이다.
XP 방법론에서 의견교환의 중요성을 가장 극명하게 보여주는 대목이자 가장 독특한 특징이라 하겠다.
8) Collective Ownership
모든코드는 모든프로그래머들이 숙지하여 변경이 필요할시 누구나 지체없이 변경할수 있어야 한다. 앞서 언급한 Pair Programming 의 결과라고 할수 있다.
9) Continuous Integration
하루에도 여러번 통합하고 빌드하라. 지속적인 통합작업으로 각각의 개발자들이 up-to-date 한 개발환경을 유지하도록 한다.
10) 40-hour week
주당 40 시간 근무
충분한 휴식후 맑고 건강한 상태로 최고의 효율을 발휘하여 프로그램을 작성하란 말이 되겠다.
개인적으로 가장 마음에 드는 항목이다 ;)
11) On-site Customer
개발과정에 고객을 적극적으로 개입시킨다. 고객위주의 프로그래밍을 할것이며 그들의 의견을 적극적으로 반영한다. 개발자입장에서는 가장 짜증나는 항목이지만 품질을 높이기 위해서는 필수불가결한
요소이다.
12) Coding Standard
항상 표준을 준수하며 깔끔하고 규칙적으로 코딩한다. 훌륭한 개발자라면 당연히 지켜야할 의무이자 기본원칙이다.
7번 항목에 효율에 대해서는 두말하면 잔소리. 자원낭비의 우려가 있지 않을까?
10번 항목..기술습득 단계에서는 40시간도 부족하다. 열심히 일한 당신 좀더 일해라~
아래에 가보면 더 많은 글을 볼수 있다. 참고할것
http://no-smok.net/nsmk/ExtremeProgramming
10번 항목..기술습득 단계에서는 40시간도 부족하다. 열심히 일한 당신 좀더 일해라~
아래에 가보면 더 많은 글을 볼수 있다. 참고할것
http://no-smok.net/nsmk/ExtremeProgramming
댓글