주제

백서:


소개페이지 맨 위

RUP(Rational Unified Process)는 Rational Software가 몇 년에 걸쳐 정제한 프로세스 프레임워크이며 모든 유형의 소프트웨어 프로젝트(소형부터 대형까지)에 광범위하게 사용됩니다. 최근 들어, 증가되고 있는 "기민한" 프로세스(예: XP(eXtreme Programming), SCRUM, FDD(Feature-Driven Development) 및 Crystal Clear Methodology)는 소형 시스템 빌드에 효과적인 방법으로 인식되고 있습니다. (Agile Alliance에 대한 자세한 정보는 www.agilealliance.org를 참조하십시오.)

다음 섹션은 프로젝트 팀이 RUP에서 정의된 보다 완전한 소프트웨어 개발 프로세스를 통해 기민한 프랙티스를 처리하는 방법을 알아보기 위한 여러 가지 방법 중 하나인 "기민한" 프랙티스의 일부를 평가하는 데 도움을 주기 위한 것입니다.

개요페이지 맨 위

기민한 커뮤니티는 특히 작고 공존하는 프로젝트 팀에 적용할 수 있는 여러 "베스트 프랙티스"를 종합한 것입니다. RUP가 모든 규모의 프로젝트 팀을 대상으로 하지만, 소형 프로젝트에 성공적으로 적용될 수 있습니다. 일반적으로, RUP 및 기민한 커뮤니티 프로세스는 양질의 소프트웨어를 개발하는 데 필요한 주요 베스트 프랙티스(예: 반복적 개발 적용 및 일반 사용자에 중점적인)에 대해 유사한 관점을 가집니다.

