개발중심의 경량화 개발방법론 (Extreme Programming :XP) #

정의 #

• 비즈니스 상의 요구의 변동이 심한 경우에 적합한 개발 방법으로 1999년 켄트 백의 저서인 'Extreme Programming Explained - Embrace Change'에서 발표되었다. 애자일 개발 프로세스 개발 방법 중 대표적인 하나.
• 10 ~ 12 개 정도의 구체적인 실천 방법(Practice)을 정의, 문서보다는 소스코드, 조직적인 개발 움직임보다는 개개인의 책임과 용기에 중점이 있다.
• 비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋다.

가치와 원칙 #

가치 #

1. 의사소통
   • 의사소통은 팀 개발에 있어서 가장 중요한 요소이다. 한 팀이라는 느낌을 만들고 효과적으로 협동하기 위해서 중요한 부분이다.
2. 단순성
   • 간단한 부분은 바로 작성하고 복잡한 설계 부분은 지속적으로 리팩토링하여 불필요한 복잡성을 줄이기 위해 노력한다.
3. 피드백
   • 피드백은 의사소통의 핵심이며 단순성에도 기여한다.
4. 용기
   • 실패하는 해결책을 버리고 새 해결책을 찾아 나서는 용기는 단순함에 도움을 주고 구체적이고 진실한 답변을 추구하는 용기는 피드백을 낳게 한다.
5. 존중
   • 팀에 속한 모든 개인의 기여를 존중해야 한다.

원칙 #

1. 인간성
   • 인간성을 통해 개인의 욕구와 팀의 욕구 간의 균형을 맞춘다.
2. 경제성
   • 기술적 성공뿐만 아니라 비지니스 목표와 필요를 충족해야 한다.
3. 상호이익
   • 관련된 모든 사람에게 이익이 되어야 한다. 해결책이 야기하는 문제보다 해결책이 처리하는 문제의 수가 많아야 상호이익이 된다.
4. 자기 유사성
   • 어떤 해결책이 효과적이라면, 그 해결책을 다른 곳에 적용해 본다.
5. 개선
   • 일단 시작한 다음 개선하는 것이 좋다. 프로세스나 설계, 스토리를 완벽하게 만들려고 노력하는 것은 가능하다. XP란 개선을 통해 탁월한 소프트웨어에 도달하는 것이다.
6. 다양성
   • 문제를 발견하려면 팀 안에 다양한 종류의 기술과 사고방식 그리고 시야들이 모여있어야 한다.
7. 반성
   • 피드백을 최대화하기 위해 XP 팀에서는 실천과 반성을 뒤섞는다.
8. 흐름
   • 개발의 모든 단계를 동시에 작업함으로써 가치 있는 소프트웨어를 흐르듯이 끊임없이 제공하는 것.
9. 기회
   • 문제를 기회로 삼아 더 개선된 소프트웨어를 만들겠다고 의식적으로 결심하는 것.
10. 중복
    • 중복을 만드는 비용보다 해결방법의 실패로 인한 재앙을 면함으로써 얻는 이익이 더 크다.
11. 실패
    • 실패를 감수하는 것이 성공으로 가는 가장 짧고 확실한 길.
12. 품질
    • 시간 안에 할 방법으로 최대한 진행 후, 마무리를 생각한다. 품질이 주는 이익에는 명확한 한계가 없으며, 어떻게 더 품질을 올릴까에 대한 이해의 한계만 있다.
13. 아기 발걸음
    • 중요한 변화를 한 번에 몰아서 시도하는 것은 위험하며 조건만 제대로 갖추어진다면, 사람들과 팀들은 많은 작은 단계를 엄청나게 빠른 속도로 밟아나가서 마치 도약하는것 처럼 보일 수 있다.
14. 수용된 책임감
    • 책임이 있는 곳에는 권한도 따라온다. 책임과 권위가 잘못 연결되면 팀의 의사소통이 왜곡된다. 권위와 책임이 잘못 연결된 상태에서는 감정적인 부담의 비용도 존재한다.

개발 절차 및 특징 #

절차 #

1. 사용자 스토리
2. 사용자 요구사항
3. 구조적 스파이크
4. 시스템 구조
5. 릴리지 계획
6. 사용자 핵심 요구사항에 대한 간단한 프로그램
7. 주기
8. 승인테스트
9. 작은 릴리즈 스파이크

특징 #

• 빠른피드백
• 중요기능을 빠르게 개발하여 일찍 피드백을 받을 수 있다.
• 용기
• 필요시 과감하게 설계를 변경한다.
• 원활한 커뮤니케이션
• 팀 혹은 고객의 의사소통을 중시한다.
• 단순성
• 설계에 얽매이지 않고 최소한의 필요와 단순함을 지키는 것을 중시한다.
• 변경 필요가 없으면 내부구조를 개선하는 리팩토링을 진행한다.

12가지 실천 항목 #

1. 계획 게임
2. 작은 릴리즈
3. 메타파
4. 단순한 디자인
5. 테스팅
6. 리팩토링
7. 페어 프로그래밍
8. 공동 소유권
9. 계속적인 통합
10. 주 40시간 근무
11. 온 사이트 고객
12. 코딩표준

문제점 #

• 고객 상위 입장에 대한 고려가 필요하다.
• 시스템 후반에 문제발생 확율이 많다.
• 산출물의 부재로 감리등이 어렵다.
• 많은 요구사항 변경으로 인한 부화가 발생할 수 있다.
• 급변하는 환경에 대한 빠른 개발이 필요하다.

Incoming Links #

Related Data Sciences (DataScience 0) #

• Extreme programming
• spring/Spring Test
• 애자일 모델

Suggested Pages #

• 0.925 Continuous integration
• 0.050 JUnit 활용
• More suggestions...