첫번째 사진에서는 지정된 번호와 함께 XP팀의 작업실의 전체적인 모습이 보여지고 있습니다. 햇볕도 잘 들어오고 천정도 높은 작업실과 원목 책상으로 쾌적한 작업환경을 만들어 놓았습니다. 사진에서 보다 싶이, 가장 넓은 벽면에는 프로젝트에 대한 여러가지 정보가 게시되어 있습니다.

1. 고객 - 사진에서는 보이지 않지만, 왼쪽에는 XP고객(product manager)이 앉아 있습니다.
2. 개발중 스토리 - 이번 1주 동안 개발이 진행될 스토리들이 상세하게 노트되어 있습니다.
3. 기술 문제 - 기술적 이슈사항을 공개합니다.
4. 반복완료 회의결과 - 결과 수치(Merics)를 포함합니다.
5. 범용 화이트보드 - 언제라도 지워집니다.
6. 스토리카드 보드 - 최근에 완료된것, 해야될 것, 예정되지 않은것들 모두를 붙여둡니다.
7. 개발자 워크스테이션 - 짝 프로그래밍을 위해서 두대의 워크스테이션이 서로 붙어 있습니다.
8. 이전 스토리카드 보드 - 몇개월 전에(오래전에) 완료된 스토리 카드를 붙여둡니다.
9. 개발 통합 서버 - 사진에는 보이지 않지만, 소스관리, 빌드, 테스트를 실시하는 서버가 있으며, 성공이나 실패에 따라 특정 소리가 들립니다.
   

1. 고객

XP의 고객(product manager)는 개발팀과는 조금 거리를 두고 작은 의자에 앉아 있습니다. 하지만, 개발자를 바라보고 있으며 언제든지 회의가 가능합니다. 개발자들은 의문사항이 있을경우 쉽게 대화가 가능하고, 부담없는 고객과의 커뮤니 케이션은 추정에 의한 개발을 큰 폭으로 감소시켜줍니다.

2. 개발중 스토리

이 보드는 이번 주에 주어지는 상황에 대한 의사소통을 원활하게 도와줍니다. 반복에 대한 계획을 세우고, 스토리들을 상세하게 기술해 갑니다. 이렇게 기술된 스토리중 몇몇은 그대로 작업사항이 됩니다만, 대부분은 더욱 자세하고 상세하게 단어수준까지 기술합니다. 이 작업 이후에는 고객에게 보여줍니다. 고객이 스토리를 검토하여 OK사인을 보내면, 개발을 시작합니다. 보드에 붙어있는 종이에는 고객이 적어준 화면 메세지나 에러 메세지들이 포함되어 있습니다.

화이트보드의 왼쪽 작은 영역에는 버그 트래킹 정보가 있습니다. 버그가 발견되면 그 영역에 적어 놓습니다. (여기에서 말하는 버그는, 실제 릴리즈 되고 안되고를 떠나서, 이전의 주 동안 완료된 스토리에서 발견되는 개발 상의 결함을 말합니다.) 우리는 한번에 두개 이상의 버그가 발생한적이 없었고, 모든 버그는 보고된 날에 해결했습니다. 한마디로, 버그 트래킹 정보는 보통, "버그가 없습니다"라고 쓰여있었습니다.

오랜지색의 박스로 둘러쌓인 영역에는 릴리즈 메모가 쓰여있습니다. 여기에는 다음에 릴리즈를 하기 위한 순서가 설명되어 있습니다. 릴리즈를 할때마다 어플리케이션을 전부 바꾸기도 하는등의 기존 어플리케이션 업그레이드가 발생했으므로, 이 부분은 자주 변경되었습니다. 릴리즈 프로세스가 자동화되는 것이 가장 이상적이었으나, 절대로 완벽한 자동화는 되지 않았습니다. 그러나 우리의 릴리즈는 점점 향상되어 갔습니다.

3. 기술문제

고객과는 상관없는 작업들이 있습니다. 예를들면 불필요한 코드의 정리라든가, 리팩토링이라던가, 설계상의 문제들을 말합니다. 이러한 것들을 잊지 않도록 화이트 보드에는 고객 스토리와는 다른 기술문제 영역을 마련했습니다. 해결 불가능 또는 해결할 이유 없음으로 인해서 그냥 지워버린 문제들도 있었습니다.

