이 글은 jacking님께서 번역하신 글입니다. - Astromaker

eXtreme Programming explained

본서 목적은 Extreme Programming(XP)에 대해서 설명하는 것이다. XP는 소중규모의 팀에서 변하기 쉬운 요구에 맞추어주며 서로 마주보면서(같은 장소) 소프트웨어를 개발하는 라이트급의 방법론이다. 왜 extreme(궁극)이라는 단어가 명칭에 포함되어 있을까. XP는 상식을 원리로 하고, 극한까지 실천하기 때문이다.

• 코드 리뷰가 좋아서 한다면, 언제라도 코드 리뷰를 한다. (페어 프로그래밍)
• 테스트가 좋아서 한다면, (팀) 전원이 언제라도 테스트를 하고 (단체 테스트), 고객도 테스트를 한다.(기능 테스트)
• 설계가 좋아서 한다면, 설계를 (팀) 전원의 일상 일의 일부로 한다. (리팩토링)
• 심플한 것이 좋다면, 시스템을 지금 이상으로 기능을 만족하면서 좀더 심플한 상태로 한다. (정확하며 좀더 심플한 상태)
• 아키텍쳐가 중요하다면, (팀) 전원이 계속 아키텍쳐를 정의하고 다듬는다. (메타포)
• 결합 테스트가 중요하다면, 하루에 수회 결합시키고 테스트한다.
• 짧은 이테레션이 좋다면, 이테레션을 짧은 단위로, 주/월/년이 아니 초/분/시 단위로 한다.(계획 게임)

XP는 2종류의 약속을 한다.

프로그래머에게 대해, XP는 프로그래머가 매일, 중요한 업무에 열중 할수 있도록 약속한다. 프로그래머는 불안한 상황에 자기 혼자만 직면하지 된다. 시스템을 성공 시키기 위해서, 자신의 힘으로 모든 할 수 있는 일을 할 수 있도록 된다. 최선을 위해서 결단을 내리고, 자신이 적임이지 않은 일에 관해서는 결정은 내리지 않는다.

고객과 매니져에 대해, XP는 매주마다 어느 프로그래밍으로부터 최고의 가치를 얻을 수 있다는 것을 약속한다. 수주간마다 골을 향해서 구체적인 진보가 보일도록 한다. 계획 외의 코스트가 생기지 않도록 하고, 개발 도중에서 프로젝트의 방향이 변하는 것이 가능하도록 한다.

다시 말해, XP는 프로젝트의 리스크를 줄이고, 비지니스 변화에 리스폰스(적응)를 개선 하고, 시스템의 가동기간(라이프)을 통해서 생산성을 향상시키고, 동시에 팀에게 소프트웨어를 만들때 기쁨을 느낄 수 있도록 약속한다.

XP라는 것은 무엇인가 ?

XP는 뭘까. XP는 라이트급으로, 뛰어나고, 적은 리스크, 응용이 좋고, 예측가능하며, 과학적으로, 재미있게 소프트웨어를 개발하는 개발 방법이다. 이하의 점에서 타방법론과 구별된다.

• 짧은 사이클로 빠르게 구체적으로 컨스택트한 피드백을 행한다.
• 빠르고 전체의 계획을 성공시키는 인텔리털한 계획에 의한 어프로치 그 계획은 프로젝트의 활동기간중 계속 개선되어진다.
• 비지니스의 수요의 변화에 대응하여 기능의 구현을 유연하게 스케줄 한다.
• 개발의 진척을 감시하고, 시스템을 전개시켜, 결함을 조기에 발견하기 위해서 프로그래머와 유저(고객)가 작성한 자동화된 테스트로부터 신뢰가 얻을 수 있다.
• 시스템의 구조와 목적을 알리기 위해서의(口頭로) 커뮤니케이션, 테스트, 소스코드로부터 신뢰를 얻을 수 있다.
• 시스템이 계속하는 한 발전적인 계획 프로세스로부터 신뢰를 얻을 수 있다.
• 일반적인 스킬(skill) 프로그래머가 밀접하게 협력하는 것에 의해 신뢰를 얻는다.
• 프로그래머의 단기적인 직감과 프로젝트의 장기적인 이익 양쪽을 만족시키는 실천으로부터 신뢰를 얻는다.

Out Line

본책은 3개의 섹션으로 나누어져 있다.

• 문제 - "리스크:기본적문제"의 장부터 "기본으로 돌아간다"의 장까지는 익스트림 프로그래밍이 풀려고 하고 있는 문제를 설정하고, 해결책을 평가 하기 위해 기준을 제공하고 있다. 이 섹션은 익스트림프로그래밍의 전체상에 대해서 아이디어를 줄것이다.

• 해결책 - "개략" 장부터 "테스트 전략" 장까지는 제 1섹션의 추상적인 아이디어를 구체적인 방법론 이라고 말하는 실천으로 변환한다. 이 섹션에서는 어떻게 그 실천을 실행할까에는 엄밀하게는 이야기하지 않고, 일반적인 형에 대해서 진술한다. 각 실천의 이론은 제 1섹션에 잡은 문제와 원칙에 관련되어 있다.
• XP를 구현한다 - "XP를 채용한다"의 장부터 "직장에서의 XP"의 장까지는 XP의 구현에 관련된 여러가지 화제, 어떻게 채용할까, 궁극적으로 프로젝트에 관련되어 있는 사람에게 무엇을 기대할까, XP가 시스템 이용자에게 어떻게 받아 들여지고 있는가, 라고 하는것에 대해서 쓰여 있다.

제1 섹션

문제

이 섹션에서는 소프트웨어 개발에 유효한 새로운 규율의 확립에 의해 해결되는 문제의 여러가지 측면을 의논하고, 익스트림 프로그래밍의 무대를 설정한다. 그리고, 소프트웨어 개발의 다양한 국면애 대처 할 수 있는 방안을 선택하기 위해서 사용하는 기본적인 가정을 의논한다.

제 1장

리스크 : 기본적인 문제

소프트웨어 개발의 기본적인 문제는 리스크이다. 리스크의 예를 들어보면

