시작하며
익스트림 프로그래밍은 chapter1 에서 등장했던 애자일 방법론 중 하나이다. 비즈니스 상의 요구가 시시각각 변동이 심한 소규모 프로젝트에 적합한 개발 방법론이다.
XP 실천방법
고객 팀 구성원
- 고객과 개발자가 서로 긴밀하게 작업하면서 서로의 문제를 인식하고 이를 해결하기 위해 노력해야 한다
사용자 스토리(user story)
- 현재 진행 중인 요구사항에 관한 대화의 연상 기호이다
- 고객이 우선순위와 추정 비용에 근거해 요구사항의 구현 일정을 수립하게 해주는 계획 툴이다
짧은 반복
- XP 프로젝트는 일반적으로 개발 중인 소프트웨어를 2주마다 공개한다.
- 반복(Iteration) 계획 : Minor delivery(최종 제품에 반영될수도 , 그렇지 않을수도 있음) : 보통 2주
- 릴리즈 계획 : Major delivery(보통 최종 제품에 포함됨) : Iteration(2주) * 6 = 보통 3개월
인수 테스트(acceptance test)
- 이 테스트는 시스템이 고객이 명시한대로 동작하는지 여부를 명시한다
짝 프로그래밍
- 결함이 적고 더 나은 프로그램을 만들 수 있어서 전체적으로 효율성은 좋아진다
TDD(Test-Driven Development)
- 테스트는 프로그램이 잘 동작하는지 점검할 수 있게 해준다
- 리팩토링을 용이하게 한다.
- 코드를 모듈별로 분리하여 독립적으로 테스트될 수 있게 해야 한다
공동 소유권
- 도메인이나 구조 별로 담당자를 특별하게 구분하지 않는다. 즉, 전문 분야의 일에만 묶여있지 않는다
지속적 통합(continuous Integration)
- 비차단 소스 제어 방식 사용(nonblocking source control) → 언제나 편하게 코드를
check-in(push), check-out(pull) 할 수 있어야 한다. - 하루에도 여러 번 처음부터 끝까지 전체 시스템을 빌드 한다.
지속 가능한 속도
- 소프트웨어 프로젝트는 마라톤이다. 꾸준히 지속 가능한 속도 (pace)로 달려야 한다
열린 작업 공간
- 팀 내 소통은 언제나 열려 있어야 한다. War room에서 함께 일하는 것이 생산성을 향상 시킨다
계획 세우기 게임
- 짧은 반복과 빈번한 릴리즈를 통해서 고객과 개발자사 프로젝트 리듬에 익숙해 지면, 프로젝트의 소요 기간과 비용을 빠르게 측정할 수 있게 된다.
단순한 설계
최대한 단순한 방식으로 요구사항을 구현한다. 만약 요구사항이 필요로 할 때만 인프라가 추가된다.
- 어떻게든 동작하는 가장 단순한 것을 생각한다. 현재 스토리를 구현하는 가장 단순한 솔루션을 선택한다
- 인프라(기반구조)가 필요하지 않을 것이라는 가정에서 시작한다. 기반구조를 추가하는 것이 효과적이라는 확실한 증거가 있을 때 추가한다
- 코드를 중복해서 쓰지 않는다. 중복성(redundancy)를 제거하는 최선의 방법은 추상화(abstraction)이다. 추상형을 사용하면 결합성(coupling)이 낮아진다
리팩토링
- 코드 구조는 퇴화하기 쉬우며, 언제나 잦은 리팩토링으로 이를 극복해야 한다. 리팩토링은 행위에 영향을 주지 않고 시스템 구조를 개선한다.
메타포(metaphor)
- 전체 시스템을 하나로 묶는 큰 그림. 이것은 모든 개별적인 모듈의 위치와 형태를 명백하게 만든다.
결론
XP는 에자일 개발 프로세스를 구성하는 단순하고 구체적인 방식의 집합이다.
마치며
XP는 소규모 프로젝트에 적용하기 좋은 방법론이기 때문에, 아직 대규모 프로젝트보다는 소규모 프로젝트를 많이 다루는 나에게 더 적합할 것 같다.
XP는 빠르게 변하는 니즈에 대처하기 유연한 개발방식인 것 같다.🥨
