[Chapter 2] 익스트림 프로그래밍 소개

익스트림 프로그래밍 실천방법

---

익스트림 프로그래밍(XP)는 애자일 방법 중에서도 가장 유명하다. 단순하면서도 서로 의존적인 실천방법의 집합으로 구성되어 있다. 전체적으로 각 부분에 대해서 간단하게 살펴보자.

고객 팀 구성원

• 고객과 개발자가 서로 긴밀하게 작업하면서 서로의 문제를 인식하고 해결
• 고객 : 기능 요소를 정의하고 우선 순위를 매기는 개인 또는 그룹
• XP프로젝트에서는 고객이 누구든 간에 팀의 멤버이며, 팀에서 일할 수 있음
• 가장 최고의 상황은 개발자와 고객이 같은 공간에서 일하는 것

사용자 스토리

• 프로젝트 일정 계획을 세우기 위해 요구사항을 알아야하지만 요구사항을 추정할 수 있을 만큼의 정보만 있으면 OK, 세부적인 것까지 필요 X
• 요구사항의 구체적인 세부 내용은 시간이 지남에 따라 쉽게 바뀌기 때문
• XP를 사용할 때, 고객과 대화함으로써 요구사항의 세부 내용에 대한 감을 잡음 -> 세부사항을 기록 X
• 고객 -> 같이 합의해서 정한 색인 카드에 몇 개의 단어를 적어 그 대화 내용 기억
• 개발자 -> 고객과의 대화를 바탕으로 추정한 내용을 카드에 기록
• 사용자 스토리는 현재 진행 중인 요구사항에 관한 대화의 연상 기호
• 고객이 우선순위와 추정 비용에 근거해 요구사항의 구현 일정을 수립하게 해주는 계획 툴

짧은 반복

XP 프로젝트는 개발 중인 소프트웨어를 보통 2주마다 공개한다. 각 반복마다 이해당사자의 어떤 요구를 처리하는 소프트웨어를 만든다. 그리고 각 반복의 끝마다 이해당사자의 피드백을 받기 위해 시스템을 시연한다.

반복계획

• 보통 2주 단위로 진행
• 마이너 공개 -> 최종 제품에 반영될 수도, 안될 수도
• 개발자가 세운 예산에 따라 고객이 선택한 사용자 스토리의 집합
• 개발자는 이전 반복을 기준으로 각 반복의 예산을 세움
• 고객은 전체 견적이 그 예산을 넘지 않는 내에서 각 반복의 스토리를 선택
• 반복이 시작되면 반복 동안에는 스토리 정의나 우선순위를 바꾸지 않는다고 약속
• 개발자는 스토리를 자유롭게 태스크에 나눠 넣고 기술적, 업무적으로 가장 합리적인 순서로 그 태스크를 수행

릴리즈 계획

• 약 6번의 반복 일정을 정밀하게 표현하는 릴리즈 계획을 수립
• 보통 3개월 동안을 의미
• 메이저 공개 -> 보통 최종 제품에 포함
• 개발자가 제시한 예산에 맞춰 고객이 선택한, 우선순위가 정해진 '사용자 스토리' 묶음으로 구성
• 개발자는 이전 릴리즈에서 얼마나 완성할 수 있었는가를 측정하여 릴리즈의 예산을 세움
• 고객은 그 예산 내에서 릴리즈에 포함할 스토리를 선택
• 고객은 릴리즈에서 구현될 스토리의 순서를 결정 가능
• 릴리즈는 절대적인 것이 X -> 고객은 요구 사항을 언제든지 변경 가능(스토리 취소, 새로 작성, 우선순위 변경 등)

인수 테스트

• 사용자 스토리의 세부사항은 인수 테스트의 형태로 기록
• 인수 테스트는 그 스토리가 구현된 바로 앞 또는 구현되는 동시에 작성
• 자동적으로, 반복적으로 실행될 수 있는 스크립트 언어의 한 종류로 작성
• 고객이 명시한 대로 동작하는지 여부를 결정
• 일반적으로 인수 테스트 툴 개발에 QA 부서를 참여시키고, 직접 인수 테스트를 만듬
• 인수 테스트가 실패하면 그 빌드는 실패를 선언
• 통과하면 통과한 테스트의 본문에 추가
• 인수 테스트는 하루에도 몇 번씩, 시스템을 빌드할 때마다 계속 수행

짝 프로그래밍

• 프로그래머 짝들이 함께 운영 코드를 작성
• 한 멤버는 키보드를 잡고 코드 입력
• 다른 멤버는 에러와 개선점을 찾음
• 프로그래머 짝의 역할은 자주 바뀜
• 결과물 코드는 두 멤버가 함께 설계하고 만들어낸 것
• 적어도 하루에 한 번 바꿔서 모든 프로그래머가 매일 서로 다른 두 짝으로서 일할 수 있게 해야함
• 한 반복 과정동안 팀의 모든 멤버는 팀의 다른 모든 멤버와 함께 일해봐야하고 그 과정에서 진행되는 모든 작업을 해봐야함
• 이러한 방식으로 더 빨리 지식이 확산
• 전문성을 요구하는 태스크도 짝을 이루어서 모두가 경험하게 하여 위기 상황에 대비 가능

테스트 주도 개발