• 스케줄 연장
• 프로젝트의 취소
• 시스템의 진부화(陳腐化) - 소프트웨어는 무사하게 가동에 들어 갔지만, 수년 후에는 개량을 위해서 코스트 또는 결함율이 너무 높아저서, 시스템을 교체해야 된다.
• 결함율
• 비지니스의 오해 - 소프트웨어는 가동에 들어갔지만, 당초 제기된 비지니스상의 문제는 해결되지 않았다.
• 비지니스의 변화
• 오해된 기능강화 - 소프트웨어는 잠재적으로 재미있는 기능을 가지고 있어 프로그램하는 것은 재미있다. 그러나, 그러한 것이 유저에게 이익이 되는 것은 아니다.
• 스탭의 퇴직

XP는 바로 이러한 것들에 대해서 대처 할수 있게 해준다. XP는 생산성을 높이고, 고품질의 소프트웨어를 생산하고, 실천하면 기쁨도 늘어나게 된다.

XP는 어떻게 위의 리스크에 대처할까.

• 스케쥴의 연장 - XP는 짧은 리리스 사이클을 요구한다. 길어도 수개월. 그렇게 하면 연기의 범위가 한정된다. 하나의 리리스로 XP는 1-4주간의 이테레이션을 소비한다. 이테레이션에서는 유저가 요구하는 기능에 전진하며 세밀한 피드백을 행한다. 하나의 이테레이션 속에서, XP는 1-3일의 태스크를 계획하고 그 사이에 발생하는 문제를 해결하는것도 가능하다. XP는 중요한 기능을 먼저 실천하는 것을 요구한다. 그 결과 리리스에 늦어진 기능은 앞에 구현한 기능보다 덜 중요한 것이 된다.

• 프로젝트의 취소 - XP는 유저에게 비지네스 상에서 높은 가치가 있는 최소규모의 리리스를 선택하게 한다. 그 결과, 가동에 들어 가기 전에 프로젝트가 나쁜 방향으로 흘러가는 일은 조금도 없게 되고, 소프트웨어의 가치는 최대가 된다.

"소프트웨어의 가치" 라는 것은, 개발된 소프트웨어에 의해, 유저가 얻어지는 이익이 많을수록 가치가 높다고 말하는것을 의미한다.

• 결함율 - XP는 프로그래머가 적은 함수 하나 하나와, 엔드유저가 적었던 프로그램 기능을 양쪽의 시나리오(관점)로부터, 테스트를 한다.

• 비지니스의 오해 - XP는 유저에게 팀에 합류하는 것을 요구한다. 프로젝트의 작업은 개발시에 체크되어 팀은 유저로부터 배운 것을 소프트웨어에 반영시킨다. (유저(고객)가 팀과 같이 일하면서 비지니스 상의 일에 대해 팀에 이해 시킨다는 뜻임.)

• 비지니스의 변화 - XP는 리리스 사이클을 짧게 설정한다. 그 때문에 하나의 리리스내에서 비지니스의 변화에따라 일이 변화하여도 영향을 받지 않는다. 리리스 동안에 유저는 아직 완성하지 않은 기능에 대해서 새로운 아이디어를 넣든지 바꿀수가 있다.

• 오해된 기능 강화 - XP는 최우선의 가장 중요도가 높은 일만을 취급한다.

• 스탭의 퇴직 - XP에서는 프로그래머는 자신의 일을 정확하게 파악하고 개발시간 동안 세밀한 피드백을 받는다. 그리고 자신의 일에 대한 계획은 충실하게 지킬 것을 요구한다. 그리고 프로그램 작성 기간을 명확하게 정하기 때문에 불가능한 일을 요구하지 않아 프로그래머가 욕구불만이 되는 일은 별로 없다. XP는 팀에서의 인간 관계를 중요시하고 직장에서 고독감에 빠지지 않도록 한다. XP는 스탭의 교체시에는 구체적인 대응책을 준비하고 있다. 새로운 멤버는 서서히 증가해 가는 책임을 자각하고, 타 멤버에게 도움을 받아 가면서 팀에 융화된다.

우리들의 사명

해결해야 되는 문제가 프로젝트 리스트로 있다면, 어디에 해결책을 찾으러 갈까. 필요란 것은 이러한 리스크를 취급하는 소프트웨어 개발 스타일을 확립하는 것이다. 이 규율을 프로그래머, 매니져, 유저(고객)에 할수 있는한 명확하게 알려주지 않으면 않된다. 이 스타일을 본서의 제 1섹션과 제 2섹션에서 해결하고 있다. 일보씩 개발의 새로운 스타일이랑 규율을 만들때 문제점을 보고, 그 후 문제를 풀어간다. 기본적인 가정으로부터 계획, 테스트, 개발, 배치라고 하는 소프트웨어 개발에 있어 여러가지 활동을 어떻게 연동 시키고, 보다 좋은 개발 스타일을 확립하기 위해서 무엇이 필요한가에 대해서 생각하자.

제 2장

간단하게 요약합니다.

• 프로그래머는 페어로 되어(2명씩), 함께 프로그래밍한다. - 2명씩 짝이 되어 서로 번갈아가며 코딩(어떤 문제에 대해 확실한 생각을 가지고 있는 쪽이)하며, 코드에 대해서 서로의 의견을 나누면서 고쳐나감

• 개발은 테스트에 의해 시작되고, 테스트에 의해 끝이 난다. 먼저 테스트하고 다음에 코드를 적는다. 모든 테스트가 통과되지 않으면 종료 되지 않는다. 모든 테스트가 통과, 실패 할것 같은 테스트가 떠오르지 않을 때 기능추가가 끝난 걸로 한다. - XP의 특징 중의 하나로 기존의 방법과 다르게 설계나 코딩 보다 먼저 테스트를 하고 코드를 적어면 최적화 될때 까지 계속 리팩토링 함.

• 페어는 테스트 케이스를 실행시키는 것만이 아니다. 시스템의 설계도 개량한다. 갱신은 특정의 영역에 한정되지 않는다. 페어는 시스템의 분석, 설계, 구현, 테스트에 더욱더 가치를 부여한다. 시스템이 필요로 하는 모든 장소에 가치를 부여한다.

• 결합은 결합 테스트도 포함, 개발 직후에 행한다.

제 3장 소프트웨어 개발의 경제학

