XP(eXtreme Programming)
애자일 방법론 중 하나로 빠른 개발 속도를 유지하며 고객이 원하는 요구를 지속적으로 피드백하는 방법이다.
약 12개의 구체적인 실천방법을 정의하였다.
짧은 주기로 여러 번 고객에게 납품을 반복한다.
개발문서보다는 소스코드를, 조직적인 개발보다는 개개인의 책임과 용기를 중시한다.
Scrum과 마찬가지로 대규모 프로젝트에는 적용하기 힘들고, 개개인의 습관-실력에 따라 프로젝트의 품질차이가 발생할 수 있다.
1. The Planning Game
유저 스토리 중심으로 개발 활동 및 배포 계획을 수립한다.
장점)
1)중요하지 않은 기능 개발에 낭비되는 시간을 줄일 수 있다.
2)고객이 특성의 비용에 대한 이해를 높을 수 있다.
단점)
1)계획을 지나치게 자주하게 될 수 있다.
2. Small Release
매우 짧은 주기로 모듈을 업데이트 한다.
장점)
1)피드백의 빈도가 높다.
2)전체 프로젝트의 실패를 막을 수 있다.
단점)
1)모든 프로젝트에 적용하기 힘들 수 있다.
2)모든 프로젝트에 필요하지 않다.
3. Metaphor
문장 형태로 아키텍처를 기술한다.
장점)
1)시스템의 일반 용어를 사용함으로써 오해의 가능성을 줄인다.
단점)
1)또 다른 오해를 불러일으킬 수 있다.
4. Simple Design
단순 설계
장점)
1)불필요한 시스템을 설계하는데 낭비되는 시간을 줄일 수 있다.
2)리팩토링, 코드의 자유로운 수정이 가능해진다.
단점)
1)단순한 것이 언제나 정답은 아니다.
5. Testing
항상 단위 테스트를 작성한다.
장점)
1)단위테스트는 테스트의 완성도를 높일 수 있다.
2)테스트는 개발자에게 일차적 목표를 제공한다.
3)TDD
단점)
1)단위 테스트에 의존하는 것은 좋지 않다.
2)테스트의 결과는 테스트로서의 가치가 있다.
6. Refactoring
기능 변화 없이 코드의 질을 높이는 것이다.
장점)
1)관리자가 전체적으로 시스템에 대한 이해도를 높일 수 있다.
단점)
1)모든 사람이 refactoring에 능력이 있는 것은 아니다.
7. Pair Programming
개발자 2명의 공동작업
장점)
1)한 사람이 두 사람보다 낫다.
2)두 사람은 이 방식이 작동하는 전체 접근법인가?/아직 실행하지 않은 test-case가 존재하는가?/이 문제를 간단화할 수 있는 방식이 있는가?
단점)
1)모든 작업이 두명의 개발자를 필요로 하지는 않는다.
8. Collective Ownership
시스템에 있는 코드는 누구든지 언제라도 수정이 가능하다.
장점)
1)팀 구성원이 떠나는 손실을 완화할 수 있다.
2)개발자가 시스템의 일부가 아니라 전체 시스템에 대한 책임을 질 수 있게 한다.
단점)
1)개별적인 능력을 평가하기 힘들다.
9. Continuous Integration
하루 단위로 소프트웨어의 통합과 빌드의 빈도를 높인다.
장점)
1)긴 프로세스를 단축시킬 수 있다.
단점)
1)하루 단위는 항상 실용적이지만은 않다.
10. 40-Hour Week
주에 40시간만 일한다.
장점)
1)대부분의 개발자들은 40시간 이상일 때 효율성을 잃는다.
단점)
1)어떤 사람들은 더 일하고 싶어할 수 있다.
11. On-Site Customer
개발자와 고객의 직접적 피드백
장점)
1)무엇이 개발되어야 하는지 확실하게 알 수 있다.
단점)
1)이런 고객을 찾기 힘들다.
2)고객은 전문 지식을 갖추고 있지 않을 확률이 높다.
12. Coding Standards
표준화된 코딩 방식
장점)
1)모호한 코드가 줄어든다.
단점)
1)inline 문서의 질을 떨어뜨린다.
Comments