• 모든 운영 코드는 실패하는 단위 테스트를 통과하기 위해 작성 (실패 -> 통과)
• 테스트 케이스와 코드를 작성하는 사이의 간격은 1분 정도로 매우 빠름
• 테스트 케이스의 완성된 본문은 코드와 함께 발전
• 테스트는 개발자가 프로그램이 잘 동작하는지 점검할 수 있게 함
• 프로그램을 조금 변경해도, 바로 테스트로 문제 여부를 판단 가능 -> 리팩토링을 굉장히 용이하게 함
• 테스트 케이스를 통과하기 위해 코드를 작성한다면, 그 코드는 당연히 테스트 가능한 것
• 코드를 모듈별로 분리하여 각각 독립적으로 테스트될 수 있게 해야한다는 필요성도 강력히 대두
• 이러한 방식으로 작성되는 코드 구조는 상호 간섭이 아주 적음 -> 객체 지향 설계 원칙은 이런 비간섭화를 구현하는데 큰 역할

공동 소유권

• 짝은 어떤 모듈이라도 점검하고 개선할 권리를 가짐
• 하나의 개별적인 모듈이나 기술에 개인적인 책임 X
• 모든 팀원이 모든 부분 작업에 참여
• 누구도 어떤 모듈이나 기술에 대해 다른 사람보다 더한 권한을 갖지 않음
• 전문성을 부정하는 것이 아닌 전문 분야의 일에만 묶여 있지 않게 하는 것

지속적인 통합

• 긴 병합과정을 피해가 위해, 팀원은 모듈을 매우 빈번하게 체크인
• 먼저 모든 테스트가 작동하는지 확인 -> 새로운 코드를 이미 존재하는 기반 코드에 통합 -> 통합 후, 통합된 새로운 시스템을 빌드하고 인수 테스트를 포함해 시스템에 있는 모든 테스트 실행 -> 통과하면 체크인 완료
• XP 팀은 하루에도 여러 번, 처음부터 끝까지 전체 시스템을 빌드

지속 가능한 속도

• 소프트웨어 프로젝트는 단거리 경주가 아닌 마라톤
• 팀이 지속 가능한 속도로 달려서 에너지와 경각심을 보존해야함
• 꾸준히, 적당한 속도로 달려야 한다.
• 유일한 예외는 릴리즈의 마지막 주

열린 작업 공간

• 팀은 열린 공간에서 함께 일함
• 문제가 생기면 누구나 그것을 인지 가능
• 각 팀원은 서로의 상태를 잘 알고, 개발자들은 집중적으로 대화할 수 있는 위치에 있음

계획 세우기 게임

• 업무와 개발의 책임 분리
• 업무 관련 인력(고객) -> 기능 요소가 얼마나 중요한지를 결정
• 개발자 -> 그 기능 요소를 구현하는 데 얼마나 비용이 들 것인지를 결정
• 각 릴리즈와 반복을 시작할 때, 개발자는 예산을 세워 고객에게 제출
• 고객은 총비용의 합이 예산을 넘지 않는 정도로 스토리를 선택

단순한 설계

• 설계를 가능한 단순하고 표현적으로 만듬
• 현재 반복에서 작업하기로 계획했던 스토리에만 초점을 맞추어 공략
• 다음에 작업할 스토리에 대해 걱정 X
• 시스템이 현재 구현하고 있는 스토리에 가장 적합한 설계가 되도록
• 기반구조를 이용해 시작하지 않음 (데이터베이스, 미들웨어 등 먼저 선택 X)
• 가능한 가장 단순한 방식을 동작하게
• 스토리가 진행되며 그것을 강요할 때만 기반구조를 추가

3가지 XP지침

① 어떻게든 동작하는 가장 단순한 것을 생각한다.

현재 스토리를 구현하는 가장 간단한 방법을 생각한다. 그리고 실제로 구현할 수 있을 정도로 최대한 단순한 솔루션을 선택한다.

② 필요하지 않을 것이라는 가정에서 시작한다.

기반구조가 필요하지 않을 것이라는 가정하에 프로젝트를 시작한다. 지금 기반구조를 추가하는 것이 기다리는 것보다 효과적이라는 확실한 증거가 있을 때, 적어도 아주 강한 근거가 있을 때 비로소 추가한다.

③ 코드를 중복해서 쓰지 않는다.

중복 코드가 발견될 때마다 이를 제거한다. 중복 코드를 발견하면 함수나 부모 클래스를 만들어 제거한다. 가끔 둘 이상의 알고리즘이 비슷하긴 하지만 미묘한 부분에서 다를 경우, 함수로 바꾸거나 템플릿 메소드 패턴을 사용한다. 중복성을 제거하는 최선의 방법은 추상화이다. 중복성을 제거하기 위해 팀은 많은 추상형을 만들고, 그 결과 결합도도 낮아지게 된다.

리팩토링

• 리팩토링은 행위에 영향을 주지 않고 시스템의 구조를 개선하는 일련의 작은 변환을 만드는 방식
• 각각의 작은 변환이 끝나면 단위 테스트를 실시하여 문제 여부를 확인
• 리팩토링을 통해 깔끔하고 단순하며 의미있는 코드를 유지 가능

메타포

• 전체 그림을 의미
• 메타포는 전체 시스템을 하나로 묶는 큰 그림
• 모듈의 형태가 메타포와 일치하지 않는다면 그 모듈이 잘못되었음을 알 수 있음
• 종종 시스템을 어떠한 이름으로 요약함 -> 시스템의 요소에 기호를 부여하고 그 관계를 정의하는 것을 도움

결론

---

XP는 애자일 개발 프로세스를 구성하는 단순하고 구체적인 방식의 집합이다. 여러 프로젝트에 XP를 적용하여 사용할 수 있을 것이고 경우에 따라서 방식을 추가하거나 수정할 수 있을 것이다.