블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

실용주의 ALM (Application Lifecycle Management) Overview

ALM | 2009.02.18 17:35 | Posted by 조대협

 

Practical Application Life cycle Management (ALM)

 Overview

ALM의 정의를 wikipedia에서 찾아보면 다음과 같다.

Application lifecycle management (ALM) is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.[1]

 

해석해 보자면, 기존의 애플리케이션 개발은 기술적인 관점에서 많이 접근이 되어 왔으나, 비즈니스 요건 관리 부분과 실제 소프트웨어 개발 프로세스를 융합하고 이에 대한 관리를 자동화된 툴을 이용하도록 하는 것이 ALM의 개념이며, 이 부분에는 요구 사항 관리, 아키텍쳐, 코딩, 테스팅, 그리고 이슈 추적과 릴리즈 관리등을 포함한다. 

한마디로 이야기 하면 비즈니스와 실제 소프트웨어 개발간의 괴리를 없애고, 소프트웨어 개발의 요구사항 분석에서부터 릴리즈까지의 모든 과정을 툴을 도입함으로써 관리하겠다는 개념이다. 

기존에 소프트웨어 개발 프로세스는 요구 사항 관리에 대한 문서나 시스템, 아키텍쳐나 디자인에 대한 Case tool과 산출물, 코드 관리, 일정 관리 등등이 각기 다른 제품과 다른 프로세스 다른 템플릿으로 구현이 되어 왔고 이로 인해서 소프트웨어 개발 과정에 대한 개념이 실제로 구현되었을때는 단계별로 추적성과 실용성이 떨어졌다.

ALM의 의미는 이런 현실과 괴리된 부분을 좀더 통합되고 현실적으로 전문화된 도구를 이용하여 현실화 시키고 궁극적으로 소프트웨어 개발 프로세스를 개선하는데 목적을 두고 있다고 말할 수 있다. 

ALM이 실제 커버하는 범위를 보면 아래 그림과 같이 요구사항 관리에서부터 프로젝트 관리, 릴리즈 관리까지 소프트웨어 개발의 거의 전 영역을 커버하는 것을 볼 수 있다.


(위키피디아 ALM Concepnt 그림 인용 : http://en.wikipedia.org/wiki/Application_lifecycle_management)

 

요즘 들어서 많은 업체들이 이 ALM이라는 개념을 사용하고 있다. H*의 경우 버그 추적 시스템을 기반으로 이슈 관리, 테스트 자동화 도구를 가지고 ALM이라고 이야기 하고 있으며 Mc* 라는 업체의 경우 테스팅 툴 하나만을 가지고 ALM 업체라고 이야기 하고 있다. 

ALM이 가져야 할 최소한의 요건은

요구 사항 관리, 프로젝트 스케쥴 관리를 위한 Task 관리, 빌드 환경 자동화 및 형상 관리, 테스트 자동화 부분이 핵심이다.

그외에 Deployment의 경우 주로 운영 (SM : System Management) 조직이 담당하며, Design이나 아키텍쳐링의 경우 ALM 사상내에 포함되는 것이 이론적으로는 맞지만, 사실 Design의 경우 프로세스를 정형화 시키기 어려울뿐더러, 실제 프로젝트에서는 Design이 프로젝트가 진행되어감에 따라 변화하고 완성되어 가기 때문에,  Design을 포함시키는 것은 쉽지 않다.

사람들은 프로젝트를 하면서 똑똑해지고 시스템은 프로젝트 진행됨에 따라 명확해 진다. Agile 사상에서도 Design은 선행 작업이 아니라, 주로 프로젝트 진행과 같이 가는 On going 작업으로 정의하고 있다. Design을 ALM의 구현체 내에 포함시키기 위해서는 말단 개발자까지 상당 수준의 성숙도가 필요하다. 

문제점

ALM의 사상적인 출발은 툴을 이용한 소프트웨어 개발 사이클의 현실화인데, 시장에 있는 툴의 경우 그 성숙도가 매우 높아서 프로젝트에 적용하는데 상당한 경험과 지식을 필요로 한다. 실용적인면에서 생각했을 때 ALM의 적용 범위는 일반 말단 개발자 수준에 까지 적용이 되어야 하기 때문에 난이도가 높을때는 실제 프로젝트에 적용하기가 어려운 점이 많다.

또한 ALM Company를 자칭 하는 많은 회사들이 ALM에 대한 Full set을 가지고 있지 않은 상태에서 마케팅적인 메시지로 Drive 하는 경우가 많아서 사용자의 혼란을 초래하고 있다. 

그리고 무엇보다 중요한 것은 ALM을 시스템으로 구축하기 위한 제품이 아니라 ALM을 조직에 적용하기 위한 프로세스와 방법론 즉, 컨설팅과 같은 인적 지원면인데, 적어도 국내의 벤더들에서는 실용적으로 ALM을 프로젝트에 적용할 수 있는 업체가 있는지는 의문이다. 

실용주의 ALM

실용주의 ALM은 이런 문제점을 바탕으로 좀더 실용적이고 실무적인 ALM을 개발하여 실무에 사용하고자 하는데 목적을 두고 있으며 아래와 같은 특징을 갖는다.

l        주로 오픈소스나 저비용의 제품을 조합하여 ALM의 핵심 범위를 커버한다.
l        Agile과 Kent Beck, Erich Gamma, Joel Spolsky 등에 의해서 주장되고 있는 실용주의 방법론 (Practical methodology)를 바탕으로 하여, 튼튼한 이론적인 바탕을 가지고 현실에 맞는 실용적인 프로세스를 구축한다.
l        구현팀을 위주로 프로세스를 정의한다.
l        품질 향상 

End to end use case (시나리오)

이해를 돕고자 이제부터 소개하고자 하는 실용주의 ALM 프레임웍의 가상 시나리오를 살펴보도록 하자


개발자 시나리오
1)       개발자 D씨는 아침에 출근해서 이클립스 IDE를 오픈한다.
2)       이클립스 IDE는 이슈추적툴로 부터 D씨에게 할당된 작업들이 리스트업되고, 그중에서 오늘해야 할 작업을 선택하여 PROGRESS로 상태를 변경한다.
3)       SCM으로 부터 최신 코드를 UPDATE받고 코딩을 시작한다.
4)       코드를 만들고 테스트 케이스를 작성하여 코드가 제대로 작동함을 확인하고, 커버러지 분석을 통해서 금일 코딩한 내용이 테스트에서 모두 확인 되었는지 체크한다.
5)       오늘 코딩한 내용을 INSPECTION툴을 통해서 잠재적인 문제가 있는지 없는지 검증 받고 NAMING RULE등이 문제 없는지 확인한다.
6)       완료된 내용을 SCM에 작업 번호와 함께 COMMIT한다.
7)       자동 빌드 머신에서 COMMIT된 소스코드를 감지하고 모든 소스를 내려받아서 빌드를 완료한후에 개발 서버에 자동으로 배포하고 테스트를 수행한다.
8)       테스트가 실패한 경우 이전 버전으로 개발 서버를 원복 시키고 모든 개발원과 PM에게 이메일로 테스트 실패 사실을 통보한다.
9)       PM은 테스트 실패사실을 이메일로 통지 받고, 이번 빌드에서 변경된 부분을 빌드 자동화 시스템을 통해서 확인하고 빌드 자동화 시스템에 의해서 리포트된 내용에 따라 누가 어느 모듈을 수정했는지를 찾아서 해당 개발자에게 수정을 지시한다.
10)   개발자는 수정을 마친후에 다시 SCM에 소스를 반영하고 빌드 자동화 시스템은 빌드,테스트,커버러지 분석,코드 복잡도 분석,INSPECTION작업을 수행한다.
11)   PM은 빌드가 완료된 결과를 통보 받고, 복잡도가 높은 클래스 모듈 10개에 대해서 제대로 테스트가 커버하는지 확인하후에 미비한 부분에 대해서 담당 개발자에게 테스트 보강을 지시한다. 

PM의 작업지시 시나리오
1)       PM P씨는 아침에 출근하여 고객으로 부터 새로운 요건을 받았다.
2)       P씨는 요건을 정리하여 내용을 이슈 트랙킹 시스템에 등록하고 심각도와 우선 순위를 지정해서 개발 PL에게 ASSIGN하였다.
3)       개발 PL은 요건의 우선 순위와 긴급도를 보고 누구에게 작업을 지정할것인지 고민한다. 이슈 트랙킹 시스템에서 개발원별로 진행중인 이슈 사항을 보고 개발 난이도에 맞는 사람중에서 가장 할당된 이슈가 적은 사람에게 이슈를 ASSIGN하였다.
4)       개발자는 해당 ISSUE를 받아서 처리한 후 PL에게 다시 ASSIGN한다.
5)       이때 작업에 관련된 메일,전화 통화내용 기타 관련 내용들을 시스템에 모두 LOGGING한다.
6)       PL은 작업이 완료된 내용을 검토한후 해당 ISSUE를 CLOSE한다.
7)       PM은 자신이 지시한 내용에 대해서 누가 진행하고 있으며 진행현황이 어떻게 되었는지를 이슈를 통해서 추적할 수 있다.

PM의 현황 관리 시나리오

1)       PM P씨는 1차 오픈 때까지 해결되어야 할 이슈를 이슈 관리 시스템에서 검색한다.
2)       심각도가 높은 이슈와 오픈된지 오래된 이슈를 확인하여 진행이 안되고 있는 이유는 무엇인지 RISK는 무엇인지를 조사하고, RISK에 대한 대비책을 세운다.

만약에 날짜에 비해서 해결되어야 할 이슈가 많을 경우 심각도와 우선순위를 고려하여 2차 오픈으로 이슈를 연기한다.

실용주의 ALM 구성

실용주의 ALM은 크게 4가지 모듈로 구성된다.


Task Management (Task 기반의 프로젝트 관리)

프로젝트에서 진행되는 작업에 대한 진행 상황과 스케쥴링 그리고 리소스에 대한 관리 방법론을 제공한다. 기본적인 사상은 Agile 방법론의 프로젝트 관리 방안을 기반으로 하고 있다.Task Management 모듈은 다음과 같은 서브 모듈을 포함하고 있다  

Process
1)       Task Management Process : Agile Scrum 기반의 Task 관리 프로세스
2)       SOA or Open API Service Lifecycle Management Process (Optional) : SOA나 WEB 2.0에서 Service Lifecycle (서비스 신청에서부터 배포 까지) 관리 프로세스와 시스템
3)       Requirement Analysis Process (TBD) : 요구 사항 추출 프로세스

Reference Architecture
1)       Task Management System Reference Architecture  : 프로세스를 구현한 Task 관리 시스템
2)       Task Management Dash board Reference Architecture : 프로젝트의 진행 상태를 한눈에 알 수 있는 Dash board
3)       Requirement Analysis Management Reference Architecture (TBD) 요구 사항 관리 시스템

Build Environment (빌드 환경)

Implementation 단계에서 사용되는 개발환경을 제공한다. 기본적인 사상은 Pragmatic(실용주의) 방법론으로 Kent beck이나 Joel Spolsky에 의해서 소개된 방법론을 기초로 하며, 일일 빌드와 점진적/반복적 통합론을 중심으로 개발환경 구성에 대한 가이드를 제공한다.

다음과 같은 서브 모듈을 포함하고 있다

Process
1)       SCM branch guide : 소스 형상 관리에 대한 브렌치 관리 전략
소스 코드 관리에 있어서 브렌치에 대한 관리 방법을 기술한다. 브렌치는 잘못쓰면 전체 소스코드 관리를 하는데 있어서 엄청난 혼란을 초래할 수 있는 만큼 적절한 브렌치 관리 정책이 정해져야 한다.

2)       Contiguous Integration Process : 점진적 통합 방법에 대한 프로세스
자동 빌드 시스템을 구축하여, 개발자의 소스 코드 변화를 자동으로 인지하고 매일 자동 빌드를 통해서 코드의 통합을 빅뱅 방식이 아니라 매일 점진적인 방식으로 진행함으로써 통합으로 인해 발생할 수 있는 문제를 조기에 발견하고 해결할 수 있도록 하며, 빌드 과정내에 테스팅을 포함시켜서 결함을 조기에 발견하여 전체 소프트웨어 품질 향상을 유도 한다.

Reference Architecture
1)       Standard IDE : 개발자를 위한 표준 개발 환경 가이드
프로젝트에서 개발자별로 선호하는 개발 도구들이 다르다. (이클립스, NetBeans, VI 등) 다른 개발 도구는 구현된 코드에도 영향을 주며, 특히 새로운 팀원이 합류했을 때 보통 1~2일을 개발환경을 셋업 하는데 시간을 소요 하게 된다. 표준 개발 환경은 ZIP으로 개발에 필요한 모든 환경을 만들어서 개발자가 ZIP 파일만 풀면, IDE에서 테스트 프레임웍, 테스트용 서버 환경까지 일괄로 셋업이 되서 모든 개발자가 빠른 시간내에 동일한 개발환경에서 소프트웨어를 구현할 수 있도록 한다.

2)      Contiguous Integration Reference Architecture
실제 CI 환경을 구축하는데 필요한 아키텍쳐에 대해서 설명한다.

3)       Standard Build Script : 표준 빌드 스크립트 구축 가이드

표준 개발환경과 마찬가지로 빌드 스크립트 역시 표준화 되어야 한다. LIB 위치나 버전, 빌드 스크립트내의 TARGET 정의, 빌드 순서등을 통합하고 표준화된 형태로 제공하여 개발자가 빌드 스크립트 작성에 소요되는 시간을 절약하고, 비표준화된 빌드스크립트 사용에서 오는 오류를 예방한다. 

Test Automation (테스트 자동화)

일반적으로 테스팅은 QA팀의 역할로 인식이 되어 왔고, 시스템 개발이 완료된 후에 QA팀에 의해서 테스팅이 되는 것이 일반적이었다.

 여기서는 소프트웨어 개발중에 개발팀에 의해서 수행되는 단위 테스트와 통합테스트에도 비중을 두고, 테스트 자동화와 회귀 테스트(테스트 마다 지난번 테스트했던 내용을 포함하여 테스트 하여, 변경 사항이 기존 기능에 영향을 줬는지 여부를 검증함)를 중점적으로 다룬다.

테스팅 모델은 전통적은 Waterfall 방식을 확장한 V-Model을 기반으로 한다.

Process
1)       Testing Process (테스트 프로세스)
소프트웨어 개발 단계에서 부터의 단계별 테스팅 프로세스에 대해서 정의한다.
V-Model에 기초하여 Unit Test,Integration Test, System Test, User Acceptance Test 4단계로 나누어서 정의한다.

2)       Defect Management Process (결함 관리 프로세스)
테스트 결과 발견되는 결함에 대한 관리 프로세스를 정의한다.

Reference Architecture
1)      Unit Test Framework Reference Architecture
특히 단위 테스트의 경우 소프트웨어의 안쪽을 테스트 하기 때문에, 일반적인 테스팅 도구보다는 소프트웨어 컴포넌트에 따라 더 정밀한 테스팅 도구가 필요하다.
단위 테스트를 수행하는데 필요한 테스팅 프레임웍에 대해 정리한다

2)      Static Testing Reference Architecture
소프트웨어 테스팅 기법중에서, 소프트웨어의 동작 상태가 아니라 코드 검증을 통해서 결함을 찾아내는 방법을 Static Test라고 한다. 이 테스트에서는 코드의 Naming Convention이나 특정 패턴에 따른 잠재적인 결함 (메모리 누수, Null Pointer Exception)을 찾아낼 수 있다. 이 Static Test를 수행할 수 있는 도구에 대해서 설명한다.

3)      System Test Reference Architecture
테스팅 중에서 주로 성능과 비기능 (확장성, 가용성등)에 대한 테스팅 수행 도구에 대해서 설명한다.

Collaboration (협업)

협업 모듈은 팀이 프로젝트를 진행하는데 있어서 의사 소통과 공동 작업을 돕기 위한 몇가지 기법과 시스템에 대해서 소개한다.

Process
1)      Code Review
코드 리뷰는 실제로 코드를 검토하여 예측 되는 결함을 찾아내고 서로 개선 방향을 찾아내는 행위이다. 코드 리뷰의 방식은 여러가지가 있으나 비형식적인 코드리뷰라도 투자대비 소프트웨어 품질에 많은 효과를 줄 수 있기 때문에, 협업의 기법중의 하나로 소개한다. 

Reference Architecture

1)      Wiki Based Document Management Reference Architecture
ALM을 이용해 구축된 표준이나 프레임웍, 프로세스등 많은 내용들이 Architect 레벨에서 일반 개발자들에게 전달되어야 한다. 이런 지식을 전달하는 방법이 문서등 여러가지 방법이 있겠지만, 문서등은 여러 버전 관리나 변경 관리가 어렵고, 표현의 한계가 있다.
 Wiki의 경우 내용을 하나의 장소에서 계속 업데이트가 가능하고, 검색이 가능하며, TEXT와 이미지뿐만 아니라 멀티미디어 데이터를 넣을 수 있기 때문에 직관적인 정보 전달이 가능하다.
 또한 링크를 이용하여 정보간의 연관 관계를 정의할 수 있다.

MS-WORD등으로 만들어진 문서는 공유 폴더에서 사장되거나 또는 이쁘게 바인딩되어서 책장이라는 무덤속으로 사라질 수 있는데, Wiki를 이용하는 이유중의 하나는 꼭 필요한 문서만, 필요할때 사용할 수 있도록 하여, 프로젝트에서의 정보 공유를 가속화 하는데 그 목적이 있다.