- 별 다른 내용이 없어 그냥 통과합니다.^^

제 4장 4개의 변수

- 코스트, 시간, 품질, 스코프라는 4개의 변수를 프로젝트에서 관리해보자. 이 중에서 스코프는 가장 관리 할 가치가 있는 것이다.

변수를 시스템을 관리하는 시점으로 본 소프트웨어 개발 모델이다. 이 모델에서는 소프트웨어 개발에 4개의 변수가 있다.

• 코스트
• 시간
• 품질
• 스코프(프로그램의 기능 중 추구하고 싶은 것. 게임을 예를 들면 그래픽을 중점으로 할건지 아니면 AI를 중점으로 하는가를 말한다.)

이 모델에서 소프트웨어 개발 게임 방법은 외부의 힘(유저(고객),관리자)가 3개의 변수 값을 정한다. 개발팀은 남은 4번째 변수의 값을 정한다. 관리자랑 유저 중에는 4개의 변수 모두의 값을 정 할려고 생각하는 사람도 있다. "전부 요구를 만족시키며 다음달 초까지 완성시켜주세요. 물론 품질은 최우선으로 하고" 이런 이야기를 들은 경우, 품질은 항상 창 밖으로 내던져진다.(통상은 보통 정도로 할려고 하지만) 스트레스 많은 환경에서는 좋은 일은 할수 없기 때문이다. 또 시간도 관리 할수 없게 되는 경향도 있다. 결국 납기가 늦어져 소프트웨어의 가치가 없게 된다.

해결책은 4개의 변수를 눈에 보이는 형으로 하는 것이다. 어쩌면, 모든 사람 (프로그래머, 유저,관리자)이 4개의 변수 모두를 보는 것이 가능하다면, 어느 변수를 관리 해야 될것인가를 확실하게 선택 할수 있다.)

변수간의 상호작용

• 코스트 - 투입하는 자금이 많으면 프로젝트를 원활하게 진행 할수 있지만, 초기에 필요 이상으로 많은 자금을 투입하면, 역으로 풀어야 할 문제 이상의 문제를 일으킨다. 반대로 프로젝트에 주여지는 자금이 너무 작으면, 유저(고객)의 비지니스 문제를 풀수 없게 되기도 한다.
• 시간 - 남품까지 시간이 너무 길면, 품질은 향상하고, 스코프는 늘어난다. 그러나, 가동중의 시스템으로부터의 피드백은 다른 어느 류의 피드백 보다도 중요하다. 그 때문에 남품까지의 시간을 너무 길게 잡으면, 귀중한 피드백을 얻을 찬스를 잃어 버린다. 역으로, 프로젝트에 주여지는 시간이 작으면 품질이 훼손된다. 이를테면, 스코프에 주여지는 영향은 시간쪽이 코스트보다 훨씬 크다.
• 품질 - 품질은 관리하는 변수로써 취급하기 어렵다. 의식적으로 품질을 희생하는 것은 단기적으로(수일이나 수주간) 이익은 얻을 수 있지만, 인간적, 비지니스상, 또는 기술적면으로 잃어버리는 코스트는 거대하다.
• 스코프 - 스코프를 작게하면, (유저의 비지니스상의 문제를 해결하고 있는 한) 납품물의 품질을 높이는 것이 가능하다. 보다 쉽고 빠르게 납품하는 것이 가능하다.

4개의 변수간의 관계는 단순하지 않다. 예를 들어 자금을 많이 사용하여도, 바르게 소프트웨어를 만들수는 없다. "여자를 9명 모아도 아기는 1개월만에 태어나지 않는다" 는 것이다. 여러가지 면으로 코스트는 좀더 제약이 있는 변수 이다. 품질, 코스트, 스코프, 짧은 리사이클을 위해서 자기 멋대로 자금을 늘리 수는 없다. 실제, 프로젝트가 스타트 했던 시점에서는 자금을 사용해야만 되는 것은 아니다. 투자는 없이 시작하면서 점차 확대하지 않으면 안된다. 조금 더 지나면 자금을 점차 생산적으로 사용할수 있도록 된다. 일반적으로 코스트는 타 변수와 깊은 관계를 맺고 있다. 투자 범위내에서 유용하게 운용된다면 자금을 많이 사용함으로써 스코프를 늘리고, 보다 자발적으로 하고, 품질을 향상시키고 (어느정도)시장에 출하 할때까지의 시간을 단축한다.

프로젝트의 시간을 관리하는 제약은, 일반적으로 외부에서 온다. 최근의 예로서는 2000년 문제이다. 그것 이외에에도 예를 들면 그해년의 연말, 4/4분기의 시작전, 구 시스템이 정지할때, 큰 전시회/쇼 가 있을때 등 외부의 제약은 많다. 시간의 변수는 프로젝트의 관리자가 아닌 유저의 손에 달려 있는 경우가 많다.

품질도 변화하는 변수이다. 품질을 올리기 위해 행한 일이 결과로써 프로젝트를 빠르게 끝나게 할수도 있고, 주어진 시간내에 보다 많은 것을 할 수도 있다. 이것은 개별 테스트를 하기 시작할때 나에게 일어난 일이다. 테스트가 익숙해지면, 자신의 코드에 자신감이 생기고 보다 빨리 스트레스 없이 코딩을 할수 있게 되었다. 시스템을 정리하는 것도 재미있게 되고, 다음 개발이 즐겁게 된다. 많은 팀에서 일어난 현상이다. 테스트를 시작하고 혹은 코딩 규약에 동이하면 코딩하는 것은 빨라진다.

품질은 외부와 내부에서 보는 관점이 서로 다른 점이 있으므로 서로간의 차이가 있으며 때에따라 추가 비용이 들기도 한다. 품질을 올리는 것에 의해 인간적인 효과도 생긴다. 누구라도 좋은 일을 하고 싶다고 생각한다. 좋은 일을 하고 있다고 느끼면 일이 훨씬 더 잘된다. 의식적으로 품질을 낮추면 당초의 예정보다는 빨리 끝나도 생산에 도덕감이 작아져 테스트를 하지도 않고 리뷰도 하지 않아 표준에 못 미치게 되기도 한다. 그렇게 된다면 빨리 시스템을 완성시켜도 의미가 없게 된다.

