XP의 전반적인 이야기가 잘 요약된 듯 하여 여기에 적어 놓습니다. - Astromaker
익스트림 프로그래밍 인스톨드(?eXtreme Programming Installed)의 한국어판을 읽게 된 것을 환영합니다. 책이 출간된지 거의 2년이 지났습니다. 저는 이 새로운 서문에 그간의 시각을 추가할 수 있는 기회를 갖게 된 것을 기쁘게 생각합니다.%%% 책이 나오고 나서 제가 배운 것은 XP의 법칙과 실천사항(practices)에 관한 것들입니다. 우리가 이 책을 썼을 때, XP를 하기 위해서는 실천사항들을 정확히 행하는 것이 중요하다고 생각했습니다. 사람들이 XP를 시도할 때 그 실천사항을 정확히 행하는 것이 나는 그들이 켄트 벡(Kent Beck)이 설명한 대로 그리고 우리 책에 설명한 대로 실천사항을 지켜야 한다고 고집했습니다.%%% 시간이 지남에 따라, 사람들은 구체적인 실천사항들은 XP에 있어 중심적인 것이 아니며, XP의 근간을 형성하는 것은 어떤 정신 혹은 어떤 원칙들이라고 주장했습니다. 이 정신을 갖는다면, 이 실천사항들을 이해한다면, 곧 XP를 이해하는 것이라고 말합니다. 나는 이 견해가 옳다고 믿습니다만, 그렇다고 시작부터 자신만의 XP를 발명하라는 말은 아닙니다.%%% 무술에서 학생은 처음에 형 혹은 가타(가라데에서의 품세, 형 - 역자)를 선생이 가르치는 그대로 따라하도록 배웁니다. 나중에, 훨씬 나중에야 그 규칙을 어길 수 있고, 더 나중에, 마침내는 자신의 상황에 맞게 규칙을 맘대로 조정할 수 있게 됩니다.%%% 익스트림 프로그래밍은 이런 방식으로 접근해야 합니다. 실천사랑들은 익스트림 프로그래밍의 끝이 아니고 시작입니다. 처음에는 규칙을 배워야 하고, 그것을 정확히 지키고, 정말 갈 수 있는 데까지 가봐야 한다고 믿습니다. 할 수 있는 데까지 "익스트림"해져야(극단적이 되어야 - 역자) 합니다. 책에 설명된 대로 실천사항들을 수행하는 것을 익히기 전까지는 그 한계점을 찾으려고 하지 마십시오. 실천사항 중 어느 하나라도 제멋대로 변용하기 전에, 가능하다면 모든 실천사항을 함께 해보도록 노력해주시길 바랍니다. 실천사항들은 함께 작용하는 것이기 때문에, 그것을 모두를 배우고 함께 경험하는 것이 최선입니다. 가능하다면 말이죠.%%% 상황에 따라 이것이 힘들 수도 있겠습니다만, 할 수 있는 최선을 다하세요. 하지만 가능하다면, 실천사항들을 되도록 단순하게(simply) 행하는 것이 XP를 배우는 최선의 길입니다.%%% 제가 단순하다는 것은 무슨 의미 일까요? 간략하게 몇 개의 실천사항을 훑어가면서 각각을 시도해볼 수 있는 좋은 방법에 대해 몇 마디씩 해보도록 하죠.
전체 팀은 한방 안에서 함께 일해야 합니다. 모든 프로그래머들과 모든 고객들이 말이죠. 전화 걸기나 기타 프라이버시를 위해 사적인 방을 둘 수는 있습니다만 모든 작업을 한방 안에서 하도록 노력하십시오. 한방에서 모두 함께 일하는 것은 대부분의 팀에게 있어 따로 일하는 것보다 효과적입니다.%%% 자 그러면 고객 한 명 혹은 고객 팀이 필요합니다. 당신은 고객이 요구사항(requirement)을 써서 보내게 하는 "더욱 효율적"인 방법의 유혹을 받을 겁니다. 요구사항을 이해하는 누군가와 직접 일해보기 전까지는, 옆에 있는 그들이 종이 위나 혹은 전자 문서에 쓰인 말에 비해 얼마나 가치 있는지 이해하지 못할 겁니다.
계획 게임을 우리가 설명하는 대로 해보세요. 배포 계획(Release Planning)에서는, 고객이 스토리를 설명하게 하고 나서 프로그래머들은 그것들이 얼마나 어려운지 추정을 합니다. 정확도에 대해서 걱정하지 마세요. 속도(velocity; XP에서 load factor를 대치하는 팀의 진행 속도 측정치 - 역자) 계산이 알아서 처리할 것입니다. 어느 스토리가 더 크고, 더 작은지 추정해야 합니다. 1, 2, 3 같은 작은 숫자들을 사용하세요.%%% 반복 계획(Iteration Planning)을 할 때에도 우리가 설명하는 대로 하세요. 작업 계획(task planning)은 그룹으로 하세요. 이것은 중요한 설계 단계입니다. 작업을 고르는 사람들이 각자 최종 설계 결정을 내리도록 하되 대강의 설계 윤곽을 그리는 것은 그룹으로 하세요.
격주에 한번씩 실제로 돌아가는 소프트웨어를 고객에게 줄 수 있어야 합니다. 네, 심지어는 프로젝트의 첫 두 주간에도, 그리고 그 이후에도 격주에 한번이 되어야 합니다. 이것은 '__가능합니다.__' 시도해 보세요. 아마 좋아하게 될 겁니다.
고객 소유의 인수 테스트를 마련하지 못하는 것은 XP에서 가장 흔한 실수 중 하나입니다. 매 반복(iteration)마다 고객에게 인수 테스트 정의를 받도록 하세요. 고객이 그 테스트들을 정의하도록 도와주세요 - 조언을 해주세요. 그 테스트들을 구현하고, 바라는대로 시스템이 작동한다는 것을 고객에게 보여주세요. 고객은 더 나은 테스트와 더 나은 기능을 만드는 법을 배우게 될 것이고, 프로젝트에 참가하는 모두가 당신이 어디쯤 있는지 알게 될 겁니다. 인수 테스트를 작성할 도구를 기다리지 마세요. 다른 여타의 프로그램이나 테스트들처럼 그냥 프로그램하세요. 그 도구들이 시간이 지남에 따라 진화하도록 하세요. 중요한 것은 바로 테스트를 갖는 것입니다.
설계가 단순해지도록 힘쎄야 합니다. 어느 순간에라도, 설계는 현재 스토리만 가까스로 충족해야 합니다. 앞으로의 스토리에 집중하지 마세요. 리팩토링이 그걸 처리하도록 하세요.
짝(Pair)과 d께 작업을 하고, 짝을 자주 바꾸도록 하세요. 이 테크닉의 힘은 엄청납니다. 더 좋은 코드를 얻을 것이고, 더 잘 이해할 것이며, 무엇보다도, 더 나은 팀이 될 것입니다. 제품 코드(production code)의 모든 행을 두 명의 프로그래머가 함께 작업하면서 작성하도록 하세요.
테스트 주도 개발(Test-Driven Development)을 사용하세요. 작은 테스트 하나를 만들고, 그게 작동하게 한 다음, 또 다른 테스트를 만듭니다. 코드가 필요하다는 것과 그 코드가 무엇을 해야 하는지를 알려주는 실패 테스트가 있을 경우에만, 오로지 그 경우에만 새로운 코드를 작성하도록 해보세요. 이 테크닉은 환상적인 코드를 생산해냅니다. 매우 정확한 테스트를 대량으로 생산해내게 됩니다. 리팩토링에 준비하도록 해줍니다. 또 그 무엇보다도, 스트레스를 감소시켜 줍니다. 많은 테스트가 있을 때에는, 필요한 경우 프로그램을 변경하는 것이 두렵지 않습니다.
항상 설계를 개선할 필요가 있다는 것을 환기시키기 위해 나는 이 실천사항의 이름을 바꾸었습니다. 리팩토링에서 큰 파도를 경험하고 있다면 - 리팩토링할 것이 상당히 많을 때 - 이것은 당신이 진행해 나가면서 작은 리팩토링을 충분히 하고 있지 못하다는 말이 됩니다. 모든 테스트를 통과하고, 가능한 한 깨끗한 코드를 체크인(check in; 코드 저장고에 집어 넣는것 - 역자) 하도록 애쓰십시오.
팀의 모든 사람은 어느 때이건, 어느 코드이건 개선할 권한을 갖고 있습니다. 이것은 테스트를 개선하는 것을 포함합니다. 물론 모든 테스트를 실행하는 것도 마찬가지입니다. 그리고 코드 개선 중에는 짝 프로그래밍을 기억하세요. 프로젝트에 관여한 모든 사람을 모든 코드에 접근할 수 있게 함으로써, 우리는 이것이 팀 노력의 성과라는 것을 상기하게 되며 모든 사람의 아이디어에서 오는 이득을 얻을 수 있스빈다. 게다가, 모든 사람은 서로 배우게 됩니다.
코드를 프로젝트 속에 보관하지, 모래상자(실험용 장소 - 역자)나 당신의 로컬 컴퓨터에 보관하지 마십시오. 체크아웃(check out; 코드저장고에서 작업을 위해 가지고 나오는 것 - 역자)한지 오래된 코드는 체크인하기 어렵습니다. 코드의 통합이 어려워 보인다면, 이것은 코드 통합을 오히려 더 자주 해야 한다는 신호입니다. 최고의 팀들은 하루에도 여러 번 통합을 합니다. 이런 면에 있어서 최고의 팀 중 하나가 되도록 하십시오.
우리는 당신이 몇 시간이나 일하는 지에 대해 그다지 신경 쓰지는 않습니다. 그러나 당신이 일을 잘하고 있다면, 아마 대략 여섯 시간 동안의 집중적인 짝 프로그래밍이 효과적으로 일할 수 있는 최대한이라고 알게 될 것입니다. 팀의 퍼포먼스를 반복(iteration)당 끝마친 스토리를 측정하십시오. 그리고 결함이 생기는 비율에도 주의를 하세요. 당신의 팀만의 위한 최적 페이스를 찾으세요. 그 페이스는 주당 60시간보다는 40시간 부근일 공산이 큽니다. 이상적인 페이스가 무엇이건 간에, 그걸 찾아야 하고, 또 그 페이스에 맞춰 일할 필요가 있습니다.
XP 실천사항들을 그 순수하고 "익스트림"한 형태로 시도해주기 바랍니다. 쓰인 대로 그것들을 완전히 마스터했을 때에, XP가 당신에게 무얼 제공해줄 수 있는지 배웠을 것이고, 단순한 법칙을 넘어서서 형을 깨트리고, 자신만의 형을 창조할 준비가 될 겁니다. 시작점에서 출발하고, 기본을 마스터하는 것이 최선입니다. 그러고 나서 그것들을 넘어 서야죠.
여러분들이 익스트림 프로그래밍을 즐기길 바랍니다. 시험 삼아서 한번 해보면 그것이 유용하다는 것을 알게 되리라 확신합니다. 어떻게든 제가 여러분에게 도움이 될 수 있다면, 부담마시고 제게 이메일을 보내주세요. 행운을 빕니다. 그리고 즐겁게 일하시길!
론 제프리즈(Ron Jeffries)%%% ronjeffries(at)acm.org
| 제일 위로 |
| 최종 수정 일시: 04월 28일(2003년) 07:02 AM 편집 | 정보 | 차이 | 비슷한 페이지 DebugInfo |
| 유용한 페이지들: 분류 분류 | 자유로운 연습장 SandBox | 무작위 페이지들 RandomPages | 인기있는 페이지들 MostPopular |