eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), Scrum 같은 Agile 개발 방식이 소프트웨어 개발 프로젝트를 수행하는 새로운 방식으로서 도입된 지는 얼마 되지 않는다. 오늘날 반복 개발(iterative development), 테스트 중심 개발, 연속적인 통합 등의 Agile 개발 관행들은 거의 일반화 되었고 소프트웨어 개발의 대안 방식으로서 채택되고 있다. 여러분이 무엇을 믿건, 또는 어떤 것을 경험했든 간에 Agile 개발 프로젝트는 시간과 예산에 맞춰, 성공적인 기능을 수행할 수 있다는 점은 부인할 수 없을 것이다. ¹

이 글에서는 Agile 개발 방식을 사용하는 소프트웨어 개발 프로젝트에서 사용되는, 경량의SCM이라 할 수 있는, Agile 개발의 특수한 측면, 즉 Agile Software Configuration Management 또는 Agile SCM에 대해 논하고자 한다. IBM Rational SCM 툴셋 같은 엔터프라이즈 SCM 툴셋이 Agile 프로젝트에 어떻게 사용되는지를 설명하겠다.

Agile 개발

대부분의 Agile 개발 방식은 사용자 또는 고객의 직접적인 개입과 이들과의 인터랙션, 빈번하고 짧은 주기로 수행되는(일반적으로 2주에서 12주) 반복 기간 안에 기능의 개발이다. 일반적으로 각 반복을 시작할 때 Agile 팀은 고객과 협상을 통해 새로운 기능을 정의하거나 요청을 수정한다. 개발자들은 이를 평가한 후 다음 반복 동안에는 고객이 우선순위를 정한다. (그림 1) 한 반복 동안에 구현되지 않은 기능이나 변경 요청들에 대한 미 처리분은 새로운 요청들과 함께 저장되며 다음 반복 시기에 고객들에 의해 우선순위가 정해진다. 개발자들은 각 반복 동안 요청에 대해 작업을 하거나 리랙토링을 수행하고 기존 코드를 단순화 한다. 이렇게 하는 이유는 디자인을 간결하게 유지하고 기능 과잉을 방지하기 위해서이다. 코드 또한 지속적으로 통합된다; 커밋할 때 통합에러를 체크하기 위해 호출되는 자동화된 빌드 프로세스로서 매우 작은 단위들로 구성되어 자주 구현, 테스트, 커밋된다.

그림 1: 각 반복의 시작에서 Agile 팀은 고객과 협상을 통해 새로운 기능을 정의하거나 요청을 수정한다. 개발자들은 이것을 평가한 후 다음 반복 동안에는 고객이 우선순위를 정한다.

다른 소프트웨어 개발 프로세스와 마찬가지로 Agile 개발 방식에는 핵심 환경과 이를 지원하는 팀 환경이 필요하다. 바로 이것이 소프트웨어 설정 관리(software configuration management) 또는 SCM이라고 불린다. 어떤 사람들은 SCM을 구식의 불필요한 규제라고 생각한다. 이것은 분명 오해이다. 너무나 많은 잘못된 SCM이 Agile 개발 프로젝트를 망치고 있는 것도 사실이지만 반복 개발과 연속적인 통합 같은 Agile 관행이 SCM 없이는 제 기능을 수행할 수 없다는 점도 사실이다.

그렇다면 이러한 유형의 프로젝트에는 얼마나 많은 SCM이, 어떤 형태의 SCM이 필요할까? 비교적 새로운 개념인 Agile SCM을 소개하겠다.

Agile SCM

Agile SCM의 개념은 Brad Appleton과 Stephen Berczuk이 그들의 저서인 Software Configuration Management Patterns 와 SCM portal CM Crossroads ² 에 상세히 설명해 놓았다.