스코프에 착안한다.

코스트, 품질, 시간은 관리변수로써 많은 사람이 알고 있지만, 4번째의 변수는 그다지 잘 알고 있지 않다. 소프트웨어 개발에 있어 스코프는 의식해야될 아주 중요한 변수이다. 프로그래머도 비지니스맨(유저/이용자)도 개발중의 소프트웨어의 가치에 대해서 막연한 생각밖에 가지고 있지 않다. 스코프를 감소 시키는 것은 프로젝트 관리의 결정으로써 아주 강력한 방법의 하나이다. 적극적으로 스코프를 관리하면, 관리자와 유저(고객)가 코스트, 품질, 시간을 관리 할수 있게 된다.

스코프에 대해서 중요한 것은 스코프는 변동이 큰 변수라는 것이다. 십수년간 프로그래머는 "유저가 요망 하는것을 제대로 알려주지 않는다"라고 불평해왔다. 유저가 원하는 것을 말한 것에 대해서 제대로 알아 차릴수 없었다. 이것은 소프트웨어 개발에의 절대적인 사실이다. 최초간은 요구는 결코 명확하지 않다. 유저는 결코 원하는 것을 정확하게는 가르쳐 주지 않는다.

소프트웨어의 일부분을 완성하면, 요구는 달라져 간다. 최초의 리리스를 본 유저는 다음 리리스에서 원하는 것, 어쩌면 최초의 리리스에서 정말 원했던 것을 알아 차린다. 생각으로는 알수 없는 것으로 중요한 지식이 있다. 경험으로밖에 배울 수 없는 것도 있다. 그러나 유저 단독으로는 도달 할수 없다. 단순한 가이드역으로만 아닌 친구로써 프로그래머와 같이하는 사림이 필요한다.

요구의 변화라는 불확실함을 문제점이 아닌 찬스로써 잡을 수도 있을 것이다. 그렇게된다면 스코프를 4개의 변수 중에서 가장 관리하기 쉬운 것으로 선택 할수 있다. 정확하지 않아 결정 할수 없다는 것은 상황에 맞추어 어느 것으로도 변경 시킬수 있다고 할 수 있다.

이 모델에 기초를 잡아 개발 규율을 만들면, 1 peace의 소프트웨어의 코스트, 품질, 일정도 결정 할 것이다. 최초의 3개의 변수에 의해 나타나는 스코프도 알게 될거다. 그리고, 개발이 진행하면서 때때로 상황에 맞는 스코프를 정리 해 나가면 좋다.

프로젝트가 방향을 바꾸는 일을 많으므로, 변화 신속하게 대응할수 있는 프로세스가 필요하다. 리리스 사이클의 최후에 중요한 기능을 넣지 못하면 유저는 실망 할 것이다. 이런 사태를 피하기 위해 XP는 2개의 전략을 사용 한다.

1. . 연습을 많이 한다. -> 구체적으로는 예측을 세우는 것으로 실책으로부터 피드백을 얻는 것이다. 예측이 좋게되면 기능을 빼 먹는 일이 없게 된다. (예측이란 어떤 일을 언제까지 할수 있는 가를 말한다.)
2. . 유저가 가장 요구하는 것을 처음에 구현하다. 그렇게 하면, 혹 그 다음 기능 구현하지 못해도 시스템상에서 지금 움직이고 있는 기능보다는 중요한 것이 아닐 것이다.

제 5장

갱신 소프트

소프트웨어 엔지니어링의 보편적 가정의 하나로 프로그램의 갱신 코스트는 시간이 지남에따라 지수함수적으로 증가한다고 한다. 리노니움 바닥의 큰 교실에서 대학 3년때 교수가 아래 그림(코스트 비율로 요구->분석->설계->구현 까지는 원만하게 상승하다 테스트->제품화에서는 급격하게 상승하는 그래프임)과 같은 커브를 그리고 있는 그림을 본 기억이 있다.

소프트웨어의 수정 코스트는 시간이 지남에 따라 지수함수적으로 증가한다. 요구분석에서 본다면 1$ 증가한 문제가, 소프트웨어가 가동(운용)에 들어가면서 바로 수천 $가 걸린다.

그때, 나는 문제를 절대로 가동전에는 해결하자고 결심했다. 문제는 가능한 빨리 발견하자. 일어날 문제를 전부 좀더 전에 대책을 세우자. 코드를 리뷰하고, 크로스 체크를 하자. 문제는 이 커브는 이제 올바르지 않다는 것이다. 물론 테크노르지와 프로그램 구현에 의해 정말 정반대의 커브를 만들어 내는 것이 가능하다. 그것은 다음과 같은 이야기로부터 알수 있다. 이것은 내가 최근 생보험회사의 급여관리 시스템으로 체험한 일이다.

17:00 -- 이 시스템에 있어, 빌린 쪽에서 빌려주는 쪽으로의 모든 금액의 이동은 싱글 트랜젝션으로 복수구좌를 서포트 하고 있다. 실은, 이 멋진 기능이 사용되지 않고 있었다. 실제 트랜젝션은 하나의 구좌간에만 이동이 되어 잇었다.

17:02 -- 나는 Massimo에게 상황을 조사하고 있는 동안 나의 옆에 않아주도록 부탁하고 쿼리를 코딩했다. 시스템 내의 300,000 트랜젝션은 어느것도 하나의 빌려주는 쪽과 하나의 빌리는 쪽으로 되어 있다.

17:05 -- 틀린 것을 수정 하면서, 어느 것을 해야 할까. 트랜젝션의 인터페이스를 변경하고, 구현을 변경했다. 필요한 4개의 메소드를 코딩하고 테스트를 시작했다

17:15 -- 테스트(1000이상의 단체. 기능테스트)은 100% 동작했다. 변경이 동작하지 않는 이유는 아무것도 생각나지 않아서 데이타 베이스를 이행(移行)하는 코드에 몰두하기 시작했다.

17:20 -- 밤 사이에 패치가 끝나고, 테이타 베이스는 백업 되었다. 코드의 새로운 버젼을 인스톨하고 이행을 실행했다.

17:30 -- 사전 테스트(sanity test)를 몇개인가 실행했다. 생각했던 모든 테스트가 동작했다. 다른 떠오르는 생각이 없게 되어서 퇴근했다.