2)      Communication with Forum Reference Architecture
Wiki의 경우 대부분 위의 조직에서 아래 조직으로의 하향성을 가진 단방향 커뮤니케이션이다. 이를 보안하기 위해서 Forum은 좋은 양방향 커뮤니케이션 도구로 사용될 수 있는데, Wiki를 통한 단방향 정보 전달의 Feedback으로 사용할 수 있다. 

이러한 협업 도구들은 전체 협업의 생산성을 높혀줄 수 있는 일부만을 권장하는 것이며 조직의 수준과 구조에 맞춰서 별도의 협업 프레임웍을 구축 하기를 권장한다

실용주의 ALM 의 구현

ALM을 프로젝트에 적용 하기 위해서는 아래와 같이 3가지 관점에서의 접근이 필요하다.


프로세스

ALM은 전체 소프트웨어 개발 프로세스를 커버하기 때문에, 각 모듈을 프로젝트에 적용되는 프로세스에 대한 정의가 필요하다.

Reference Architecture

프로세스를 실제로 시스템으로 구현하기 위해서, 어떤 형태의 시스템 아키텍쳐를 이용하여 프로세스를 현실화할 수 있는지에 대한 가이드를 제공한다.

조직

시스템과 프로세스를 가지고 프로젝트에 적용할때, 적용하는 주체의 역할과 책임에 대해서 정의한다. 

성공적인 ALM 구현 전략

간략하게 실용주의 ALM에 대해서 살펴보았다. 이 실용주의 ALM을 성공적으로 적용하기 위해서 몇 가지 전략이 필요한데, 다음과 같다.

1)      Liquid

전체 프로세스가 모난 부분이 없이 물 흐르듯이 하나의 프로세스로 연결되어야 한다.

프로세스가 넘어가는 단계가 매끄럽지 못하면 전체 개발 프로세스에 병목이 생기게 되고, 프로세스 흐름에 문제가 생긴다.

2)      Seamless

앞에서 소개한 실용주의 ALM의 모듈 구성을 보면 알겠지만, 상당히 많은 부분을 많은 기술로 커버하고 있다. 이러한 기술들이 유기적으로 결합되어 마치 하나의 통일된 프레임웍과 같은 형태를 취하여 사용자 입장에서 하나의 프레임웍을 쓰는 듯한 느낌을 줘서, 사용자 관점에서 올 수 있는 혼돈을 미연에 방지해야 한다.

3)      Process Oriented

ALM의 가장 중요한 요소는 프로세스이다. ALM은 소프트웨어 개발 프로세스를 시스템화 하는 것이기 때문에, 프로세스 자체가 중요하며 자칫 잘못하면 시스템 구현에 이끌려서 프로세스가 망가지는 경우가 있다.

4)      Step by Step

실용주의 ALM이 다른 ALM에 비해서 경량이고 현실적이라고는 하지만, 커버하는 영역이 상당히 넓다. 한번에 전체 개발 프로세스를 변경하는 것은 구성원들에게 큰 혼란을 초래할 수 있기 때문에, 난이도별로 단계적으로 적용하는 것을 권장한다.

5)      팀의 수준에 맞춰서

팀의 성숙도에 맞춰서 실용주의 ALM을 Customization해서 적용해야 한다. 성숙도가 낮은 팀에 실용주의 ALM을 적용할 경우, 마치 기존의 중량의 방법론을 적용할때와 마찬가지로 형식 지키기에만 급급해지고 실제 생산성은 오히려 더 떨어질 수 도 있다.

6)      Be Simple

모든 기능을 커버하려 하지 말고, 목표가 100일때 80만 커버하더라도 단순성을 우선시해야 한다. 복잡도가 높아질 수 록 실용주의 ALM 사용으로의 진입장벽과 Learning Curve가 급격하게 올라가고 이는 또 다른 형식적인 방법론으로 전락할 수 있다.

 

 

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 서영아빠 2009.03.05 09:00  댓글주소  수정/삭제  댓글쓰기

    매번 유용한 글 잘 보고 갑니다. ^^
    그리고 글 내용중에서 SCM branch guide에 대해서 좀 더 상세한 설명이나 포스팅을 부탁드려도 될까요? branch는 아무리 머릴 굴려봐도 항상 어렵네요. 사례같은 것도 찾기가 쉽지 않네요.

    # 빌드환경에서 Contiguous => continuous 오타났어요^^;;

    • 조대협 2009.03.05 09:58 신고  댓글주소  수정/삭제

      ^^: 안그래도 ALM Full Framework 을 PPT로 다시 정리하고 있는데, 이제 반 정도 했네요.. (다 만들면 대략 200장 정도의 자료가 될것 같은데요.) 요즘 Branch Guide 작성하고 있습니다.

      프로젝트를 들어와서 ALM을 업데이트할 시간이 많지 않은데요. Branch Guide 작성되는데로 빨리 올리도록 하겠습니다.

      의견 고맙습니다.

  2. 씨니 2010.05.05 02:42 신고  댓글주소  수정/삭제  댓글쓰기

    ALM에 대해 잘 정리된 글이네요. 퍼감다.
    (새로 이직하신 회사에서 잘 되셔서 고공비행 하시길 빕니다.)

오랜만에 ALM 업데이트

ALM | 2009.02.17 18:13 | Posted by 조대협
잘 아시겠지만(?) ALM을 만들고 사이트에 적용하고, 여러 자료들을 발표한지도 꽤 오랜 시간이 지났습니다.
제가 소개하는 ALM은 오픈소스나 저 가격 솔루션으로 구성되어 있고 현재는 크게 4가지 파트로 구성이 되어 있습니다.

Task Management
Build Automation
Test Automation
Collaboration

입니다. Build Automation은 Hudson을 중심으로 한 일일 빌드, Test Automation은 xUnit을 이용한 단위 테스트와 함께 V-Model 기반에 전체 테스팅 프로세스를 커버 합니다. Task Management는 Issue Tracking 시스템을 이용한 프로젝트 관리를 Collaboration은 Wiki와 Forum 중심의 협업 환경과 Code Review 등의 프로세스를 포함합니다.

4개의 ALM 모듈은 모두 각각의 프로세스와 아키텍쳐 그리고 Implementation 예제를 포함합니다.

제가 근무 하는 회사와 하는일이 기본적으로 미들웨어와 아키텍쳐에 관련되다 보니, ALM에 대한 직접적인 솔루션은 가지고 있지 않습니다만, 컨설팅 업무가 종종 PM이나 PL의 역할을 하기 때문에 필요에 의해서 만들었기 때문에 경험은 들어 있지만, 체계적으로 정리할 시간이 많지 않습니다.

지금 까지 Hudson을 이용한 Build Automation, xUnit Family를 통한 단위 테스트에 대한 글을 조각조각 포스팅 하였고, 오늘은 ALM/Task Management 모듈에 대한 프로세스를 정리해서 올립니다.

시간이 되면 전체 내용을 한번 쭈욱 정리해서 올렸으면 좋겠는데.. 컨설턴트로써, 아빠로서 시간이 잘 허락되지 않는군요..  도움이 되셨으면 좋겠고, 문의나 토론은 언제나 환영합니다.
감사합니다.

'ALM' 카테고리의 다른 글

실용주의 ALM (Application Lifecycle Management) Overview - PDF  (0) 2009.02.18
실용주의 ALM (Application Lifecycle Management) Overview  (3) 2009.02.18
오랜만에 ALM 업데이트  (0) 2009.02.17
오랜만에 지방 출장  (3) 2009.01.23
ALM 온라인 강의  (0) 2009.01.07
ALM Concept  (0) 2008.12.24
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG ALM

댓글을 달아 주세요

PDF 버전입니다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 김호성 2010.05.27 10:52  댓글주소  수정/삭제  댓글쓰기

    안녕하세요.
    회사에서 SCRUM 방법론을 적용하고 있습니다.
    아주 좋은 자료를 얻게 되는군요.. ^^
    공유 감사드립니다.

Overview

프로젝트에서 중요한 포인트중의 하나는 팀의 운영과 관리이다. 프로젝트에 Unified Process나 Waterfall model과 같은 기존의 방법론을 사용하더라도, 그 방법론에는 자세한 task 관리 프로세스에 대해서는 거의 정의가 되어 있지 않다. 

반대로 요즘 유행하는 Agile 방법론의 경우, task 관리에 대한 전략과 수행 방법을 기술하고 있지만, 실제 프로젝트를 관리하는 관점에서는 전체 스케쥴에 대한 예측과 관리가 어렵기 때문에(불확실성의 문제), SI 프로젝트등에서는 쉽게 적용할 수 없는 문제를 가지고 있다.

또한 실제 프로젝트에서는 이미 고객이나 주관사의 방법론을 표준으로 사용하고 있기 때문에 Agile 방법론을 적용하는 것이 쉽지 않다. 

이 문서의 목적은 위 두 가지 접근 방법의 문제점을 상호 보완하여, 전체 프로세스는 기존의 전통 방법론을 따르고, 전체 프로세스의 각 단계를 Agile 방법론으로 보완하여, 실질적인 task 관리 방법론을 구축하고자 하는데 목적이 있다. 

Agile 방법론은 요즘 들어 가장 인기 있고 가벼운 방법론 중에 하나이다. 이 방법론의 특징은 구성원간의 협업 (Collaboration)을 중요시 하는 사상을 가지고 있다. 본 문서에는 이 사상을 기반으로 하여, 일일 Task 관리를 하는 기법을 중심으로 설명하고자 한다. 

Agile 방법론에는 XP,AUP,Scrum,Lean 등 여러가지 구체적인 방법론 들이 있는데, 아래 도표를 보면 알 수 있듯이, 근래에 들어서는 Scrum이 가장 인기있고 많이 사용되는 방법론이다.


 출처 http://crankypm.com/2008/10/poll-results-software-development-methodologies-agile-vs-waterfall/

 Scrum

 Summary

그럼 먼저 Scrum 방법론에 대해서 살펴보도록 하자.


Scrum은 기본적으로 Iterative and incremental 개발 방법에 기초를 한다.

Scrum은 몇 개의 Iteration으로 구성되는데, 이 Iteration을 Sprint라고 부르며 각 Sprint는 1~4주 정도의 기간을 갖는다. 이 Sprint는 일종의 Timebox의 개념을 가지며 한번 정해진 Sprint의 기간은 변경될 수 없다는 것을 전제로 한다. 

다음으로 Scrum에는 고객의 요건으로부터 작성된 Product Backlog라는 것을 가지고 있다. 쉽게 이야기 하면 “대략적인 할일 목록”이다. 구현 단계에 Scrum을 적용할 경우에는 SRS (Software Requirement Specification)이나 TRS (Technical Requirement Specification)들의 목록이 Product Backlog의 항목으로 적절하다.

Product Backlog의 항목을 팀 미팅을 통해서 이번 Sprint에 구현할 항목을 선택한다. 항목의 선택은 Product Backlog 항목의 우선순위(Priority)를 통해서 선택이 되고, 이 선택된 항목들을 구체적으로 구현하기 위해서 TASK로 쪼게 진다. 이 task 목록은 이번 Sprint에서 구체적으로 해야 할 일을 정의하고 되고 이 목록 리스트를 Spring Backlog 라고 부른다.

 Sprint Backlog의 task 들은 스케쥴이 지정되어 팀의 담당자에게 Assign된다. 팀은 이 Sprint Backlog를 가지고 정해진 기간동안의 Sprint를 구현한다. 

Sprint중에 매일 아침 팀원들은 10~20분 정도의 Daily Scrum Meeting 이라는 회의 시간을 갖는데, 이 시간 동안, 팀원들은 어제 한일과 오늘 한일에 대해서 간략하게 보고하고, 기술적인 질의 사항에 대한 문의나 (팀원들의 도움을 받을 수 있는), RISK 사항등을 고융한다. 이 Daily Scrum Meeting을 통해서 팀은 현재 Sprint의 진행 상황을 공유할 수 있다.

 Sprint가 끝난 후에 팀은 프로젝트의 stakeholder (고객)과 간단한 Review 미팅을 갖는데, 주로 이번 Sprint 에서 구현한 내용을 간단한 형태의 DEMO로 소개를 하고 Feed back을 받아서 Product Backlog를 업데이트 하고 다음 Sprint를 준비한다.

 Review가 끝난 후에는 팀원끼리 Sprint에 대한 회고 (Restrospective)의 시간을 갖는데,

 이 시간에는 Sprint에서 Scrum 방법론을 적용했을 때의 잘되었던 점과 잘못되었던 점을 토론하여 Scrum 운영 프로세스에 반영하여 팀의 Scrum 운영 방식을 성숙화 시킨다.

Role in Scrum

Scrum에서는 이 프로세스를 적용하기 위해서 몇 가지 역할을 정의하고 있다.

Product Owner

Product Owner는 요구 사항을 정의하고, Product Backlog를 업데이트 하는 역할을 맏고 있다. 가장 중요한 역할은 Product Backlog내의 Item 에 대한 우선 순위를 정하고, 정해진 구현 기간 내에 프로젝트 팀의 ROI (Return Of Investment)를 극대화 하는 책임을 가지고 있다. Product Owner는 직접 Sprint에는 참여하지 않고, Sprint 전에 Backlog의 업데이트후, Spring review에 구현 내용이 요구 사항에 맞춰서 적절하게 구현되었는지 확인하는 작업에만 참여한다. 

Team

Team은 Product Backlog의 내용에 따라 Sprint에서 구현하는 역할을 맏는다. 

Scrum Master

Scrum Master는 Project Manager도 아니고, 3자의 입장에서 Team과 Product Owner가 Scrum 방법론을 제대로 수행할 수 있도록 돕는 역할을 수행한다. 예를 들어 Product Owner가 Sprint중에 요건을 추가하려고 할 때 이를 제지하거나, Team이 Scrum을 수행하는 데 어려움이 있을 때 이를 돕는 역할을 한다. 종종 Scrum Master의 역할과 Product Owner의 역할을 한 사람이 겸임하는 경우가 있는데, Scrum Master의 역할중의 하나가 Product Owner가 Sprint중에 영향을 줄 수 있는 요건 변경을 막아야 하는 역할이기 때문에, 겸임할 수 없다. 

지금까지 Scrum 방법론에 대해서 간략하게 설명하였다. 그러나 이 Scrum 방법론은 태생이 제품 개발을 위한 프로세스로 개발되었다. (Product Owner와 같은 용어에서 알 수 있듯이..) 그래서 Requirement나 기능의 추가/삭제가 비교적 자유로운 In house 개발이나 패키지 솔루션 개발에서는 사용될 수 있을지 몰라도, 구현해야 하는 Requirement의 범위가 고정적인 Enterprise 프로젝트에는 적용하기가 어렵다. 그래서 다음은 경험을 바탕으로 하여 Customize 한 Enterprise 프로젝트에서의 Scrum 프로세스에 대해서 설명하고자 한다.

 ALM / Task Management Process

Process Design Principals (프로세스 디자인 방향)

ALM / Task Management Process 의 기본 디자인 방향은 기존의 전통적인 개발 방법론을 대체하는 것이 아니라, 기존의 방법론은 전체 개발 프로세스를 커버하고, ALM / Task Management Process 는 Scrum 방법론에 기반 하여 각 단계에 대한 TASK 관리를 위해서 사용된다.


전체 프로젝트 관리로는 사용되지 않고, 각 수행 그룹에서 사용된다. (예를 들어 전체 프로젝트가, 고객 지원 업무, 빌링, 포탈 등으로 구성되어 있을 때 전체 프로젝트 관리는 전통적인 개발 프로세스에 기반하여 프로젝트가 관리되고, 빌링팀, 포탈팀 등 각 개발 단위팀에서는 ALM / Task Management Process 방법론을 이용하여 팀을 관리한다.)

Team Structure for ALM / Task Management Process

ALM/Task Management을 실제 팀에서 수행하기 위해서 팀 구조와 역할 정립이 필요하다.

l        Project Manager : 전체 프로젝트를 관리 하는 역할을 한다. 큰 프로젝트의 경우 PMO나 여러 개발 단위의 PM을 정의하며 주로 전통적인 개발 프로세스를 기준으로 프로젝트를 관리한다. 단 ALM / Task Management Process의 개념을 이해하고, ALM / Task Management Process와 기존의 개발 프로세스를 연계 시키는 역할을 맏는다.

l        Project Leader : 작은 조직이나 프로젝트에서는 PL이 없이 PM이 PL역할을 함께 하는 경우가 많으며, 실제 개발팀을 가지고 Implementation을 리드하는 사람이다. 실제로 ALM / Task Management process를 이용하여 팀의 Task를 관리한다.

l        ALM Process Coach : 특이한 Role일지도 모르겠는데, Scrum의 Scrum Master와 같은 역할로 생각하면 된다. Process가 팀에 완전히 정착되기 까지는 팀에 대한 교육과 프로세스에 대한 지속적인 Mentoring이 필요하다. ALM Process Coach는 팀의 프로세스를 set up하고, 팀이 프로세스를 준수하도록 도우며, 개선하는 역할을 진행한다.


