birdkr's home

7월 한달간 팀에서 시범적으로 짝 프로그래밍을 실시해 보기로 하고 '플레이어간 동기화'에 대한 작업을 진행했는데, 이즈나라님이 그 경험담을 블로그에 올려놓으셨다.

• 이즈나라님의 Pair Programming 경험담
  

결과적으로 어느 정도 성과를 거두어 좀 더 사용해 보기로 결정하였다. 이번에는 두 명만 짝 프로그래밍을 하는 것이 아니라 희망하는 팀원 모두 짝 프로그래밍을 해보기로 하였는데, 모든 작업을 다 짝 프로그래밍으로 진행하기에는 무리가 있고 일단은 전체 작업중 일부 짝 프로그래밍에 적당한 작업을 골라서 해보기로 하였다.

앞으로 이것이 단지 실험으로만 끝날지, 아니면 좀 더 좋은 방향으로 나아가기 위한 밑거름이 될지는 좀 더 지켜봐야 할 것 같다.

Noel Llopis님 블로그의 A Day in the Life라는 글을 번역해봤다. XP중에서도 특히 짝 프로그래밍으로 게임을 개발 하는 모습을 생생하게 보여주고 있다.

XP 게임 회사의 하루(A Day in the Life)

출처 : Games from Within(http://www.gamesfromwithin.com/articles/0602/000104.html)
작성 : Noel Llopis
번역 : 남기룡(birdkr), 이승애(교정)

High Moon Studio는 게임 산업에서 특이한 회사이다. 우리는 개발 전 부분에 애자일 방법론을 적용하고 있다. 우리 팀은 특히 애자일 관리 방법론인 Scrum과 애자일 기술 방법론인 Extreme Programming 둘 다 사용하고 있다. 물론, 그것은 우리가 짝 프로그래밍, 테스트-주도 개발 그리고 그 외에 모든 논란이 많은 방법들을 종종 사용하고 있다는 것을 의미한다. 나는 몇 년 안에 이 실천법들이 지금보다 훨씬 일반적이 될 것이라고 예상한다.

나는 여기서 R&D 팀을 이끌고 있고, 우리 팀의 주된 책임은 게임 팀들이 여러 가지의 프로젝트에 사용하는 기술을 개발하는 것이다. 요즘에 그것은 게임 팀의 페이스에 많은 미들웨어 프로그램을 만들어 넣고 그 중에서 우리의 필요에 맞는 것을 고르는 것을 의미한다.  그러나, 그것은 굉장히 많은 양의 작업과 엔진과 툴의 많은 코드를 작성하는 것을 의미한다.

그것을 상기한 채로, 주중의 평범한 나의 하루를 따라가보자.

8:10 AM
나는 평상시처럼 자전거를 타고 출근한다. 내가 일찍 일어났음에도 우리 팀 프로그래머인 짐(Jim)은 몇 분 먼저 도착해 책상에 이미 앉아있었다. 나는 바로 이 메일을 확인한다. 나는 또한 우리의 codebase의 PCLink 패스가 몇 개의 작은 경고를 잡은 것을 확인한다. 그래서 바로 그것들을 고치고 체크인 한다.

8:20 AM
오늘은 화요일이고, 2주 반복되는 이터레이션이 금요일에 끝난다.  이터레이션은 고정된 기간(보통 우리의 경우에는 2주)으로 구성되어 있으며, 이 기간 동안 팀은 고객의 스토리를 통해 기술된 기능 집합작업을 맡는다. 고객(우리의 경우 사내에 있는 다른 내부 팀)은 스토리 집합을 만들고 우선 순위를 매긴다. 그 다음에 우리 팀은 그 스토리들을 작업으로 분류하고, 완료하는데 얼마나 걸릴지 추정한다. (작업은 1시간에서 8시간 사이로 추정한다.)

짐(Jim) 과 나는 "워룸(war room)"(벽에 붙여진 사용자 스토리의 작업 카드가 있는 방)으로 간다. 그리고 우리는 "rigid body를 캐릭터에 던져서 히트 리액션을 보는 것" 이라는 사용자 스토리의 작업 목록 중에 "ragdoll과 애니메이션 블렌딩"이라고 적혀진 작업을 선택한다. 작업은 원래 3시간으로 추정되었지만, 지금 우리는 ragdoll 시스템이 우리가 생각했던 것보다 좀 더 복잡하다는 것을 안다. 그래서 4시간으로 다시 추정한다.

8:23 AM
자기 개인 자리 이외에, R&D 랩에는 두 개의 모니터, 두 개의 키보드, 두 개의 마우스, 두 개의 의자, 그리고 두 사람을 위한 넉넉한 공간이 있는 짝 프로그래밍 스테이션이 있다. 모든 제품의 코드는 2인조의 프로그래머들이 작성한다. 우리는 자리를 잡고 작업을 시작한다.

우리는 테스트 주도 개발을 사용하고 있기 때문에, 우리는 먼저 우리가 하려고 하는 것을 위한 아주 간단한 유닛 테스트를 작성하고, 단지 테스트를 통과하도록 코드를 작성한다. 이 경우에, 첫 번째 테스트는 입력 없이 블렌더(blender) 오브젝트를 만드는 것과 그것이 아무런 산출물을 만들지 않는 것을 검사한다. 그 후 우리는 블렌더 클래스를 만들고 테스트를 통과하도록 만들었다. 이것은 아주 작은 단계지만, 올바른 방향으로 나아가기 위한 단계이다. 테스트를 만들고, 테스트를 통과하는 코드를 만들고 리팩토링하는데 걸리는 시간은 겨우 5분에서 10분, 그리고 우리는 그것을 계속해서 실행한다.

8:39 AM
우리는 약간의 기능을 구현했는데, 모든 코드를 빌드하고 모든 테스트를 통과하여 소스 컨트롤에 코드를 체크인한다. 이것은 지속적인 통합이라 불리는데, 프로그래머가 소스 컨트롤의 최종 버전으로 작업하고 하루 종일 여러 번 코드변화를 체크인 하도록 요구한다.

8:50 AM
다른 팀원들이 도착해서 짝 프로그래밍 자리를 잡고 일을 시작한다. 자리를 잡으면서 우리와의 짧은 대화로 그들은 우리가 무슨 일을 하고 있는지 알아낸다.

Work hard...

9:37 AM
나는 조엘(Joel)과 게리(Gary)가 물리 시뮬레이션 업데이트 요구사항을 어떻게 테스트할지에 관해 토론하는 것을 우연히 들었다. 난 겨우 며칠 전에 그것을 작업했기 때문에 그 토론에 참가한다. 알고 보니 그들이 내가 이미 했던 것과 거의 같은 것을 작업해야 해서 나는 그들에게 내가 작성했던 것을 가르쳐 줬고, 그들은 그것을 그들의 필요에 맞게 수정할 것이다.

10:05 AM
모든 것이 제대로 진행되고 있다. 우리는 아침에 이미 4번이나 체크인했다. 두 명의 프로그래머가 정말 속도를 낸다면, 하루에 20번 이상 체크인할지도 모른다. 이 비율로 우리는 우리가 추정했던 4시간 보다 더 빨리 완료될지도 모른다.

10:14 AM
10시 15분에는 매일하는 스크럼 미팅이 있어서 우리는 워룸으로 갔다. 전체 팀원(8명에 우리 프로듀서인 브라이언(Brian)까지 더해서)이 서서 하는 스크럼 미팅은 아주 짧다. 우리는 모든 사람들이 속도를 높이기 위해 하고 있는 것들을 토론하기 위해 서로 의견을 나누었다.

10:23 AM
회의하는 동안 우리가 물리 자산을 어떻게 로딩해야 하는지에 관한 화제가 생겼다. 그래서 우리는 짝 프로그래밍 지역으로 돌아와서 관련된 사람들과 짧은 토론을 가졌다. 우리는 화이트 보드에 즉석으로 몇 개의 UML 차트를 그리고 어떻게 데이타가 전달될 것인지에 대해 생각한다. 그리고 10분 후 우리는 합의에 이르렀고, 다시 우리 작업을 하기 위해 자리로 돌아왔다.

11:15 AM
우리는 블렌딩이 제대로 작동되게 하였다. 비록 우리는 데모를 아직 다 구현하지 않았지만, 모든 유닛 테스트가 통과되었다. 데모 구현을 위한 또 다른 작업 카드가 있다. 우리는 바로 코드를 체크인 한다. 우리는 그것이 작동하는 것에 집중하고 있었기 때문에 코드는 몇 부분이 개선되는 동안 충분히 견딜 수 있다.  그래서 우리는 리팩토링하는데 시간을 좀 보냈다. 우리는 많은 유닛 테스트를 했기 때문에 리팩토링이 아무런 버그도 만들지 않는다는 확신이 있었다.

11:56 AM
코드는 이제 훨씬 더 좋은 상태가 되었다. 우리는 체크인하고 빌드 서버가 모두 올바르게 빌드되고 모든 테스트가 통과했는지 리포트 하기를 잠시 기다렸다. 그 동안 우리는 다음 작업을 무엇으로 해야 하는지에 대해서 대화를 나누었다.

12:05 PM
오늘은 멋진 어깨 높이의 파도가 친다. 그래서 나는 여러 명의 팀원들과 점심에 파도 타기하러 나간다. 파도 타기를 하지 않을 경우에는 농구, 싸이클, 러닝이나 요가를 한다. 모두 싫으면, 하이문(High Moon) 클랜의 남은 사람들과 항상하는 길드워 게임이 있다.

1:10 PM
나는 책상으로 돌아와서 짝 프로그래밍을 하느라 아침부터 확인하지 못했던 이메일을 확인하면서 점심을 빠르게 먹었다. 나는 미들웨어 개발자로부터 온 오늘 일찍 보냈던 질문에 대한 답변 이메일을 읽고 빠른 답변을 보냈다.

1:25 PM
숀(Sean) 이 내 자리에 들렀다. 그는 다시 일할 준비가 되었지만, 아침에 그와 짝으로 있던 프로그래머가 우리 일 중에 우선 순위가 제일 높고 출시를 얼마 남기지 않은 Darkwatch의 몇 가지 막판 문제점을 작업하는 일이 호출되어 그 일을 하게 되었다. 션(Sean)은 짧게 둘이 아침에 작업했던 것을 나에게 설명해줬다. 그것은 우리의 물리 시스템에 이용되는 정확한 메모리 사용을 표시하기 위한 작업이었다. 나는 오늘 아침 스크럼 미팅에서 언급했던 것을 기억했다. 나는 또한 지난주에 물리 시스템을 작업했었다. 그래서 나는 그 코드에 아주 익숙하다. 몇 분 후 우리는 이미 진전을 보이고 있다.

... rock hard :-)