다음날 -- 에러 코드도 나오지 않았고, 유저로부터 크레임도 없다. 변경한 것은 제대로 동작했다.

다음 수 주간 동안 시스템을 단순하게 할 수 있다는 것이 판명되었다. 심플하게 하는 것으로 시스템의 구좌부분을 아주 새로운 기능을 공개하고 시스템은 보다 심플하고 보다 명확하여 보다 쓸데없는 것이 없게 되었다.

소프트웨어 개발 커뮤니티는 십수년간, 변경 코스트를 감소시키기 위해서 막대한 리소스를 늘려 왔다. 예를들어 보다 좋은 언어랑 데이타 베이스 기술을 채용하고, 프로그래밍 구현, 환경, 툴 그리고 새로운 표기법을 도입해 왔다. 어쩌면 투자의 성과가 충분히 얻어져, 언어랑 데이타 베이스에 걸리는 투자가 이 이상 필요가 없게 된다면, 다시말해 투자 레벨이 어느 정도까지 달한다면, 어떻게 될까. 변경 코스트는 시간과 함께 지수함수적으로 증가하지 않고, 천천히 점근선(漸近線)으로 된다면 어떻게 할까. 내일 강의에서 소프트웨어공학 교수가 그림(완만한 곡선을 가진)를 칠판에 그린다고 하면 어떻게 될까.

이것은 XP가 전제조건으로 하는 것중 하나이다. XP의 기술적인 전제이다. 어쩌면 변경 코스트가 시간과 같이 천천히 상승하고, 그대로 일정 치를 유지한다고 가정한다면 코스트가 지수함수적으로 상승하는 경우와 당신은 동작은 완전히 다른 것이 될 것이다. 프로세스 내에서 큰 결정을 하는 것을 가능한 뒤로 미루고, 결정을 정확하게 내릴 수 있을때까지 기다리자. 꼭 해야만 될 일만 하고, 내일 필요와 예측되는 것은 현실화 하지 않는 것으로 한다. 지금 코드를 심플하게 할 수 있을 때 혹은 다음에 쓸 코드를 심플하게 할 수 있을때만 설계에 요소를 도입한다.

변경 코스트를 낮게 하는 것은 마법과 같이 일어나지 않는다. 소프트웨어가 플레시블하게 변경 가능하게 하기 위해서는 테크노르지와 실천이 필요하다. 테크노르지 면으로는 오브젝트 기술이 key가 된다. 메세지를 사용하여 오브젝트들을 묶는 방법은 변경에 유연하게 싼 가격으로 대응 할 수 있는 강력한 방법이다. 각 메세지는 장래 수정 될지도 모르는 잠재적인 포인트이고, 지금 코드를 풀지 않고도 수정 할 수 있다.

오브젝트 데이타 베이스는 이 플렉시빌리티를 가진 채로 보존하는 것이 가능하다. 오브젝트 데이타 베이스에서는 어느 포맷의 오브젝트를 다른 포맷의 오브젝트에 간단하게 머지(Merge) 가능하다. 코드는 데이타에 부속해 있고, 이제까지의 데이타 베이스 테크노르지 같이 분리하고 있지 않기 때문이다. 오브젝트를 머지하는 방법이 발견되지 않아도, 2개의 구현방법을 공존시키는 것이 가능하다. 플렉시블 하기 때문에 오브젝트 기술을 사용하지 않으면 안된다고 이야기하는 것만은 아니다. 나는 아버지가 리얼타임 프로세스 관리 코드를 어셈블러로 코딩하고 있는 것을 보고, XP의 기본을 배웠다. 아버지는 프로그램의 디자인을 다듬는 스타일을 개발했다. 그러나 나의 경험으로는, 변경 코스트는 오브젝트 기술을 사용한 쪽이 훨씬 쉽게 코스트를 낮출 수 있었다.

오브젝트 기술을 사용하면 그것으로 충분하다고 말하는 것은 아니다. 나는 누구도 이해하고 싶지 않은 오브젝트 지향의 코드를 본 적이 있다(실은 거의 그런일이 많다).

완성에서 수년 걸려도 코드를 수정하기 쉬운 스토리(이야기)에서 몇개의 원인을 알 수 있다.

• 심플한 설계 -> 쓸데없는 설계 요소가 없다. 아직 사용하지 않지만 장래 사용할지도 모른다 라는 것을 넣지않는다.
• 자동화된 테스트 -> 시스템의 지금 행위를 틀리지 않게 변경하고 있는가를 확인 할 수 있다.
• 설계를 수정하기 위해서 많은 실천 -> 시스템을 변경 할때 불안하지 않게 된다.

심플한 설계, 테스트, 설계를 계속 개선하는 태도를 하는 것으로 나는 평단화한 커브를 경험했다. 2년간 가동(운용)한 시스템에서 엄천난 코딩 중에서 어디를 고치면 좋을까라는 것을 몇분만에 확인하고, 30분으로 변경을 완료했었다. 오늘 해야 될 일은 확실하게 하고, 틀린게 있다면 다음날 수정한다는 것 같은 사고를 바꾸지 않기 때문에 질질 언제까지라도 같은 결정에 몇 일이나 몇 주간 소모하고 있는 프로젝트를 나는 이제 까지 봐왔다.(불확실한 일을 하고 틀리면 다음에 고친다고 무작정 일을 하여 그 이후 문제가 제대로 풀리지 않고 일이 계속 제자리 걸음을 한다는 말 같습니다.^^)

제 6장. 운전면허 취득

- 소프트웨어 개발을 관리하기 위해서 필요한 것은 큰 수정을 몇번으로만 하는 것이 아닌 작은 수정을 수많이 하는 것이다. 자동차 운전과 같다. 길에서 벗어남을 알리기 위한 피드백과 수정하는 찬스가 많을 필요가 있다. 그리고 그 수정은 합당한 코스트로 할 수 있어야 한다.