...설정 관리(Configuration Management)는 Agile 개발 방식의 중요한 토대가 될 것이다. "agilists(Agile 주의자)"가 가볍고 단순한 것에 지나치게 의존하고, Agile 프로젝트에 대한 CM은 강제력이 덜하기 때문에(Grady Booch는 이를 low-friction이라고 했다.), Agile 프로젝트를 성공으로 이끎과 동시에, (과도한 반동으로 인해) 너무 작게 만들어서 실패하는 일도 없어야겠다.

나의 견해에 동의하면 Agile 프로젝트에 있어 SCM은 더욱 경량이고 두드러지지도 않지만, SCM 그 자체로는 이 같은 프로젝트의 필수 요소이다. 대부분의 Agile 프로젝트가 CVS, Subversion, BitKeeper 같은 기초적인 경량의 SCM 툴을 채택하는 것도 우연의 일치는 아니다. 이 툴들은 궁극적으로 Agile 프로젝트에 필요한 충분한 기능을 제공한다. 또한 조직화된 프로세스에 순응하기 보다는 강제력이 약하다.

이론상으로는, Agile 개발에 SCM 툴을 사용하지 않을 이유가 없다. 툴의 모든 기능들을 사용할 필요가 없고 대부분의 툴은 일정한 프로세스 개인화가 허용된다. IBM Rational ClearCase 같은 엔터프라이즈 툴들의 경우, 어떤 기업은 툴이 지원하는 모든 기능들을 사용하여 무거운 SCM 프로세스를 정의하곤 한다. 하지만 그와 같은 프로세스로는 여러분의 프로젝트의 요구 사항들을 채울 수 없다. 개인화의 올바른 프로세스와 레벨을 찾기 위해 요구 사항들을 규명 및 정의해야 한다. 다시 말해서, 개발 프로세스가 어떻게 되는지를 정확히 이해하고 SCM이 이를 어떻게 지원할지를 결정해야 한다.

일반적으로 SCM은 개발 프로세스의 "관리(governance)"에 관한 것이 아니다. SCM은 프로젝트를 제어하지만, 이와 동시에 개발자들이 그 프로세스 내에서 무엇인가를 만들 자유도 주고 있다. Agile 개발 방식을 사용하면 개발자들에게는 변경 사항들을 구현할 많은 자유와 권한이 주어진다. 하지만 연속적인 통합과 테스트 중심의 개발 관행의 한 가지 특징은 자가 규제 및 자가 관리 방식이 잘 되어있다는 점이다. 예를 들어, 코드 변경 시, Agile 개발자들은 먼저 단위 테스트를 작성하고, 테스트가 작동할 만큼 충분한 코드를 작성한 다음, 변경 사항을 완료하기 위해 충분한 리팩토링을 한다. 코드 변경이 이루어지면 단위 테스트는 통합 슈트의 일부가 된다. 전체 단위 테스트 슈트를 컴파일 및 실행하면서, 변경의 부작용은 통합 구현 메커니즘을 통해 즉시 나타난다. 발견된 문제들은 즉시 수정된다.

Agile SCM에서 거버넌스 모델은 개발 과정의 자연스러운 일부이고 모든 결과들은 개발자들에게 투명하게 보여진다. 거버넌스 모델을 보다 자세히 이해하려면 SCM의 다양한 특성들을 보고 이들이 어떻게 Agile에 사용되는지를 파악해야 한다.

