7장은 XP를 적용할 때 안전하게 사용할 수 있는 실천방법들을 소개한다. 아래에서 설명하는 방법들 중 어떤 것들을 채용할지, 어떤 순서로 적용할지는 각 팀이 처한 환경, 개선하고 싶은 부분에 달렸다.
함께 앉기
개발 작업은 팀 전체가 들어가기 충분할 만큼 크고, 열린 공간에서 하라. 그리고 이 공간에서 만큼은 사생활을 접어 놓아라. 사생활은 나만의 작은 공간을 만들고, 시간을 분리해 해결한다.
하지만, 함께 앉기는 팀이 준비되기 전에 실행한다면 생산성은 오히려 낮아질 것이다. 팀원의 안정감이 자신만의 공간을 소유하는 것과 연관되 있을 수 있기 때문이다. 따라서 팀을 구성하고, 함께 앉기를 조금씩 천천히 진전시켜도 된다. 물리적 가까움이 의사소통을 향상시킨다는 사실을 알고 의사소통의 가치를 배운다면, 자신의 공간을 기꺼이 개발할 것이다.
전체 팀
프로젝트가 필요하기 위해 필요한 기술과 시야를 가진 사람들을 전부 팀에 포함시켜라. 전치 팀을 구성하는 요소는 동적으로 변한다. 어떤 기술이나 태도의 집합이 중요해진다면, 그 기술을 지닌 사람을 팀으로 데려온다. 어떤 사람이 더이상 필요 없다면, 그 사람은 다른 곳으로 가도 된다.
사람들은 팀에 속한다믄 속감이 필요하다.
1. 우리는 소속되어 있다.
2. 우리는 이 안에 함께 있다.
3. 우리는 서로의 작업, 성장, 배움을 돕는다.
정보를 제공하는 작업 공간
작업 공간을 작업에 대한 것들로 채워라. 누군가가 작업 공간에 들어왔을 때, 수십초 내에 작업의 대략적인 진행 상황을 파악할 수 있어야 한다. 더 자세히 관찰한다면, 지금 있는 문제와 앞으로 생길 수 도 있는 문제에 대해 더 많은 정보를 얻을 수 있어야 한다.
많은 팀이 이를 위해 스토리 카드를 붙인다. 카드를 일정한 기준에 맞춰 공간상으로 정렬하면 정보를 빠르게 파악할 수 있다. 아래 그림은 공간상으로 정렬된 스토리 카드가 붙은 이상적인 스토리 벽의 모습이다.
작업 공간은 인간적인 욕구도 채워줘야 한다. 물고 간식은 사람을 편안하게 해주고, 긍정적인 상호작용을 촉진한다. 깨끗한 공간은 지금 푸는 문제에만 집중하게 해주고, 독립된 개인 공간과 작업 시간의 한도는 사생활에 대한 욕구를 채워준다.
활기찬 작업
생산적으로 일할 수 있는 정도의 시간만, 일의 활력을 유지할 수 있는 정도의 시간만 일하라. 자신을 혹사시키는 것은 자신을 위해서도, 팀을 위해서도 좋지 않다.
몸이 아프면 쉬어라. 자신을 잘 돌보는 것이 활력 넘치는 작업으로 복귀하는 가장 빠른 방법이다. 다른 사람에게 병을 옮겨 새산성을 떨어트리지 않는, 팀을 보호하는 방법이기도 하다. 아플때 일을 하는 것은 팀에 대한 헌신을 보여주는 것이 아니다.
근무시간을 점진적으로 개선할 수 있다. 같은 시간을 일을 해도, 질을 높여라.
짝 프로그래밍
제품으로 출시할 프로그램을 두 사람이 컴퓨터 한 대에 앉아 작성하라. 짝 프로그래밍은 둘이서 동시에 프로그래밍을 하면서 프로그램을 더 낮게 만들려고 노력하는 두 사람 사아의 대화다. 짝 프로그래머들은 다음과 같이 일한다.
1. 서로 일에 집중하도록 해준다.
2. 시스템을 더 좋게 다듬기 위해 방법을 브레인스토밍한다.
3. 떠오른 생각을 명로하게 다음어 준다.
4. 한 사람이 막힐 때 주도권을 다른 사람에게 넘겨서, 짜증을 덜 나게 해준다.
5. 팀에서 지키기로 한 실천 방법을 서로 책임지고 지키도록 한다.
짝 프로그래밍을 한다는 것이 혼자 생각할 시간이 없다는 것은 아니다. 만약 혼자 생각할 시간이 필요하다면, 그 시간을 가져도 된다. 다만, 혼자서 생각이 정리되었다면, 다시 팀으로 돌아와 짝프로그래밍을 이어나가야 한다. 그러면 더 많은 사람들이 결과를 이해할 수 있고, 프로젝트에 전체적으로 도움이 된다.
짝 프로그래밍과 개인적 공간
짝 프로그래밍을 할 때는 가까운 거리를 유지한다. 하지만, 개인에게 편안함을 주는 신체적 공간의 크기는 사람마다, 문화마다 다르다. 두 참여자가 모두 일을 잘하려면 개인적 공간을 반드시 존중해야 한다.
개인적인 위생 상태와 건강도 중요하다. 기침 등으로 발생하는 분비물을 조심하고, 몸이 아플 때는 일하지 말아야 한다.
스토리
‘사용자가 자주 사용하는 변호는 두 번 클릭만으로 사용할 수 있게 된다’ 처럼 고객이 볼 수 있는 기능을 단위로 해서 계획을 짜라. 스토리를 작성한 뒤 그것을 구현하기 위해 필요한 개발 노력을 추정해 본다.
‘요구 사항’이라는 말의 정의는 ‘필수적이거나 강제적인 무엇’ 이다. 이 말의 어감은 절대적이고 영속적인 어감이 들어 있다. 이는 변화를 포용하지 못하게 가로막는다.
스토리 실천 방법은 다른 요구사항 실천방법에 비해 추정 하는 시기가 빠르다. 추정에서 사업과 기술적 시야가 상호작용 하는데, 이를 통해 조기에 가치를 만들어 낼 수 있다. 이런 이른 시기에 아이디어가 최대 참재력을 갖는다. 팀이 여러 기능에 들어가는 비용을 알 경우, 팀은 기능들을 쪼개거나, 합치거나, 그 기능들의 가치레 대해 아느 것을 바탕으로 범위를 확장하거나 할 수 있다. 따라서, 초기 단계에서 스토리 추정은 모든 사람이 어떻게 가장 적은 투자로 가장 많은 이익을 볼 수 있을지 생각하게 만든다.
스토리에는 짧은 글이나 그림 설명과 짧은 이름을 다랑야 한다. 스토리 카드의 예는 다음과 같다.
일주일별 주기
한 번에 일주일 분량의 일을 계획하라. 한 주를 시작하는 회의를 열며, 이 회의에서는 다음과 같은 일을 한다.
1. 지금까지 진행된 상황을 검토하는데, 지난주의 실제 진행 정도가 예상 진행 정도를 달성했는지 역시 포함해 검토한다.
2. 이번 주에 구현할 일주일 분의 스토리를 고객이 고르도록 한다.
3. 스토리를 여러 과업(task)로 쪼갠다. 팀 구성원들은 자기가 할 과업에 서명을 하고, 얼마나 걸릴지 추정한다.
스토리들이 완성되었다면, 통과할 자동화 테스트들을 작성하라. 그 후, 남은 시간을 스토리들을 와성하고 테스트를 통과할 수 있도록 만드는 데 사용하라. 테스트를 겨우 통과할 수 있는 정도의 구현을 하는 것이 아닌, 스토리를 완벽하게 구현하라.
일주일 이라는 단위는 팀원들이 금요일에 집중할 수 있게 해준다. 만약 5일 안에 테스트를 작성하고 통과하게 만들지 못했다면, 가장 가치있는 스토리들을 선택해 그것들을 완성시키면 된다.
분기별 주기
한 번에 한 분기 분량의 일을 계획하라. 한 분기 계획에서는 다음과 같은 일을 한다.
1. 병목, 특히 팀의 힘이 미치지 않는 외부에서 생기는 병목을 찾아본다.
2. 수선(repair) 작업을 시작한다.
3. 이번 분기의 주제(들)를 계획한다.
4. 그 주제들을 다룰 한 분기 분랴의 스토리들을 고른다.
5. 프로젝특라 조직에서 차지하는 위치라는 큰 그림에 초점을 맞춘다.
분기별 주기를 사용하면, 분기별로 일어나는 다른 사업 활동과 잘 맞아 떨어진다. 분기는 외부 공급자나 고객과 상호작용할 때 편리한 시간 간격이기도 하다.
분기별 주기에가 일주일별 주기와 달리 스토리가 아닌 주제를 다루는 이유는 스토리가 더 큰 그림에서 어떤 위치를 차지하는지 파악하기 위해서다. 이를 통해 큰 그림을 고려하지 않고 일의 세부사항에만 초점을 맞추는 것을 방지할 수 있다. 주제는 마케팅 로드맵을 그리는 것 같은 더 큰 규모의 계획과도 잘 맞아 떨어진다.
여유
어떤 계획이든, 일정에 뒤처질 경우 포기할 수 있는 덜 중요한 과업들을 포함시켜라. 나중에 여유가 생길 경우, 더 많은 스토르들을 추가해 약속한 것보다 더 많은 것을 제공할 수 있다.
여유를 가지고 과잉 약속을 하지 말라. 약속을 지키는 것은 낭비를 줄인다. 분명하고 솔찍한 의사소통은 긴장을 완화하고 신뢰를 회복시킨다.
10분 빌드
10분 만에 자동으로 전체 시스템을 빌드하고 모든 테스트를 돌려라. 빌드가 10분 이하여야 실행하는 횟수가 많아지고 더 많은 피드백을 받을 수 있다. 10분 빌드를 설명하는 문장인 “10분 만에 자동으로 전체 시스템을 빌드하고 모든 테스트를 돌린다”는 하나의 이상이다. 이 이상을 위해 우선적으로 빌드 프로세스를 자동화 해야 한다. 그런 다음 변경한 부분만 빌드하게 만들어볼 수 있다. 마지막으로, 변경 때문에 실패할 위험에 처한 시스템의 특정 부분만 테스트를 돌리게 만든다.
자동화된 빌드는 스트레스를 낮추어 준다. 실천 방법은 스트레스를 낮추어 주어야 한다. 팀의 스트레스가 높아지면 수동 빌드 빈도는 줄어든다. 그에 따라 더 많은 에러와 스트레스가 발생한다. 반면 자동화된 빌드는 잠시 긴박함에서 벗어나 빌드를 지켜봄으로 서 스트레스 해조자가 된다.
지속적 통합
변경한 것은 두세 시간 안에 통합하고 빌드하라. 통합을 오래 미룰수록 비용이 더 들고 통합 비용을 예측화기 힘들어진다. 지속적인 통합을 하는 가장 흔한 방식은 비동기적 방식이다. 변경한 것을 체크인하면 조금 있다가 빌드 시스템이 변경이 있음을 알아차리고 빌드와 테스트를 시작한다. 그에 반해 동기적 방식도 존재한다. 동기적 방식은 짝프로그램이 에피소드가 하나 끝날 때마다 짝과 함께 통합한다. 빌드가 완료되고 전체 테스트 슈트가 깨지는 것 없이 돌아갈 때까지 기다리고 일을 마저 진행한다. 동기적 방식이 좋은 이유는 반성의 시간을 주기 때문이다. 테스트가 돌아가는 것을 기다리는 시간 동안 방금 끝낸 작업에 대한 회고를 한다. 또 한, 새로운 일을 시작하지 않을 채로 피드백을 받을 수 있기 때문에 새로운 일을 멈추고 이전 작업에 대한 기억을 되살리느라 시간을 낭비할 필요가 없다.
테스트 우선 프로그래밍
코드를 작성하기 전에 일단 실패하는 자동화된 테스트를 작성하라. ‘테스트 우선 프로그래밍’ 실천 방법은 여러 문제를 동시에 해결해 준다.
슬금슬금 늘어나는 범위
프로그래밍할 때는 ‘혹시 모르니까’라는 이유로 코드를 작성하기 쉽다. 테스트는 프로그램이 무엇을 해야 하는지 명시적이고 객관적으로 밝히게 한다. 다른 코드를 넣고 싶다면 해당 테스트가 통과하고 나서, 다른 테스트를 작성하라.
결합도와 응집성
테스트를 작성하기 쉽지 않다면, 이는 설계에 문제가 있다는 신호다. 결합도가 낮고 응집성이 높은 코드가 테스트 하기 쉽다.
신뢰
작동하지 않는 코드를 작성한 사람을 신뢰하기 힘들다. 작동 하는 깨끗한 코드를 작성하고 자동화된 테스트로 의도를 드러내면, 팀원들의 신뢰를 얻을 수 있다.
리듬
코딩하다 몇 시간씩 무엇을 해야 하는지 파악하기 위해 길을 잃을 수 있다. 테스트를 우선적으로 작성하는 것은 다음에 할 일을 명확하게 한다. 이는 자연스럽고 효율적인 리듬으로 발전한다. 테스트 - 코드 - 리팩터링.
점진적 설계
시스템의 설계에 매일 투자하라. 시스템의 설계가 바로 그날 그 시스템이 필요로 하는 것에 훌륭하게 들어맞게 되도록 애써라.
학교에서 가르치는 전략인 “구현하기 전에 할 수 있는 한 모든 것을 설계해 놓는다”의 학문적 근거는 1960년 베리 보엠의 방위산업 연구다. 이 연구는 시간이 지날수록 결함을 고치는 비용이 지수적으로 증가하는 것을 보였다. XP팀은 소프트웨어를 변경하는 비용이 지수적으로 증가하지 않게 하기 위해 노력한다. 자동화된 테스트, 지속적인 설계 개선이 그 예시다.
매일 설계에 주의를 기울여라. 그렇지 않으면 설계가 나쁘고, 깨지기 쉽고, 변경하기 힘든 시스템이 나온다.
점진적 설계는 설계를 사용하는 시점과 가까운 때에 설계하는게 더 효율적이라는 것을 알려준다. 작동중인 시스템에 점진적인 변경을 주는 것에 대한 경험이 쌓이면, 설계 노력을 점점 더 뒤로 미룰 수 있다. 그러면 시스템은 더 단순해지고, 프로젝트의 진도는 더 일찍부터 나가며 테스트도 더 작성하기 쉬워진다. 시스템이 작아지므로 팀에서 의사소통 해야 하는 정보의 양도 줄어든다.
출처 - 익스트림 프로그래밍