XP 개방방법론

.사용자스토리

 - UML의 유스 케이스와 같은 목적

 - 배포 계획에 대한 시간 계산에 사용되기도 하며 요구사항 문서 대신 가능

 - 시스템을 사용하는 고객이 필요한 것이 무엇인지 기술 -> 인수테스트에 사용

스파이크

 - 잠재적인 솔루션들을 고려하기 위해 작성하는 간단하 프로그램

 - 사용자 스토리의 신뢰성 증대 또는 기술적인 문제의 위험성 감소에 사용

배포계획

 - 전체 프로젝트에 대한 배포 계획을 생성

 - 의사결정을 하기 위해 프로젝트에 포함되는 모든 것들에 대한 규칙을 가짐

 - 규칙들은 프로젝트를 수행하기 위한 방법들로 정의

반복

 - 반복적 개발에서는 민첩함을 중요하게 여김

 - 하나의 반복을 1~3주 정도로 나눔, 반복들을 프로젝트 전반에 균일하게 유지 

 - Xp의 반복은 프로세스의 평가와 계획을 단순, 신뢰성 있게 만드는 핵심 항목

 - 즉각적인 계획과 실행은 사용자 요구 사항들의 변경에 쉽게 대처하기 위함

인수테스트

 - 고객은 제대로 작동하는 시스템을 보면서 진척사항을 확인하고

 - 시스템이 자신이 직접 명세한 테스트를 통과했는지 파악

작업배포

 - 작은 배포는 XP 주기의 마지막 단계

 - 소규모로 빈번하게 배포하면 고객에게 여러 가지 이득을 조기 제공

  -프로그램은 빠른 피드백을 제공 받음

pair programming

 개발자가 짝을 이루어 프로그램 작성

Small Release

 작은 단위의 신속한 배포

테스트

 개발중 지속적인 테스트 수행

메타포

 요구사항을 다이어그램으로 명확화

공동책임

 개발된 코드에 대해 공동의 책임

주 40시간

 주 40시간 이내의 근무

계획측면

 - 팀이 개발한 SW의 가치를 최대화

 - 가능한 적게 투자, 가능한 빨리, 가능한 가장 가치 있는 기능 구현

설계측면

 - 의사소통을 통하여 설계, 중복된 코드가 없을 것 -> 가장 단순하게 개발

 - 가능한 클래스와 메소드 들은 적게 만들 것 -> 변경에 유연

개발 측면

 - 지속적인 통합, 수정, 테스트, 배포

 - 복잡한 코드 제거

 - 페어 프로그램으로 완벽한 코딩

테스트측면

 - 각 테스트는 다른 부분과 관련이 없어야 함 -> 테스트 자동화

 - 테스트 프로그램 만드는 주체는 프로그래머 함수 단위, 고객 스토리 단위

전망

설명

긍정적인 전망

 - 방법론 그 자체가 아니라 일부 기법이나 사상이 사용하기 매우 좋음

 - 중,소형 프로젝트에서 적용하기에 적합 -> 대형 프로젝트도 타스크

   단위로 적용 바람직

 - 아키텍쳐 설계 및 프로토타이핑 수립과 같은 태스크 수행 시 적합

부정적인 전망

 - 방법론 그 자체로서 적용하기에는 프로세스 정립은 부족함

 - 대형 프로젝트에서 적용하기에 적합하지 않음

 - 감리에 대한 대응의 어려움

 - 관리 방법에 대한 가이드라인이 부족함