4. 반복 완료 회의 결과와 수치화

각각의 반복은 일주일을 주기로 가졌고, 매주 금요일 점심식사 이후에 반복 완료 회의를 실시하여 새로운 반복 계획을 세웠습니다. 회의에서는 금주의 반성을 하였으며 다음주를 위한 반복 계획을 세웠습니다. 그리고 고객이 앞으로 진행되거나 다가올 스토리카드와 프로젝트의 중요점들을 확인해 주었습니다. 우리는 일주일에 걸쳐 발생한 일들에 대한 확인도 하였습니다.

사진에는 각종 측정값(metrics)이 적혀 있습니다. 프로젝트의 수치화는 필요이상 하지 않도록 조정하였습니다. 개발 코드의 양과 테스트 코드 양에 대한 특별한 대책이나 조정을 하지 않았습니다만, 흥미롭게도, 개발 코드와 테스트 코드는 위의 그래프에서처럼 거의 유사한 결과값을 보였습니다.

문제점들에 대한 측정을 위해서 두가지 측정방법을 사용하였습니다. 첫번째로, 인수테스트가 예정보다 늦어지면 그것에 대한 원인을 추적하게 하였습니다. 일시적으로 개발자를 인수테스트로 돌려서, 고객의 엄격한 관찰 아래에 인수테스트를 실시하게 하였습니다. 원인의 측정을 위해서 인수테스트가 진행되지 않는 스토리를 파악했습니다.

두번째는, 개발자들이 아직 온전히 완성되지 않고 있다고 느끼는 경우에 사용하였습니다. 사진에서는 고객의 대외비 보호를 위하여 항목을 흐릿하게 처리했습니다만, 이것은 특정 항목에 대한 양을 측정하고 있는 모습입니다. 적히는 정량을 통하여 상태를 확인할 수 있습니다.

5. 범용 화이트 보드

분석이나 설계할 때는 화이트보드를 활용했습니다. 화이트 보드 하나로 충분했다고는 할수 없습니다. 만약에 프로젝트 기간이 더욱 길다면, 더 많은 화이트 보드가 필요할 수 도 있겠지요.

6. 스토리카드 보드

이 스토리카드 보드가 제품 개발에 중심이 되었습니다.

보드는 3개의 영역으로 나뉘어져 있습니다. 위에서 3번째 줄까지는 최근에 완료한 스토리가 놓여집니다. 숫자가 적혀있는 메모가 같이 놓여져 있는데요. 그것은 몇번째 반복이며, 몇개가 완료됬는지를 보여주는 것입니다. 그 아래의 왼쪽부분에는 현재 일정이 진행중인 스토리가 놓여집니다. 각 줄마다 일주일(1반복주기)만큼의 스토리를 놓고, 총 9주의 스토리를 보여줍니다. 보드의 우측에는 일정이 정해지지 않은 스토리들을 고객이 정한 비지니스 우선순위에 따라 늘어놓았습니다. 추가적으로 맨 아래에는 아이디어 코너를 만들었으며, 도 비품보관통도 달아 놓아서 포스트 잇이나 카드 및 필기도구를 넣어놓았습니다.

스토리카드 작성에는 다음과 같은 방식을 적용하였습니다.

• 초록카드 - 엔드유저를 위한 기능
• 파란카드 - 개발자를 위한 기능
• 보라카드 - 스파이크 솔루션 개발
• 오렌지색 탭 - 인수테스트 미완료
• 붉은색 탭 - 고객으로부터 비지니스 요구사항을 듣고 측정이 필요함
• 붉은 포스트잇 - 고객에게 할 질문
• 노란색 탭 - 릴리즈 등의 중요 마일스톤(이정표) 기입

개발이 진행되는 작업실 중앙에 이런 큰 게시판을 설치하는 것은 상당히 멋진일입니다. 스케줄에 대해 고민이 될때면, 이 보드 앞에서면 됩니다. 스토리카드를 사용하는것은 큰 수확을 보장해 줄 것입니다.

구조