여기까지 소프트웨어 개발에 관한 일반적인 문제에 대해서 생각해 왔다. 리스크에 연결되는 막대한 코스트와, 옵션을 사용해서 그 리스크를 관리하는 방법, 해결책을 만들기 위해서 필요한 리소스에 대해서 이다. 또, 개발 사이클의 후기에 있었어도 큰 금액의 코스트가 걸리지 않게 변경 할 수 있다. 자 그러면, 해결책에 집중해 보자.    처음에 필요한 것은 메타포어(비유)와 공감 할 수 있는 스토리이다. 팀 전원이 공유 할 수 있는 스토리가 있으면 스트레스가 쌓일 때나 결정이 필요 할 때도 바른 길을 걸어 갈수 있다.

지금이라도 처음 차를 운전했던 날을 확실하게 기억하고 있다. 어머니와 나는 칼리포니아주 치코 근처의 주간고속도를 드라이브 하고 있었다. 그곳은, 직선의 평범한 길로, 지평선까지 뻗어 있는 하이웨이였다. 그 때, 어머니가 조수석에서 나의 손 위로 단단히 핸들을 쥐었다. 그리고 핸들에 힘을 줌으로써 차의 방향이 어느 위치에서 변하는가를 가르쳐주었다. "이렇게 운전해요. 차선의 가운데에 라인을 잡고 지평선까지 똑바로 달려라." 라고 말했다.    나는 길을 똑바로 달리는 것에 의식을 집중하였다. 차를 차선의 가운데로 향해 조금씩 움직이여 차도의 중안에 위치 할수 있도록 하였다. 능숙하게 할 수 있어 조금 놀랐었다.    그러나 돌연 차가 차도를 넘어, 모래쪽으로 올라 갔을떼 겨우 되돌아 왔다. 어머니는 천천히 차를 차도로 되돌렸다. 그후부터 실제로 운전을 가르쳐주었다. "운전은 차를 올바른 방향으로 나아가면 된다고 말하지만 그렇지 않아. 보통 주의를 주면서 이쪽으로 조금 저쪽으로 조금씩 수정하는것이야."

이것이 XP의 패러다임이다. 똑바로 평탄하지 않은 것이다. 일이 완벽하게 진행하고 있는 것 같이 보여도 길에서 눈을 떼면 안된다. 변화는 일반적인 정수이다. 이쪽으로도 저쪽으로도 이동 할수 있는만큼의 준비는 언제나 필요하다. 어떨때는 사방으로 이동하지 않으면 안될때도 있을지도 모른다. 이것은 프로그래머로써 숙명이다.

소프트웨어 모든 것은 변화한다. 요구는 변화한다. 설계는 변화한다. 비즈니스는 변화한다. 테크노르지는 변화한다. 팀은 변화한다. 팀의 멤버는 변화한다. 변화자체는 문제가 아니다. 변화는 끊임없이 일어난다. 문제는 변화가 일어날 때 대항 할 수 없는 것이다.

소프트웨어 프로젝트에 있었어, 운전수는 유저(고객)이다. 소프트웨어가 유저가 원하는 동작을 하지 않을때는 실패이다. 물론 유저는 소프트웨어가 해야될 것을 정확하게는 모른다. 소프트웨어 개발은 핸들을 다루는 것과 같이 그저 차를 똑바로 달리게 하는 것과는 다른 이유가 있다. 프로그래머로써의 직무는 유저에게 핸들을 넘겨주고, 도로의 어디에 있는가 라는 정확한 정보를 피드백하는것이다.

운전의 스토리는 XP의 프로세스 자체의 모델도 포함하고 있다. 다음 장에서 해설하는 4개의 가치(커뮤니케이션, 심플, 피드백, 용기)는 우리들이 소프트웨어 개발에 어떤 감정을 가져야 하는가를 설명하고 있다. 그러나 그 감정에 기초로한 실전은 경우에 따라, 시간에 따라, 사람에 따라 다르게 될것이다. 개발 프로세스에 당신의 손에 넣고 싶은 감정이 실천 가능하도록 심플한 실천을 받아들인다. 개발을 계속하면, 어느 실천이 적절하고 어느 실천이 불적절한 것인가를 자연스럽게 알게 될 것이다. 각 실천은 실험이고, 부적절하다고 알 때까지 해보는 것이다.

제 7 장. 4개의 가치

- 인간적으로나 상업적으로 수요를 채우는 항구적인 가치(커뮤니케이션, 심플, 피드백, 용기)를 찬성하는 스타일을 가지고 있다면 성공 할 것이다.

운전을 배우는 이야기에서 소프트웨어 개발의 실전을 이끌어 내기 전에 올바른 방향으로 가고 있는가를 확인 할 필요가 있다. 시작 한 후 개발 스타일이 마음에 들지 않던지 잘되지 않는다고 한다면 좋지 않은 것 이다.    단기적으로 개인의 목표는 회사의 장기적인 목표와 대립하는 경우가 많다. 우리 회사는 이와 같은 대립을 피하기 위하여 공동 가치를 만들어 냈다. 신화, 규칙, 벌, 상이다.    이러한 가치가 없으면 사람은 자신의 단기적인 이익에만 빠지는 경향이 있다.    XP의 4개의 가치는 아래와 같다.

1. 커뮤니케이션
2. 심플
3. 피드백
4. 용기

커뮤니케이션

XP에 있었어 첫번째의 가치는 커뮤니케이션이다. 프로젝트의 문제라는 것은 중요한 일을 다른 누군가에게 상담하지 않는 것에서 일어난다.    프로그래머는 설계가 크리티컬하게 변하여도 누군가에게 알리지 않는 경우가 때때로 있다. 프로그래머는 유저(고객)에게 적절한 질문을 하지 않고, 그 결과 크리티컬한 영역의 결점을 놓쳐버리던지 관리자가 프로그래머에게 적절한 질문을 하지 않기 때문에 프로젝트의 진행이 틀리게 되었다는 보고도 있다. 커뮤니케이션은 갑자기 나쁘게 되는 것이 아니다. 커뮤니케이션을 방해하는 많은 환경 요인이 있는 것이다. 프로그래머가 관리자에게 나쁜 뉴스를 전달하면 관리자가 그 프로그래머를 벌한다. 유저가 프로그래머에게 중요한 일을 전할려고 하여도 그 프로그래머는 그 보고를 무시해    버린다. XP에서 채용하는 실천의 대부분은 커큐니케이션 없이는 할 수 없는 것이다. 바꾸어 말하면 XP는 적절한 커뮤니케이션이 흘러가는 것을 목적으로 하는 것이다. 단체(X體) 테스트, 페어프로그래밍, 태스크 예측 등은 단기적인 판단 능력을 부여하는 실천인 동시에 프로그래머, 유저, 관리자가 커뮤니케이션을 하지 않으면 있을 수 없는 것이다.    물론, XP 프로젝트에서는 커뮤니케이션이라도 되어 있으면 문제는 일어나지 않는다고 말 할 수 없다. 사람은 불안에 빠지고, 실수를 하고, 혼란스러워 한다. XP는 커뮤니케이션이 정착되지 않을 때 그것을 개선시키는 코치를 도입한다.

