익스트림 프로그래밍 실천방법
익스트림 프로그래밍은 애자일 방법 중 가장 유명한 것으로, 단순하면서도 서로 의존적인 실천방법의 집합으로 구성되어 있다. 이 장에서는 그러한 실천방법들을 전체적으로 살펴본다.
고객 팀 구성원
고객이란 개발자와 같은 회사에서 일하는 비즈니스 분석가일수도, 사용자를 대신하는 대리인일 수도 있다. 어떤 경우건 XP 프로젝트에서 고객은 개발자와 긴밀하게 소통하는 팀의 구성원이 되어야 한다. 고객과 개발자가 긴밀하게 소통하기 위해 책의 저자는 이 둘이 서로 가까운 거리에서 일할 것을 추천한다.
사용자 스토리
사용자 스토리란 현재 진행 중인 요구 사항에 관한 대화 연상 기호이다. 예를 들어 고객과 개발자는 서로의 협의 하에 하나의 사용자 스토리로써 대화 내용을 요약한 몇 개의 단어를 색인 카드에 적어 보관할 수 있다. 사용자 스토리는 XP 팀이 요구 사항을 대략적으로 추정하고 구현 일정을 짜는 데 도움을 줄 수 있다.
사용자 스토리는 아키텍쳐 설계에서 종종 등장하는 유스케이스와 비슷한 개념이라고 이해했다.
짧은 반복
반복 계획
XP 프로젝트는 개발 중인 소프트웨어를 2주마다 공개한다. 2주마다의 반복은 이것이 최종 제품에 반영될 수도, 그렇지 않을 수도 있는 마이너 공개(minor delivery)임을 나타낸다.
릴리즈 계획
릴리즈는 보통 3개월 동안을 의미하며, 보통 최종 제품에 포함되는 메이저 공개(major delivery)를 의미한다. 하지만 릴리즈가 절대적인 것은 아니다. 고객은 요구 내용을 언제든지 변경할 수 있으며, 스토리를 취소하고 새로운 스토리를 작성할 수도 있다.
인수 테스트
인수 테스트는 앞서 말한 사용자 스토리의 세부 사항을 기록해 놓기 위한 수단으로 사용된다. 시스템이 어떤 인수 테스트를 통과하면 그 테스트는 더 이상 수정되지 말아야 하며, 인수 테스트가 실패한다면 그 빌드는 실패한 빌드이다.
TDD 방법론과 연결지어 생각해볼 수 있을 것 같다. 테스트 코드를 작성하는 목적이 단순히 기능을 검증하는 것이 아니라 우리가 구현해야 하는 세부 사항들의 기록이라고 생각한다면, 개발에 앞서 테스트 코드를 먼저 작성하는 것이 보다 자연스러운 흐름이 될 것이다.
짝 프로그래밍
책의 저자가 줄곧 말하는 것처럼 의사소통의 가장 확실한 수단은 일대일로 대화하는 것이다. XP 프로젝트에서 가장 중요한 것은 사람, 그리고 사람 사이의 소통이며, 이는 개발을 하는 과정에서도 다르지 않다. 프로그래머가 둘씩 짝을 지어 긴밀하게 소통하며 개발하면서 도메인 지식은 더욱 빠르게 공유될 수 있으며, 예상과는 다르게 코드 작성의 효율 또한 오히려 높아질 것을 기대할 수 있다.
테스트 주도적 개발
TDD에서 개발자가 작성하는 언제나 테스트 가능한 상태에 있기 때문에 프로그램을 조금만 변경해도 즉시 테스트해볼 수 있고, 이는 리팩토링을 굉장히 용이하게 하는 결과를 낳는다.
또한 TDD에서 개발이란 테스트를 통과하기 위한 행위이므로, 개발자는 언제나 테스트 가능한 코드를 작성하게 된다. 각 기능별로 독립적으로 테스트 가능하도록 만들기 위해 작성된 코드는 불필요한 결합도와 의존성을 낮추며, 이는 객체 지향 개발의 핵심과 맞닿아 있다.
공동 소유권
XP 프로젝트에서는 모든 팀원이 일정한 권한과 책임을 가진다. 프로젝트는 팀원 모두의 소유이다.
지속적인 통합
XP 프로젝트에서는 긴밀한 소통 하에 빈번한 수정과 추가가 이루어지기 때문에 도메인 모델이 무결성 있게 유지되는 것에 특히 주의를 기울여야 한다. 그러기 위해서는 CI가 필수적이다.
지속 가능한 속도
XP 팀은 지속 가능한 속도로 달리면서 에너지와 민첩성을 보존해야 한다. 꾸준히 적당한 속도로 달려야 한다. XP 팀은 릴리즈의 마지막 주를 제외하고는 초과 근무를 하지 않도록 해야 한다.
단순한 설계
XP 팀의 설계는 가능한 단순하고 표현적이어야 한다. 아래 세 가지 지침을 따르며 설계한다.
- 어떻게든 동작하는 가장 단순한 것을 생각한다.
- 필요하지 않을 것이라는 가정에서 시작한다.
- 코드를 중복해서 쓰지 않는다.
메타포
메타포는 말 그대로 비유/은유를 뜻한다. 우리가 개발하고 있는 시스템에 대한 적절한 메타포는 보다 넓은 시야에서 큰 그림을 제시해주고, 나아가야할 방향을 설정해줄 수 있다.
메타포가 정말 필요한 지의 여부에 대해서는 말이 많지만, 나는 개인적으로 필요하다고 생각한다. 도메인 주도 설계에서도 소개된 것처럼 적절한 메타포는 새로운 도메인 지식의 창출을 유도할 수 있으며 심층 모델로의 도약을 가능케 한다.
