[클린소프트웨어#2] 익스트림프로그래밍(XP)에 대해서

# 시작하며

 앞선 게시글에서 애자일이 무엇인지에 대해서 정리했었다. 애자일은 방법론 중 하나이다. 애자일을 적용한 방법 중 익스트림프로그래밍(XP)라 불리우는 방법이 있다. 이를 통해서 애자일의 가치와 원칙들이 어떻게 적용되는지 구체적인 사례를 통해서 살펴보도록 하자.

 

# 고객은 누구인가?

 애자일방법론에 대해서 배우며 고객이라는 단어가 많이 등장했다. 고객에 요구사항에 맞게.. 고객의 변경되는 요구사항... 등등 고객은 우리를 힘들게 했다. 고객은 우리에게 소프트웨어 프로젝트를 맡긴 의뢰인인 것일까? 정답은 맞긴 맞는데 그뿐만은 아니다라는 것이다.

 XP팀에서 고객은 기능요소를 정의하고 우선순위를 매기는 개인또는 그룹이다. 즉, 사내에서 같이 일하는 업무 분석가나 마케팅 전무가 그룹이 될 수 도있고, 사용자를 대표하는 대리인 또는 실제로 현금을 지급하는 사람일 수 도 있다. 중요한 것은 우리에게 일거리를 준 사람이다!

 그리고 이러한 고객과 XP팀원(개발자)와의 최적의 관계는 같은 공간에서 일해야하는 것이다. 같은 공간은 진짜 물리적으로 같은 공간이다. 책에서는 100피트 이내의 거리에서 일하면 괜찮다고까지 했다. 이러한 고객과 거리가 멀어질 수록 팀원과의 소통이 어려워지고 하나의 팀이 되는 것이 어려울 것이다. 근데 요즘은 줌이 있지 않나!?

 

# 사용자 스토리(User Stroy)

 요구사항을 추정할 수 있을만큼의 정보를 가진 요구사항을 알아야한다. 이 요구사항은, 너무나 구체적인 것 까지는 알 수 없다. 왜냐하면 시간이 지남에 따라서 바뀔 것이 분명하기 때문이다. 고객과 대화하면서 요구사항에 대한 감을 잡고, 색인카드의 몇개의 단어를 적어가며 내용을 기억한다. 이를 통해 고객이 우선순위와 추정 비용에 근거해 요구사항의 구현 일정을 수립하게 해주는 도구가 된다.

 

# 짧은 반복

XP프로그래밍에서는 반복과 릴리즈라는 개념이 등장한다. 2주마다 개발중인 소프트웨어를 공개하며 고객의 피드백을 받기 위해 실제 시스템을 신연한다. 이를 통해 고객은 현재 진행되는 사항에대한 느낌을 알 수 있다.

## 반복 계획

 반복이난 2주단위의 term을 잡는다. 이것은 minor한 업데이트가 되는 사항이다. 반복이 시작되면 고객은 스토리의 정이나 우선순위를 바꾸면 안된다. 

## 릴리즈 계획

6번의 반복(12주)의 term으로 릴리즈 계획을 세운다. 12주(3개월)을 의미한다. major공개가 되며, 반복계획에서는 스토리의 집합을 여기선 스토리의 묶음이 구성된다. 

각 반복과 릴리즈를 통해서 예산을 알 수 있다.

 

# 인수테스트(acceptance test)

 사용자 시나리오에 맞춰 진행되는 테스트로, 소프트웨어의 내부구조나 방법등을 따지는 것이 아닌 실제 유저의 관점에서 시나리오가 정상적으로 동작하는지에 대한 테스트이다. 스토리를 위한 인수테스트는 그 스토리가 구현되기 바로 앞에 작성되거나 동시에 작성된다. 

 

# 짝 프로그래밍

 애자일 방법에서도 설명했던 짝 프로그래밍이다. 사실 이 방법을 봤을때는 저걸 진짜 하라는건가 싶었는데.. 우테캠관련된 블로그들을 보다 보니까 정말 2인1조로 짝을 만들어 pair하게 개발을 진행시킨다는 것을 보고 놀랐다.

 짝 프로그래밍의 목표는 간단하다. 시스템의 전체적인 개요를 잘 이해하기 위해서이다. 2인1조로 짝을 구성하고 역할을 바꿔가며 개발을 한다. 그리고 이러한 짝은 하루에 한번은 바뀌도록 하여 모든 프로그래머가 매일 다른 두짝과 일할 수 있도록 해야한다는 것이다. 그렇게 함으로써 지식이 더 빨리 전달되고 결함 발생률을 줄인다.

 

# 테스트 주도 개발

 개발하기전에 단위 테스트(Unit Test)를 만들고 이 테스트를 통과시키기 위해서 코드를 짜는 것이다. 옛날에 이 방법을 알고 매우 신게했었다. 그러나 객체지향을 공부하고 디자인 패턴을 공부하면서 엄청난 개발방법이라는 생각이 들었다. 실제 경험해보지는 못했지만 꼭 실무에서 경험해보고 싶은 방법 중 하나이다.

 단위테스트가 어려울 필요는 없다. 매우 간단하게 작성하고 이 함수를 통과시키는 것이다. 이는 리팩토링을 굉장히 용이하게 함과 동시에, 각각의 테스트를 통과시키기 위해서 코드를 작성하다보면 서로 독립적인 관계가 형성되어 상호간섭이 적다는 장점이 있다.

 

# 공동 소유권

 개발자들은 하나의 모듈이나 기술에 대해서 개인적인 책임을 지지 않고 공동의 책임을 진다. 모든 팀원들이 모든 부분작업에 참여하면서 공동 소유권을 가지게 된다.

 

# 지속적인 통합

 자신들이 개발하고 있는(된) 코드를 수시로 체크인(chek in)한다. 체크인은 깃허브에 코드를 올리는것 과 같다고 생각하면 된다. 이러한 잦은 check와 merge를 수행하면서 후에 있을 긴 병합과정을 방지한다. 

 

# 지속가능한 속도

 프로젝트는 길게 이어지기 때문에 초반부터 무리하게 달리는 것이 아닌, 일정한 속도로 유지될 수 있도록 한다. 직원들을 갈아 넣지 말라는 것이다. 어떻게 보면 회사 복지와 관려이 있지 않을까 싶다. 그러나 예외는 릴리즈 주인데, 이때는 유일하게 초과 근무를 허용하라고 한다.. 하하

 

# 열린 작업 공간

 물리적인 작업공간을 자유롭게 하고, 잡담이 오가는 근무환경을 만듦으로써 팀원들간 끊임없이 대화하며 문제를 해결 할 수 있도록 한다.

 

# 계획 세우기 게임

 위에서 이야기한 짧은 반복과 릴리지를 통해서 얻어낸 주기의 대한 비용을 고객에게 제공한다. 이러한 예산은 고객이 프로젝트의 리듬에 익숙해질 수 있고 전반적인 소요기간과 비용을 알 수 있게 된다.

 

# 단순한 설계

 디자인 패턴을 공부하면서 단순한 설계가 얼마나 중요한지 알아가고 있다. 현재 스토리에 집중하며 그 다음 일어날 일에 대비하는 코드를 작성하지 않는 것이다. 이러한 방법은 괜히 더 복잡하게 만들고 강한 의존관계를 만들어 버린다. 즉 어떻게든 동작하는 가장 단순한 것을 생각하고, 미래에 있을 것이 필요하지 않을 것이라는 가정에서 개발 한다. 기반구조를 추가하는 것이 비용면에서 효과적일것이라는 강한 근거에 기반한 확신이 있을때마 추가한다.

또한 반복된는 코드를 중복해서 쓰지 않도록한다. 코드가 반복됨을 느끼면 함수로 만들거나 모듈로 분리할 수 있도록 해야 한다. 

 

# 리팩토링

 잦은 리팩토링을 통해서 코드가 퇴화하지 않도록 한다. 리팩토링은 행위에는 영향을 주지 않고 시스템 구조를 개선하는 일련의 방식이다. 리팩토링 후에는 단위테스트를 통과하는지 확인해야 한다.

 

# 메타포 

 이 은유의 방법은 말그대로 진짜 은유이다. 우리가 어떤 방법에 대해서 이야기할때 예시를 들어서 설명하는거와 같다. 이러한 방식은 실제 개발에도 프로젝트의 전반적인 이해에 도움을 준다고 한다.

 마틴은 1초에 60개의 글자를 화면에 전송하는 시스템을 개발할때의 방법을 예시로 들었는데 이 프로젝트를 실제 "쓰레기를 운반하는 덤프트럭"이라는 메타포를 가지고 개발을 하는 것이 큰 도움이 됐다고 소개했다.

 

# 마치며

 어떻게 보면 회사의 복지와도 귀결되는 사항이 XP프로그래밍, 애자일 방법론인 것 같다.