고객인 James Home께서 동네에 있는 Home Depot이라는 가게에서 대충 재료를 사다가 만들어 주었습니다. (형태는 William Pietri의 자료에서 배워서 만들었습니다.) 가로에 L자 형태의 플라스틱 판을 붙여 놓았습니다. 스토리카드는 플라스틱 판과 목제 사이에 꽃을수 있게 하였고, 이들을 나사로 고정하였습니다. 분해도 간단하고, 아래의 바퀴덕분에 이동도 쉽습니다. 그런데 James는 이것을 한번 만들고 더 만들기 싫다는 군요. 이거를 만드는데 흥미가 있는 목수는 직접 메일을 보내주시요.

7. 개발자 워크스테이션

개발자 모니터는 두대의 1280*1024모니터를 사용하였습니다. 하지만, 키보드와 마우스는 1대씩만을 설치하였습니다. 우측의 화면에는 에디터가 보여지고, 그 외(웹브라우저, JUNIT, 탐색기, 쉘...)에는 모두 좌측 화면을 사용했습니다. Java개발에는 IntelliJ IDEA 및Ant ,Tomcat 을 사용했습니다. 모두 리눅스에서 작동시켰습니다. 책상위에는 필기도구와 메모장을 많이 놓아 두었습니다.

8. 이전 스토리카드 보드

스토리카드 보드의 공간을 만들기 위해서, 개발한지 오랜 시간이 경과된 스토리 카드는 이 게시판으로 이동시켰습니다. 이것에 의해 개발팀은 현재의 개발 대상이나 목표에 집중하면서도 지금까지의 개발 성과를 시각적으로 알수 있었습니다.

9. 개발 통합 서버

개발 통합 서버에는 CruiseControl 을 설치하였습니다. CVS에 새로운 버전의 소스가 체크인 할 때마다, CruiseControl 은 해당 변경을 탐지해서 자동빌드를 개시합니다. 빌드가 성공하면, 단위 테스트와 인수테스트가 실행됩니다. 모두 성공하면 기쁜음악이 연주되지만, 문제가 발생하면 슬픈음악이 연주됩니다.

용어정리

XP에 친숙하지 않은 사람들을 위해서 간단한 용어정리를 합니다. 보다 자세한 정보는 여러 멋진 사이트들을 통해서 얻을 수 있습니다. (역자: 영어사이트 입니다.) XP로 위시되는 기민한 방법론 컨설턴트로써 언제라도 질문을 받겠습니다.

• 작업실은 프로젝트 룸 혹은 사무실, 전쟁터, 감옥등으로 불리는 프로젝트에 전적으로 사용되는 공간을 의미합니다. 특별한 회의를 제외하고 우리 개발팀은 프로젝트의 모든 시간을 이곳에서 보냈습니다. 작업실의 다른 예는 William Wake's site에서 볼 수 있습니다.
• 스토리는 작업의 기본 단위로써, 적당히 둘러 말하면... 기능단위로 설명된 요구사항입니다.
• 각각의 반복은 우리 개발팀의 경우는 1주일이었습니다. 하지만 이것은 개발팀 마다 다를것입니다. XP에서는 고객이 사용 가능한 제품을 제공할 수 있는 반복 단계를 정의하도록 합니다.
• XP에서 고객이라고 부르는 사람이 스토리를 선택합니다. 고객은 product manager라고도 부릅니다.
• 각각의 스토리는 1~3까지의 추정되는 점수가 복잡도에 의해서 부여됩니다.
• 일주일동안 소화되는 포인트의 합계를 velocity라고 불럿습니다.
• 스토리를 통해서 개발에 필요한 기간을 추정하지 못하는 경우도있습니다. 그것을 가능하게 하기 위해서 사전 조사하거나 시험 개발을 하는것을 스파이크라고 부릅니다.
• XP의 실천사항중에 짝프로그래밍을 채용했습니다. 4명이 개발하는데 책상이 둘뿐인것은 짝프로프로그래밍을 하였기 때문입니다.

프로젝트 관계자

James Home이 XP의 고객 및 UI설계를 담당하였습니다. 또한 게시판 등을 만들었으며, 본 포스트의 사진을 촬영하여 주었습니다. William Pietri는  팀을 구성한 사람으로써, XP를 교육하였고 본 포스트의 원서를 작성하였습니다. Jim Kingdon ,Justin Sampson 및Brian Slesinsky는 개발자로써 프로젝트에 큰 공헌을 하였습니다.

본 포스트의 모든 문장과 사진의 저작권은 William Pietr와 James Home 에게 있습니다.