실제로 모 금융 프로젝트에서 ALM / Task Management Process를 적용해본 적이 있는데, PM이 두개의 팀을 운영하고 있었다. 그중에 A팀에 본인이 투여되었고, ALM / Task Management Process와 System을 구축하여 A팀에서 적용하여 효과를 보자 PM이 다른팀(B팀)에도 본 프로세스를 적용해 주기를 요청하였다. 그래서 System을 공유해줬으나, B팀에는 별도의 코칭을 제공하지 않았다. 프로세스를 제대로 준수하는지, 상태 업데이트는 제대로 하는지에 대한 코칭이 없었는데, 1개월후 A팀은 Task Management Process에 어느정도 적응을 하여, 효율적으로 만족 스럽게 사용하고 있었으나, B팀의 경우 이 프로세스와 시스템 사용이 또 다른 Burden이 되서 실업무 따로, 시스템 운영 따로 되는 결과를 만들어 냈다. 그만큼 ALM / Task Management Process를 적용하기 위해서는 성숙단계까지 지속적인 관찰과 코칭이 필요하다.

 Step 1. Prepare Product Backlog

Product Back log는 실제로 구현되어야 하는 기능 목록을 나열한다.

목록은 고개의 요구 사항으로부터 도출 되는데, 일반적으로 SRS (Software Requirement Specification)이나 TRS (Technical Requirement Specification)로부터 도출이된다. 구체화 되고 정확하고 상세한 목록을 도출 해야 한다. 비즈니스 요건 같은 경우를 목록으로 도출하였을 경우에는 종료 조건이 모호해질 수 있고 그런 경우 종료에 대한 기준이 모호해 질 수 있다.

Product Back Log의 항목은 다음과 같다.

1) NO

ITEM에 대한 ID

2) Item

실제 구현 요건

3) Description

요건에 대한 간략한 설명

4) Estimated Resource

얼마나 많은 Resource가 소요되는 가에 대한 예측치를 기록한다. 이 값에 따라 추후 PLANNING에 반영한다. 이 값은 초기 예측 값으로 매번 Sprint가 종료될 때 마다 새롭게 업데이트 한다. 업데이트 기준은 기존에 수행한 Sprint의 Item의 실제 수행 시간을 기준으로 앞으로 수행할 Item의 상대적인 개발 난이도등을 측정하는 방법으로 예측할 수 있다.

5) WIKI URL

Back Log의 Item의 이름과 Description만 가지고는 정확한 요건을 알 수 없다. 그래서, 해당 Item에 대해서 정확한 요건 (Requirement description 또는 Use case)을 알기 위해서는 별도의 문서를 참조해야 한다. 문서는 MS-WORD와 같은 형태로 공유 파일 폴더에 들어가 있거나 Subversion과 같은 SCM에 저장이 되어 있거나 Wiki에 작성되어 있을 수 있다. 여기에는 Item과 요구 사항에 대한 추적성을 유지하기 위해서 해당 문서에 대한 위치 (파일 위치나, WIKI URL)을 기술한다.

6) Priority

Item에 대한 우선 순위를 지정한다. 이 우선 순위에 따라서 Sprint를 스케쥴링 하기 때문에 Product Back Log에서 매우 중요한 부분이다.

Priority의 설정은 비즈니스에 대한 영향이 큰 기능, 필수 기능, 그리고 난이도가 높은 기능, 비기능적 요건 등에 대해서 우선 순위를 높게 설정하는 것을 권장한다. 특히 비기능적 요건은 성능이나 안정성등에 관련되는 경우가 많고 이러한 요건들은 아키텍쳐에 많은 영향을 주고 아키텍쳐는 후반으로 갈수록 변경이 어렵기 때문에 초반에 구현 및 검증 작업을 수행해야 한다.

7) Status

Status는 해당 Item의 진행 상황을 의미한다. 이미 아직 진행전이지, 진행중인지 완료가 되었는지를 표현한다. 필드의 값은 프로젝트 상황이나 프로세스에 맞춰서 변화한다. (QA 검증중, 운영 서버에 반영됨 등)

8) Estimated Value of item (Optional)

이 항목은 Item의 비즈니스적인 가치에 대해서 점수를 메기는 방법으로 SI개발보다는 제품 개발이나 In House 개발등에 유용한 항목이다. 이 값의 조정을 통해서 Product Owner는 정해진 기간내에 최대의 ROI (Return Of Investment)를 낼 수 있도록 Back Log의 우선 순위를 지정할 수 있다. 

Step 2. Release Planning

해야할 일의 목록 (Product Back Log)가 정의 되었으면, 언제 어떤 일을 해야할 지를 정의해야 한다. 일반적으로 말하는 스케쥴링인데. Release Planning에서는 프로젝트의 큰 Mile stone을 정하는 작업을 한다. Release 시기 마다 작동 가능한 Product을 Release한다. (모든 기능이 완료되지 않았다 필 수 기능이 완성 되었으면 Release한다. ) Release된 시점에서 QA팀에게 Release version을 넘겨서 Testing을 수행하고 구현된 부분에 대한 품질을 보장 받는다. 이러한 활동은 모든 개발이 끝난 시점에서 Big bang 방식으로 통합하고 테스트 하는 기존에 방식에 비해서 위험을 조기에 발견할 수 있고, 그 위험을 해결하는 비용을 줄일 수 있다. (복잡한 문제일 수 록 나중에 발견되면, 더 고치기가 어렵다.)

그리고 이 Release version을 고객에게 DEMO를 통해서 요구사항과 부합하는 지 확인하고, 잘못된 부분에 대해서 수정할 수 있는 기회를 갖을 수 있다.

이 단계에서 해야하는 구체적인 작업은 다음과 같다.

1)       주요 릴리즈 일정 지정
2)       릴리즈 일정별 Product backlog 내의 Item 지정

이 단계에서 완성된 Release Plan은 Project 관리 입장 (Project Management Officer)에서 전체 스케쥴 WBS (Work breakdown structure)와 맵핑이 되서 관리팀 관점에서 스케쥴 관리를 용이하게할 수 있다.

Step 3. Sprint Planning

Release Planning이 끝난 후에는 각 Release를 달성하기 위해서 Release Planning을 Sprint로 나눈다.

전통적인 Scrum 방법론에서는 다음과 같은 절차로 Sprint를 계획한다.
l        팀원의 가용 시간
l        Product Back Log Item을 구체적인 Task로 분할
l        Task 에 대해서 수행 시간을 예측
그러나 이 전통적인 접근 방법은 몇가지 문제를 가지고 있다. 먼저 Task 에 대한 수행 시간 예측후에 가용 인력에 Assign하는 방식인데, 이는 각 팀원의 능력이 동일함을 전제로 하고 있다. 그래서 실제 프로젝트에서는 다음가 같은 방법을 권장한다.
l        Product Back Log Item을 Task 로 분할 
l        Task를 팀장이 적절한 사람에게 배분
l        배분된 사람이 Task의 수행 시간을 예측 하도록 함 

이 작업을 좀더 상세하게 설명해보면

 Sprint는 보통 1주~4주 정도로 정의된다. Sprint의 기간을 정의할 때 기준중의 하나는 고객의 요구 사항 변경이나 작업에 대한 변경도가 얼마나 많은가? 예측된 작업 일정이 충분한가? 와 같이 불확실성이 높을 수 록 Sprint 주기는 짧게 잡는 것이 좋고, 불확실성이 적고 스케쥴이 안정적으로 정의될 수 있는 경우에는 길게 잡는 것이 좋다.

 필자의 경우에는 보통 2주 정도를 Sprint주기로 관리를 한다.

Sprint를 정의할 때 먼저 Sprint 기간과, 가용 Resource를 바탕으로, Release Plan에 의해 정의된 Product Back log Item들의 예측 기간(Estimated Resource : Man/Day)를 기준으로 Sprint에 Product Back log Item 들을 할당한다. 

해당 Sprint의 기간과 수행할 Back Log Item을 정의하는 일은 PM/PL이 수행하는 것을 권장한다.

Scrum 방식이 유연 해도, 스케쥴 자체는 프로젝트 진행에 있어서 가장 중요한 RISK FACTOR중의 하나이며, 팀원간의 협의를 해서 진행한다 하더라도 고객 입장에서는 꼭 끝 맟춰야 하는 부분이기 때문에, 우선순위 지정과 스케쥴 조정은 그에 대한 책임을 지고 있는 프로젝트 관리자가 하는 것이 RISK 관리 측면에서 합리적이다.

 선별된 Product Back Log Item은 실제로 수행되기 위해서 구체적인 TASK로 나뉘어진다.

TASK는 어떤 사람이 무슨 일은 한다는 구체적인 정의로, 명확한 종결 조건을 가지고 있어야 한다. 예를 들어 “Logging 기능의 설계” 는 언뜻 보면 적절한 TASK로 생각될 수 있지만 설계에 대한 종료 조건이 명확하지 않다. 즉 “Logging 기능 설계 문서를 WIKI에 업데이트” 또는 “Logging 설계 REVIEW 회의”와 같이 산출물이나 회의와 같이 어느정도 정해진 종결 조건을 정의하게 되면 TASK를 관리하기가 용이하다. ( “Logging 기능의 설계” Task만 있다면 문제지 위에 예를 든 종료 조건이 다른 Task로 정의되어 있으면 괜찮다)

 실제 TASK관리를 해보면, “구현 TASK”가 끝났다고는 하는 경우 개발자 본인의 역량에 따라서 Coding만 되고 실제로 기능이 작동하지 않거나, 의도하지 않은 설계대로 구현되어 있는 경우가 생각보다 많기 때문에, 이런 경우 프로젝트를 관리하는 입장에서 “구현 보강” 이라는 새로운 TASK를 만들고 새롭게 RESOURCE와 시간을 할당해야 하는 부담을 가지게 되기 때문에, TASK에 대한 종료 조건을 명확히 하는 것은 매우 중요하다. 

1:1:1 법칙

 Task를 정의하는데 가이드를 제시하면, Product Back Log Item은 분석/설계, 구현, 테스트 이 3가지로 크게 분리될 수 있다. 어떤 구현 테스트를 하기 위해서 요건에 대한 분석 및 설계가 필요하다. 비록 미리 다 설계가 되어 있는 부분이라도, 실제 구현에 있어서는 국지적인 설계 변경이 필요하거나, Prototyping (설계 검증을 위한) 들이 필요하기 때문에 분석/설계에 대한 시간은 소요된다.

다음으로 테스트는 구현된 내용을 바탕으로 검증을 해야 하는데, 특히 비기능적인 요건은 시스템 테스트를 하지 않더라도 최소한 자기 PC에서 성능 테스트 (이를 Micro benchmark test라 한다.)를 하고 단위 테스트를 수행해야 하고, 구현이 아닐 경우라도 설계나 요건 분석등의 문서상 산출물은 REVIEW 시간을 필요로 하기 때문에, 일반적으로 분석/설계, 구현,테스트에 대한 시간 및 Resource 할당 비율은 1:1:1이 된다.

Task 수행의 위의 3단계가 종료될 때 마다 주요 Task에 대해서는  어떤 형식으로든지, 리뷰 회의를 갖는 것을 권장한다. (Peer Review, Team Walkthrough etc)

 20% 버퍼의 법칙

이렇게 Task list를 도출하고 나면 각 Task에 수행 시간과  담당자를 지정해야 한다.

Task list 도출과 이 과정은 팀원들과 함께 수행되어야 하는데, 팀원들의 능력과 근무 가능 시간이 각각 다르기 때문에 팀원의 의사가 매우 중요하다. 팀원과 미팅을 통해서 해당 Task를 수행 가능한 사람에게 Assign 하고, Assign을 받은 사람과 수행 시간을 논의하여 결정한다. 되도록이면 Assign 받은 사람의 수행 시간에 대한 결정과 의견을 존중하는 것을 권장한다. 실제 Task에 대한 시간을 Estimation해보면, 경험상으로 충분한 시간으로 Task 수행시간을 Assign 하게 하고 Buffer율을 20%를 두도록 해도, 실제 수행해보면 그보다 20~50%의 시간이 모자라는 경우가 태반이고, 이는 초반 프로젝트 스케쥴 관리에 Risk factor가 된다. 보통 1~2개월간의 Sprint 기간에는 이런 스케쥴 예측에 대한 오차 범위가 크게 나타나는데 이를 반영해서 일정을 잡고, 2개월 후에는 팀의 스케쥴 측정에 대한 경험이 쌓여서 점점 더 정확하고 세밀한 스케쥴 관리가 가능하게 된다. 

 이렇게 만든 Sprint의 Task 목록, 예측 시간, 담당자의 목록을 Sprint Back Log 라고 하고 다음과 같은 형태로 작성이 가능하다. 


위와 같이 엑셀을 사용해서 Sprint 스케쥴을 관리할 경우에는 Task의 스케쥴을 우측에 날짜 박스를 만들어놓고, 수행 기간을 칠해 놓는 방식으로 그래프 형태로 스케쥴을 관리할 수 있다. 

Release Planning과 Sprint Planning을 정리해보도록 하자.

기본 원리는 큰 스케쥴을 작은 단위의 스케쥴로 나누어서 관리하는 방법으로, 기존의 전통적인 방법론이 가지고 있는 스케쥴 단계를 Release Plan으로 나누어서 관리한다.

Release Plan은 PMO에서 관리될 수 있는 단위의 프로젝트 주요 Mile stone이 되며, 각 Release Plan은 실제 개발팀이 수행할 하루 단위의 개인 스케쥴로 정의되는 Sprint Plan으로 나뉘어서 관리 된다.


Step 4. Sprint Tracking

Sprint 계획이 끝났으면, 계획에 따라서 프로젝트를 수행한다.Sprint의 Task 진행 상황을 추적하기 위해서 몇 가지 기법을 지원하는데 다음과 같다.

Daily Scrum

Daily Scrum은 일일 오전 업무 공유(보고가 아닌) 회의이다., Scrum에서 가장 유용하고 중요한 기법 중의 하나이다.

Scrum 팀은 매일 오전에 같은 자리에 모여서 어제 자신이 한일과 오늘 자신이 해야할 일을 짧게 발표한다. 전체 회의 시간은 30분을 넘지 않도록 한다. 이와 함께 자신이 진행하고 있는 Task를 Close하는데 필요한 시간을 같이 이야기 한다.

이 과정에서 팀원은 다른 팀원의 Task 진행 상황을 Share할 수 있고, 만약 일의 진행에서 문제가 있는 부분이나 도움을 받고 싶은 부분은 이 회의 과정에서 이슈로 제기하여 다른 사람의 도움을 받거나 PM이 일정을 조정할 수 있도록 한다.

PM 관점에서는 Daily Scrum을 통해서 지정된 Task의 진행 상황을 매일 추적할 수 있다.

PM은 회의에서 공유된 일정을 바탕으로 Sprint Back Log 를 업데이트 하는데, 중요한 점은 각 Task의 종료시까지 남은 시간을 반드시 기록한다. 이 데이터는 처음 계획 대비 현재 상황이 어떻게 되고 있는지를 판단할 수 있게 해주는 중요한 지표가 된다.. 

이상적인 프로젝트 진행이라면 위의 Sprint Planning (칠해진 부분)이 끝나는 다음날 남은 작업 시간이 0 이 되어야 한다. 만약 연장 작업이 계속 되더라도 칠해진 블록의 범위는 변경하지 않고,  남은 날짜만 계속 업데이트 해간다. 그러면 추후에 결과가 계획 대비해서 얼마나 초과되어서 끝났는지를 확인할 수 있다. 

진행중에 고객 요건 변경이나 구현의 난이도에 의해서 스케쥴을 바꿔야 할 경우가 있는데, 전통적인 Scrum 방법론에서는 Sprint가 한번 계획된후에 Sprint 중간에는 바꾸지 못하도록 가이드 하고 있다. 변경이 생겼을 경우 Sprint를 중지하고 다시 Sprint 계획을 하도록 하는데, 국내 SI프로젝트와 같은 상황에서는 이를 매우 통제하기가 어렵기 때문에, 개인적으로는 융통성 있게 Task 를 추가하거나 일정을 변경하는 것을 반영하는 것을 권장한다. 단. Sprint 전체 스케쥴에 최소한의 impact를 줄 수 있는 범위내에서 변경을 하되, 새롭게 발생한 Task가 있을 때 그만큼 다른 Task에 대한 일정을 미루는 것을 전재로 해야 한다.

Burn down chart

Sprint Product Back Log를 위와 같은 방법으로 Update하면, 매일 남은 작업 일 수를 계산할 수 있는데, 이를 그래프로 표현한 것을 Burn down chart라고 한다.


이상적인 Burn down chart는

(remaining time)=(total work)/(current date)

의 형태를 띄어야 한다. 그리고 실제 프로젝트의 remaining time역시 이 이상적인 곡선에 근접해야 하는데, Burn down chart를 매일 업데이트 함으로써, 이상인 그래프에서 실제 프로젝트의 remaining time 그래프가 얼마나 벗어 나는가를 측정함으로써 프로젝트의 일정상 위기 요소를 파악하고 대비할 수 있다.

Burn down chart는 프로젝트 룸의 칠판이나 또는 시스템의 Dash board나, Daily Scrum 을 통해서 공유되는 것이 좋은데, 프로젝트 팀원 역시 사람이고, 사람은 Visual 한 개념을 통해서 현재 상태를 파악하고 프로젝트의 위험도를 좀더 체감할 수 있기 때문에, Risk 요소에 대해서 심각도를 서로 공유하는데 잘 사용될 수 있고 이는 실제 팀의 사기에 영향을 줄 수 있다. 

Task Status

다음으로 각 Task에 대해서 상태를 관리해야 한다. 위의 예시에서 보여준 Sprint Product Back Log의 Status 부분을 말하는데, 이 부분은 사실 매일 Daily Scrum 미팅을 하고 엑셀로 프로젝트를 관리하는 경우에는 크게 중요하지 않지만, 좀더 전문화되고 정교한 Task 관리 절차를 만들거나 시스템으로 구축하고자 할때는 제일 필수적인 부분이다.