2:07 PM
몇 개의 유닛 테스트를 작성하고 기능을 구현한 후, 우리는 데모 프로그램에 메모리 표시를 추가할 준비가 되었다. 몇 분 후 우리는 데모에 물리 시스템이 얼마나 많은 메모리를 사용하는지 가리키는 화면을 만들었다. 그리고 우리는 데모에서 rigid body를 더하거나 뺄 때 메모리가 올라가고 내려가는지를 확인한다.

그런데 뭔가 잘못되었다. 우리가 rigid body를 제거했을 때, 메모리는 그 전 수준으로 내려오지 않았다. 우리는 데모를 종료하고 메모리 누수 덤프를 확인한다. 우선 먼저 우리가 바꾼 것을 확인하고, 메모리를 누수하고 있는 코드를 찾기 시작한다. 그것은 아마도 우리가 작성한 코드 때문은 아닐 것이다. 그러나 우리는 "공동 코드 소유권"을 가지고 있었고, 그것은 우리 모두가 어떤 부분이든 고쳐야 하는 것은 모두 고치는 것이 요구되는 것을 말한다.

2:12 PM
방금 빌드가 깨졌다. 빌드 서버는 실패된 빌드를 검출하고 시스템 트레이 어플리케이션을 통해 우리에게 통지한다. 나는 마지막 빌드 로그를 꺼내서 릴리즈 모드에서 실패한 유닛 테스트중 하나를 확인한다. 우리 옆 자리에 앉아있는 타이슨(Tyson)이 "아, 그게 뭔지 알아요, 제가 바로 고칠께요" 라고 말했다. 그는 30초보다 짧게 그것을 수정하고 체크인한다. 몇 분 후 빌드 시스템은 빌드가 통과되었다고 보고했고, 모든 것이 다시 정상으로 돌아왔다.