심플(SIMPLE)

XP의 두 번째의 가치는 심플이다. XP의 코치는 "동작시키기 위해서, 좀 더 심플한 것은 무었일까" 라고 팀에 질문한다. 심플하게 한다는 것은 간단하지 않다. 내일, 내주, 내월에 실천하려고 하는 것을 생각 없이 있다는 것은 어렵다. 그러나 무리하게 앞의 일을 생각해 버리면 변경의 코스트 커브가 급격하게 올라가는 방향으로 진행되어 버린다. 때로는 팀에 부드럽게 "야 당신들은 나보다도 뛰어나 이런 복잡한 트리 검색을 이용하여 처리하는구나. 나는 선형 검색으로 되지 않을까라는 단순하게 생각하고 있었는데" 라고 우회적으로 코치는 팀에게 복잡한 방향으로 향하고 있다는 것을 알려줄 필요가 있다.    - Greg Hutchinson은 말하고 있다.

'내가 컨설팅을 하고 있던 유저는 텍스트를 표시하는 범용 다이얼로그가 필요하다고 결정했었다. 그래서 이 다이얼로그의 인터페이스랑 다이얼로그의 기능을 서로 이야기 했다. 프로그래머는 다이얼로그에 많은 기능을 부여하기 위해 사이즈와 문자를 수정하고 행수는 폰트사이즈랑 그 외의 변수에 따라가게 하는 것까지 정의하고 싶다고 말했다. 나는 그 기능을 현재 필요로 하는 프로그래머가 몇 명 있는가를 물었다. 필요로 하는 것은 1명의 프로그래머만 이었다. 현 단계에서는 다이얼로그가 그런 많은 기능이 없이 지금의 case에 대응하는 클래스를 만들고. 인터페이스를 공개하면 된다. 다른 요구가 필요로 되는 다른 case가 발생 할 때 언제라도 기능을 향상시키면 된다고 제안했다. 나는 이 프로그래머를 설득하지 않고 우리들은 이 코드를 만들기 위해서 2일간을 소요했다. 3일째 그들의 요구는 변화하여 누구도 새로 만든 기능을 필요로 하지 않게 되었다. 타이트한 프로젝트에서 2일간을 허비했다. 누군가 이 코드를 사용하고 싶다면 알려라'(출전 E-Mail)

XP는 다음과 같은 전략 방법을 취하고 있다. 그것은 오늘 단순한 일을 하고 내일 변경이 필요하게 되었을 때 변경 코스트를 지불하는 쪽이 오늘 복잡한 일을 하고 결국 사용되지 않는 것보다 좋다. 라고 말 하는 것이다.    심플과 커뮤니케이션은 서로간에 돕는 멋진 관계이다. 커뮤니케이션을 받아 들일수록 무엇을 해야 되는가를 확실하게 알게 된다. 그리고 필요로 하지 않는 것을 알아내는 것이 가능하다. 시스템이 심플하게 되면 필요한 커뮤니케이션은 작아진다. 특히 프로그래머를 줄일 정도로 시스템을 심플하게 하면 보다 완벽한 커뮤니케이션을 전달 할 수 있도록 된다.

피드백

XP에 있었어 세 번째의 가치는 피드백이다. 코치적인 어투를 사용하면 "나에게 묻지마라, 시스템에게 물어라"와 "이제 그것의 테스트 케이스는 끝냈지?" 라고 말하는 것이다. 시스템의 현재의 상태에 대한 구체적인 피드백은 무한한 가치이다. 낙관주의적 태도는 프로그래밍 현장에 해저드(재해요인)을 발생시킨다. 피드백이 대처법이다.    피드백의 타임 스케일은 다양하다. 처음은 수분간, 수일간으로 한다. 프로그래머는 시스템의 일어 날 수 있는 모든 로직에 대해서 단체 테스트를 한다. 프로그래머는 시스템의 상태에서 분각으로 주체적인 피드백을 잡는다. 유저(고객)가 새로운 "스토리(기능 설명)" 를 적으면, 프로그래머는 바로 평가한다. 그리고 유저는 스토리의 품질에 대해 구체적인 피드백을 얻는다. 게다가 태스크의 진행관리자는 모든 것이 먼저 설정한 기간 내에 끝 낼 수 있는가를 팀 전체에게 피드백 해준다.    피드백은 주(週)랑 월(月) 단위로 행한다. 유저와 테스터는 시스템이 구현한 모든 기능을 적고("간단한 유저케이스"를 생각한다.) 시스템의 현재의 상태에 대해서 구체적인 피드백을 얻는다. 유저는 2,3 주간마다 스케줄을 다시 보고 팀 전체의 속도가 계획에 맞혀 가고 있는가를 조사한다. 틀리다면 계획을 수정한다. 기능이 완성되면 시스템을 바로 가동시켜 유저에게 시스템이 어떻게 움직이고 있는가를 보여주고 "인상"을 줄 수가 있다. 이렇게 하면 유저는 시스템을 최대한으로 살리는 방법을 알아 차릴 것이다.    조기에 시스템을 가동시키는 것에 대해서는 조금 설명이 필요하다. 계획 프로세스 전략의 하나는 팀이 가장 가치 있는 스토리를 가능한 빨리 처음부터 가동하도록 하는 것이다.    이것에 의해 프로그래머는 자신들의 결단이 정확하다라는 것을 구체적인 피드백과 개발은 타이어가 도로에 붙기 직전에 착수해나가야 된다는 개발 프로세스를 얻게 된다. 가동중의 시스템에 구애 받지 않는 프로그래머들도 있다. 그들은 어떻게해서 좋게 일을 하는 방법을 몸에 배게 되었을까.    일반적인 프로젝트는 정반대의 전략을 취하고 있다. 다시말해 "시스템이 가동에 들어가 버리면 이 이상의 변경을 할 수 된다. 그러므로 시스템을 개발 기간을 길게 한다"라는 것이다.정말 반대이다. "개발중" 이라는 것은 일시적인 상태로 시스템의 라이프 사이클에 작은 부분에 지나지 않는다. 시스템에 독립된 삶을 주고 자립시켜 혼자 호흡하게 하는 것이 더욱 좋다. 시스템의 가동을 서포트 하고 동시에 기능을 개발하면서 살아가야 되는 것이다. 물론 가동 서포트와 새로운 기능의 개발을 동시에 하지 않으면 안된다. 가동과 보다 빠른 개발 양쪽을 조절하는 것에 익숙해지지 않으면 안된다.    구체적인 피드백은 커뮤니케이션과 심플 양쪽에 있었어도 가지고 있어야 되는 것이다. 피드백이 많을수록 커뮤니케이션이 하기 쉬워진다. 당신이 쓴 코드에 이론(異論)을 가진 사람으로부터 실패한 테스트 케이스를 보여주게 된다면 설계논의에 소비하는 수천시간은 절약 할 수 있다. 확실하게 커뮤니케이션을 하고 있다면 시스템을 이해하기 위해서 무엇을 테스트하고 무엇을 측정하면 좋을가를 알게 된다. 심플한 시스템은 테스트도 쉽다. 테스트를 하면 시스템이 얼마나 심플하게 될 수 있는 가를 알게 된다. 테스트가 성공 할 때까지 끝나지 않는다. 테스트가 모두 성공 했을 때 끝나게 되는것이다.