시스템으로 구축할 경우에는 해당 TASK를 Daily Scrum 때 뿐만 아니라, 항상 상태를 업데이트 해서 팀원이나 운영 조직간에 자주 의사 소통을 할 수 있고, 저장된 상태나 값을 기반으로 여러가지 지표를 뽑아 낼 수 있다.

Task Status는 Task의 상태 흐름에 따라 정의 되는데 이를 Task Workflow라고 한다. Task Workflow는 최대한 단순해야 하며, 관리 지향적이기 보다는 실무 중심적이어야 한다.

 또한 Workflow가 적용되는 업무의 특성별로 잘 정의되어야 한다. (개발의 Task workflow와 Bug의 Task workflow는 분명히 달라야 한다.) 

다음은 Task workflow의 예이다.


l       
Open (생성됨) 새롭게 생성되고 정의된 TASK로, 담당자가 지정되지 않은 TASK이다.
l        Assigned (할당됨) TASK가 담당자와 협의를 거쳐 지정되게 되고, 수행 시간이 ASSIGN되고 스케쥴링 된 상태이다. 이때 반드시 담당자가 TASK의 내용을 이해하고 자신에게 ASSIGN되었다는 것을 인지해야 한다.
l        Need more information (추가 정보 필요) 만약에 할당 받은 Task의 내용이 명확하지 않거나 추가 정보가 필요할 경우 Need more information으로 상태를 바꾸고 PM/PL에게 Task의 재정의를 요청하는 상태이다.
l        In Progress 지정된 (진행중) TASK를 개발자가 작업을 시작했을 때 “진행중” 인 상태를 나타낸다.
l        Postponed (연기됨) 진행중인 작업이 어떤 이유(Product Bug, 환경 준비 미비)로 인해서 더 이상 진행할 수 없을 때, PM과 상의하여 해당 Task를 “지연” 상태로 변경한다.
l        Resolved (해결됨) 개발자가 할당된 TASK를 완료하고 종료조건을 충족하였을 때, “해결됨” 상태로 바꾸고 PM에게 작업이 완료되었음을 알린다.
l        Closed (종료됨) PM은 개발자가 완료한 작업을 TASK의 지시사항대로 제대로 종료되었는지 확인하고, 종료조건을 충족하여 제대로 완료되었을 경우에는 “종료” 상태로 바꾸거나, 만약 제대로 종료가 되지 않았으면 상태를 Assigned로 바꿔서 다시 개발자에게 할당한다.

Step 5. Ending Sprint

정해진 기간 동안 Sprint가 종료되면, Sprint를 정리 한다.Sprint의 종료 조건은 팀에 따라 정할 수 있는데 크게 아래 조건들을 많이 사용한다.
l        정해진 시간
l        Task 종료
l        예산 종료시 까지

어떤 조건을 사용하던지, 가장 중요한 것은 명시적인 종료 조건을 정의 해야 한다는 것이다.
좋은 종료 조건의 예
1)       구현의 경우  : 단위 테스트 100% 성공, Code Coverage Rate 60% 달성
2)       설계 단계 : 메시지 채널 설계 문서 고객 확인 받음
3)       설계 단계 : Prototype 작성 및 A,B,C,D 기능 동작 확인
4)       기간 BASE 경우 : 3/19일까지 코드 분석된 내용 리뷰 (이 경우, 컨설팅이나 Code Inspection, 탐색적 테스팅 같이 특정 기간과 예산을 가지고 진행하는 경우에는 기간 단위의 종료 조건을 사용하는 경우도 있다. )

Review Sprint

Sprint가 종료된 후에는 Sprint에서 구현된 산출물을 Review하는 단계가 필요하다. 요건에 따라 적절하게 구현이 되었는지 품질은 만족해야 했는지 등의 검증이 필요하다.

단순히 Sprint에서 무엇 무엇을 했고, 잘됐다 안됐다가 아니라, 실제 구현 코드, 산출 문서, 테스트 결과등의 구체적인 자산을 가지고 Review를 수행해야 한다.

이 과정에서는 고객을 참여 시켜서, 자산에 대해서 간략한 데모를 고객에게 수행한다. 이 데모는 고객 보고를 위해서 별도의 PPT나 데모 준비를 하는 것이 아닌 Informal한 리뷰이다. Formal한 리뷰는 Release 시기별로 진행하도록 하고, Sprint Review 준비를 위해서 별도의 시간이나 Resource를 낭비하지 않도록 한다. 

Test

특히 Sprint가 Implementation인 경우, Implementation이 제대로 완료되었는지 아닌지를 확인할 수 있는 방법은 Testing 밖에 없다.

Sprint Planning에서 Implementation의 경우 Test Task를 반드시 포함시켜야 하고, Review과정에서는 이 Test 결과를 Review하도록 한다. Test는 기능적 테스트 뿐만이 아니라 , 안정성이나 성능과 같은 비기능적 요건에 대한 Test도 반드시 포함되어야 한다.

 Sprint별 테스트를 통해서 잠재적인 문제를 빨리 찾아낼 수 있고 필요에 따라서 디자인이나 아키텍쳐에 대한 변경을 가할 수 있다. 

 Scrum을 사용하는 실제 구현 팀에 대해서 테스팅 구현은 다음과 같은 구현을 권장한다.
l        단위 테스트 (Unit Test) : 개발자가 개발 컴포넌트 단위로 테스트 수행
l        회귀 테스트 (Regression Test) : 테스트 했던 내용을 다음 테스트에도 포함 시켜 새로운 코드 추가나 변경이 기존 기능에 영향을 주지 않는 지 매번 검증
l        테스트 자동화 (Test Automation) : 테스트를 자동화 하여 회귀 테스트를 지원하고, 테스팅의 효율성을 극대화 함
l        점진적 통합 (Contiguous Integration) : 일일 빌드등을 통해서 BIG BANG방식의 코드 통합이 아닌 점진적 통합 전략을 사용함 

[!] 위의 내용은 본 문서에서 다루고자 하는 범위가 아니기 때문에 좀더 자세한 부분은 ALM/Test Automation 과 ALM/Build Automation 을 참고하기 바란다.

Code Review

Code Review는 완성된 산출물을 같이 Review하여 Defect를 찾아내고, 좀더 좋은 개선 방안에서 의견을 수렴하는 자리다. 일반 Review와 달리, 특정 산출물을 가지고 진행한다는 것이 다른데, 주로 Design이나 Implemented code와 같은 구현에 밀접한 산출물을 가지고 진행한다.

Code Review는 원래 Code Inspection이라는 개념에서부터 시작했다. Code Inspection 전문적인 지식을 가지고 있는 팀이 정형화된 프로세스에 따라서 Code를 Review하고 Defect를 발견하는 과정을 정의 한다. Code Inspection은 Assembly 로 코딩하던 시절에 시작되었고, 요즘과 같이 많은 코드와 변경 사항이 있는 시스템에서는 적용하기가 적절하지 않다. 그래서 좀더 비형식적인 Code Review 형태가 개발되었는데, Team Review, Walkthrough, Peer Review등이 그것에 속한다. 

[!] Code Inspection은 특정 룰을 바탕으로 하기 때문에 자동화된 툴을 통해서도 어느 정도 효과를 볼 수 있다. Code Inspection을 위한 팀과 프로세스를 구성하는 것보다 Test 과정에 Inspection 도구를 사용하면 최소한의 비용으로 효과를 볼 수 있으며, Open source 기반의 Inspection 도구로는 PMD, FindBugs를 권장한다.

 어떤 형태로건, 비형식적인 Code Review는 준비 시간이 짧고, 그에 비해서 Defect나 시스템 개선에 대한 효과가 상대적으로 크기 때문에, Sprint 말에는 Code Review를 수행하는 것을 권장하며, Sprint 중간에라도, 구현 Task 가 끝났을때는 비정기적으로라도 Code Review를 수행하는 것을 권장한다. 

[!] 위의 내용은 본 문서에서 다루고자 하는 범위가 아니기 때문에 좀더 자세한 부분은 ALM/Collaboration 을 참고하기 바란다.

 Code Review를 진행함에 있어서 중요한 점은 Code Review도 Resource와 시간이 투여되는 작업인 만큼 하나의 Task로 정의되어 관리 되어야 한다.

Code Review시에는 Code Review 결과를 Wiki등에 Meeting Minutes (회의록) 형태로 기록 해야 하며, Review 과정에서 나온 내용들은 Action Item으로 정리되어 Sprint Back Log내에 Task로 생성되고 관리되어야 한다.

Step 6. Update product backlog

Review가 끝났으면 Review 과정에서 나온 추가 요건이나 변경 상황을 반영하여 Product Back Log를 업데이트 한다. 팀이 모여서 우선 순위를 재 조정하고, 요구 사항을 좀더 구체화 하며, 예상 소요 시간을 업데이트 한다.

사람들은 프로젝트를 수행하면서 배우게 되고, 실력적으로 진화하게 된다. 그래서 요구 사항이나 예측치는 그때 상황에 따라 계속 업데이트 되어야 한다. Product Back Log 는 고정된 것이 아니라 항상 변경되고 실상황을 반영해야 한다.

Step 7. Retrospective

 Sprint가 종료되고 모든 작업이 끝나면, 팀에서 운영중인 방법론 자체에 대한 Review가 필요하다. 팀에서 운영중인 Task Management Process는 처음에 셋업 되면 많은 시행 착오를 겪게 된다. 수행 시간 예측이나, Sprint 주기 설정, Task 관리 프로세스 등등 많은 과제들이 있는데 Sprint의 경험을 기반으로 회고를 수행함으로써, 프로세스를 발전시킬 수 있는 방향을 찾을 수 있다.

가장 간단한 수행 방법은 PM이 이메일이나 종이를 이용하여 이번 Sprint에 “무엇이 잘되었는가?” 와 “무엇이 잘못되었는가”를 수집한다음에 SWOT 분석

(http://en.wikipedia.org/wiki/SWOT_analysis )  등을 통해서 개선 방안을 찾아볼 수 있다.

 Process Summary

지금 까지 설명한 프로세스를 개념을 한 그림으로 정리해보면 다음과 같다.


 Implementation

실제로 Task Management Process를 구현하는 몇 가지 방법에 대해서 설명한다. 가장 중요한 점은, 어떤 툴을 사용하느냐가 아니라 어떤 프로세스를 사용하느냐이다.

종종 ALM / Task Management Process를 현업에 적용해보면 문제가 프로세스에 대한 인식이나 성숙된 적용이 없이, 툴을 도입해서 툴에 이끌려가는 경우가 많다. 그래서 프로세스 자체가 또 다른짐이 되고 실제 업무 따로 Task 관리가 따로 이루어 지는 경우를 많이 봤다.

어떤 툴을 사용한다고 해도, 조직과 업무에 맞는 현실적이고 실행 가능한 프로세스를 사용하는 것이 가장 중요하며, 이를 위해서는 1~2개월 정도의 시행 착오 기간이 생길 수 있고 가급적이면 이 기간 중에는 프로세스를 관리하고, 이해 당사자들이 제대로 프로세스를 준수 하는 지를 챙길 수 있는 Coach를 두는 것을 권장한다.

Jump start with Excel

소규모의 팀에서 이 Task Management Process를 사용하기 위해서는 툴과 도구를 설치하는 시간에 대한 소모를 줄이기 위해서 Microsoft Excel만을 사용해도 충분하다. 보통 단일팀에서 10명 이하라면 약간 불편하긴 하지만 빠르게 방법론을 적용할 수 있고, 만약에 시스템을 적용하더라도, 가장 중요한 것은 프로세스이기 때문에 구축 전에 미리 Excel을 이용하여 프로세스를 적용해보고 단계적으로 발전 시켜가는 것을 권장한다.

Excel Template은 http://bcho.tistory.com에서 다운 받을 수 있다.

Implement Task management process with Atlassian Product

회사내에 자체적으로 ALM을 구축하고자 할때는 Atlassian Product를 추천한다.

Atlassian은 JIRA라는 Issue tracking 시스템을 가지고 있는데, 태생 자체가 Task 와 같은 프로젝트 관리 관점 보다는 Bug Tracking 관점의 접근이기 때문에 툴과 Process에 대한 Customizing이 필요하다 그러나 상대적으로 가격이 매우 저렴하고, (Professional Version이 250만원선) 전세계적으로 매우 널리 사용되기 때문에, 관련 자료나 Plug in 들이 많다.

또한 CI나 테스팅 툴, SCM 도구들과 잘 통합이 되는 장점도 가지고 있다.

아래는 ALM/Task Management process 구축을 위한 Atlassian 제품을 이용한 권장 구축 아키텍쳐 이다.


1)       Task Management : Sprint에서 관리되는 각종 Task를 관리한다. Atlassian의 JIRA(이슈 트랙킹) 시스템으로 구축하되, Product BackLog Item과 Sprint Back Log Item이 서로 Parent/Child 관계로 맵핑이 되어야 하기 때문에 Issue에 대한 Parent/Child 관계는 JIRA Professional Version 이상에서만 지원한다.

2)       Product Back Log Mgmt : Product Back Log에는 Product Back Log Item들과 그에 대한 자세한 설명 (예를 들어 Use case)이 들어간다. Product Back Log Item은 JIRA내에 Parent Task로 등록해서 관리할 수 있기 때문에 이에 대한 연관 관계를 JIRA내에 확장 필드로 등록하여 Wiki와 JIRA 사이에 상호 추적이 가능하도록 구축한다.
그 위에 Zagile의 Wiki Smart라는 플러그인을 사용할 수 있는데, Wiki Smart를 사용하면, Product Back Log Item 입력등을 위키 형식이 아니라 좀 더 정형화된 폼을 이용해서 사용할 수 있다.

3)       WBS Mgmt : 전체 프로젝트의 WBS를 관리할 때 통상적으로 사용하는 도구가 MS Project이다. http://www.the-connector.com/ 에서 제공하는 플러그인은 MS-Project의 Task와, JIRA의 Task를 연계 시켜준다. 이 도구를 이용하여, MS-Project를 이용한 WBS 관리와 JIRA를 통한 실제 Task 관리를 연동 할 수 있다.

4)       Integrated view : JIRA와 Wiki는 각각의 View를 가지고 있기 때문에 한눈에 원하는 화면을 보기도 어려울 수 있고 이로 인해서 툴의 사용 효율성이 떨어질 수 있다. zAgile의 Portal 도구는 Atlassian의 툴을 하나의 View로 통합할 수 있는 기능을 제공한다.

5)       Personalized view : 각 이해 당사자 Customer/PM/PL/개발자 별로 봐야 하는 화면이 틀리다. Customer나 PM은 프로젝트의 진척도나 위험도등의 간단한 Dash board를 보고 싶어하며, 개발자는 자신에게 할당된 작업상황에 대한 모니터링을 원한다. zAgile Portal은 개인화 기능을 제공함으로써 역할별로 원하는 화면을 만들 수 있도록 한다.

 Implement Task management process with VersionOne

다음으로 Version One (http://www.versionone.com )이라는 전문화된 Task Management 도구가 있다. AUP나 Scrum과 같은 Agile 방법론을 기반으로 하고 있기 때문에 본 Task Management Process에도 적용이 잘 된다.

 또한 패키지 판매와 함께, Hosting service도 제공하기 때문에 프로젝트 수행후 빠지는 SI 성 프로젝트에서 임시로 사용하기에는 그만이다. (1 Project의 경우 제한된 인원 내에서 무료로 사용할 수 있으니,작은 조직에서 툴을 Evaluate 할 경우 추천한다.)

 단 Issue tracking에 주 목적을 두고 있기 때문에 ALM의 Build Automation이나 Test Automation등의 통합에 문제가 있을 수 있다.

 Conclusion

Agile 방법론이 아무리 실용성을 강조하더라도, Risk관리 측면이나 일정 비용을 가지고 프로젝트를 진행하는 현실에서는 Agile의 목표가 불 명확한 방법론은 적용하기가 어렵다. 그래서 전체 프로젝트에 대한 큰 Mile stone은 기존 방법론을 적용하고, 그 아래에서 Agile 방법론을 팀의 Task 관리 기법으로 사용하도록 디자인 된 것이 ALM / Task Management Process이다.

 ALM/Task Management Process를 실제로 구현하는데 가장 중요한 것은 어떤 전문화된 시스템이나 도구가 아니라, 팀이 최대한의 효율을 낼 수 있는 프로세스이다. 도구는 프로세스를 도와주기 위해서 존재하는 것이지, 도구에 프로세스나 팀이 이끌려 가서는 안된다.

Reference

Methodology

1) SWOT Analysis : http://en.wikipedia.org/wiki/SWOT_analysis
2) Scrum in 5 minutes : http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
3) Scrum primer : http://scrumtraininginstitute.com/home/stream_download/scrumprimer

Tools