2:17 PM
우리는 메모리 릭을 찾았다. 그것은 레퍼런스 카운팅을 잘못 사용하고 있는 거였다. 우리는 먼저 그것이 실패하는 유닛테스트를 만들고 그리고 나서, 우리는 물리 라이브러리를 고치고 코드를 체크인 한다.

2:18 PM
우리는 워룸으로 가서 다음 작업을 가져왔다. 이 작업은 여러 가지 변수와 함수를 데모에서 나타나게 하여 GUI를 통해 조절할 수 있게 하는 작업이다.  우리는 그 작업에 사인하고, 작업을 시작한다.

3:43 PM
우리는 무아지경이었다.  미친 듯이 테스트와 코드를 작성했고 이 작업은 아주 잘 진행되고 있다. 우리는 지난 한 시간 동안 이 작업으로만 관련해서 체크인을 세 번 했다.

4:12 PM
다른 짝이 몇몇 특이한 경우에 어떻게 에러를 처리할 지를 토론하고 있었다. 이것은 중요한 화제이고, 모든 코드에 일관되게 행해져야 해서 우리는 팀원 대부분을 포함하여 그것에 관해 빠른 토론을 가졌다. 5분 후 우리는 결론을 짓고 하던 일을 다시 시작한다.

5:40 PM
우리는 오늘의 마지막 체크인을 한다. 그 작업을 거의 끝마쳤지만 아직 완전히 끝내지는 못했다. 한 시간 더 작업을 해서 그것을 끝내볼 수도 있지만, 우리는 이제 완전히 지쳤다. 그래서 명확하게 생각하지 못하기 시작했고, 뭔가 실수할 것이다. 우리는 내일 아침에 오자마자 이것을 마무리 지을 수 있다.  중요한 점은 체크인을 할 수 있는 상태로까지 발전한 것이다.