• 브랜치(Branches). Agile 프로젝트는 간단한 브랜칭 전략을 세운다. 주로 Active Development Line ³ 과 Release Prep Line이다. Active Development Line은 개발자가 변경 사항을 나타낼 때 사용하며 이를 통해 연속적인 통합이 이루어진다. Release Prep Line은 고객이 사용하기 전에 릴리스를 안정화 하고 엔지니어링 하는데 사용된다. 개발자들은 변경 사항들을 여기에 나타낼 수 없다.
• 작업공간(Workspaces). 개발자들은 일반적으로 개인적인 작업공간을 갖고 있다. 이 작업공간은 처음에는 최신 버전의 Active Development Line을 가리킨다. 그들의 작업공간은 새로운 기능에 대한 작업을 시작할 때나, 또는 변경 사항들을 Active Development Line에 위임하여 통합 문제를 검사하기 전에 업데이트 된다.
• 레이블(Labels). 전통적인 SCM과 마찬가지로 레이블은 전체 코드 버전에서 중요한 곳에 위치해 있기 때문에 필요하다면 구현 환경을 다시 만드는 것도 가능하다.
• 구현과 통합(Builds and integration). 자동화된 구현 프로세스는 성공적인 Agile 개발의 핵심 요소이다. 구현 프로세스는 Active Development Line을 모니터링 하고, 커밋(commit)이 발견되면 유예 기간 후에 통합 구현과 단위 테스트를 실행한다. 구현 성공 또는 실패 공지는 Agile 팀에 있어서 중요한 커뮤니케이션 요소이다.
• 변경 제어(Change control). 앞서 논의되었듯이 Agile 개발 팀에는 권한 프로세스가 있다. 개발자들은 필요에 따라 고객 우선순위나 리팩토링에 기반하여 수정할 수 있다. 요청 사항들은 변경 제어 시스템 또는 보다 비공식적인 프로젝트에서 기록된다. 특히 eXtreme Programming 프로젝트에서는 카드나 플립 차트에 기록된다.

이와 같은 SCM 특성이 Agile 프로세스에서는 일반적인 것이라 하더라도 특정 프로젝트가 요구하는 기민성 정도에 따라 조정될 수 있다. 예를 들어, 어떤 프로젝트는 각 커밋 위에 구현될 수 없고 대신 매일 또는 매일 밤 통합 구현을 초기화한다. 또한 프로젝트는 고립되지 않는다. 일반적으로 이들은 한 기업 내의 많은 프로젝트들 중 하나가 된다. 기업에는 Agile과 전통적인 플랜 중심의 프로젝트가 혼합되어 있기 때문에 주어진 프로젝트는 특별한 시장 영역에 존재한다. 이러한 기업 정황은 SCM 툴셋을 선택하는데 가장 강력한 요소가 된다.

Agile SCM과 기업

하나의 Agile 프로젝트를 따로 떼어놓고 보면 SCM 요구 사항들은 비교적 간단한 툴셋으로도 충분히 충족될 수 있다. 이와 같은 툴셋은 프로젝트 내에서 사용 및 관리된다. 하지만 대부분의 대기업에서는 프로젝트에서 사용하는 툴셋을 지원하기 보다는 하나의 SCM 툴셋으로 표준화 하는 것을 선호하고, 이것에 기반하여 조직적 프로세스를 개발한다. 이렇게 하는 데는 두 가지 중요한 이유가 있다.

• 툴셋과 프로세스의 총 소유 비용(total cost of ownership)을 줄이기 위해
• 필수 호환성이나 규율 프레임웍에 순응할 수 있도록

총 소유 비용은 주관적인 문제이다. 여기에는 라이센스, 관리, 지원 비용, 기능 또는 확장성 같은 주관적인 측면이 포함되기 때문이다. IBM Rational 툴셋 같은 기업용 툴셋은 라이센싱, 관리, 지원 비용이 더 많이 들지만, 올바르게 구현된다면 기업의 역량을 향상시킬 수 있다. 또한 확장성은 이미 입증되었고, 지역적으로 분산된 개발 조직을 지원할 수 있을 정도의 통합된 인프라스트럭처를 갖고 있다. 앞서 언급했듯이 이 같은 툴셋에서 가장 위험한 것은 필요한 것 보다 더 많은 기능을 사용하고자 하는 유혹이다. 이것 때문에 Agile 프로젝트를 망칠 수 있다. 기업 레벨의 SCM 프레임웍은 구축되어야 하고, 설정이 가능하여 다양한 프로젝트의 필요를 채울 수 있어야 한다.