다음 섹션은 기민한 커뮤니티에서 식별된 "베스트 프랙티스" 중 일부를 이러한 베스트 프랙티스에서 이익을 얻으려는 RUP 기반 프로젝트에 적용하는 방법에 대해 설명합니다. 이 경우, XP(eXtreme Programming) 방법론으로 표시되는 프랙티스에 특히 중점을 둡니다. (XP에 대한 자세한 정보는 http://www.extremeprogramming.org 웹 사이트를 참조하십시오.)

XP 프랙티스페이지 맨 위

XP는 4가지 기본 "활동"(코딩, 테스트, 청취 및 설계)을 포함하며 실제로 RUP 규칙과 보다 밀접하게 결합되어 있습니다. 이러한 XP 활동은 추가 활동을 수행해야 하는 프랙티스 세트를 사용하여 수행되며 RUP의 다른 규칙 중 일부에 맵핑됩니다. XP의 프랙티스는 설명된 Extreme Programming에 따르면 다음과 같습니다.

  • 계획 게임: 비즈니스 우선순위와 기술적 예측을 결합시켜 그 다음 릴리즈의 범위를 신속히 판별합니다. 계획이 현실에 미치지 못하면 계획을 갱신하십시오.
  • 소형 릴리즈: 간단한 시스템을 프로덕션에 빨리 투입한 후 아주 짧은 주기로 새 버전을 릴리즈합니다.
  • 메타포: 전체 시스템이 작동하는 방법에 대한 간단한 공유 정보를 통해 모든 개발을 안내합니다.
  • 단순 설계: 시스템은 언제든지 가능한 단순하게 설계되어야 합니다. 초과된 복잡도는 발견되자마자 제거됩니다.
  • 테스트: 프로그래머는 계속 단위 테스트를 작성하여 지속적인 개발을 위해 완벽하게 실행해야 합니다. 고객은 기능이 완료되었음을 예시하는 테스트를 작성합니다.
  • 리팩토링: 프로그래머는 중복을 제거하고, 의사소통을 개선하며, 단순화 또는 유연성 추가를 위해 작동을 변경하지 않고 시스템을 재구축합니다.
  • 페어 프로그래밍: 하나의 시스템에서 두 명의 프로그래머가 함께 전체 프로덕션 코드를 씁니다.
  • 공동 소유권: 누구나 언제든지 시스템의 코드를 변경할 수 있습니다.
  • 지속적 통합: 타스크가 완료될 때마다 하루에 여러 번 시스템을 통합하고 빌드합니다.
  • 주 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의 프랙티스 중 하나가 아닙니다(프랙티스가 XP에 대해 잘 설명하는 방법을 알아낼 수 있을 때까지, 즉, 메타포가 프랙티스에 도움을 줄 수 있을 때까지).
  • 공동 소유권: 소형 시스템 또는 서브시스템을 책임지고 있는 팀 구성원이 모든 코드에 익숙한 경우 유용합니다. 그러나 모든 팀 구성원에게 변경사항을 작성할 수 있는 동등한 권한을 주어야 할지 여부는 코드의 복잡도에 따라 달라야 합니다. 대개의 경우 현재 관련된 코드 세그먼트에 대해 작업하고 있는 개인(또는 페어)이 수정사항을 작성하도록 하는 것이 보다 빠르고 안전합니다. 가장 잘 작성된 코드에 대한 친밀도는 특히 복잡한 알고리즘을 가진 경우에 시간이 경과함에 따라 빠르게 줄어듭니다.
  • 리팩토링: 대형 시스템에서 빈번한 리팩토링은 구조의 결핍을 대신할 수 없습니다. Extreme Programming Explained에서는 "XP의 설계 전략이 등산 알고리즘과 유사하도록 합니다. 단순한 설계를 가져와 이 설계를 약간 더 복잡하게 만든 다음 약간 더 단순하게 만들고 또 다시 약간 더 복잡하게 만듭니다. 등산 알고리즘의 문제점은 작은 변경은 상황을 개선할 수 없지만 큰 변경은 상황을 개선할 수 있는 로컬 최적 조건에 도달하는 것입니다." RUP에서 구조는 크고 복잡한 시스템을 추적할 수 있도록 하기 위해 "큰 언덕"에 대한 보기 및 액세스를 제공합니다.
  • 소형 릴리즈: 고객이 새 릴리즈를 승인하고 전개할 수 있는 비율은 일반적으로 비즈니스 영향과 상관되는 여러 요인(예: 시스템의 크기)에 따라 달라집니다. 일부 유형의 시스템의 경우 2개월 주기는 너무 짧을 수 있습니다. 전개의 세부 계획이 이를 금지할 수 있습니다.

주의를 요하는 XP 프랙티스페이지 맨 위

최종적으로, 첫눈에 RUP(단순 설계)에서 잠재적으로 사용 가능하다고 여겨지는 XP 프랙티스는 일반적으로 적용될 때 약간의 면밀성과 주의가 필요합니다.

  • 단순 설계
    XP는 아주 많은 기능으로 구동됩니다. 사용자 내용을 선택하고 타스크로 분해한 후 구현합니다. Extreme Programming Explained에 따르면 주어진 시점에서 소프트웨어에 대한 올바른 결정은 모든 테스트를 실행하고 중복된 논리가 없으며 프로그래머에게 중요한 모든 목적을 진술하고 가능한 적은 클래스 및 메소드를 가지는 것입니다. XP는 고객에게 비즈니스 가치를 전달하기 위해 필요하지 않은 것을 추가하는 것을 신뢰하지 않습니다.

    RUP가 "비기능적" 요구사항을 호출할 때 사용하는 방법을 처리할 때 로컬 최적화 문제점과 유사한 문제점이 있습니다. 이러한 요구사항은 또한 고객에게 비즈니스 가치를 전달하지만 내용으로 표시하기에는 다소 어렵습니다. XP가 제한조건이라고 하는 것 중 일부는 이 카테고리로 분류됩니다. RUP는 모든 종류의 추론적인 방법에 필요한 것 이상으로 설계하는 방법은 지지하지 않지만 구조적 모델(비기능적 요구사항을 충족하기 위한 핵심 중 하나인 모델)을 염두에 두고 설계하는 방법을 지지합니다.

    따라서 RUP는 "단순 설계"가 모든 테스트 실행을 포함해야 한다는 것을 XP와 동의하지만, 여기에는 소프트웨어가 비기능적 요구사항을 충족시키는 것을 예시하는 테스트를 포함한다는 추가사항이 포함됩니다. 다시 말해, 이 점은 시스템 크기와 복잡도가 증가할 때나 구조가 전에 없던 구조이거나 비기능적 요구사항이 부담이 될 때 주요한 문제로 대두됩니다. 예를 들어, 데이터 정렬에 대한 요구(이기종 분산 환경에서 조작하기 위해)가 코드를 몹시 복잡하게 하는 것처럼 보이지만 이 요구는 프로그램 전체에서 여전히 필요합니다.

소형 프로젝트에 대한 결과물 맵핑페이지 맨 위

소형 프로젝트에 맞게 RUP를 조정하고 그에 따라 결과물 요구사항을 줄이면 XP 프로젝트의 동일 결과물과 이것을 어떻게 비교합니까? RUP의 ../../../examples/devcase_sp/dc_index.htm -- This hyperlink in not present in this generated website소형 프로젝트에 대한 예제 개발 케이스에서 더 적은 결과물을 생성하도록 구성된 샘플 RUP 형상을 볼 수 있습니다(표 1에 표시됨).

XP 결과물
내용
대화의 추가 문서
비전
용어집
유스 케이스 모델
제한조건 추가 스펙
승인 테스트 및 단위 테스트
테스트 데이터 및 테스트 결과

../../../process/artifact/ar_tstpl.htm -- This hyperlink in not present in this generated website테스트 계획
../../../process/artifact/ar_tstcs.htm -- This hyperlink in not present in this generated website테스트 케이스../../../process/artifact/ar_tstste.htm -- This hyperlink in not present in this generated website
테스트 모음
(../../../process/artifact/ar_tstsc.htm -- This hyperlink in not present in this generated website테스트 스크립트, ../../../process/artifact/ar_tstdta.htm -- This hyperlink in not present in this generated website테스트 데이터 포함)
../../../process/artifact/ar_tstlog.htm -- This hyperlink in not present in this generated website테스트 로그
테스트 평가 요약

소프트웨어(코드) 구현 모델
릴리스 ../../../process/artifact/ar_prdct.htm -- This hyperlink in not present in this generated website제품(전개 단위)
../../../process/artifact/ar_rlsnt.htm -- This hyperlink in not present in this generated website릴리즈 정보
메타포 소프트웨어 구조 문서
설계(CRC, UML 초안)
기술 타스크 및 기타 타스크
마지막에 생성되는 설계 문서
지원 문서
설계 모델
코딩 표준 ../../../process/artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website프로젝트 특정 가이드라인
작업공간
테스트 프레임워크 및 툴
../../../process/artifact/ar_devcs.htm -- This hyperlink in not present in this generated website개발 케이스
../../../process/artifact/ar_tstenv.htm -- This hyperlink in not present in this generated website테스트 환경 형상
릴리즈 계획
반복 계획
내용 추정 및 타스크 추정
소프트웨어 개발 계획
반복 계획
전체 계획 및 예산 비즈니스 케이스
위험 목록
진행에 대한 보고서
타스크 작업에 대한 시간 레코드
메트릭 데이터(자원, 범위, 품질, 시간 포함)
결과 추적
회의에 대한 보고서 및 기록
상태 평가
반복 평가
검토 레코드
결함(및 연관된 데이터) 변경 요청
코드 관리 툴 프로젝트 저장소
../../../process/artifact/ar_wkspc.htm -- This hyperlink in not present in this generated website작업공간
스파이크(솔루션)

프로토타입
사용자 인터페이스 프로토타입
구조적 개념 증명

XP 자체(권장사항 및 가이드)

../../../process/artifact/ar_tstidslst.htm -- This hyperlink in not present in this generated website테스트 아이디어 목록
../../../process/artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website프로젝트 특정 가이드라인

[XP에 포함되지 않음]

데이터 모델
../../../process/artifact/ar_eusm.htm -- This hyperlink in not present in this generated website일반 사용자 지원 자료

표 1: 소형 프로젝트에 대한 결과물의 XP에서 RUP로의 맵핑

XP 및 RUP에서 결과물의 세분성이 서로 다르긴 하지만, 일반적으로 소형 프로젝트(XP 유형이 부족함 없이 처리함)에 대한 RUP의 결과물은 XP 프로젝트의 결과물에 아주 잘 맵핑됩니다.

../../../examples/devcase_sp/dc_index.htm -- This hyperlink in not present in this generated website소형 프로젝트에 대한 예제 개발 케이스는 또한 XP에서는 다뤄지지 않지만 여러 프로젝트에 필요한 몇 가지 결과물도 포함한다는 점을 주의하십시오. 여기에는 데이터 모델 및 전개와 관련된 결과물(예: ../../../process/artifact/ar_eusm.htm -- This hyperlink in not present in this generated website일반 사용자 지원 자료)이 포함됩니다.

활동페이지 맨 위

RUP는 활동역할에 의해 수행되는 작업으로 정의합니다. 활동은 입력물을 사용하고 변환하거나 또는 새로 작성되거나 변경된 출력 결과물을 생성합니다. RUP는 RUP 규칙에 따라 이들 활동을 계속해서 열거하고 카테고리화합니다. 이러한 규칙에는 비즈니스 모델링, 요구사항, 분석 및 설계, 전개 및 프로젝트 관리가 포함됩니다.

활동은 생산하고 소비하는 결과물을 통해 시간과 관련됩니다. 활동은 입력이 사용 가능할 때(적절한 상태일 때) 논리적으로 시작할 수 있습니다. 이는 결과물 상태가 허용할 경우 생산자-소비자 활동 쌍이 시간적으로 겹칠 수 있음을 의미합니다. 엄격히 순서화될 필요는 없습니다. 활동은 결과물이 생성되어야 하는 방법에 대해 강력한 가이드를 제공하기 위한 것으로 프로젝트 관리자를 도와 계획하는 데 사용될 수도 있습니다.

라이프사이클, 결과물 및 활동에 대해 설명한 대로 RUP를 통해 짜여진 것이 예측 가능한 스케줄 및 예산으로 빌드된 양질의 소프트웨어를 만들어내는 것으로 증명된 "베스트 프랙티스": 소프트웨어 엔지니어링 원칙입니다. RUP는 활동(및 관련 결과물)을 통해 이러한 베스트 프랙티스를 지원하고 구현합니다. 베스트 프랙티스는 RUP를 통해 실행되는 주제입니다. XP가 "프랙티스"의 개념도 사용하지만 보이는 대로 RUP의 베스트 프랙티스 개념과 정확하게 대응되지는 않습니다.

XP는 소프트웨어 개발 보기를 일부 지원 프랙티스에 따라 사용 가능해지고 구조화되는 4가지 기본 활동(코딩, 테스트, 청취 및 설계)을 가짐으로 눈에 띄게 단순한 모습으로 표시합니다(제 9 장 Extreme Programming Explained에서 설명). 실제로, 앞서 참고한 바와 같이 XP 활동은 RUP 활동보다는 RUP 규칙에 대한 범위에 더 근접하며, XP 프로젝트에서 발생하는 많은 활동(네 가지 기본 활동 외)은 해당 프랙티스의 완성과 적용으로부터 나옵니다.

따라서 RUP 활동과 동등한 XP 활동이 있지만 XP의 "활동"은 공식적으로 식별되거나 그와 같이 설명되지 않습니다. 예를 들어, 제 4 장 Extreme Programming Installed에서 "User Stories"를 보면 "카드에 쓰여진 내용으로 요구사항 정의" 표제가 있고 이 장 전체에는 프로세스 설명과 사용자 내용의 개념, 생성되는 방법 및 주체에 대한 가이드가 설명되어 있습니다. 그리고 계속해서 XP 서적의 여러 섹션(결과물 중심 및 활동 중심이 혼합된 표제로)을 통해 여러 레벨의 규정 및 세부사항으로 "생성된 것"과 "수행된 것"을 모두 설명합니다.

보기에 높은 레벨의 RUP 규정은 활동과 활동의 입력 및 결과물을 처리하는 방법에서 완전성 및 더 큰 형식성으로부터 결과됩니다. XP에 규정이 부족한 것은 아니지만 부족한 상태로 남으려 할 경우, 형식성 및 세부사항이 간단히 생략됩니다. 특수성이 부족한 것은 강점도 약점도 아니지만 XP에서 자세한 정보가 부족한 것을 단순성과 혼동해서는 안됩니다. 세부사항을 갖지 않는 것이 경험이 많은 개발자에게는 좋겠지만 대부분의 경우 추가 세부사항은 새로운 팀 구성원과 팀의 소프트웨어 개발 방법에 대해 여전히 초보적인 지식을 가지고 있는 팀 구성원에게 큰 도움을 줍니다.

결과물에서와 마찬가지로 활동에서는 달성하려고 노력하는 것에 계속 중점을 두는 것이 중요합니다. 맹목적으로 활동을 수행하는 것은 올바른 프랙티스가 아닙니다. 목표를 달성하기 위해 필요할 때 볼 수 있도록 활동 및 관련 가이드라인이 제공되지만 달성하려고 노력 중인 것을 해결하지 못한 데 대한 변명으로 사용되어서는 안됩니다. XP에는 이러한 원칙이 명료하게 표현되어 있으며 모든 RUP 사용자는 이를 적용해야 합니다.

역할페이지 맨 위

RUP에서 활동역할(또는 보다 정확히 말하면 역할을 수행하는 개인 또는 그룹)에 의해 수행된다고 합니다. 또한 역할은 특정 결과물에 대한 책임을 가집니다. 책임을 맡은 역할은 일반적으로 결과물을 작성하고 다른 역할(적어도 허용된 경우)이 작성한 변경사항이 결과물을 중단시키지 않는지 확인합니다. 개인 또는 그룹은 하나의 역할 또는 여러 역할을 수행할 수 있습니다. 역할은 조직에서 하나의 위치 또는 "슬롯"에만 맵핑될 필요는 없습니다.

Extreme Programming Explained는 XP에 작용할 수 있는 7가지 역할(프로그래머, 고객, 테스터, 추적자, 지도원, 컨설턴트 및 총 책임자)을 식별하고 이 역할의 책임과 이를 수행하는 사람에게 필요한 능력에 대해 설명합니다. 이러한 역할에 대한 참조는 일부 기타 XP 서적에도 나와 있습니다. XP와 RUP의 역할 수에 차이가 있는 것은 설명하기 쉽습니다.

  • XP는 모든 RUP 규칙을 적용하지 않습니다.
  • XP 역할이 RUP 역할에 비해 조직(여러 책임을 가짐) 내의 직위와 더 유사합니다. 예를 들어, XP의 프로그래머는 실제로 약간 다른 능력이 있어야 하는 여러 RUP 역할(구현자, 코드 검토자 및 통합자)을 수행합니다.

소형 프로젝트에서 XP 및 RUP 역할 페이지 맨 위

RUP 역할을 소형 프로젝트에 맵핑할 때 직위 또는 직함의 수가 다섯 개므로 RUP 역할이 대응되는 XP 유사 역할의 수가 상당히 감소됩니다. 표 3(RUP에서 그려짐)은 대응되는 XP 역할과의 맵핑을 표시합니다.

XP 역할 예제 RUP 소형 프로젝트 팀 구성원 RUP 역할
지도원
컨설턴트
총 책임자
Sally Slalom, 선임 관리자 프로젝트 관리자
../../../process/workers/wk_depm.htm -- This hyperlink in not present in this generated website전개 관리자
기술 검토자
형상 관리자
변경 제어 관리자
고객 스테이크홀더(비전에 문서화되어 있음)
관리 검토자
기술 검토자(요구사항)
고객
총 책임자
추적자
Tom Telemark, 선임 소프트웨어 엔지니어 시스템 분석가
요구사항 지정자
사용자 인터페이스 설계자
소프트웨어 아키텍트
기술 검토자
테스트 관리자
../../../process/workers/wk_tstanl.htm -- This hyperlink in not present in this generated website테스트 분석가

및 더 작은 범위의 개발자 역할.

프로그래머
테스터

Susan Snow, 소프트웨어 엔지니어

Henry Halfpipe, 하급 소프트웨어 엔지니어

설계자
구현자
기술 검토자
통합자
../../../process/workers/wk_tstds.htm -- This hyperlink in not present in this generated website테스트 설계자
../../../process/workers/wk_tstr.htm -- This hyperlink in not present in this generated website테스터
../../../process/workers/wk_tchwr.htm -- This hyperlink in not present in this generated website기술 자료 작성자
추적자 Patrick Powder, 부관리자 프로젝트 웹 사이트를 유지보수하고 프로젝트 관리자 역할이 활동을 계획/스케줄하는 데 도움을 주며 변경 제어 관리자 역할이 결과물에 대한 변경을 제어하는 데 도움을 주는 책임을 맡습니다.  필요한 경우 다른 역할에도 도움을 줄 수 있습니다.

표 3: 소형 프로젝트에서 XP 역할을 RUP 역할에 맵핑

RUP와 함께 XP 프랙티스 사용페이지 맨 위

RUP는 특정 프로세스가 구성된 후 인스턴스화될 수 있는 프로세스 프레임워크입니다. RUP가 구성되어야 합니다. 이것은 RUP 자체에 정의된 필수 단계입니다. 엄격히 말해, 조정된 RUP 버전을 XP와 비교해야 합니다. 즉, XP가 명시적으로 구축한 프로젝트 특성(및 추론될 수 있는 프로젝트 특성)에 맞게 조정된 RUP와 비교해야 합니다. 이렇게 조정된 RUP 프로세스는 많은 XP 프랙티스(예: 페어 프로그래밍, 테스트 우선 설계 및 리팩토링)를 적응시킬 수 있지만, RUP가 구조, 추상(모델링), 위험 및 시간적 다른 구조(단계 및 반복)의 중요성을 강조하므로 여전히 XP와 동일하지는 않을 것입니다.

XP의 방향은 의도적으로 소규모 프로젝트를 위한 경량의 프로세스를 구현하는 데 있습니다. 따라서 완전히 구현되지 않은 설명(책에 포함된 최소 내용)도 포함합니다. XP 구현에는 서둘러 발견하거나 조작하거나 정의해야 하는 것이 항상 있습니다. RUP는 규모 및 유형에서 XP의 범위에 맞거나 넘어서는 프로젝트를 적응시킵니다. 이 로드맵에 표시된 것처럼, RUP는 실제로 XP 문헌에 설명된 대부분의 프랙티스와 완전히 호환 가능합니다.

XP의 본질이 조직, 사람 및 문화에 초점을 두고 있음을 유념하십시오. 이것은 모든 프로젝트에 중요하며 RUP를 사용하는 프로젝트에 확실히 적용할 수 있습니다. 소형 프로젝트는 이러한 프랙티스를 함께 사용하여 크게 이익을 얻을 수 있습니다.

기민한 프로세스 참조페이지 맨 위

  • 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. 이 책은 Expreme Programming Explained보다 더 세부적으로 특정 XP 프랙티스를 다루고 있습니다. 이 책은 XP 양식을 프로그래밍하는 방법에 대해 설명합니다.
    • Planning Extreme Programming. 저자: 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/home을 참조하십시오.



Rational Unified Process   2003.06.15