1) Atlassian : http://www.atlassian.com
2) JIRA : http://www.atlassian.com/jira
3) Confluence Wiki : http://www.atalssian.com/confluence
4) JIRA & MS Project Connector : http://www.the-connector.com/
5) zAgile  : http://www.zagile.com
6) VersionOne : http://www.versionone.com





 

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 에코지오 2009.02.18 09:08 신고  댓글주소  수정/삭제  댓글쓰기

    찬찬히 읽어봐야할 내용 같습니다. 소중한 자료 공유 감사드립니다.
    바빠서 일단은 즐겨찾기에 추가~ ^^;

  2. mark 2009.03.26 00:52  댓글주소  수정/삭제  댓글쓰기

    곰곰히 되집으면서 읽고 있습니다.^^ scrum master의 역할이 무척 중요한데에 비해서 그 존재의 가치를 아는 사람이 무척 드물다고 봅니다. jedi master yoda가 생각나는건 왜일까요....

  3. just 2010.03.18 10:07  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다.

    SI프로젝트에 스크럼 도입에 관한 아주 좋은 내용 같습니다. 전반적으로 스크럼에 관한 이해도 할 수 있었구요. 버전원을 회사에 도입해볼까하는데 가격대가 어느정도 할까요??

    • bwcho75@gmail.com 2010.03.19 12:17  댓글주소  수정/삭제

      VersionOne이 아마 제일 비싸고 어려울겁니다. :)
      억대가 넘는것으로 알고 있습니다만.

  4. Yarmini 2010.05.10 21:01  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다^^

    덕분에 이해가 잘 됬습니다.


    귀한 자료네욥~!

  5. TaskManager 2010.09.14 18:44  댓글주소  수정/삭제  댓글쓰기

    안녕하세요, 좋은 글 감사합니다.

    본문 내용중에서, excel 기반으로 alm을 관리할 수 있는 것을 블로그내에서 다운받을 수 있다고 하셨는데, 찾을 수가 없어서요,, 혹시 어디서 찾아볼 수 있는 지 알 수 있을 까요?

    e-mail: igiti at naver dot com

  6. Will 2013.09.12 11:22  댓글주소  수정/삭제  댓글쓰기

    안녕하세요.
    SCRUM 공부를 이제 막 시작한 초짜 PM 입니다.
    한국어로 되어 있는 SCRUM 관련 내용중에서는 이 글 만큼 좋은글이 없는 것 같은데요.
    위 글을 참고하여 Excel 을 이용하여 task management process 를 만들어 보고 싶은데.
    위에 올려주신 블로그에서 다운 받으려 했으나, 잘 안보이네요.
    e-mail: bestwillchoi gmail dot com
    보내주시면 감사하겠습니다.

  7. 2017.08.22 18:15  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

The Art of project management

사는 이야기/책 | 2009.02.06 15:17 | Posted by 조대협

THE ART OF PROJECT MANAGEMENT
카테고리 컴퓨터/IT
지은이 스콧 버쿤 (한빛미디어, 2006년)
상세보기

 사놨다가 읽다 말다 한책인데.
요즘 Scrum 방법론을 프로젝트용으로 개선하는데 유용하게 읽고 있다.
PM은 한번쯤 꼭 읽어봐야 할 책인데.
재미있는 것중 하나가. AGILE 방법론에 대한 책이 아님에도 불구하고
AGILE의 프로젝트 관리 사상들이 거의 다 나온다.
Communication,일일빌드,Task 관리 등등. Agile 제목을 단 다른 책들보다 오히려 이해하기 쉽고 직관적이랄까?



'사는 이야기 > ' 카테고리의 다른 글

[서적 소개] Measuring User Experience  (0) 2009.07.20
SOA Design Patterns by Thomas Erl  (0) 2009.06.19
The Art of project management  (0) 2009.02.06
Enterprise Integration Patterns  (2) 2009.01.30
SOA Design Pattern  (2) 2009.01.19
파피용  (0) 2007.12.27
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

오랜만에 지방 출장

ALM | 2009.01.23 12:57 | Posted by 조대협
어제와 그저께 오랜만에 지방 출장을 다녀왔습니다.
운전 왕복 10시간에.. 고객의 준비가 치밀해서 많은 내용을 이야기하고 오늘 거의 넉 다운 상태입니다.

그래도 이런 출장이 싫지만은 않습니다.
고객분들 중에서 제가 이야기하는 기술적인 가치에 대해서 인정해주는 고객이 있어서 이런 경우에는 모라도 하나 더 드리고 싶은 경우가 있습니다. 이번 출장도 그런 고객분들중의 한분입니다.

ALM 사상은 제가 근무하는 회사의 제품과는 사실상은 관련이 없습니다. 단 프로젝트를 수행하는데 있어서 컨설팅 방법론으로 사용하는 기법입니다. 요즘 유행인 AGILE사상이나 실용 주의 사상과도 유사하구요.

ALM 을 프로젝트 수행하는 곳에 소개하면 좋아합니다만 별도로 돈을 들여서 컨설팅을 받고자 하지는 않습니다. 공짜로 받기를 원하지요. 그런데 이번 고객은 제 ALM 이론을 직접 돈을 들여서 현재 현실화 시키는 프로젝트를 하고 있습니다. 완성도가 높게 잘 구현하고 있더군요.

더군다나, 이번에 고객사의 수행사는 대우 정보기술입니다. 예전 Spring Framework을 Enterprise 환경에서 구현할 수 있는 수행사를 찾던중에 본적이 있어서 관심을 가졌던 팀인데... 기대했던데로 어느정도 수준 이상의 실력을 가지고 있었습니다. 이번 출장에서 많은 기술적인 토론을 할 수 있는 기회를 가진 이유도 이 팀 덕분이 아닌가 싶습니다.

Spring이 점점 국내 엔터프라이즈 환경에서도 많이 사용되고 있지만 국내의 블로그 포스팅들은 엔터프라이즈 환경에 적절한 Spring에 대한 내용이 얼마나 있는지는 잘 모르겠습니다 엔터프라이즈 환경은 서비스 시스템에 비해서 훨씬 높은 가용성,안정성,성능에 대한 요건과 복잡한 Message Exchange Pattern등을 지원해야 합니다.
예를 들어 서비스 시스템에서 빌링 오류가 한번 나서 복구가 안되면 1000~2000원 컨텐츠 구매 비용을 손해 보겠지만.. 만약에 은행에서 한 트렌젝션이 오류가 나면 몇 십억의 돈이 유실 될 수 있기 때문에 아키텍쳐의 복잡도가 비교적으로 상당히 높습니다.
그래서 오픈소스를 기업에서 사용할때는 경험이 많이 필요한데, 실제 이런 경험을 가지고 있는 팀이 아닌가 싶습니다.

아마 금년중에는 이 고객사의 ALM 구현체를 볼 수 있을 것 같습니다.

마지막으로 이번 컨설팅 과정에도 느꼈지만 ALM의 구축을 하다보면 솔루션이나 툴에 집중하게 되는데, ALM은 프로세스와 의사소통이 기본입니다.

'ALM' 카테고리의 다른 글

실용주의 ALM (Application Lifecycle Management) Overview  (3) 2009.02.18
오랜만에 ALM 업데이트  (0) 2009.02.17
오랜만에 지방 출장  (3) 2009.01.23
ALM 온라인 강의  (0) 2009.01.07
ALM Concept  (0) 2008.12.24
재미있는 ALM 플랫폼.  (1) 2008.11.03
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. amazing 2009.01.28 10:15  댓글주소  수정/삭제  댓글쓰기

    대협님때문에 얼마나 많이 도움이 되었던지... 감사하구요... 다음에는 사석에서 더 많은 얘기 나누었으면 좋겠습니다^^

  2. 으앙.. 2009.03.18 23:18  댓글주소  수정/삭제  댓글쓰기

    대우정보기술이 아니구 대우정보시스템 아닌가요?
    혹시 울산으로 가셨는지..

ALM 프레임웍중에서, JIRA와 같은 이슈 추적 시스템을 이용하여 스케쥴 관리와 작업 추적을 할 수 있지만,
프로젝트에 따라서는 이슈 추적 시스템의 도입이 어렵거나, 별도의 프로세스 정립이나 Learning Curve가 필요한 경우가 있기 때문에, 때에 따라서는 Excel 기반의 Task관리가 효율적일 수 있다.

조엘 온 소프트웨어에서도 언급된바있는 내용인데,

엑셀 항목에
TASK # | Category | Sub task | Detail Task | Assignee | Priority | Due data | Status 를 정한다.
  • Category는 Task의 종류가 된다. 디자인,분석 같은 단계가 될 수 도 있고, Logging,Exception Handling과 같은 각 패키지가 될 수 도 있다.
  • SubTask는 Task들을 나눠서 정의하는 부분으로 Sub category정도로 생각하면 되고, 가장 좋은 단위는 독립된 기능으로 하는 것이 좋다.
  • Task는 실제 작업을 해야하는 Task인데, 보통 1일단위로 나누는 것이 좋고 최대 3일을 넘지 않아야 제대로된 관리가 가능하다.
  • Assignee는 작업이 지정된 사람을
  • Priority는 중요도를
  • Due date는 작업 예상 종료일을 지정한다.
  • Status는  New/Assigned/In Progress/Postponed/Closed 로 정하는데, New는 새로 생성된것, Assigned는 생성되고 각 개발자에게 할당된 작업, In  Progress는 실제 작업중인것, Postponed는 일정에 의해서 미뤄진 작업이고,Closed는 완료된 작업이다.
뒤에 그래프는 날짜별로 작업을 진행하는 기간을 명시한다.

프로세스
크게는 Scrum 방법론을 따르는데, 기본적으로 해야할 Task list들을 정하고 Iteration 기간을 정한다. 보통 한달 이하가 적절하다. Task list를 뽑는 것은 PM이 주도로 하고 세세한 Task는 각 구성원이 직접 작성하고 그에 필요한 시간 역시 직접 작성한다. 그래야 책임 여부가 확실해 지지만, 이것은 스케쥴이 늦어 졌을때 책임을 묻기 위함이라기 보다는 좀더 현실적인 스케쥴링을 하고 책임감을 부여하기 위함이다.
PM은 구성원이  작성한 스케쥴을 가지고, Iteration 기간내에 맞출 수 있는지 체크하고 Task 가 over되었을 경우에는 Priority에 따라서 다음 Iteration으로 넘기거나, Resource를 더 할당 한다.

Task 시간을 예측 하는데는 몇가지 규칙이 있는데,
절대 Task는 각 팀원의 Utilization을 100%로 해서 잡지 않는다. 80%가 적절한데, 80%로 잡더라도 항상 100% 근처가 되기 때문에, 낭비가 되지는 않는다.
그리고 다른 규칙은 모듈을 개발할때, 설계:구현:테스트의 비율이 실제적으로 실행해보면 1:1:1 의 비율을 갖는다. 설계 단계에서는 관련 기술을 Search하고, 테스트 하고 문서화 하는 기간, 테스트 에서는 버그 추적 및 Refactoring등의 기간이 들어가기 때문에 1:1:1의 법칙역시 많은 시간을 소요 하는 것은 아니다.

이를 바탕으로 오전에 10~20분 정도 팀원의 스케쥴을 체크하고 문제 사항이 없는지 도움을 주거나 받을 사항을 간단하게 이야기 하고 매일 Task List를 업데이트 하여 스케쥴 상에 발생할 수 있는 Risk를 관리한다.

예전에 Issue Tracking 시스템을 쓸 수 없는 프로젝트에서 한번 사용했었는데, 요즘도 참 유용하게 사용하고 있다는..



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 2009.01.23 10:16  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  2. 2010.01.07 13:49  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  3. 안기탁 2010.02.10 01:51  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 보고 갑니다. 프로젝트관리에 요즘 신경이 많이 쓰이는데
    excel template 를 다운받을 수 있으면 정말 유용하겠어요.

    아무리 찾아도 안 보여서 댓글을 남깁니다.

    termi@postech.ac.kr 로 부탁 드릴께요.

  4. 문시영 2010.02.10 23:50  댓글주소  수정/삭제  댓글쓰기

    Scrum 에 관심있는데 좋은글 감사합니다.
    저도 excel template를 찾고 있는데
    어디 있는지 찾기가 너무 힙듭니다.

    siyoungmoon@hanmail.net으로 화일 부탁드립니다.
    감사합니다.

  5. 2011.08.05 13:39  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  6. 2012.01.09 14:58  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  7. 우노★ 2013.03.26 11:15 신고  댓글주소  수정/삭제  댓글쓰기

    감사합니다. 파일 잘 받아갑니다. 건강하십쇼~

ALM 온라인 강의

ALM | 2009.01.07 13:40 | Posted by 조대협
예전 플루토 미디어에서 ALM에 대해서 강의한 내용이 온라인으로 올라왔습니다.
http://www.bizdeli.com/online/detail.asp?pfid=S2343
에 있구요. 유료로 올라왔네요.
작년에 여러군데서 강의했는데, 혹시 필요하신데 못 들으신분들은 참고하시면 되겠습니다.

'ALM' 카테고리의 다른 글

오랜만에 ALM 업데이트  (0) 2009.02.17
오랜만에 지방 출장  (3) 2009.01.23
ALM 온라인 강의  (0) 2009.01.07
ALM Concept  (0) 2008.12.24
재미있는 ALM 플랫폼.  (1) 2008.11.03
ALM 온라인 세미나  (5) 2008.10.15
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

ALM-Project Management

ALM/Task Management | 2008.12.24 10:43 | Posted by 조대협
ALM의 이슈트랙킹 시스템을 통한 프로젝트 관리 방법입니다.
아래 그림이 구현하고자 하는 내용의 모두라고 볼 수 있습니다.
  •  PM : 요구 사항을 시스템에 등록하고 각 요구 사항에 대해서 스케쥴링을 한후에 각 요구사항을 해당 개발팀의 팀장에게 ASSIGN합니다.
  • PL : PL은 각 요구사항을 분석하여 실제 작업(TASK)로 쪼게고 개발자의 스케쥴과 역량 그리고 작업의 심각도와 긴급도에 따라서 개발자에게 ASSIGN합니다.
  • 개발자 : 개발자는 진척 상황을 TASK에 COMMENT로 로깅하고, 각 TASK에 연관된 단위 테스트 케이스를 작성하여 진행을 합니다.
  • PM은 요구 사항을 개발 PL뿐만 아니라, QA 팀에도 ASSIGN하는데 QA 팀에서는 각 요건을 검증할 수 있는 테스트 케이스를 개발 초기단계 부터 작성합니다. 이 테스트 케이스들 (실제로 구현된 JUnit과 같은 구현체)은 Test case management 라는 툴에서 관리 됩니다. 한번 등록된 테스트 케이스들은 이 툴에서 다시 Invoke될 수 도 있고, 그 결과 역시 시스템에 다시 레코딩이 됩니다.
  • 테스트 과정에서 발생된 문제는 Defect Management System(버그 추적도구)에 의해서 리포팅이 되고 각 버그는 하나의 TASK로 PM->PL을 거쳐 개발자에게 다시 ASSIGN이 됩니다.


    이 일련의 프로세스가 ISSUE TRACKING시스템을 통해서 구현되고 각각의 TASK가 추적성을 갖게 됩니다.

이것이 ALM의 PROJECT MANAGEMENT모듈의 개념입니다.
어떤 툴을 사용하느냐, 개발팀의 모델이나 일정 수준에 따라서 Variation이 상당히 많습니다. 그외에 PM이나 고객을 위해서 DASHBOARD를 제공하거나 개발자를 위해서 Eclipse에 플러그인(Mylyn)을 제공하거나 환경적인 설정 방법도 상당히 많습니다. 제대로 적용하면 상당히 효과가 좋은 모듈이지만 반대로 잘못하면 자체가 짐이 되버리는 경우가 많기 때문에 도입시에 많은 고려가 필요한 부분입니다.

개인적으로 JIRA,Mantis,Bugzilla를 프로젝트에서 사용해봤고, Trac,Polarion,Code Beammer, Rally Enterprice, VersionOne등의 이슈관리 도구들을 테스트해봤지만 개인적으로 가장 사용하기 편하고 유연성이 있으며 가격대비성능(ROI)가 높은 도구는 JIRA인것 같습니다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 박기수 2008.12.24 11:34  댓글주소  수정/삭제  댓글쓰기

    지금 구축 프로젝트를 진행중에 있습니다.. 이글도 많은 도움이 될것 같습니다..
    저희는 프레임워크 고도화라는 제목하에 ALM, 배치 시스템, 협업환경을 동시에 진행하고 있네요. 또란 프레임워크에 기본적으로 필요한 공통 서비스등도 정재하면서....
    계속 좋은 글 부탁드립니다.

  2. doortts 2008.12.25 22:40 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요? 코멘트는 처음 남기는 것 같습니다만, RSS로 등록해 놓고 올리시는 글들, 늘 감사히 잘 보고 있는 사람 중 한 명입니다. :)

    올리신 글에서 도식화된 그림을 굉장히 인상깊게 보았습니다.
    직접 작성하신 건지, 아니면 출처가 따로 있는 건지 여쭤봅니다. :)

    그럼, 행복하고 즐거운 연말 되시길 기원하겠습니다.
    감사합니다!

    • 조대협 2008.12.26 11:40 신고  댓글주소  수정/삭제

      도움이 되고 있다니 감사합니다.
      제 블로그에 올라오는 모든 글은 별도의 인용에 대한 멘트가 없는 이상 모두 제가 작성한 글과 도식입니다. 이 글에 대한 도식과 프로세스 역시 프로젝트 경험을 통해 직접 작성한 글입니다.

  3. 정병호 2015.01.16 11:25  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 현재(2015/1/16) JIRA를 issue tracker로 사용하고 있는 개발자 입니다. 그런데 회사에서 Code beammer를 ALM으로 도입하려 하는데요. 아직 Code Beammer를 적극적으로 사용하고 있지 않아서 인지 두개의 장단점을 모르겠습니다. 그래서 검색을 통해 여기까지 오게 되었네요.2008년도에 이 글을 올리셔서 지금은 많이 달리질 수도 있을텐데요. 이때 말씀하신 개인적으로 JIRA가가장 사용하기 편하고 유연성이 있다고 하신 구체적인 이유를 좀 알려주실 수 있으신가요?
    감사합니다.

    • 조대협 2015.01.17 03:36 신고  댓글주소  수정/삭제

      그렇네요. 굉장히 오래되었네요.
      근래에는 코드비머는 사용하지 않고 지라만 사용한지 꽤 오래되서 비교 하기가 어렵군요.

      제 관점에서 보자면, 사용자 권한 관리가 쉽고
      특히 애자일 보드를 통해서 태스크 관리가 편리합니다. (코드 비머로도 되는걸로 압니다만...) 스윔레인도 커스터마이징이 가능해서 프로젝트 태스크 관리 프로세스 세팅과 편하구요.
      무엇보다 플러그인이 많아서 커스터마이제이션이 편합니다.

      가장 근래에 작성한 JIRA 관련 링크를 드립니다. http://bcho.tistory.com/826 한번 참고해보십시요.

      감사합니다

  4. 윤용균 2015.03.05 12:36  댓글주소  수정/삭제  댓글쓰기

    저랑 같은 고민을 하시는 분이 같은 질문을 하셨네요. ^^