Sarbanes Oxley, Basel II, CFR 21 Part 11 같은 최신 산업 규제들 때문에 SCM 프로세스에 오버헤드를 생긴다. 변경 관리가 특히 그렇다. "의무의 분리" 같은 관행-개발자는 실행 환경에 전개할 수 없음-이 있어야 하지만, Agile 프로젝트에 너무 강력하게 변경 관리를 수행한다. 이러한 규제를 따르지 못할 경우 비즈니스 비용은 매우 크기 때문에, Agile 프로젝트는 중요치 않는 거버넌스 관행을 피해야 하기 때문에 대부분의 경우 오버헤드는 불가피하다. 좋은 소식은 올바르게 구현된다면 자동화된 SCM 툴셋이 이러한 거버넌스의 대부분을 책임지고 기업이 조직적인 제어를 수행하고, 개별 프로젝트와 개발자들은 새로운 소프트웨어 기능을 만드는 등의 생산적인 일에 집중할 수 있도록 한다.

IBM Rational 툴셋으로 Agile SCM 구현하기

IBM Rational 툴셋을 사용할 경우, Agile 프로젝트에서 강력한 거버넌스와 기민성 간 균형이 어떻게 맞춰지는지를 살펴보자.

IBM Rational 툴셋 같은 엔터프라이즈 SCM 툴셋은 Agile 개발 방식에는 사용될 수 없다. 이러한 툴셋의 주요 기능들은 다른 유형과 크기의 개발 환경에 사용된다. 결과적으로 어떤 기능 요소들이 사용되어야 하는지를 규명하는 것은 쉬운 일이 아니며 SCM 프로세스가 과도하게 엔지니어링 될 위험도 있다. IBM Rational SCM 툴셋을 위한 Agile SCM 제품은 없다. 다만 툴셋 구현자가 적절한 구성을 찾아서 필요를 맞춰야 한다.

다행히도, 많은 기업들이 그와 같은 구성을 찾아 IBM Rational 툴셋을 기반으로 Agile 개발을 성공적으로 수행한다. 이러한 프로젝트들을 관찰해 보면 많은 베스트 프랙티스들이 있다. 비록 절대적인 것은 아니지만 여러분의 Agile SCM 프로세스를 구현하는 데는 좋은 틀이 될 수 있을 것이다. 다음과 같이 요약해 보았다.

• 간소화된 브랜칭 전략 구현. Agile 프로젝트는 단순한 브랜칭 전략을 세운다. Base ClearCase와 ClearCase UCM (Unified Change Management) 모두, 브랜치(UCM 용어로는 "스트림(stream)")는 쉽고 간단히 만들어 질 수 있다. 그렇기 때문에 정말로 필요한 것 이상으로 복잡한 브랜칭 전략을 정의하고 싶은 유혹도 많이 있다. Agile 프로젝트는 연속 통합과 리팩토링을 적극 권장하지만 개발자가 브랜치에 고립되어 있다면 문제가 많거나 복잡한 합병이 생길 수 있다. 네임스페이스 리팩토링(파일이나 디렉토리의 재명명, 추가, 삭제)의 경우 특히 그렇다. 결국, 대부분의 Agile 프로젝트는 Active Development Line으로서 작동할 특정 브랜치와 개발자가 직접 작업할 브랜치를 구현한다. Base ClearCase에서 이것은 메인 브랜치 또는 특정 프로젝트 통합 브랜치이다. UCM에서 이것은 UCM 프로젝트의 통합 스트림이 된다. 릴리스를 위해 환경을 고립시키기 위해서는 일반적으로 Release-Prep Line이 만들어진다. 이는 후보 레이블(UCM baseline)에서 릴리스 브랜치(또는 UCM 스트림)을 만들면 되는 것이다. 이 레이블은 통합 구현의 일부로서 직접 또는 자동으로 만들어진다. (그림 2)
  
  
  
  그림 2: 릴리스를 위해 환경을 고립시키기 위해서는 일반적으로 Release-Prep Line이 만들어진다. 이는 후보 레이블(UCM baseline)에서 릴리스 브랜치(또는 UCM 스트림)을 만들면 되는 것이다. 이 레이블은 통합 구현의 일부로서 직접 또는 자동으로 만들어진다.
  
  단순화된 브랜칭 전략은 물론, Agile 프로젝트는 ClearCase 디폴트를 "unreserved" 체크아웃 모델로 설정한다. 개발자들은 어느 시점에서나 Active Development Line에서 파일을 검사할 수 있다. 디폴트 ClearCase 모델은 첫 번째 검사가 "reserved" 되도록 한다. 다시 말해서, 여러분이 합병을 할 필요 없이 엘리먼트를 검사할 수 있다는 것을 의미한다. 하지만 다른 사람들은 여러분이 파일을 돌려놓을 때 까지 reserved 엘리먼트를 검사할 수 없으며 엘리먼트를 unreserved로 검사한 사람들은 합병 전에 되돌려 놓을 때 까지 기다려야 한다. 이 같은 방식은 Agile 원리에 반하는 것이다.