우리는 누구도 코드를 체크인하고 떠날 수 없다는 규칙이 있다. 빌드 서버가 코드를 성공적으로 빌드하고 모든 테스트를 통과하는 것을 기다려야 한다. 우리는 빌드타임을 짧게 만들기 때문에 거의 보통 4-5분 정도는 기다려야 한다는 것을 의미한다. 뭔가 중단되면, 당신은 그것을 고치거나 당신이 했던 것을 돌려놔야 한다. 깨진 빌드인 채로 떠나는 것은 용서가 되지 않는다.

나는 빌드 서버가 끝내는 것을 기다리는 동안, inbox에 오늘 쌓인 이 메일 더미를 확인한다.

5:44 PM
몇 분 후 빌드 서버로부터 녹색으로 진행된 것을 확인한다. 오늘은 아주 생산적인 날이었다. 그리고 이 속도로 우리는 금요일까지 확실히 모든 유저 스토리를 완료할 것이다. 우리가 함께 만들고 있는 데모는 이미 아주 멋있어 보이기 시작하고 있다.

애자일 개발 중에 특히 짝 프로그래밍은 매일을 매우 집중하도록 만든다. 이메일을 읽거나, 웹사이트를 확인하거나 빈둥거릴 시간이 없다. 우리는 근무 시간에 많은 것을 얻게 된다. 그러나 그 페이스를 오랜 시간 동안 유지할 수는 없다. 그래서 그것을 멈추고 퇴근하는 것이 중요하다. 그것은 집에서 기술 서적을 읽거나, 프로토타입의 다른 아이디어를 떠올리게 하거나, 편한 다른 프로젝트를 하거나, 가족과 시간을 보내거나, 다른 취미를 즐길 수 있도록 시간을 준다.

나는 자전거에 뛰어 올라 크게 미소 지으며 집으로 향한다.