재미있는 ALM 플랫폼.

ALM | 2008.11.03 09:53 | Posted by 조대협
ALM 플랫폼을 만들었을때 대충 컴포넌트가
  • 프로젝트 관리 부분
    테스트 자동화 부분
    자동 빌드 부분

3군데로 나뉘어져서 디자인을 했고. 각 모듈에 사용 되는 제품들은 오픈소스들을 대부분 조합하였다.
그런데 이 경우 seamless하게 제품을 조합하는 것과 유지보수 문제에 대한 고민이 있어서...
혼자 생각으로 이런 모든 Full Process를 묶어서 제품화 했으면 좋겠다 생각을 했는데. 오늘 우연히 구글 광고에서 재미있는 제품을 발견했다.

http://www.appperfect.com

단위 테스트 자동화, 부하 테스트, UAT등을 지원하고
요건 관리,테스트 케이스 관리등이 모두 지원된다. 겉보기에는 썩 괜찮은툴인듯... ^^
아직 한국에 들어오지 않은게 아쉽지만 가격도 꽤 경쟁력 있어보이는데...
항상 몬가를 생각하면 누군가가 미리 하고 있다....


'ALM' 카테고리의 다른 글

ALM 온라인 강의  (0) 2009.01.07
ALM Concept  (0) 2008.12.24
재미있는 ALM 플랫폼.  (1) 2008.11.03
ALM 온라인 세미나  (5) 2008.10.15
9/20 devmento에서 발표한 빌드 배포 및 테스트 자동화에 대한 자료  (4) 2008.09.29
첫 ALM 발표 합니다.  (3) 2008.09.18
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. [짱가™] 2008.11.03 14:06 신고  댓글주소  수정/삭제  댓글쓰기

    "항상 몬가를 생각하면 누군가가 미리 하고 있다."..... 맘에 와 닿습니다.

ALM 온라인 세미나

ALM | 2008.10.15 17:41 | Posted by 조대협
ALM 온라인 세미나가 준비중입니다. 11월 21일 아마 웹을 통해서 웨비나 형식으로 진행할것 같습니다.
근데 써먹어도 너무 써먹는거 같은데... 

ALM 사례 : 아키텍쳐 대회 발표
ALM INTRO : 데브 멘토 컨퍼런스 발표
ALM INTRO : S社에서 아키텍트 대상 발표
ALM INTRO : 사내 SALES 대상 발표
ALM INTRO : 아키텍쳐 모임 월 정기 발표
ALM INTRO : 11월 21일 웨비나...
그외에 영업들 요청으로 사이트로 전달되거나 다른분이 대신 발표한것이 3군데...

이번이 6번째 발표네요... 금년까지만 하고 내년에는 새 주제 찾아봐야 겠습니다.


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG ALM, 발표

댓글을 달아 주세요

  1. 남종환 2008.10.16 19:54  댓글주소  수정/삭제  댓글쓰기

    실제로 쓰여지기 위해서는
    현업에서의 적용 노하우가 쌓일 곳이 있었으면 좋겠습니다
    - 보고 배울수 있게...

    작은 것부터 하나씩 도입해보고자
    여러 자료를 준비하고 있지만
    적용까지 가기가 힘든 부분이 많이 있네요

    우선 리더를 설득 시키기가 힘드네요
    충분히 이해되지만,
    한번 질러봐(?!) 주면 않될까 하는 생각도 듭니다
    역시 관련된 충분한 노하우를 가진 사람이 있으면
    설득하기가 훨씬 수월하리라 생각됩니다

    하루 왠종일 앉아만 있으라고 해도 좋으니
    제대로 적용하고 있는 현업에 가서
    배워오고 싶은 심정이네요

  2. 박기수 2008.10.20 07:43  댓글주소  수정/삭제  댓글쓰기

    저희는 이번에 CIO승인을 받아서 프레임워크 고도화라는 명목으로 진행을 할려구 하고 있습니다. 저희는 개발부의 research한 설문 조사 결과가 의외로 잘 먹혔습니다. 또한 이러한 프로세스는 상단의 관리자에게 어필이 필요한 항목을 가지고 접근을 할때 승인을 쉽게 받을수 있는 것 같습니다. 프로세스보다는 문화의 변화를 위한 초기 단추로 인식을 주는 것이 중요하다고 봅니다. 저는 CMMI, 아웃소싱 관리, 조직의 mission변화에 초점을 맞추었습니다. 도움이 되시길...

    • bwcho75@gmail.com 2008.10.20 17:39  댓글주소  수정/삭제

      역시 갑다운 갑입니다. 항상 많이 배우고 있습니다.
      감사합니다.

  3. 김성훈 2008.10.30 01:03  댓글주소  수정/삭제  댓글쓰기

    혹시 코드 리뷰하는 툴들을 사용해 보신 경험이 있으신지요?

    • bwcho75@gmail.com 2008.10.30 09:29  댓글주소  수정/삭제

      이야기만 들었고. 실제로 써보지는 못했습니다. ^^
      혹시 좋은 아이디어 있으신가요?


약속드린데로 9/20일에 발표한 devmento 빌드 배포 자동화에 대한 자료를 올립니다.
45분의 시간 동안 얼마나 많은 내용이 전달되었는가 모르겠습니다. 좀 더 시간이 있었으면 많은 이야기를 할 수 있었을텐데 다소 아쉬움이 많이 남습니다.
책을 써볼까? 장기 강좌를 해볼까? 생각은 많이 하고 있습니다만.. 역시 쉽게 시간이 허락되지 않는군요.
그래도 시간 나는데로 이 개념에 대한 실천 방법과 구현 경험에 대해서 지속적으로 포스팅하겠습니다.
의견이나 토론환영합니다.
감사합니다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 박기수 2008.09.29 13:14  댓글주소  수정/삭제  댓글쓰기

    내용 잘보았습니다...역시 대협이름이 부끄럽지 않네요,,,저희도 이번에 하는 프젝에 많은 사상을 넣어봐야 겠습니다,,

  2. 에코지오 2008.10.01 21:31 신고  댓글주소  수정/삭제  댓글쓰기

    저도 요즘 빌드,배포 자동화에 대해서 고민중인데 잘 참고하겠습니다.
    발표 동영상이 있으면 꼭 보고싶네요.
    좋은 자료 감사드립니다.

  3. 김혁 2008.10.02 16:03  댓글주소  수정/삭제  댓글쓰기

    내용 잘 보았습니다.
    예전에 수은에 있을때에는 automate로 빌드자동배포하는 넘을 만들었었는데
    요즘은 좋은 툴도 많이 나오는거 같아요~

    자료 잘 보고 갑니다 ~ ^^

  4. 레인 2008.10.17 07:54  댓글주소  수정/삭제  댓글쓰기

    링크타고 조대협님 블로그 알게 되었는데..우와..완전히 보물창고 인데요..ㅎㅎ 앞으로도 좋은글들 많이 기대합니다.

첫 ALM 발표 합니다.

ALM | 2008.09.18 10:28 | Posted by 조대협

그동안 ALM (이슈 관리, 빌드 자동화,테스트 자동화 등등) 에 대한 포스트도 올리고 은행과 제조 업체에 delivery를 해봤는데. 그간의 경험들을 정리해서 첫 발표 세션에 나섭니다.
사실은 "아키텍쳐 대회"나 고객 대상으로 발표를 한적이 있기 때문에 첫 발표라고 보기는 어렵지만, 일반 개발자 대상으로는 첫 발표인것 같습니다.

http://www.devmento.co.kr/conference/conference.jsp

devmento에서 진행하는 컨퍼런스에서 발표합니다.
개념과 그간의 경험들을 위주로 발표하게 될것 같습니다.
반가운 얼굴들 많이 볼 수 있으면 좋겠습니다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 자바지기 2008.09.18 18:17  댓글주소  수정/삭제  댓글쓰기

    아쉽네요. 그날 결혼식이 두건이나 있어서 참석 못합니다. 그렇지 않아도 참석해 달라고 했는데.. ㅠㅠ

  2. kenu 2008.09.18 21:05  댓글주소  수정/삭제  댓글쓰기

    시간 맞으면 꼭 듣고 싶습니다.
    저도 비슷한 내용으로 발표하는게 있네요.
    제목은 "개발팀 협업 프로세스와 오픈소스"입니다.

  3. 남종환 2008.09.19 14:06  댓글주소  수정/삭제  댓글쓰기

    방금 접수했습니다^^
    기대됩니다!

국내에서도 ALM 의 개념을 가지고 접근하는 제품이 있다는 것은 참으로 반가운 일이다.
http://www.snh.co.kr/?s=product&m=shape1
형상관리 제품은 많이 보았는데, ALM의 개념을 가지고 있는 제품은 처음 본것 같다...
그러나 역시 한국 고객 특성에 맞도록 되어 있다...
그말은 실용적이기 보다는 고객의 엉뚱한 요건(?)을 만족 시키기 위한 기능들이 있다는것...
고객의 엉뚱한 요건이란, 실제 업무 프로세스 위주로 구성이 되는것인데.
변경 요청이나 승인 프로세스들은 상당히 프로세스가 고도화된 후에나 ALM에 녹일 수 있는 것인데..
아마도 고객의 커스터마이징 요청에 의해서 그런 그림이 나오지 않았나 싶다...

고객으로 부터 ALM등에 대한 개발 Layer 이상의 관리적인 요건이 있으면 차라리 이런 업체에 넘겨 버리는 것이 좋을것 같다.

이슈 관리 도구도 있네..
http://www.snh.co.kr/brochure/CodeInside2_workitem/CodeInside2.html
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG ALM, 실루엣

댓글을 달아 주세요

이클립스 ALF

ALM/Build Automation (빌드 자동화) | 2008.08.12 00:34 | Posted by 조대협

이클립스 프로젝트로 진행중인 ALM
업체들이 뭉쳐서 진행하고 있는 것 같은데.
다소 약한 느낌이 들기도...

http://www.eclipse.org/alf/Flash/ALF003Demo.htm

테스트쪽을 분리해놓고 테스트 관리 부분이 강화 된것이 흥미롭다.

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

Maven pom properties  (0) 2013.03.26
국산 형상 관리 솔루션 실루엣  (0) 2008.08.12
이클립스 ALF  (0) 2008.08.12
괜찮은 ALM툴  (5) 2008.06.11
Hudson을 이용한 빌드 배포 테스트 자동화  (8) 2008.04.07
플러그인 개발 순서  (0) 2008.04.02
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

About CodeBeamer

ALM | 2008.06.17 20:58 | Posted by 조대협


일이 바뻐서 요즘 공부나 플랫폼들 보는 것에는 소홀해 있다가.
야근하다가 잠깐 쉬는 겸해서 예전에 인스톨해놓았던 CodeBeamer를 review해봤다.
아키텍쳐 그룹에서 제공해준 패키지 덕분에 쉽게 인스톨하고 문서들도 참고 할 수 있었다. (감사)

사용자 삽입 이미지



인스톨해서 드는 느낌은 완성도가 높고 쉽다는 것 정도?
다시 말하면 이것저것 필요한것은 다 들어 있지만, 타 Agile 툴에 비해서 깊이는 떨어지는 것 같은 느낌은든다.
모라고 비교해야 하나 Mantis와 JIRA를 보는 느낌이라고나 할까?

프로세스나 워크플로우도 정형화 되어 있어서 복잡한 프로세스가 없는 팀이나 기업이라면 크게 문제 없이 사용이 가능할것 같다. 기본적으로 있을것은 있으니까는.
무엇보다 장점은
이슈 트랙킹과 요구사항 추적, 작업 관리, 버그 추적의 개념을 가지고 있다는 것과
SCM (소스 관리), CI (빌드 자동화), WIKI(지식 및 문서 공유)를 한번에 다 ALL IN ONE으로 가지고 있다는 것이 마음에 든다.
여기에 플러스해서 채팅과 FORUM도 제공한다. 채팅의 실요성을 잘 모르겠지만 FORUM은 괜찮을듯 하다.
특히나 여러 팀을 운영하는 조직이나 플랫폼이나 라이브러리와 같은 공통 API를 사용하는 경우에 의사 소통 채널로 포럼이 있다는 것은 꽤나 마음에 드는 기능이다.

빌드는 아직까지 ANT만 지원되는 것 같고...
Hudson에 비해서 다양한 옵션도 지원되지 않는다.

JIRA,Hudson,Confluence,Fisheye등을 조합해서 만든 플랫폼에 비해서는 왠지 부족한 느낌...
블로그에 QA 조직에서 사용하시겠다는 분이 있었던것으로 기억하는데
내 생각에는 QA조직 보다는 개발 조직에 유용한 도구가 아닐까 싶다. QA조직에서는 JIRA와 FISHEYE만 가지고도 떡을 칠듯....

좋은 툴임에는 틀림이 없고 쉽게 접근할 수 있을 것 같은데..
왜 자꾸 JIRA등의 툴이 떠오르고 아쉬움이 남는 것일까?
Polarion 멤버들이 만든 툴이라서 더 기대가 남는 것일까?
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 정용승 2008.06.20 10:53  댓글주소  수정/삭제  댓글쓰기

    도큐먼트 관리쪽이 맘에 들긴 하는데 형상관리 연계가 안되더군요.(치명적인 약점)
    말그대로 품질도구라기 보다는 커뮤니케이션 및 작업도구로 보기에 좋을듯 합니다.
    그리고 생각보다 가격이 낮은 편이 아니네요.
    전사QA쪽에서 쓰기에는 이 툴보다는 기능이 좋은 형상관리툴을 프로세스에 맞게 커스터마이징 하기엔 좋을 듯 합니다.
    말씀대로 소형 개발조직이나 소형 프로젝트환경에 쓰기엔 딱이네요.
    일단 좋게 보는건 직관적이고 사용이 너무 쉽다는 것.. 사람들이 워낙에 툴을 안쓸려고 해서 이게 가장 중요하네요.
    버그트래킹쪽도 맘에 듭니다. 커스터마이징이 쉬워서 잘 후리면 테스트도구로도 가능할듯..
    주인장님이 좋은툴 소개시켜주셔서 감사드립니다.

  2. 조대협 2008.06.21 22:35  댓글주소  수정/삭제  댓글쓰기

    어떤 형상 관리를 말씀하시는지?
    본격적인 형상 관리는 안되겠지만
    Subversion이 내장되어 있어 기초적은 SCM 기능은 되는 것으로 알고 있습니다.
    ^^

  3. 정용승 2008.06.23 11:12  댓글주소  수정/삭제  댓글쓰기

    산출물형상관리 쪽입니다. LiveEdit 기능이 좋긴 한데 이쪽기능은 형상관리가 안되서 조금 아깝네요. 작성자는 편하지만 형상관리담당자는 조금 불편할듯 합니다.

  4. 유승우 2008.06.24 02:22  댓글주소  수정/삭제  댓글쓰기

    오 조차장님 안내로 와봤는데요.. 오 알찬글이 많네요
    정대리님이 요청하신 내용은 일단 in-File(Line Check)방식이 아니고 Base Line 기반의 버전 관리면 4.X 대 부터 지원을 했습니다 참고 글 올립니다

    https://codebeamer.com/cb/wiki/11102#section-Using+the+Document+Manager
    요기에서 "Versioning and Access History" 쪽을 보시면 Action 컬럼에 재저장 기능등이 있습니다.

    * Price 정책은 간단합니다. 오픈소스 무료, 6명 개발자 그룹 무료(기능제약) 회사는 유저당 2,000 USD이고 ALM 상요도구 중에서는 가장 저가입니다. 경쟁제품은 Serena ALM / IBM Rational CQ / HP TD / MKS 등이 있습니다. CodeBeamer는 프로젝트엔지니어링에 가장 충실한 도구이고 위키노믹스 철학을 기반으로 만들어진 제품입니다. 요구사항정의해서 이슈나 Tasking 정의 하고 각각의 아이템 기반으로 테스트 케이스를 만들고 이와 코드 Repository View를 연계해서 마지막 빌드 자동화 모니터링까지 전체적으로 쉽게 유기적으로 할수 있는 ALM도구가 많지 않습니다(Polarion이 처음 시도 했는데 느린데다가 SAP NetWeaver를 참고 쓰는 분들만 관심을 갖는 다는...) 또 MS의 SharePoint 를 대체할수 있는 문서관리시스템도 괜찮습니다. 채팅이나 메신저(Peer Review)도 연계 될 계획입니다.

    CB의 가장 큰 장점은 모든 페이지가 위키 스타일 이며 다양한 위키태그를 지원합니다
    https://dev.virtuemart.net/cb/help/wiki.do;jsessionid=D7A481B0384E43809A27961F573CFA0D

    5.3이 곧 나오게 될 텐데요. 관심있으시면 바로 보내 드리도록 하겠습니다

  5. 정용승 2008.06.24 09:34  댓글주소  수정/삭제  댓글쓰기

    흠. Free 버전에서 히스토리기능이 안되서 정식버전에는 아마 되지 않을까 싶었습니다.
    그 내용을 문의했는데 아직은 기능이 없다고 하시길래 좀 의문이였는데 역시 되는군요.
    가격에 대한 생각은 경쟁제품들이 메이저들이라 상대적으로 높게 여겨집니다.
    이정도 기능이라면 개인적으로는 프로젝트에 적용하기에 아주 좋은 제품이라 여겨집니다.
    형상관리 기능만 한번 써봤으면 싶네요.