• 스냅샷-뷰 개발자 작업공간 사용. 개발자가 싱글 브랜치에서 작업한다면 동적 뷰는 옵션이 아니다. 동적 뷰의 힘은 뷰가 보고 있는 브랜치가 업데이트 될 때 자동으로 업데이트 된다는 데에 있다. 따라서 많은 개발자들이 싱글 브랜치에 동적인 뷰를 갖고 있다면 작업공간에 제어나 고립이 적다. 개발자 브랜치들이 구현되더라도 또 다른 문제가 생길 수 있다. 따라서 Agile 프로젝트는 스냅샷 뷰를 구현한다. 이 곳에서 개발자들은 작업공간을 업데이트 하여 다른 개발자들이 변경한 것을 적용할 수 있다. 실제로 이렇게 하면 개발자에게 충분한 제어와 고립이 허용된다.
• 구현 프로세스 자동화. 싱글 브랜치 개발과 점증적인 체크인은 자동화된 구현과 테스트가 빈번하게 실행될 때에만 유효하다. 대부분의 Agile 프로젝트는 구현 프로세스를 설정하여 모든 개발자의 체크인 시 실행하도록 되어있다. 코드를 컴파일 하는 것은 물론, 새로운 코드가 코딩 규약에 맞는지를 검사하고 필요에 따라 단위 테스트도 실행한다. Agile 개발 방식에서 이러한 관행을 연속적인 통합이라고 한다. 통합 문제들을 가능한 빨리 포착하여 프로젝트의 매 단계 마다 구현, 테스트, 릴리스 될 수 있도록 하는 것이 이 통합의 목적이다. 연속적인 통합은 테스트 중심 개발 관행과 얽혀있다. 개발자들은 모든 코드에 대해 단위 테스트를 작성하여 구현이 컴파일 되었는지, 최소한의 품질을 유지하고 있는지를 검사하기 때문이다. ClearCase 관점에서 볼 때 Agile 프로젝트의 구현 프로세스는 통합 브랜치(UCM 스트림)를 감시하고 체크인 시 구현 스크립트를 실행한다. CruiseControl (http://cruisecontrol.sourceforge.net)이나 IBM Rational BuildForge (http://www-306.ibm.com/software/rational/buildmanagement/) ⁴ 같은 툴을 사용한다.
• 사전 설정 바이너리의 스테이징 및 재사용. 복잡한 소프트웨어 애플리케이션을 구현하는 데는 시간이 걸린다. Agile 프로젝트에서 개발자들은 작은 변경 사항들도 자주 통합하게 된다. 따라서 구현을 완성하기 까지 두 시간이나 되는 시간을 기다릴 수는 없다. 따라서 Agile 프로젝트는 사전 설정된 바이너리를 "스테이징" 및 재사용하고, 필요할 경우에 전체 시스템만 재구현 한다. (주로 야간 또는 주말) 바이너리 스테이징 방법은 여러 가지가 있다. ClearCase가 바이너리 스테이징에 사용된다. C/C++ 프로젝트의 경우 ClearCase clearmake 유틸리티가 사용된다. 자바 프로젝트에는 Ivy (http://jayasoft.org/ivy) 또는 Maven (http://maven.apache.org)이 사용된다. 프로젝트가 상당량의 오픈 소스 컴포넌트를 재사용하거나 이행적 종속성(transitive dependencies)(라이브러리가 다른 라이브러리에 의존하는 경우)과 관련한 문제가 있을 경우 적합하다.
• 합성 애플리케이션으로서 릴리스 하기. 애플리케이션을 릴리스 할 때 개별 세트 보다는 모든 파일들을 릴리스 하라. 대부분의 Agile 프로젝트는 변경된 개별 파일들 보다는 매번 전체 또는 합성 애플리케이션을 전개한다. 이것이 강력한 규칙은 아니지만 매번 같은 방식으로 전체 애플리케이션을 릴리스 하면 프로세스는 보다 반복적이 되고 파일 소실과 같은 문제들을 방지한다. 이러한 관행은 다른 프로젝트들 보다는 Agile 프로젝트에 더 중요하다. 각 반복의 끝에 실행, 테스트, 릴리스 가능한 애플리케이션을 만들기 때문이다. 분명히 이는 애플리케이션의 목표 환경에 의존한다. 이것이 웹 포탈이면 괜찮지만, (Microsoft Windows에서 실행되는) 고객 애플리케이션이라면 불가능하다.
• MultiSite 기술의 제한. 분산된 Agile 프로젝트는 어떤 코드라인에라도 자유롭게 액세스 할 수 있어야 한다. ClearCase MultiSite 기술은 전체 데이터를 사이트간 복사한다. 각 사이트에서 만들어진 변경 사항들의 충돌을 방지하기 위해 mastership이라는 개념을 만들었다. 여러 사이트에서 프로젝트가 실행되고 개발자들이 같은 브랜치를 공유한다면 변경 사항을 적용하기 전에 각 개발자들은 mastership을 요청해야 한다. 이러한 문제를 해결하는 방법도 여러 가지이지만 이들 모두 복잡성만 가중시키고 전체적으로 개발 프로세스를 지연시킨다. 때문에, Agile 프로젝트는 MultiSite 기술을 사용하지 않는다. ClearCase Remote Client (CCRC)가 개발되었기 때문이기도 하다. 이것은 싱글 서버에서 벗어난 분산 개발을 허용한다. CCRC의 첫 번째 릴리스는 기능이 제한되었지만 7.0 버전 부터는 대부분의 분산 프로젝트를 지원할 만큼의 기능을 갖추고 있다. 앞으로 분산 Agile 프로젝트에 고려해도 좋을 것이다. 그림 3은 Eclipse 환경에서 ClearCase Remote Client의 작동 모습이다.

그림 3: Eclipse 환경에서 ClearCase Remote Client의 작동

• ClearQuest 변경 관리에 있어 과도한 개인화 방지. 개방되었거나 개인화가 가능한 변경 요청 워크플로우를 구현한다. IBM Rational ClearQuest 툴은 매우 강력하고 세련된 변경 탐지 및 오류 탐지 장치를 제공한다. ClearCase를 사용하는 많은 Agile 프로젝트가 ClearQuest를 전적으로 사용하는 것을 회피하는 경향이 있지만 점점더 많은 프로젝트에서 ClearQuest를 찾고 있고 UCM 역시 그 가능성을 모색하고 있다. 확실히 ClearQuest는 캡처, 우선순위 지정, 변경 요청의 할당, 기능 백로그 등을 자동화 할 수 있다. 하지만 너무나 많은 프로세스 실행과 세세한 관리로 인해 개발자들이 새로운 변경 작업을 시작할 때 시간이 많이 걸린다. 잘 사용하지 않으면 전체 개발 프로세스를 지연시킬 수 있고 Agile 프로젝트의 생산성도 줄이게 된다. 따라서, Agile 프로젝트는 경량의 개인화가 가능한 ClearQuest 변경 요청 워크플로우를 만든다. 이는 특히 ClearQuest가 회사 전체에 걸쳐 사용될 때 더욱 많이 사용된다. 회사의 몇몇 프로젝트는 더 많은 프로세스 제어와 관리가 필요할 수 있는데 ClearQuest 툴에 이 많은 기능들이 포함되어 있다. 하지만 Agile 프로젝트는 프로세스 제어와 관리를 필요로 하지 않는다. 그와 같은 환경에 있는 기업들은 변경 요청 워크플로우가 각 프로젝트에서 설정될 수 있도록 하여 성공을 거두었다. 물론 ClearQuest 툴과 다양한 프로젝트 프로세스의 요구 사항에 대한 이해가 있어야지만 가능하다.

Agile에 맞는 프로세스

Agile SCM과 IBM Rational ClearCase와 IBM Rational ClearQuest 사용 방법을 설명했다. Agile 프로젝트에 맞는 프로세스를 선택하는데 도움이 되었기 바란다. Agile SCM 환경의 구현은 Agile 프로젝트에만 국한되지 않는다. 스스로를 Agile이라고 생각하지 않는 많은 프로젝트가 있지만 여기에도 비슷한 SCM 요구 사항들이 있다. 소규모 IS/IT 프로젝트에는 비슷한 환경 설정이 알맞다. 더 큰 프로젝트도 이 글에서 설명한 경량의, 정의가 잘된 SCM 프로세스를 구현할 수 있다. 특히 구현 자동화, 사전 설정된 바이너리 스테이징, 합성 릴리스 등은 어느 프로젝트에서도 사용될 수 있는 것들이다.

IBM Rational 툴셋 같은 엔터프라이즈 SCM 툴셋도 얼마든지 Agile 개발을 지원할 수 있다. 중요한 것은, Agile 팀을 제한하기 보다는 지원하는 데에 초점을 맞춘 Agile SCM 프로세스를 구현하는 것이다. 팀에 맞는 올바른 거버넌스 모델을 찾는 것은 쉽지 않다. 일반적으로는 보다 개방적인 프로세스로 시작할 것을 권고하곤 한다. 피드백 역시 Agile 개발의 중요한 일부이다. SCM은 자동화된 구현과 테스팅(전개) 프로세스를 통해 피드백을 받는다. 전체 프로세스의 특성을 살피는데 주의를 기울여야 한다.

Notes

¹Barry Boehm과 Richard Turner의, Balancing Agility and Discipline: A Guide for the Perplexed: Addison Wesley 2004.The Agile Journal (http://www.agilejournal.com)

² Stephen P. Berczuk과 Brad AppletonSoftware Configuration Management Patterns. Effective Teamwork, Practical Integration. Addison Wesley 2003.Streamed Lines: Branching Patterns for Parallel Software Development. PLoP Conference: 1998. http://www.cmcrossroads.com/bradapp/acme/branching/

³ Appleton, 1998, Op. cit.

⁴Kevin A. Lee, IBM Rational ClearCase, Ant and CruiseControl. The Java Developers Guide to Accelerating and Automating the build process. Addison Wesley 2006.

기사의 원문보기

• Agile SCM and the IBM Rational toolset

필자소개

Kevin A. Lee는 다양한 규모의 프로젝트에서 소프트웨어 구현 및 릴리스 관리를 수행했다. 2000년 영국 Rational Software에 입사하여 IBM Rational Software Development Platform의 전개 및 채택과 관련한 고객 지원을 맡았다. 전 세계적인 IBM Rational 사용자 컨퍼런스에서 프리젠테이션도 하고 IBM developerWorks에 글도 기고하고 있다. University of East Anglia에서 컴퓨터 공학을 전공했다.

아티클 순위

의견

위로

목차

• Agile 개발
• Agile SCM
• Agile SCM과 기업
• IBM Rational 툴셋으로 Agile SCM 구현하기
• Agile에 맞는 프로세스
• Notes
• 필자소개
• 의견