주제
Rational Unified Process(RUP)는 Rational 소프트웨어가 몇 년에 걸쳐 정제한 프로세스 프레임워크이며 모든 유형의 소프트웨어 프로젝트(소규모부터 대규모까지)에 광범위하게 사용됩니다. 최근
들어, 증가되고 있는 "Agile" 프로세스(예: XP(eXtreme Programming), SCRUM, FDD(Feature-Driven Development) 및 Crystal Clear
Methodology)는 소규모 시스템 빌드에 효과적인 방법으로 인식되고 있습니다. (Agile Alliance에 대한 자세한 정보는 www.agilealliance.org를 참조하십시오.)
다음 섹션은 프로젝트 팀이 RUP(RUP에 대한 자세한 내용은 RUP 소개 참조)에서 정의된 보다 완전한 소프트웨어 개발 프로세스를 통해 "Agile" 사례를 처리하는 방법을 알아보기 위한 여러 가지 방법 중
하나인 Agile 사례의 일부를 평가하는 데 도움을 주기 위한 것입니다.
Agile 커뮤니티는 특히 작고 공존하는 프로젝트 팀에 적용할 수 있는 여러 "우수 사례"를 종합한 것입니다. RUP가 모든 규모의 프로젝트 팀을 대상으로 하지만, 소규모 프로젝트에 성공적으로 적용될 수 있습니다.
일반적으로, RUP 및 Agile 커뮤니티 프로세스는 고품질의 소프트웨어를 개발하는 데 필요한 주요 우수 사례(예: 반복적 개발 적용 및 사용자에 중점적인)에 대해 유사한 관점을 가집니다.
다음 섹션은 Agile 커뮤니티에서 식별된 "우수 사례" 중 일부를 이러한 우수 사례에서 이익을 얻으려는 RUP 기반 프로젝트에 적용하는 방법에 대해 설명합니다. 이 경우, XP(eXtreme
Programming) 방법론으로 표시되는 사례에 특히 초점을 맞춥니다. (XP에 대한 자세한 정보는 http://www.extremeprogramming.org 웹 사이트를 참조하십시오.)
XP 사례
XP는 네 가지 기본 "활동"(코딩, 테스트, 청취 및 디자인)을 포함하며 실제로 RUP 원칙과 보다
밀접하게 결합되어 있습니다. 이러한 XP 활동은 추가 활동을 수행해야 하는 사례 세트를 사용하여 수행되며 RUP의 다른 원칙 중 일부에 맵핑됩니다. XP의 사례는 Extreme Programming Explained에 따르면 다음과 같습니다.
-
계획 게임: 비즈니스 우선순위와 기술적 예상을 결합시켜 그 다음 릴리스의 범위를 신속히 판별합니다. 계획이 현실에 미치지 못하면 계획을 갱신하십시오.
-
소규모 릴리스: 간단한 시스템을 프로덕션에 빨리 투입한 후 아주 짧은 주기로 새 버전을 릴리스합니다.
-
메타포: 전체 시스템이 작동하는 방법에 대한 간단한 공유 스토리를 통해 모든 개발을 안내합니다.
-
단순 디자인: 시스템은 언제든지 가능한 단순하게 디자인되어야 합니다. 초과된 복잡도는 발견되자마자 제거됩니다.
-
테스트: 프로그래머는 계속 유닛 테스트를 작성하여 지속적인 개발을 위해 완벽하게 실행해야 합니다. 고객은 기능이 완료되었음을 예시하는 테스트를 작성합니다.
-
리팩토링: 프로그래머는 중복을 제거하고, 통신을 개선하며, 단순화 또는 유연성 추가를 위해 동작을 변경하지 않고 시스템을 다시 구조화합니다.
-
짝 프로그래밍: 하나의 시스템에서 두 명의 프로그래머가 함께 전체 프로덕션 코드를 씁니다.
-
공동 소유권: 누구나 언제든지 시스템의 코드를 변경할 수 있습니다.
-
지속적 통합: 타스크가 완료될 때마다 하루에 여러 번 시스템을 통합하고 빌드합니다.
-
주 40시간: 일반적으로 한 주에 40시간 이상을 작업하지 않습니다. 두 주를 연속해서 초과 근무하지 않습니다.
-
현장 고객: 전시간 질문에 응답할 수 있는 실제 작업 중인 사용자를 팀에 포함시킵니다.
-
코딩 표준: 프로그래머는 코드에서 커뮤니케이션을 강조하는 원칙에 따라 모든 코드를 작성합니다.
예를 들어, "계획 게임" 사례의 결과로 수행되는 활동은 주로 RUP의 프로젝트 관리 원칙에 맵핑됩니다. 그러나 릴리스된 소프트웨어의 배치와 같은 일부 RUP 주제는 XP의 범위를 벗어납니다. 고객이 요구사항을
정의하고 제공해야 하므로 요구사항 도출은 XP의 범위를 크게 벗어납니다. 또한 XP는 보다 단순한 개발 프로젝트를 처리하기 때문에 RUP가 형상 및 변경 관리 원칙과 환경 원칙에서 자세히 다루는 문제를 매우 가볍게
처리할 수 있습니다.
RUP와 호환 가능한 XP 사례
XP와 RUP에서 서로 겹치는 원칙의 경우, XP에 설명된 다음 사례가 RUP에 적용될 수 있습니다(일부 경우에는 이미 적용됨).
-
계획 게임: 계획에 대한 XP 안내는 아주 작은 프로젝트에 대해 RUP의 프로젝트 관리 원칙에 표시되는 여러 목표를 달성하는 데 사용될 수 있습니다. 이는 특히 형식적인 중간 프로젝트 관리
아티팩트를 생성할 필요가 없는 그다지 형식적이지 않는 프로젝트에 유용합니다.
-
테스트 우선 디자인 및 리팩토링: 이 기법은 RUP의 구현 원칙에 적용될 수 있는 우수한 기법입니다. 테스트 우선 디자인이 필요한 XP의 테스트 사례는 특히 자세한 레벨로 요구사항을 명백히
나타내는데 있어서 뛰어난 방법입니다. 다음 섹션에서 볼 수 있듯이 리팩토링은 대규모 시스템에 알맞게 크기 조정될 수 없습니다.
-
지속적인 통합: RUP는 서브시스템 및 시스템 레벨에서(반복) 빌드를 통해 이 사례를 지원합니다. 유닛 테스트된 컴포넌트는 최근에 만들어지는 시스템 컨텍스트에서 통합되고 테스트됩니다.
-
현장 고객: 대부분의 RUP 활동은 현장 고객을 팀 구성원으로 포함시킴으로써 큰 이익을 얻을 수 있습니다. 이를 통해 필요한 중간 인도물(특히 문서)의 수를 줄일 수 있습니다. XP는 선호되는
고객-개발자 커뮤니케이션의 매체로서 지속성과 친숙성이 있어야 하는 대화를 강조합니다. 그러나 시스템(소규모 시스템인 경우에도)이 전이되어야 할 때는 더 많은 대화가 필요합니다. XP는 이것을 예를 들어
프로젝트 끝에서 디자인 문서와 함께 추가 정보로 사용할 수 있도록 합니다. 문서 또는 기타 아티팩트를 생성하는 것을 금지하지는 않지만 XP는 실제로 필요한 것만을 생성하도록 합니다. RUP도 마찬가지입니다.
다만 지속성과 친숙성이 이상적이지 않은 경우 필요한 내용을 계속 설명합니다.
-
코딩 표준: RUP에는 거의 언제나 필수적인 것으로 간주되는 아티팩트 프로그래밍 가이드라인이 있습니다. (사용자 조정의 주요 구동 요소가 되는 대부분의 프로젝트 위험성 프로파일이 이렇게
수행됩니다.)
-
주 40시간: XP에서와 같이, RUP는 시간 초과 작업이 상습적으로 되지 않을 것을 제안합니다. XP는 작업 시간에 대한 여러 허용 오차를 인정하여 엄격한 40시간 제한을 제시하지 않습니다.
소프트웨어 엔지니어는 추가 보상 없이 단지 어떤 일이 완성되는 것을 보는 만족감을 위해 장시간 동안 일하기로 악명이 높으므로, 관리자가 독단으로 이를 반드시 중지시킬 필요는 없습니다. 관리자는 결코 이
사례를 부당하게 이용하거나 강요해서는 안됩니다. 보상되지는 않지만 실제로 작업한 시간에 대한 메트릭을 항상 모아놓아야 합니다. 누군가 작업한 시간의 로그가 연장된 기간 보다 높게 보이면 이것은 확실히
조사되어야 합니다. 그러나 이 문제는 관리자와 개인 사이에 문제가 발생할 때 나머지 팀 구성원이 가질 수 있는 이의를 인정하면서 해결되어야 합니다. 40시간은 안내일 뿐이지 강제적인 것은 아닙니다.
-
짝 프로그래밍: XP는 짝 프로그래밍이 코드 품질에 유익하며 이 스킬을 습득하게 되면 더 쉬워진다고 주장합니다. RUP는 RUP 기반 프로세스에서 짝 프로그래밍을 확실히 사용할 가능성이 있더라도
그렇게 세분화된 레벨로 코드 생성 기술자를 설명하지 않습니다. 테스트 우선 디자인 및 리펙토링과 함께 짝 프로그래밍에 대한 일부 정보가 이제 RUP와 함께 백서의 형식으로 제공됩니다. RUP에서 이러한
사례를 사용하는 것은 분명히 요구사항이 아닙니다. 그러나 개방된 커뮤니케이션 문화를 가진 팀 환경에서 짝 프로그래밍의 이점(총 라이프사이클 비용에 미치는 영향에 따른)을 분간하기는 어려울 것으로 추측할 수
있습니다. 잘 운영되고 있는 팀에서는 강요하지 않아도 사람들이 함께 모여 매우 자연스럽게 문제점을 논의하고 해결합니다.
올바른 프로세스가 "마이크로" 레벨에서 실행되어야 한다는 제안은 종종 성향에 맞지 않고 일부 회사 문화에 맞지 않을 수 있습니다. 따라서 RUP는 엄격한 시행을 지지하지 않습니다. 그러나 일부 상황에서 XP가
지지하는 사례를 기반으로 하여 짝을 이루어 작업하는 것(그리고 일부 다른 팀 구성원과 함께 작업하는 것)은 예를 들어 다음과 같은 경우에 각 팀 구성원이 다른 구성원을 도울 수 있으므로 분명히 장점을 가지고
있습니다.
-
사람들이 친해지기 시작하는 팀 형성 초기의 경우
-
새 기술에 서투른 팀의 경우
-
숙련된 직원과 초보자가 혼합된 팀의 경우
올바로 크기 조정되지 않는 XP 사례
다음 XP 사례는 대규모 시스템에 대해 올바로 크기 조정되지 않으므로(XP에 설명된 바도 없음) RUP에서 다음 조건에 따라 XP 사례를 사용합니다.
-
메타포: 대규모의 복잡한 시스템의 경우 단순히 메타포로서의 아키텍처로 충분하지 않습니다. RUP는 Extreme Programming
Explained에 설명된 대로 단지 "큰 상자들과 연결 선"이 아니라 아키텍처에 대해 보다 풍부한 설명 프레임워크를 제공합니다. 최근에는 XP 커뮤니티에서도 메타포를 반대하고 있습니다.
메타포는 더 이상 XP의 사례 중 하나가 아닙니다(제대로 설명되지 않는 한).
-
공동 소유권: 소규모 시스템 또는 서브시스템을 책임지고 있는 팀 구성원이 모든 코드에 익숙한 경우 유용합니다. 그러나 모든 팀 구성원에게 변경을 작성할 수 있는 동등한 권한을 줄지 여부는 코드의
복잡도에 따라 달라야 합니다. 대개의 경우 현재 관련된 코드 세그먼트에 대해 작업하고 있는 개인(또는 짝)이 수정하도록 하는 것이 보다 빠르고 안전합니다. 아무리 잘 작성한 코드라도 특히 복잡한 알고리즘을
가진 경우 시간이 경과함에 따라 숙지 정도가 빠르게 줄어듭니다.
-
리팩토링: 대규모 시스템에서 잦은 리팩토링으로 아키텍처의 부족을 대신할 수 없습니다. Extreme Programming
Explained에서는 XP의 디자인 전략이 등산(hill-climbing) 알고리즘과 유사하다고 설명합니다. 단순한 디자인을 가져와 이 디자인을 조금 더 복잡하게 만든 후 조금 더 단순하게
만들고 또 다시 조금 더 복잡하게 만듭니다. 등산(hill-climbing) 알고리즘의 문제점은 작은 변경으로는 상황을 개선할 수 없고 큰 변경으로 상황을 개선할 수 있는 로컬 최적 조건에 도달하는
것입니다. RUP에서 아키텍처는 "높은 산"에 대한 보기 및 액세스를 제공하여 대규모의 복잡한 시스템을 추적 가능하게 합니다.
-
소규모 릴리스: 고객이 새 릴리스를 승인하고 전개할 수 있는 비율은 일반적으로 비즈니스 영향과 상관되는 여러 요인(예: 시스템의 크기)에 따라 달라집니다. 일부 유형의 시스템의 경우 2개월
주기는 너무 짧을 수 있습니다. 배치 물류에서 이를 금지할 수 있습니다.
주의를 요하는 XP 사례
마지막으로, 언뜻 보기에 RUP에서 잠재적으로 사용 가능하다고 여겨지는 XP 사례(단순 디자인)는 일반적으로 적용할 때 약간의 주의가 필요합니다.
-
단순 디자인
XP는 아주 많은 기능성에 기반합니다. 즉, 유저 스토리를 선택하고 타스크로 분해한 후 구현합니다. Extreme Programming
Explained에 따르면 주어진 시점에서의 소프트웨어에 대한 올바른 결정은 모든 테스트를 실행하고 중복된 논리가 없으며 프로그래머에게 중요한 모든 목적을 명시하고 가능한 적은 클래스 및
메소드를 가지는 것입니다. XP는 고객에게 비즈니스 가치를 제공하는 데 필요하지 않은 내용의 추가를 권장하지 않습니다.
RUP의 "비기능적" 요구사항 처리 시 로컬 최적화 문제점과 유사한 문제점이 있습니다. 이러한 요구사항은 또한 고객에게 비즈니스 가치를 제공하지만 스토리로 표시하기에는 다소 어렵습니다. XP의
제한조건 중 일부가 이 카테고리에 포함됩니다. RUP는 디자인 시 필요 이상으로 설명하는 방법을 지지하지 않지만 아키텍처 모델(비기능적 요구사항을 충족시키기 위한 핵심 중 하나인 모델)을 사용하여
디자인하는 방법은 지지합니다.
따라서 RUP도 "단순 디자인"이 모든 테스트 실행을 포함한다는 점에서 XP와 마찬가지입니다. 다만 소프트웨어가 비기능적 요구사항을 충족시키는 것을 예시하는 테스트를 포함한다는 점이 다릅니다. 다시
말해, 이 점은 시스템 크기와 복잡도가 증가할 때, 아키텍처가 전에 없던 형태, 또는 비기능적 요구사항이 부담이 될 때 주요한 문제로 대두됩니다. 예를 들어, 데이터 정렬에 대한 요구(이기종 분산
환경에서 작동하기 위해)는 코드를 매우 복잡하게 만들지만 이 요구는 프로그램 전체에서 여전히 필요합니다.
소규모 프로젝트에 대한 아티팩트 맵핑
소규모 프로젝트에 맞게 RUP를 사용자 조정하고 그에 따라 중간 산출물
요구사항을 줄이면 XP 프로젝트의 등가 아티팩트와 어떻게 비교됩니까? 표 1은 소규모 RUP 프로젝트에서의 일반 RUP 아티팩트 세트를 표시합니다.
표 1: 소규모 프로젝트에 대해 XP에서 RUP로의 아티팩트 맵핑
XP 및 RUP에서 아티팩트의 세분성이 서로 다르긴 하지만, 일반적으로 소규모 프로젝트(XP 유형이 부족함 없이 처리함)에 대한 RUP의 아티팩트는 XP 프로젝트의 아티팩트에 아주 잘 맵핑됩니다.
표에는 또한 XP에는 포함되지 않지만 여러 프로젝트에는 필요한 몇 가지 아티팩트도 포함됩니다. 여기에는 데이터
모델 및 배치와 관련된 아티팩트(예: 사용자
지원 자료)가 포함됩니다.
활동
RUP는 타스크를 역할에서 수행하는
작업(입력 아티팩트를 사용 또는 변환하거나 또는 새로운 출력 아티팩트나 변경된 출력 아티팩트를 생성)으로 정의합니다. RUP는 RUP 원칙에 따라
계속해서 이들 활동을 열거하고 분류합니다. 이러한 원칙에는 요구사항, 분석 및 디자인, 배치 및 프로젝트 관리가 포함됩니다.
활동은 생산하고 이용하는 아티팩트를 통해 시간과 관련됩니다. 활동은 입력이 제공될 때(및 적절히 성숙한 상태일 때) 논리적으로 시작할 수 있습니다. 즉, 아티팩트 상태에서 허용되는 경우 생산자-소비자 활동 쌍이
시간적으로 겹칠 수 있음을 의미합니다. 엄격히 시퀀스화될 필요는 없습니다. 활동은 아티팩트가 생성되어야 하는 방법에 대해 강력한 안내를 제공하기 위한 것이며, 프로젝트 관리자의 계획을 돕는 데 사용될 수도
있습니다.
RUP에서 라이프사이클, 아티팩트 및 활동을 통해 설명한 내용이 예측 가능한 스케줄 및 예산으로 고품질의 소프트웨어를 생성하는 것으로 증명된 "우수 사례": 소프트웨어 엔지니어링 원칙입니다. RUP는 활동(및 관련
아티팩트)을 통해 이러한 우수 사례를 지원하고 실현합니다(RUP 전체의 핵심 주제). 이는 RUP의 기반이 되는 중요 원칙입니다. XP에서도 "사례" 개념을 사용하지만 RUP의 우수 사례 개념과는 정확히 일치하지 않습니다.
XP는 소프트웨어 개발 보기를 일부 지원 사례에 따라 사용할 수 있고 구조화되는 네 가지 기본 활동(코딩, 테스트, 청취 및 디자인)을 통해 눈에 띄게 단순한 모습으로 표시합니다(제 9 장 Extreme
Programming Explained에서 설명). 실제로, 앞서 설명한 대로 XP 활동은 RUP 활동보다는 RUP 원칙 범위에 더 근접하며, XP 프로젝트에서 발생하는 많은 활동(네 가지 기본 활동 외)이 해당
사례의 정제와 적용으로부터 나옵니다.
따라서 RUP 활동과 동등한 XP 활동이 있지만 XP의 "활동"은 공식적으로 식별되거나 설명되지 않습니다. 예를 들어, 제 4 장 Extreme Programming
Installed의 "User Stories"를 보면 "Define requirements with stories, written on cards," 표제가 있는데, 이 장 전체에는 프로세스 설명과
유저 스토리의 개념, 생성 방법 및 주체에 대한 안내가 설명되어 있습니다. 그리고 계속해서 XP 서적의 여러 섹션(아티팩트 중심 및 활동 중심이 혼합된 표제로)을 통해
"생성된 내용"과 "수행된 내용"을 다양한 수준의 규정 및 세부사항으로 설명합니다.
RUP의 높은 수준의 규정은 활동과 활동의 입력 및 출력을 처리하는 방법에 대한 완전성 및 높은 형식성으로부터 옵니다. XP에 규정이 부족하지는 않지만 가볍게 만들기 위해 형식성 및 세부사항이 생략됩니다. 특수성의
부족은 강점도 약점도 아니지만 XP에 자세한 정보가 부족한 것을 단순성과 혼동해서는 안됩니다. 세부사항이 없으면 숙련된 개발자에게는 좋겠지만 대부분의 경우 추가 세부사항이 있으면 새로운 팀 구성원과 팀의 소프트웨어
개발 방법에 대해 알아가고 있는 팀 구성원에게 큰 도움을 줍니다.
아티팩트와 마찬가지로 활동에서는 달성 목표에 계속 초점을 맞춰야 합니다. 맹목적으로 활동을 수행하는 것은 올바른 사례가 아닙니다. 목표 달성을 위해 필요할 때 볼 수 있도록 활동 및 관련 가이드라인이 제공되지만
달성 목표를 알아내지 않아도 되는 변명으로 사용해서는 안됩니다. XP에는 이러한 의도가 명확하게 표현되어 있으며 이는 모든 RUP 사용자에게 적용됩니다.
역할
RUP에서 활동은 역할(또는 보다 정확히
말하면 역할을 수행하는 개인 또는 그룹)에 의해 수행된다고 합니다. 또한 역할은 특정 아티팩트에
대한 책임을 가집니다. 책임을 맡은 역할은 일반적으로 아티팩트를 작성하고 다른 역할(적어도 허용된 경우)이 작성한 변경사항으로 아티팩트가 손상되지 않도록 합니다. 개인 또는 그룹은 하나의 역할 또는 여러 역할을
수행할 수 있습니다. 역할은 조직에서 하나의 직위 또는 "지위"에만 맵핑될 필요는 없습니다.
Extreme Programming Explained는 XP에 작용할 수 있는 일곱 가지 역할(프로그래머, 고객, 테스터, 추적자, 코치, 컨설턴트 및 총
책임자)을 식별하고 이 역할의 책임과 이를 수행하는 사람에게 필요한 능력에 대해 설명합니다. 이러한 역할에 대한 참조는 일부 기타 XP 서적에도 나와
있습니다. XP와 RUP의 역할 수에 차이가 있는 이유는 간단합니다.
-
XP는 모든 RUP 원칙을 포함하지는 않습니다.
-
XP 역할은 RUP 역할에 비해 조직 내의 직위(여러 책임을 가질 수 있음)와 더 유사합니다. 예를 들어, XP의 프로그래머는 실제로 약간 다른 능력이 필요한 여러 RUP 역할(구현자, 코드 검토자 및
통합자)을 수행합니다.
소규모 프로젝트에서의 XP 및 RUP 역할
RUP 역할을 소규모 프로젝트에 맵핑할 경우, RUP 역할이 대응되는 XP 유사 역할 수가 다섯 개의 직위 수로 상당히 줄어듭니다. 표 3(RUP에서 가져옴)은 해당 XP 역할과의 맵핑을 표시합니다.
표 3: 소규모 프로젝트에서 XP 역할을 RUP 역할에 맵핑
RUP에 XP 사례 사용
RUP는 특정 프로세스가 구성된 후 인스턴스화될 수 있는 프로세스 프레임워크입니다. RUP는 구성되어야 하며, 이는 RUP 자체에 정의된 필수 단계입니다. 엄격히 말해, 사용자 조정된 RUP 버전을 XP와 비교해야
합니다. 즉, XP가 명시적으로 설정(및 추론 가능)한 프로젝트 특성과 사용자 조정된 RUP를 비교해야 합니다. 이렇게 사용자 조정된 RUP 프로세스는 많은 XP 사례(예: 짝 프로그래밍, 테스트 우선 디자인 및
리팩토링)를 수용할 수 있지만, RUP에서는 아키텍처, 추상(모델링 시), 위험성 및 시간적으로 다른 구조(단계 및 반복)의 중요성을 강조하므로 여전히 XP와 똑같지는 않을 것입니다.
XP는 소규모 프로젝트를 위한 경량의 프로세스 구현을 목적으로 합니다. 따라서 완전히 구체화되지 않은 설명(서적 내에)도 포함합니다. XP 구현에는 서둘러 발견, 고안 또는 정의해야 하는 내용이 항상 있습니다.
RUP는 규모 및 유형에서 XP의 범위에 맞거나 그 이상인 프로젝트를 수용합니다. 이 로드맵에 표시된 것처럼, RUP는 실제로 XP 서적에 설명된 대부분의 사례와 완전히 호환 가능합니다.
XP의 본질이 조직, 사람 및 문화에 초점을 맞추고 있음을 유념하십시오. 이는 모든 프로젝트에서 중요하며 RUP를 사용하는 프로젝트에 확실히 적용할 수 있습니다. 소규모 프로젝트에서 이러한 사례를 함께 사용하면
많은 이점을 얻을 수 있습니다.
Agile 프로세스 참조
-
XP(eXtreme Programming)(자세한 정보는 http://www.extremeprogramming.org/more.html 참조):
-
Extreme Programming Explained: Embrace Change. Kent Beck은 Extreme Programming 이면의 개념 및 철학에 대해
설명합니다. 이 서적은 방법이 아니라 대상 및 이유에 대해 설명합니다.
-
Refactoring Improving the Design of Existing Code. Martin Fowler의 리팩토링에 대한 첫 번째 권위 있는 서적입니다.
패턴으로 제시되어 있으며, 많은 Java 예제가 있습니다. 이 서적은 리팩토링 방법과 이유에 대해 설명합니다.
-
Extreme Programming Installed. 저자: Ron Jeffries, Chet Hendrickson 및 Ann Anderson. 이 서적은 특정 XP
사례를 Extreme Programming Explained보다 더 세부적으로 다루고 있습니다. 이 서적은 XP 스타일을 프로그래밍하는 방법에 대해 설명합니다.
-
Planning Extreme Programming. By Kent Beck 및 Martin Fowler. 이 서적은 신속한 전달 환경에서 소프트웨어를 계획하는 방법에 대한
최신 의견을 제시합니다. 이 서적은 XP 프로젝트를 실행하는 방법에 대해 설명합니다.
-
Extreme Programming Examined. 저자: Giancarlo Succi 및 Michele Marchesi. XP2000에 제공되며 잘 완성된 문서 세트로
대부분의 주제를 다루고 있습니다.
-
Extreme Programming in Practice. 저자: Robert C. Martin, James W. Newkirk. XP를 사용한 실제 프로젝트에 대해 자세히
설명합니다.
-
Extreme Programming Explored. 저자: William C. Wake. 대중적인 XPlorations 웹 사이트를 기반으로 합니다. 특정 주제가 자세히
설명됩니다.
-
Extreme Programming Applied: Playing to Win. 저자: Ken Auer 및 Roy Miller. XP 적용에 대한 선구자들의 경험이
설명됩니다. 9월에 출판될 예정입니다.
Agile Alliance의 다른 구성원에 대한 정보는 http://www.agilealliance.org를 참조하십시오.
|