Hudson을 이용한 빌드와 테스트의 자동화


 

2007-04-04
BEA Systems Korea
Sr consultant Byungwook Cho (bcho@bea.com)

Continuous Integration(점진적 통합,이하 CI)이란, 개발자가 각각 개발한 소스코드를 모아서 한꺼번에 빌드하는 통합 빌드의 과정을 특정 시점이 아니라 매일이나 매주와 같이 아주 잦은 주기로 수행함으로써 통합에서 발생하는 오류와 시간을 줄이기 위한 기법이다.
Extreme Programming Community (XP)에서 애자일 방법론의 일부로 Kent Beck에 의해서 고안된 방법으로 다음과 같은 특징을 가지고 있다.

1. CI의 특징
(1) 소스코드 일관성 유지
CI툴을 설정하기 위해서는 기본적으로 소스 관리 시스템이 필요하다.
대표적인 소스 관리 시스템은 Subversion,CVS,Perforce등이 있다.
CI툴은 이 소스 관리 시스템으로부터 프로젝트 소스의 메인 브랜치(trunk 라고도 한다.) 코드를 Check out 받아서 빌드를 수행한다.

(2) 자동 빌드
소스 코드에 대한 빌드는 CI툴에 의해서 자동적으로 이루어 져야 한다.
빌드가 이루어지는 시점을 정하는 방법이 두가지가 있는데 다음과 같다.

1) 커밋에 따른 자동 빌드
다른 방법으로는 소스코드가 소스 관리 시스템에 커밋이 되었을 때 마다 CI툴이 이를 감지 하고 자동으로 빌드를 수행하도록 설정할 수 있다.
이렇게 설정할 경우 소스 코드의 변경이 있을 때 마다 빌드 작업을 수행하기 때문에 소스 관리 시스템에 저장된 소스 코드에 대한 무결성을 보장하기는 매우 좋지만, 빌드 시간이 길 경우 빌드가 적체 되는 현상이 발생할 수 있다.
(일반적으로 대규모 애플리케이션의 FULL 빌드는 길게는 2~3시간 까지 소요될 수 있다.) 그래서 이 방법은 빌드 시간이 오래 걸리는 경우나 커밋이 자주 발생하는 경우에는 적절하지 않다.

2) 시간 간격에 의한 빌드
일정 시간 간격을 정해서 빌드를 하는 방법이다. 매일 5시에 빌드를 한다. 또는 매주 금요일 저녁 5시에 빌드를 한다는 것과 같이 주기를 정할 수 있다. 빌드 스케쥴이 미리 정해져있기 때문에 개발자들이 커밋에 대한 스케쥴을 관리할 수 있고 빌드 시간이 오래걸리는 대규모 빌드에도 적정하다.
 빌드 시간을 정할 때 중요한 점은 가급적이면 퇴근 시간 1~2시간 전으로 개발자들이 퇴근하기 전 시간으로 여유를 두는 것이 좋다.
이후 빌드가 깨진 경우는 컴파일이 실패하였거나 테스트가 통과하지 못하였을 경우인데 이때 소스 관리 시스템에 저장된 코드는 문제가 있는 코드이다. (빌드가 깨졌기 때문에) 이 코드들을 다른 개발자가 체크아웃 받아서 개발을 했을 때 잘못된 코드로 인해서 잘못된 개발 방향으로 갈 수 가 있기 때문에 빌드가 깨졌을 때는 가급적 빨리 문제를 수정하여 빌드를 정상화 시키고 소스 관리 시스템에 저장되 코드의 무결성을 회복하거나 빌드가 성공한 전버전으로 BACK(Revert) 해서 무결성이 보장된 코드내에서 작업하도록 한다. Revert를 위해서는 소스 관리 시스템에 빌드때마다 Tagging을 해서 무결성이 보장된 버전에 대한 History를 관리해야 한다.

Silent period에 대해서
CI툴에서는 소스 관리 시스템으로부터 소스를 체크아웃 또는 업데이트 받을 때 Silent Period라는 옵션을 제공한다.
개발자가 소스를 커밋하고 있을 때 커밋이 완료되지 않은 상태에서 CI툴이 소스를 체크아웃하게 되면 불완전한 코드가 내려와서 빌드가 망가질 수 있다. 이를 방지하는 옵션이 Silent Period인데, 커밋이 있은후 일정 시간동안 소스 관리 시스템에 변화가 없을 때 CI툴이 체크아웃을 받아서 불완전한 코드를 내려 받을 수 있는 가능성을 최소화 하는 것이다.

이렇게 자동 빌드를 하면서 얻을 수 있는 이점은, 주기적인 빌드를 통해서 소스코드의 무결성 관리와 빅뱅방식의 통합에서 올 수 있는 리스크를 개발과정 전반으로 분산할 수 있다.

(3) 자동 테스팅
빌드 과정에서 테스트를 포함할 수 있는데, 주기적인 빌드 과정에 테스트를 포함해서 자동 빌드를 통한 Syntax에 대한 검증과 더불어 테스팅을 통한 기능과 비기능적(성능등)에 대한 요건을 매번 검증함으로써 코드의 품질에 대한 무결성을 함께 유지한다.

(4) 일일 체크아웃과 빌드
개발자가 출근후 소스 관리 시스템에서 최신 코드를 내려받고, 출근전에 현재 코드를 소스 관리 시스템에 저장함으로써 소스 코드에 대한 무결성을 유지한다.

예를 들어 개발자 A와 개발자 B가 같이 개발을 할 때, 개발자 A가 작성한 모듈을 개발자 B가 참고해서 사용한다고 하자, 이런 경우 개발자 A가 임의로 컴포넌트에 대한 작동 방식이나 인터페이스를 변경했을 때 일일 체크아웃과 빌드를 하면 개발자 A의 모듈을 사용하는 개발자 B의 모듈의 컴파일 오류나 또는 테스트 오류가 발생할 것이고 코드 변경으로 인한 임팩트를 빠르게 발견하여 수정할 수 있다.
그러나 통합 빌드의 과정이 일일이 아니거나 일일 체크아웃 빌드를 하지 않고 일주일이나 한달 단위로 할 경우 일주일동안 개발자 B는 잘못된 코드를 양산할것이고, 그 만큼의 시간 낭비가 발생한다.

일일 체크아웃과 빌드는 이를 방지해주는 역할을 한다.

2.CI 프로세스

CI에 대한 프로세스를 정리해보면 다음과 같다.
 

사용자 삽입 이미지


<그림. Continous Integration Process >


(1) 개발자
1) 개발자는 아침에 출근해서 소스 관리 시스템으로부터 최신 코드를 Checkout 또는 update받는다.
2) 코드를 가지고 개발을 수행하고 테스트를 작성한다.
3) 로컬에서 빌드 및 테스트를 진행한다.
4) 테스트과정에서 커버러지분석과 Code Inspection을 수행한다. (Optional)
 커버리지 분석
커버러지 분석은 테스트의 대상중에 테스트에 해당하는 부분중에 어느 부분이 테스트가 수행이 되었는지를 체크하는 과정이다. 개발 과정에서의 테스트 커버러지 분석은 일반적으로 코드 커버러지로 분석한다.
코드 커버러지란 테스트가 전체 소스 코드중 어느부분을 수행했는지를 검토하는 것이다.
코드 커버러지를 측정할 때 가장 중요한 것은 목표 커버러지율을 결정하는 것이다. 코드 100%를 테스트하는 것이 좋겠지만, Exception,If 문에 대해서 100% 테스트가 불가능하다. 또한 Setter와 Getter만 있는 ValueObject의 경우 테스트를 작성하는 것도 쉽고 테스트 자체가 의미가 없나 Coverate rate는 많이 올릴 수 있다. 만약 커버러지율을 강제적으로 높이고자 하면 개발팀에서 VO등 테스트가 필요하지 않고 테스트가 쉬운곳에만 테스트를 집중할 수 있기 때문에 컴포넌트의 우선순위를 정해서 중요한 컴포넌트에 대해서 커버러지를 관리하는 것이 필요하다.
커버러지율은 잘 만든 테스트라도 50~70% 내외이고, 고 가용성 시스템도 80%를 넘기 힘들기 때문에, 컴포넌트의 중요도별로 목표 커버러지율을 융통성 있게 결정하는 것이 필요하다.
대표적인 오픈소스 도구로는 EMMA와 Cobertura등이 있고, 상용 도구로는 Atlassian社의 Clover등이 있다.
 Code Inspection
Code Inspection이란, 완성된 코드에 대한 검토를 통해서 코드상에 존재하고 있는 잠재적인 문제를 발견하는 과정이다. 흔히 “정적 분석” 이라는 이름으로도 불리는데, 이 과정에서 Deadlock에 대한 검출 Lock contention과 같은 병목 구간에 대한 검출 Memory Leak이나 Connection Leak과 같은 자원 누수에 대한 검출과 코딩 스타일 (변수명이나 메서드명 규칙등)에 대한 가이드를 수행한다.
보통 이런 도구들은 룰 셋을 추가하여 Inspection을 각 팀의 스타일에 맞춰서 Customizing할 수 있으며 대표적인 오픈 소스 도구로는 PMD, FindBugs등이 있다.

5) 완료된 코드를 소스 관리 시스템에 저장한다.
완료된 코드와 테스트를 소스 관리 시스템에 커밋한다.

(2) CI Tools

1) 체크아웃
CI Tools는 정해진 시간이나 소스가 커밋이 되었을 때 등 정책에 따라서 빌드를 시작한다. 먼저 소스 코드를 체크아웃 받는다.
2) 컴파일
체크아웃 받은 코드에 내장되어 있는 빌드 스크립트를 기동하여 컴파일을 수행한다.
3) 배포
컴파일이 완료된 코드를 테스트 서버에 배포한다.
4) 테스트 수행
체크아웃 받은 코드내에 있는 테스트 코드들을 수행하고 리포팅을 한다.
5) 커버러지 분석
테스트 과정중에 코드 커버러지를 수행한다.
커버러지의 기본 원리는 커버러지 분석 대상이 되는 코드내에 커버러지 분석 코드를 삽입하여 테스트가 완료된 후에 그 결과를 수집하여 분석을 하는데 분석 코드를 삽입하는 과정을 Code Instrument라고 한다. Instrumented된 코드는 커버러지 분석 기능으로 인해서 성능 저하를 유발할 수 있기 때문에 만약에 테스트 과정에 성능이나 응답시간에 관련된 테스트가 있을때는 커버러지 분석을 위해서 테스트를 마친후에 Instrument를 다시하여 3),4) 과정을 다시 거쳐서 커버러지 분석을 해야 테스트 과정에서 성능에 대한 요소를 올바르게 추출할 수 있다.
6) Code Inspection
다음으로 Code Inspection을 수행하고 리포트를 생성한다.
7) 소스 태깅
1)~6) 과정이 정상적으로 수행되었을 때, 현재 소스 관리 시스템에 저장된 버전을 안정적인 버전으로 판단하고 소스 관리 시스템에 현재 버전에 대한 이미지를 저장하기 위해서 Tagging을 수행하여 현재 버전을 저장해놓는다.
8) Reverse (Optional)
만약에 빌드나 테스트가 실패하였을때는 이전에 성공한 빌드 버전으로 소스를 롤백하고, 실패의 원인을 파악한후에 다시 커밋한다.
이것은 소스 관리 시스템에 저장된 소스는 문제가 없는 소스를 항상 유지하여 개발자들이 문제가 없는 소스로 작업을 할 수 있게 보장해주며, 릴리즈가 필요한 시기에 언제든지 릴리즈가 가능하도록 지원해준다.
9) 결과 분석
빌드와 테스트가 완료된 후에 테스트 결과서를 통해서 문제가 있는 테스트를 개발자가 수정하도록 하고, Code Inspection결과를 PM이 검토하여 담당 개발자가 수정하도록 한다.
다음으로 Coverage 분석 결과를 통해서 테스트가 부족한 부분은 PM이 담당 개발자에게 지시항 테스트를 보강하도록 한다.

3.Hudson 설치

(1) Hudson의 설치 및 기동


1) https://hudson.dev.java.net/ 에서 hudson을 다운로드 받는다.
2) 다운로드 받은 Hudson.war를 Apache Tomcat에 deploy해서 구동 하거나 도는 java –jar hudson.war로 hudon으르 기동한다. 디폴트로 설치된 hudson은 8080포트를 통해서 접근이 가능하다. (Tomcat을 통해서 설치 하지 않은 경우)

WAS에 인스톨 정보
http://hudson.gotdns.com/wiki/display/HUDSON/Containers

(2) Hudson과 소스 관리 시스템 연동
좌측 메뉴에서 “New Job”을 선택하여 새로운 작업을 등록한다.
Job name을 선택하고 “Build a free-style software project”를 선택한다. 아직까지 다른 빌드 선택은 안정화 되어있지 않기 때문에 이 메뉴를 중심으로 설명한다.
 

사용자 삽입 이미지


<그림 1. 새로운 프로젝트의 생성>

(3) 소스 관리 시스템과 연동
Job이 생성되고 나면 초기화면에서 Job을 선택할 수 있다 Job을 선택하면 좌측에 Configure라는 메뉴가 생기는데, 그 안으로 들어가면 Job에 대한 설정을 할 수 있다.

먼저 소스 관리 시스템으로부터 코드를 내려받도록 설정해야 한다.
“Source Code Management”에서 사용하는 소스 관리 시스템을 선택한다.
이 예제에서는 Subversion을 선택한다.
Subversion을 선택한후 Repository URL에 SVN접근 주소를 입력한다.
svn://source.example.com/trunk 그 아래에 “Local module directory”에 SVN 레파지토리의 하위 디렉토리를 선택한다. “/myproject” 식으로
이렇게 하면 svn://source.example.com/trunk/myproject 에서 소스 코드를 매번 내려받게 된다. Repository URL과 Location을 지정하면 Hudson이 자동으로 SVN에 접속을 시도해본다. 만약에 id와 passwd가 필요한 경우에는 아래 그림과 같이 “enter credential”이라는 링크가 Repository URL 아래 나타나서 id와 passwd를 입력할 수 있게 한다.
 

사용자 삽입 이미지


<그림 2. SVN 접속 정보 입력>
여기에 소스 관리 시스템 연결에 관련해서 몇가지 옵션을 추가할 수 있다.

 Use Update
소스 관리 시스템에서 소스를 내려받을 때 디폴트가 모든 소스를 매번 다운로드 받는것인데 이런 경우에는 소스양이 많을 경우 다운로드에 많은 시간이 소요되서 전체 빌드 시간이 늘어날 수 있다. 이때 “Use Update”라는 옵션을 사용하면 처음에만 소스 코드를 전체 다운로드 받고, 두번째 부터는 변경된 소스 코드만 다운로드 받기 때문에 소스 코드를 다운 받는 시간을 많이 줄일 수 있다. (svn update와 같은 명령)

Repository Browser
Repository Browser란 소스 관리 시스템에 저장된 소스의 내용 웹에서 브라우징할 수 있는 도구이다. 도구에 따라서 이전 버전과 변경된 부분에 대한 Diff비교 또는 처음 소스 코드가 생성되었을 때부터 매번 커밋되었을 때 변경 내용에 대한 Revision등에 대한 모든 히스토리를 출력해준다. 이런 기능은 빌드가 깨졌을 때, 바로 빌드 버전에 대한 소스 변경 내용을 추적하여 누가 어떤 코드를 변경하였는지를 추적하여 가능한한 빠른 시간내에 문제를 해결하게 해준다.
이 옵션을 체크해놓으면 빌드가 완료된후 Job의 Changes를 보면 소스 코드가 변경된 부분에 대해서 Repository Browser로 링크가 걸려서 소스를 웹에서 바로 확인하거나 전버전에서 바뀐 부분을 확인할 수 있다.
대표적인 Repository Browser로는 오픈소스 제품인 Sventon과 상용제품인 Fisheye등이 있다.

(4) 빌드 트리거링
다음 설정해야 하는 부분이 Build Triggers 설정이다.
이 설정은 언제 빌드가 돌아야 하는가를 설정하는 부분으로 3가지 옵션을 제공한다.

1) Build after other projects are built
이 옵션에는 다른 Job(Project)의 이름을 인자로 넣는다.
이렇게 하면 지정된 프로젝트의 빌드가 정상적으로 끝나면 자동으로 이 프로젝트가 Invoke된다. 만약에 빌드만 하는 Job과 테스트만 하는 Job이 있고 테스트는 자주 사용하고 빌드후에 반드시 테스트를 해야할 때, 테스트 Job에서 이 옵션으로 선행작업을 빌드로 해놓으면 빌드를 수행할 때 마다 빌드가 성공하면 테스트를 수행하게 된다. 테스트만 수행하면 빌드와 상관없이 테스트만 수행된다.
이 옵션은 프로젝트 실행의 전후 관계(Chainning)을 하는데 매우 유용하게 사용할 수 있다.