용기

처음의 3개의 가치(커뮤니케이션, 심플, 피드백)이 확실하게 하는 환경에 있었어도 수라장(修羅場)은 방문한다. 당신이 전 속력으로 달리고 있지 않다면 다른 사람이 당신을 초월하여 당신의 점심을 먹어 버릴 것이다. 그래서 여기서 용기를 실천하고 있는 이야기를 예를 들어 볼려고 한다.    처음으로 대부분의 XP프로젝트의 시간, 최초의 리리스의 10의 이테레이션중 8번째 도중에서(30주의 25주째), 팀은 구조체 기본적인 결함을 발견했다. 기능 테스트의 스코어가 잘되어 가고 있었지만, 기대되는 숫자까지는 도달하지 않았다 하나의 버그를 고치면 다른 버그가 발생 하였다. 문제는 구조적인 결함이었다. 팀의 결단은 정확했다. 이대로는 앞으로 진행 할 수 없다는 것을 알고 그 결함을 수정했다. 수정에 의해 앞에 성공한 테스트의 반은 실패가 되었다. 그러나 수일간 집중적으로 노력하여 테스트 스코어는 완성으로 향했다. 용기가 필요 했었다.    또 하나의 용기는 코드를 버리는 것이다. 어느 일에 하루 종일 붙잡고 있어도 잘 되지 않고 머신이 다운되는 경험을 한 경우가 있을 것이다. 그리고 웃기게 다음 날에는 전말의 일을 30분만으로 멋지고 심플하게 재구성 할 수 있는 방법을 발견했다 라는 경험을 한 경우가 있을 것이다.    다시 말해 이런 이야기이다. 하루가 끝 날쯤 되어서라도 코드가 조금이라도 제어 불능이라면 버려라. 설계가 끝난 인터페이스가 마음에 든다면 테스트 케이스를 하는 것이 좋지만 그렇게 하지 않아도 좋다. 한번 더 처음의 상태에서 시작해 보자. 설계의 선택 기는 세 개 정도 있을지도 모른다. 각 선택 기에 대해서 하루 코드를 코딩 하면 각각이 어떤가를 느끼게 될 것이다. 그 코드를 던져버리고 좀 더 가능성 있는 설계로 처음부터 시작해보자.    XP의 설계 전략은 골짜기를 오르는 알고리즘 같은 것이다. 심플한 설계를 했다면 조금 복잡하고, 또 좀더 심플하게 되돌리면 다시 조금 복잡하게 된다. 이와 같이 골짜기를 오르는 알고리즘에서는 몸 가까이에 있는 목표지점에 도달하기 위해 작은 변경으로 상황을 개선 할 수 없는 경우는 마음을 다지고 큰 변경을 한다.    자신만의 생각에 빠진 개발을 하지 않기 위해서는 무엇이 필요할까. 그것은 용기이다.    때로는 팀의 누군가가 시스템 전체의 복잡함을 잘라내버리는 것 같은 돌출적인 아이디어를 생각해 낼지도 모른다. 용기가 있다면 해보자. (때에 따라) 성공한다. 용기가 있다면 그것을 가동 중에 있는 시스템에 적용해보자. 지금 당신은 완전 새로운 골짜기를 오르고 있는 것이다.    최초의 3개의 가치가 없다면 용기는 (부정적인) 해킹에 지나지 않는다. 그러나 커뮤니케이션, 심플, 구체적인 피드백과 연결되어 있는 용기는 아주 가치 있는 것이 된다.    용기에 있어 커뮤니케이션은 중요하다. 왜냐면 커뮤니케이션이 아주 중요한 리스크를 발견하는 가능성을 넓이기 때문이다. "당신은 저것이 마음에 들지 않는가? 나도 저 코드가 싫어. 오후부터 그것을 좋아지도록 하는데 까지 해보자". 심플한 시스템에서는 용기를 서포트 한다. 실수로 시스템을 부서버리는 가능성은 낮다. 시스템을 심플하게 하는 가능성이 있다면 바로 해보아라. 그런 용기는 심플을 서포트 한다. 또 구체적인 피드백은 용기를 서프트 한다. 왜냐면 보턴을 눌러도 테스트의 결과가 최종적으로 통과된다면 마음 놓고 과격한 코드 변경도 할 수 있을 것이다.(성공하지 않는다면 그 코드를 버리는 것이 좋다.)