2) Poll SCM
이 옵션을 사용하면 여기에 지정한 주기별로 소스 관리 시스템을 폴링(체크)하여 변경이 있을 경우에만 빌드를 수행한다.
 

사용자 삽입 이미지


<그림 Build Trigger 등록 >

시간 설정 방법은 unix의 crontab 명령과 같은 형식으로 아래와 같은 형식을 사용한다.
분 시간 날짜 월 요일

사용 예는 다음과 같다.
# 매일 12시에 실행
00 12 * * *
# 매주 일요일 1시에 실행
00 01 * * 7
# 매일 12시와 5시에 실행
00 05 * * *
00 12 * * *

3) Build periodically
마지막으로 Build periodically는 정해진 시간 주기별로 소스가 변경과 상관없이 무조건 주기적으로 빌드를 수행하며 Poll SCM과 마찬가지로 crontab과 같은 형식으로 스케쥴을 등록한다.

(5) Build
정해진 스케쥴 정책에 따라 빌드 프로세스가 기동되면 실제 빌드를 수행할 빌드 스크립트가 구동되어야 하는데, Hudson에서는 ANT,MAVEN,그리고 Unix/Windows shell을 수행할 수 있도록 되어 있다. 여기서는 ANT 기반으로 설명을 한다.
 

사용자 삽입 이미지


<그림. Invoke ANT 설정 >

Invoke ANT를 선택 하면 다음과 같은 옵션을 선택할 수 있다.

 ANT Version
Hudson 초기화면에서 “Manage Hudson”메뉴로 들어가면 “System configuration” 메뉴에서 여러 개의 ANT_HOME을 등록할 수 있다.
ANT 버전에 따라서 플러그인이 차이가 날 수 도 있고, 프로젝트에 따라서 사용해야 하는 ANT 버전이 틀릴 수 있기 때문에 여러 개의 ANT를 등록할 수 있게 해준다.
예를 들어 프로젝트가 JUnit 3.8대와 JUnit 4.X대로 각각 구현되어 있다면 ANT에 설치되어야 하는 JUnit 라이브러리 버전이 틀리기 때문에 두개의 ANT를 설정해야 할 수 있다. 이런 경우에 “System configuration”에서 ANT를 여러 개 등록해놓고, 이 ANT Version 메뉴에서 필요한 ANT 버전을 선택하면 된다.

 Target
ANT 스크립트의 Target을 설정한다.

 Build File
ANT 스크립트를 지정한다. 일반적으로 build.xml을 지정한다.

 Properties
ANT 스크립트에 전달해야 하는 Property를 지정한다.
예를 들어 스크립트내에 $workspace라는 변수를 지정하였을 경우 –Dworkspace=값 이런식으로 텍스트 상자에 정의하면 빌드 스크립트로 인자를 전달할 수 있다.

 Java Options
ANT 를 기동하는데 필요한 자바 옵션을 지정한다. ANT도 자바 프로그램이기 때문에 여러가지 JVM 옵션이 지정되는데 Heap,Perm size등을 여기서 –Xmx256m 식으로 지정하여 이 옵션으로 ANT 프로세스를 실행할 수 있다.

여기 까지 설정하면 주기적으로 빌드를 자동화 하는 설정이  완료 되었다.

(6) Hudson의 사용
초기화면에 들어가면 등록된 프로젝트 리스트들이 나온다.
 

사용자 삽입 이미지


초기화면에서는 현재 빌드 상태와 프로젝트별 빌드 성공 실패 여부가 나타난다. 빌드가 성공하면 맑은 태양이 실패율이 높으면 천둥 모양으로 아이콘이 변경이 된다.

초기화면에서 프로젝트를 클릭하면 아래와 같은 화면이 나오는데
 

사용자 삽입 이미지


< 그림, Hudson 프로젝트별 초기화면 >
Changes는 빌드 버전별로 소스 관리 시스템에서 지난 버전에 비해서 변경된 내용 누가 변경했는지 그리고 커밋시에 개발자가 추가한 Comment를 확인할 수 있다.Workspace는 이 프로젝트의 빌드 디렉토리를 보여준다. 브라우져를 통해서 빌드에 사용된 파일등을 확인할 수 있다.
그 아래 메뉴가 “Build Now”인데 이 메뉴는 스케쥴에 상관없이 지금 강제적으로 빌드를 하게 한다.
좌측 맨 아래 메뉴는 BuildHistory로 언제 빌드가 수행되었고 현재 빌드 상태와 빌드 성공 실패 여부를 나타낸다.

(7) Hudson과 Email 연동
Hudson 초기화면에서 Manage Hudson > System Configuration 메뉴에 들어가면 Email-Notification 설정부분이 있는데, 여기 SMTP 서버를 설정해주면 빌드가 실패하였을 때 등에 담당자들에게 메일로 통보를 할 수 있다. SMTP 설정을 한후 프로젝트의 configuration 메뉴에서 Post-build Actions에서 Email Notification에 Receipients에 이메일 주소를 적어놓으면 빌드가 실패했을때와 실패한 빌드가 복구 되었을 때 이메일이 발송된다.
 

사용자 삽입 이미지


<그림. Email Notification 설정 >


(8) JUnit 테스트 연동
CI에 대해서 설명할 때 Test에 대해서 설명했는데, Hudson에서는 JUnit Test Report를 출력해주는 기능을 지원한다.
프로젝트 configuration에서 Post-build actions의 “Publish JUnit test result report” 메뉴에서 JUnit 리포트 파일명을 지정해주면 아래와 같이 테스트가 끝나고 테스트 리포트가 생성되면 테스트 성공 실패 여부를 그래프로 나타내주고, 테스트의 Progress도 누적 그래프로 프로젝트 초기화면에서 출력해준다.

사용자 삽입 이미지


<그림. 프로젝트 초기화면에서 테스트 히스토리에 대한 그래프 > 

사용자 삽입 이미지


<그림. 프로젝트별 테스트 성공 실패 요약 >

이때 주의할점은 JUnit의 테스트 리포트의 파일 경로는 절대 경로가 아니라 프로젝트 Workspace에 대한 상대 경로이기 때문에 상대 경로로 지정해야 한다.

(9) Hudson과 Japex를 이용한 부하 테스트 연동
Japex는 단위 테스트에 대한 부하 테스트를 할 수 있는 단위 부하 테스트 자동화 프레임웍이다. Japex에 대한 사용 방법은 단위 테스트의 “단위 부하 테스트” 부분을 참고하기 바란다.
Japex 역시 JUnit과 마찬가지로 성능에 대한 결과 (테스트 소요 시간)를 그래프로 출력할 수 있다. JUnit과 설정 방법이 같으며 프로젝트 > configuration > Post-build Actions > Record Japex test report에 Japex 테스트 리포트 경로를 추가하면 된다.
 
설정이 제대로 됐으면 테스트 수행후에 왼쪽에 Japex Trends Report라는 메뉴가 생겨서 성능 테스트에 대한 결과를 누적 그래프로 출력해준다.

Japex 테스트 플러그인은 Hudson에 Default로 포함된 것이 아니기 때문에 http://hudson.dev.java.net에서 다운받아서 Hudson에 추가로 설치해줘야 한다.


(10) Hudson과 Cobertura를 이용한 Coverage분석
Coverage 분석에 대해서는 EMMA와 Cobertura, Clover에 대한 확장 플러그인을 제공하는데, 플러그인을 설치한후 JUnit과 Japex와 동일한 방법으로 리포트에 대한 위치를 등록해주면 아래와 같이 커버러지의 누적 그래프를 클래스별,라인별,브랜치별로 출력해준다.
 

사용자 삽입 이미지

(11) 그외의 기능들
본 문서에서는 Hudson에 대한 대략적인 기능을 살펴보았다.
Hudson은 이 이외에도 여러 개의 Hudson 인스턴스를 구성하여 클러스터된 빌드환경을 구축할 수 있다. 여기서 클러스터란 로드분산이나 장애 대응등의 의미가 아니라,
하나의 소스 코드를 가지고 Windows,AIX,HP 버전으로 각각 빌드가 필요할 때, 각 서버에 Hudson을 따로 설치하고 각각 관리하는 것이 아니라 설치는 각각 하더라도 하나의 콘솔화면에서 컨트롤을 하도록 설정이 가능하다.
또한 여러 확장 플러그인을 통해서 기능 확장이 가능하다.

(12) Hudson 사용시 주의할점
Hudson은 이미 JBoss 프로젝트나 기타 상용 프로젝트에서 사용될정도로 매우 널리 쓰이고 안정적인 버전이다. 그럼에도 불구하고 오픈 소스의 한계점과 잦은 업그레이드로 인해서 잠재적인 버그가 있고 특히 플러그인들의 버전이 Hudson의 버전 업그레이드를 쫓아가지 못해서 일부 플러그인들은 하위 버전에서만 작동하고 최신 버전에서 작동하지 않는 경우가 있기 때문에 자신이 사용하고자 하는 플러그인들에 맞는 Hudson 버전을 사용하는 것이 중요하다.
여기서 소개된 플러그인들은 Hudson 1.7 버전을 기준으로 사용 및 검증이 되었다.

4. 그외의 CI Tools
예전에는 CI 툴이 Cruise Control이나 Ant hill이 주류를 이루고 있었으나,
Hudson이 등장하면서 많은 프로젝트들이 쉽고 직관적인 인터페이스와 확장성으로 인해서 많이 사용되고 있다.
TeamCity의 경우 일반 버전은 무료로 제공되며 TeamCity Pro는 상용이다. 무료 버전도 상용 코드를 기반으로 하는 만큼 Hudson에 비해서 높은 안정성을 가지고 있으다.
AntHill Pro 역시 꾸준히 Java 진영의 CI도구로 사용되고 Atlassian의 Bamboo도 근래에 들어 많이 프로젝트에 사용되고 있다.

Hudson을 이용한 빌드와 테스트의 자동화.doc


'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

이클립스 ALF  (0) 2008.08.12
괜찮은 ALM툴  (5) 2008.06.11
Hudson을 이용한 빌드 배포 테스트 자동화  (8) 2008.04.07
플러그인 개발 순서  (0) 2008.04.02
Code Inspection Tools  (0) 2008.02.29
빌드 자동화 업체  (0) 2008.02.12
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 치요 2008.04.21 09:10  댓글주소  수정/삭제  댓글쓰기

    잘 보았습니다
    개인적으로 안좋은일이 좀 있어서 코멘트가 늦었네요(노트북 분실 ㅜ_ㅜ)

    대협님 페이지에서 허드슨을 처음 보고 어느정도 적용해서 현재는 제대로된 프로세스에

    맞추어서 효율적인 관리가 이루어지는것 같습니다 (겉보기에는요 ㅎㅎ)

    그래도 역시 아무리 좋은 프로세스를 도입해도 사람이 문제인것 같습니다

    사용하지 않으면 말짱 꽝이니까요 .

    다음 포스팅은 mylyn을 이용한 이클립스 + CI 연동정도 해주시면 감사히 보겠습니다 ㅎㅎ

    이클립스 하나로 모든게 다 되니 너무 편리하네요

    아 그리고 개인적인 질문입니다만 , svn / mantis(JIRA) / Hudson 이것들의 백업은 어떻게 진

    행하고 계신지 알고 싶습니다. 저희는 정작 이것들에 관한 백업은 들은게 없어서 어리둥절하네





    PS. KSUG 쪽에서 박재성님 께서 TeamCity 강의를 하시더군요. 요새 CI가 대세는 대세 인가봅니다.

  2. 조대협 2008.04.21 10:30  댓글주소  수정/삭제  댓글쓰기

    현재 진행 하는 프로젝트에서는 백업을 모두 플랫폼 관리자에게 일임하였고.
    만약에 필요하시면 SVN은 CRON을 이용해서 매주 전체 백업, 매일 Incremental 백업을
    그리고 이슈 트랙킹은 MySQL 기반이니까는 매일 DB 파일만 백업 받거나 dba에게 일임하셔도 되겠네요.

  3. 머드초보 2008.09.29 10:26  댓글주소  수정/삭제  댓글쓰기

    아하...이 글이 여기가 원조구나-_-;
    저는 다른 곳에서 본 것 같아서 ^^
    저번주 토요일날 발표는 잘 들었습니다^^
    저도 Hudson으로 삽질을 했었는데-_-; 한글인코딩 문제로도 삽질하고 막 그랬었는데 ^^
    좋은 정보 감사해요~^^

  4. 폐인2 2009.05.25 14:02  댓글주소  수정/삭제  댓글쓰기

    감사 감사.. 허드슨에 대해 알고 싶었는데 일목요연하게 정리된 문서를 만나서 정말 좋네요... 좋은글 쓰시느라 수고가 많습니다. 좋은하루 되세요!~

  5. 두마니 2009.09.03 09:01  댓글주소  수정/삭제  댓글쓰기

    조대협 고수님~ 도와주세요
    허드슨과 cobertura를 연동하고 있는데요
    build.xml을 인터넷에서 뒤져서 만들어서 허드슨을 이용해 빌드를 했는데요
    cobertura 결과가 전부 100%가 나옵니다.
    근데 빌드과정에서 생성되는 cobertura의 html과 xml 파일을 열어보면
    html은 cobertura 결과가 생성되어 있는데
    xml은 전부 100%로 생성됩니다.
    즉, html과 xml의 결과가 다르게 나오는거죠
    지금 요것땜에 jdk랑 cobertura랑 junit이랑 버젼벌로 전부 설치도 해봤구여
    일주일째 날밤새고 있습니다...눈도 감기고..머리도 간지럽고..미치고 환장~
    저좀 도와주세요

    제가 설치한 툴의 버전입니다.
    jdk1.6.0_07
    Hudson 1.301
    cobertura 1.9.2
    junit 4.4

    메일주소
    저의 메일주소는 osiosi@empal.com입니다
    고수님의 따스한 가르침을 기다리겠습니다.

  6. 샤샤s 2013.01.29 18:51  댓글주소  수정/삭제  댓글쓰기

    Hudson 처음이라 궁금한게 많았는데
    많이 도움받았내요^^
    혹시 글 퍼가도 괜찮을까요?

  7. 임종대 2014.03.20 22:43  댓글주소  수정/삭제  댓글쓰기

    임베디드 개발만하다가 CI 구성 프로젝트를 맡게 되서....ㅠㅠ 많은도움이 되었습니다.
    현재 Redmine - Jenkins(구hudson) - SVN 연동해서 redmin-hudson plugin 이용하여 redmin에서
    build now 까지는 구성하였습니다. 그외 자잘한 기능들은 모두 확인했는데 위에서 원하는 것이
    redmin -> 일감(issue) 작성시 예약 key값 설정으로 jenkins 예약 빌드가 가능한지 궁금합니다.
    plugin 계속 찾아보고있는데 없는거 같아서요 redmine 코드 자체를 수정해서 사용해야 하는것인지...
    아니면 그러한 기능의 plugin 을 못찾는 것인지 도통 감을 못잡겠네요..
    혹시나 아시는 정보가 있으시면 댓글이나 메일 부탁드려도될까요 ?
    다음주 월요일 시연인데...미치기 직전이네요 ㅠㅠ 부탁드리겠습니다.
    이메일 : XXXXXXXXXXXX

ALM 솔루션

ALM | 2008.03.13 18:39 | Posted by 조대협
ALM이란 Application Lifecycle management로
소프트웨어 개발의 전반적인 관리에 해당하는 내용이다.
즉 요구사항을 수집하고, 일정을 잡고, 작업을 배분하고 릴리즈,테스트,버그관리까지의 전과정을 핸들링 하는것인데..

개발환경 자동화를 하면서 이슈 트랙킹 시스템이 이슈 자체를 관리하는 것은 가능하지만 요구사항에서부터의 추적이나 스케쥴 관리에 있어서 문제가 있었다.

그래서 ALM쪽을 살펴보는데
역시 요즘은 Agile이 강세다.
그런데 웃긴것중에 하나... 국내 사이트에서 애자일을 검색해보면 애자일이 어쩌고 저쩌고 하는 사람들은 많은데.. 정작 프로세스를 정립하는 것은 툴하나 없이 액셀 시트가 어쩌고 저쩌고 포스트잇이 어쩌고?
어이가 없어서...

엔터프라이즈 시스템 그렇게 만들고 감리를 어떻게 받을것이며 고객에게 어떻게 보고를 할것인지? 애자일하게... 서로 갈구지 말라? 아니면 고객과 짝 프로그래밍을 할까?
회고도 좋고 애자일도 좋은데... 실용적인 애자일을 하자고...
엔터프라이즈가 무겁네 마네가 아니라... 입으로만 떠드는게 아니라 실용적이고 적당히 가벼운 절차가 필요하다고

오픈 소스로 XPlanner를 테스트해봤는데.. 개념은 마음에 들지만.. 기능이 놀랄만큼 간단하다... 팀에서 간략한 일정 관리로는 가능하겠지만 이슈 관리로는 과연...

상용도구로는
http://www.polarion.com/index.php
VersionOne
RallyDev
등이 있는데..

이슈 트랙킹과 연동성 여부는 좀더 고민해야할듯...

아직 입맛에 딱 맛는것이 없네 그랴..

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요