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


Archive»


 
 

오랜만에 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  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

Selenium (UI 테스트 자동화)

ALM/Test Automation | 2009.02.09 12:46 | Posted by 조대협
UI 테스트 프레임웍이다.
강규영님의 강좌 동영상을 보니까는, Fire Fox에 화면 Recorder까지 나와서 상당히 현실적으로 쉽게 테스트 케이스를 만들 수 있을것 같고..
무엇보다 테스트 스크립트 자체가 Meaningful 하기 때문에, 스크립트가 테스트케이스가 될 수 있다.

그런데 요즘 이상하게 프로젝트 할때 UI테스트할일이 없어진다.
Integration성 프로젝트만 해서 그런지.. 아니면 요즘 RIA CLIENT가 많아서 그런지...
Enterprise System에서는 Pure HTML로 된 페이지를 보기가 힘든것 같다.

'ALM > Test Automation' 카테고리의 다른 글

Software Testing Proces  (0) 2009.04.09
Cloud 컴퓨팅을 이용한 대용량 Selenium 테스트  (0) 2009.02.18
Selenium (UI 테스트 자동화)  (1) 2009.02.09
EasyMock을 이용한 단위 테스트  (5) 2008.11.07
테스트 자동화 도구들  (0) 2008.08.07
Junit best practices  (0) 2008.03.12
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG Selenium, test

댓글을 달아 주세요

  1. kenu 2009.02.09 23:03  댓글주소  수정/삭제  댓글쓰기

    간단히 테스트하고 있는데, pause, waitForTextPresent 등 Ajax에도 유용한 것들이 많이 있더군요.

Scrum 지원 도구

ALM/Task Management | 2009.01.29 18:23 | Posted by 조대협

  • Version One (Saas와 Windows 기반 PKG모두 지원)
  • Rally Enterprise (Saas)
  • BaseCamp
  • Scrumworks 이 제품은 Scrum 개념을 아주 충실하게 지원함

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

댓글을 달아 주세요

오랜만에 지방 출장

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 Concept

ALM | 2008.12.24 10:34 | Posted by 조대협
제 블로그에 자주 오시는 분들이나 혹은 강연이나 기고를 보신분들은 아시겠지만
2008년 한해는 ALM (Application Lifecycle Management)쪽에 많은 시간을 할애한 한 해였습니다.
CI(Contiguous Integration), Unit Test,실용주의 방법론이 유행한 한해이기 때문에, 유난히 관련 서적을 많이 접했던 이유도 있지만 컨설턴트로써 프로젝트 관리와 소프트웨어 품질 관리에 대한 필요성이 많았기에 많은 시간을 부었습니다.

ALM에 대해서 시간이 나는데로 좀더 정리를 해보고자 합니다.

제가 이야기 하는 ALM은 기존의 어떤 방법론이나 사상은 아닙니다. 프로젝트를 하면서 필요하다고 생각되는 부분을 묶어서 정리한 하나의 간단한 방법론 정도로 생각하면 됩니다.
ALM은 크게 3가지 모듈로 구성됩니다.

프로젝트 관리와, 빌드 환경 그리고 테스트 환경입니다.
프로젝트 관리는 JIRA와 같은 이슈 트랙킹 시스템으로 프로젝트에서 발생되는 모든 작업을 기술하고 리소스와 시간(개발자와 스케쥴)을 관리하는 방법을 기술합니다. 특히 각 이슈간의 연관 관계를 기술함으로써 추적성을 부여하는 것인데 예를 들어 고객의 요건이나 시나리오가 실제 코드까지 어떻게 반영되는지에 대한 추적성을 부여합니다. 지금까지 (K*,하*,소*,S*)등 약 4개 사이트에 프로젝트를 하면서 적용을 해봤고 장단점과 문제점에 대해서 보강을 하면서 성숙 시켜온 방법입니다.

빌드 환경은 개발자 IDE와 특히 지속적 통합(CI)를 통하여 빅뱅식 통합에서 오는 문제를 없애고 좀더 Agile한 접근방법으로 개발환경을 셋업할 수 있는 방법에 대해서 가이드 하고 있습니다. 이 내용 안에는 빌드 스크립트에 대한 작성 방법, 개발자의 표준 개발환경 구성 방법 및 Subversion과 같은 SCM도구를 이용한 Configuration management와 branch 관리 전략에 대해서 기술합니다.

마지막으로 Test Automation은 단위 테스트 자동화뿐만 아니라, V-Model에 기초한, 단위테스트,통합테스트,시스템 테스트,사용자 인수 테스트에 대해서 폭넓게 이야기 하고 있으며, 실제 구현 방법 및 전략에 대해서 기술하고 있습니다. 특히 테스트가 시스템의 품질을 검증하는 것이라면, 커버러지 분석 기법과, 코드 복잡도 분석기법, Risk 기반 테스팅 방법 이론을 기반으로 테스트 자체의 품질을 검증하는 방법을 기술합니다.

앞으로는 협업에 대한 부분을 추가해볼 예정입니다. 위의 방법론이 시스템을 통하여 최소한의 품질 수준을 끌어올리는 것이라면, 의사 소통과 협업을 통해서 최대한의 품질 수준을 올리는 방법에 대해서 추가할 예정입니다. Wiki나 Forum을 이용한 시스템 그리고 팀내의 의사 소통 방법과, 페어 프로그래밍, 코드 리뷰 방법에 대해서 기술해볼 예정입니다. 금년에 코드리뷰냐 위키 사용은 몇몇 프로젝트에서 진행해봤지만 시스템이 아니라 사람과 해야 하는 일이기 때문에 더욱 어려운것 같습니다.

Collaboration (협업)


'ALM' 카테고리의 다른 글

오랜만에 지방 출장  (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
9/20 devmento에서 발표한 빌드 배포 및 테스트 자동화에 대한 자료  (4) 2008.09.29
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

EasyMock을 이용한 단위 테스트

ALM/Test Automation | 2008.11.07 18:06 | Posted by 조대협

 

Unit Test with Easy Mock

자바스터디 조대협(bwcho75@지메일.컴)

 단위 테스트는 소프트웨어 구성 요소의 각 컴포넌트를 독립된 환경에서 테스트 하는 것이다. 그렇지만 일반적으로 소프트웨어 컴포넌트는 혼자서 동작할 수 없고 다른 컴포넌트에 대해서 종속성(Dependency)를 가지고 있기 때문에 종속관계에 있는 컴포넌트가 완성되지 않거나 그 컴포넌트에 오류가 있으면 정상적으로 테스트를 진행할 수 없다.

이 문서를 읽기 전에 먼저 Junit 테스트에 대해서 숙지하기 바란다.
http://bcho.tistory.com/entry/단위-테스트-1회-JUnit

이런 문제를 해결하기 위해서 사용하는 것이 Mock Object 이다. Mock Object는 가상 오브젝트로 테스트를 위한 Operation만을 구현하여 테스트에 사용할 수 있다. 

이러한 Mock Object를 POJO (Plain Old Java Object)로 만들어서 직접 구현할 수 있지만 이러한 경우 모든 Interface를 구현해야 하고, 테스트 케이스가 해당 Mock Object에 대해서 종속성을 가지게 되며, 시나리오에 따라서 Mock Object를 따로 작성해야 하기 때문에 효율성이 떨어진다. 

이러한 문제를 해결하기 위해서 고안된 프레임웍이 EasyMock이라는 테스팅 프레임웍이다. 이 프레임웍은 Junit 3.8X와 4.X와 함께 사용되어 단위테스트에서 Mock Object 생성을 지원한다. 내부적으로 EasyMock은 Java의 Reflection을 이용하여 단위테스트 Runtime에서 가상 객체와 그 객체의 메서드를 생성하여 준다. 

1.       다운 로드 받기

http://www.easymock.org에서 easymock 2.4 를 다운로드 받는다.압축을 풀면 easymock.jar가 나온다. 이 파일을 이클립스 프로젝트내에 클래스 패스에 추가한다.

2.       클래스 작성

작성할 클래스는 RunCaculator라는 클래스로 두개의 메서드를 가지고 있다.

Ø         doSum 메서드는 Caculator라는 클래스를 호출하여 a,b 두개의 값을 더해서 리턴을 한다.

Ø         sayHello  메서드는 Caculator 클래스를 호출하여 입력받은 문자열을 출력한다.

package bcho.easymock.sample;

 

public class RunCaculator {

        Caculator cal;       

        public void setCal(Caculator cal) {

               this.cal = cal;

        }

         // return sum of a and b

        public int doSum(int a,int b){

              System.out.println("## summing "+a+"+"+b+"="+ cal.sum(a, b) ); 

               return cal.sum(a, b);

        }

        // echo string to console

        public void sayHello(String str){

               cal.echo(str);

        }

}

 3.       종속된 인터페이스 작성

Caculator 인터페이스는 두개의 메서드를 가지고 있다.

package bcho.easymock.sample;

public interface Caculator {

        public int sum(int a,int b);

        public void echo(String echo);

}

 Ø         A,B 두개의 값을 더해서 리턴하는 sum 메서드와

Ø         입력 받은 문자열을 화면으로 출력하는 echo 라는 메서드

4.       테스트 케이스 작성

테스트를 하고자 하는 클래스 RunCaculator는 이미 완성되어 있다. 그러나 이 클래스가 사용하는 인터페이스 Caculator에 대한 Implement Class가 없다. 이 Caculator에 대한 클래스를 EasyMock을 이용해서 Simulation 해볼것이다.

Mock Object의 사용 순서는 간단하다.

Ø         Mock Object를 생성한다.

Ø         Mock Object가 해야 하는 행동을 녹화한다. (record)

Ø         Mock Object의 행동을 수행하도록 한다. (replay)

Ø         테스트를 수행한다.

예를 통해서 살펴보자.
EasyMock 을 사용하기 위해서 easymock 정적 메서드들을 아래와 같이 Import 한다.

import static org.easymock.EasyMock.aryEq;
import static org.easymock.EasyMock.createMock;
import static org.easymock.EasyMock.expect;
import static org.easymock.EasyMock.expectLastCall;
import static org.easymock.EasyMock.replay;
import static org.easymock.EasyMock.verify;

 테스트 케이스의 Set up에서 테스트를 할 객체를 생성하고 Mock object를 createMock 메서드를 이용해서 생성한다. 이때 인자는 생성하고자 하는 가상 객체의 클래스명(인터페이스명)을 주면 된다. 

public class CaculatorTest extends TestCase {

        Caculator mock;
        RunCaculator runner;
        protected void setUp() throws Exception {

               mock = createMock(Caculator.class);   // create Mock Object
               runner = new RunCaculator();
               runner.setCal(mock);
               super.setUp();
        }

 

먼저 Mock Object의 행동을 recording해야 하는데,

mock.메서드

로 정의하면 해당 행동이 recording 된다. 만약에 리턴값이 있을때에는

expect(mock.메서드).andReturn(리턴값)

식으로 정의하면된다.

예제를 보고 정리하면 앞으로 불릴 Mock object는 sum(1,2)라는 메서드가 호출될것이고 그에 대해서 리턴값을 3을 리턴한것이다. 라고 정의하는 것이다. sum(1,2)가 아닌 다른 인자로 호출이 되면 미리 레코딩 된 행동이 아니기 때문에 에러가 날것이고 마찬가지로 sum(1,2)가 호출되더라도 1회 초과로 호출되면 이 역시 예상된 행동이 아니기 때문에 에러가 발생된다.

 

        public void testDoSum() {
               expect(mock.sum(1,2)).andReturn(3);   // record mock action
               replay(mock);                         // replay mock          

               this.assertEquals(3,runner.doSum(1,2));              

               verify(mock);
        }

 아래의 예는 일부로 에러를 발생 시킨 경우인데 echo(Hello) 메서드가 한번만 호출되기로 되어 있었는데, 아래 테스트 케이스를 보면 echo(Hello)가 연속으로 두번 호출 된후 echo(Hello bcho)가 한번 호출되기 때문에 에러가 발생된다.

        public void testSayHello() {
               mock.echo("Hello");
               replay(mock);
               runner.sayHello("Hello");
               runner.sayHello("Hello");
               runner.sayHello("Hello bcho");
               verify(mock);

       }

 


 

 

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

댓글을 달아 주세요

  1. 지나가던.. 2008.11.08 17:23  댓글주소  수정/삭제  댓글쓰기

    XXmock류의 프레임웍은 간단히 쓰기엔 좋으나 빡세고 다양한 기능이 필요한 경우에는
    날로(...)짜는게 좋습니다...spring 내부 테스트쪽 코드를 보면 http servlet쪽 테스트에 필요한 mock object들은 날로 구현되어 있지요.
    그냥 두가지 방법을 다 써야 한다는 잡담이었습니다 ^_______^

  2. 초보자.. 2009.02.11 00:52  댓글주소  수정/삭제  댓글쓰기

    안녕하세요^^ 조대협님께서 작성한 포스트를 통해 Mock객체가 어떻게 쓰이는지
    아~~주 확실히 알게됐답니다~ 너무너무, 진심으로 감사드립니다^^

    그런데요.. 위에 올리신 예제 JUnit으로 테스트하면 testDoSum메소드도 exception이 나던데요,

    RunCaculator의 doSum메소드 안에서 Caculator객체의 sum메소드가 두번 호출되기때문에 JUnit테스트 시 에러가 나네요^^; testDoSum메소드에서 expect(mock.sum(1,2)).andReturn(3);를 두번 써줘야 하는게 아닌지요?

  3. Steven J.S Min 2013.02.26 12:48 신고  댓글주소  수정/삭제  댓글쓰기

    자료 잘 읽고 갑니다.. 혹시 호주에서 일하시는지요 ??? 링크에 호주 잡서치가 있어서...저도 호주에서 서식하고 있거든요...BTW G'LUCK!

  4. Hyomini 2019.01.19 17:18  댓글주소  수정/삭제  댓글쓰기

    좋은 정보 감사합니다!

JIRA 클라이언트

ALM/JIRA | 2008.11.07 14:40 | Posted by 조대협
Mylyn을 이용해서 이클립스 상에서 JIRA를 웹 인터페이스가 아닌 클라이언트 인터페이스로 사용할 수 는 있지만 부족한 느낌이 많았다. 그래서 사실 사용도 안했고
오늘 다른것 찾던중에 JIRA 전용 클라이언트를 발견... 가격도 그리 비싼거 같지 않고.


뷰가 마치 아웃룩 같다. Polarion 등에서 이런 뷰를 제공하는게 부러웠는데.. 더 이상 부러울것이 없는듯. 아직 사용은 못해봤는데.. 웹보다 편할지 아닐지는 써봐야 할거 같고. 보기에는 일단 마음에는 든다.

http://almworks.com

ALM 솔루션,빌드 자동화, 테스트 모두 모아서 조합해놓고.. 판매하고 컨설팅하는 회사나 하나 차릴까? 솔루션 컨설팅하면서 할려니 정말 깊게 볼 시간이 없네.. 그랴..


'ALM > JIRA' 카테고리의 다른 글

Atlassian JIRA를 이용한 애자일 Scrum 프로젝트 관리  (15) 2013.12.20
JIRA 클라이언트  (0) 2008.11.07
Atlassian JIRA를 이용한 프로젝트 관리 (기초편)  (0) 2008.04.04
JIRA와 SVN 연동  (1) 2008.03.03
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

재미있는 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  댓글주소  수정/삭제  댓글쓰기

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

 회의를 하면서 느끼는 건데..
특히나 요구사항과 관련된 회의 등에는 요구 사항은 많이 나오는데 정리가 안되거나 나중에 실제 해야할일들이 누락되서 낭패를 당하는 경우가 많다.

회의록을 정리하는 기법이다.

1. 회의 내용 기록하기
구글 DOC을 이용해서 실시간으로 회의 참여자들이 회의 내용을 기록한다. 이때 누가 어떤 이야기를 했다는 것 정도는 기록되는 것이 좋다.
Terry/HP@Byungwook/Oracle :....
HP의 Terry가 Oracle의 Byungwook에게 ... 런 이야기를 했다.
이런식으로  정리하고 가능하면 회의록에 요점을 정리하거나 ACTION ITEM을 뽑는것도 방법이된다.

2. Action Item 추출
회의가 끝난후에 회의 내용을 정리해서 해야할일들을 Action Item으로 정리한다. 각 Action item 아래에 회의에서 오갔던 내용들을 Copy & Paste해서 붙여 넣는다.

3. Action Item 검증
팀장이나 또는 의사 결정자가 Action Item을 Review하여 실제로 수행해야할 Action Item들만 추출한다.

4. Issue로 등록
Issue Tracking 시스템이 있다면 Issue Tracking 시스템에 각 Action Item을 등록하거나 또는 Excel 장표로 정리한다.

5. Action Item과 Issue Mapping
Issue #를 회의록에 Action Item #와 맵핑 시켜서 기록해놓는다.
이렇게 해서 추후에 고객이 요청했던 내용의 진행 내용을 Full 로 Trace할 수 있다.

6. 고객에게 회의록 전달
Google Doc에 정리된 회의록을 MS-WORD로 Export한 후, 고객 회의록 포맷에 맞춰서 고객에게 전달한다.

아래는 위의 프로세스를 정리해놓은 그림이다.


 

사용자 삽입 이미지

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

댓글을 달아 주세요

  1. Roess 2008.09.25 18:02 신고  댓글주소  수정/삭제  댓글쓰기

    매우 좋은 방침이고 저도 저렇게 신속한 절차로 모든 회의를 이끌려고 노력합니다만, 1단계에서 항상 문제가 생깁니다.
    구두로 발언을 함과 동시에 누군가(또는 모든 사람이) 그걸 '써서 기록한다'는 것이 회의 리듬과 의식의 흐름을 많이 방해하더라구요. 회의에서 발언이 오고가는 '합'에도 기세가 있는데 말이지요 ^^. 모든 사람이 머리와 손이 동시에 바빠 멍하게 되는 걸 방지하기 위해 한 사람에게 서기를 집중시키면 그 사람이 '심각하게' 멍해지구요. 회의 전체 차원에서는 한 사람 분량의 지능을 잃게 되는 것이지요. 그렇다고 발언 사이사이에 기록을 위해 시간을 두면 안 그럴때보다 회의 시간 길어지고.
    요즘은 그래서 발언 자체가 기록이 되도록 음성을 데이터화하여 이용하는 방법이 없을까 생각중입니다만, 마이크가 들이대져 있으면 사람들은 더 멍해질까요? ㅎㅎ
    아무튼 훌륭하신 여러 회사의 여러 인력과 같이 이런 시도 하에 회의를 진행해보지만 1단계 문제는 항상 어렵습니다. 이런걸 해결할 수 있는 디지털 솔루션이 만들어지면 좋을텐데요!

  2. 놀새~ 2008.09.26 13:21  댓글주소  수정/삭제  댓글쓰기

    개인적인 경험에 의하면 mindmap software를 이용하는 것이 Roess님이 말씀하는 부분까지 해결할 수 있는 방법이었네요. 회의가 진행될수록 점점 가시화가 되어갈 수 있었던 경험을 가지고 있어요.

  3. kenu허광남 2008.09.29 01:01 신고  댓글주소  수정/삭제  댓글쓰기

    표기 관례상 @는 at 의미로 많이 쓰이기 때문에 Terry/HP@Byungwook/Oracle 보다는
    Terry@HP/Byungwook@Oracle :.... 이게 더 자연스러워 보입니다.

작년에 ALM에 대한 research를 하면서 관심 분야가
프로젝트 관리와 테스팅쪽으로 많이 옮겨왔다.

요즘 하는 프로젝트에서 캐나다 출신 컨설턴트와 일을 하고 있는데..
예전에 고민했던것중 하나가 프로젝트 관리를 어떻게 시스템화 할것인가?? 가 하나의 과제였다.
그 대안이 JIRA나 WIKI등을 이용한 방법이었는데.
이친구는 새로운 접근 방법을 사용하더라..

그 방법이 Google Application인데.
나열해보면 아래와 같다.

1. Google Groups
메일링 그룹을 설정하는 기능이다. 간단하지만 막상 프로젝트 들어가면 꼭 필요한것이 메일링 그룹인데. 서버 관리자에게 부탁하기도 어렵고.. 또는 Outlook을 사용하자니 혼자만 되는데.. 깔끔하게 고민을 해결해준다.

2. Google Calendar
말 그대로 간단한 달력인데. 재미있는 것이 사용자간에 Share가 된다. 내가 만든 일정을 팀원이 공유할 수 있고 참석자도 설정할 수 있다는 것. Outlook에는 당연히 있는 기능이지만 프로젝트 나가는 곳에는 Outlook이 안되는 상황이 많기 때문에 제법 유용하게 사용된다.

3. Google Doc
역시 Google이다 할만한 작품인데.
단순하게 MS-WORD를 웹상에서 한다고 생각하면 된다. 단!!! 재미있는 것이
동시에 여러명이 하나의 문서를 편집할 수 있다는 것. 고로 문서에 대한 협업이 가능하고 이 문서는 사용자간 공유가 가능하기 때문에 산출물을 어디에 저장할 것인지 그리고 서로 SYNC가 안맞는 문제가 단박에 해결된다. History기능도 있기 때문에 잘못된 문서를 저장하는 것도 rollback하는 것도 물론이고~~
그리고 MS-WORD로 Export/Import가 자유롭기 때문에 나중에 산출물로 제출하는 것도 가능하다.

일반 Document뿐만 아니라 회의중에 회의록을 작성하는 것에도 유용하게 사용되는데.
프로젝트 특성상 외국인은 많은데 발표나 회의가 한글로 진행되는 경우 Google doc을 열어놓고 서로 실시간으로 회의 내용을 영어로 적어서 공유하고 필요한 내용도 Comment를 달아 놓으니.. 진짜 효율적이다.
Word process뿐만 아니라 spread sheet(Excel), Presentation tool(PPT)도 지원한다.

4. Google Team Site
 이게 정말 물건인데. 간단하게 생각하면 위키 같은 개념으로 Customization이 가능한것이라고 생각하면 된다. 그중에서도 좀더 프로젝트 관리에 가까운 툴인데.
위에 모든것들을 여기에 모아 놓는다. Caledar를 여기에 놓고
MS-WORD와 같은 산출물들을 Shared File 폴더를 만들어서 보관한다. (같은 이름으로 파일을 계속 올리면 자동으로 Versioning이 되고, 마찬가지로 rollback도 가능하다.)

Google doc에 대한 문서 리스트도 링크 시켜 놓으면 최근에 업데이트된 내용을 Dashboard에서 확인할 수 있도록 되어 있다.

Google Ap 기반으로 프로젝트를 관리하면 좋은 점이... 초기에 설치에 대한 비용이 필요없다는 것이고 Google 답게 사용하기가 쉽기 때문에 Learning curve에 드는 cost가 매우 적어서 프로젝트 제반 환경 설정이 매우 신속하다는 것이다.

지금도 프로젝트를 하면서 계속 좀 더 최적화 시켜나가고는 있는데, 나중에 하나의 툴킷으로 만들어서 사용해보도록 해야겠다...

쓰면서 느낀것이.. 역쉬 구글이다.. 그리고 비싼돈 받는 컨설턴트는 모가 달라도 다르구나...
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 열이아빠 2008.09.25 16:16  댓글주소  수정/삭제  댓글쓰기

    각각은 알고 있던것들이지만 이렇게 조합을 해보니
    또 새로운 느낌이네요.
    매번 회의하고 회의록을 메일로 날리는 낡은 습관은 버려야겠죠..ㅎㅎ

  2. 남종환 2008.09.25 16:17  댓글주소  수정/삭제  댓글쓰기

    말씀해주시는 정보들이 큰 도움이 되고 있습니다
    감사합니다

    지금 일본에서 일하고 있습니다
    아예 물리적으로 독립된 곳에
    프로젝트 관련 산출물들을 관리하고 있습니다

    구글을 베이스로 프로젝트를 관리할 경우의
    단점에 대해서는 어떻게 생각하시는지 궁금합니다

    짧은 생각으로는 기업내 정보를 오픈된 구글에 보관하였을 경우
    보안이 가장 걸림돌이 되지 않을까 생각되는데요...
    그에 해당하는 해결책이 이미 있으니
    운용하고 있지 않을까 하는 생각도 드네요

    • 조대협 2008.09.25 17:32 신고  댓글주소  수정/삭제

      저도 보안이 제일 문제인것 같습니다.
      그래서 그런 경우에는 개인적으로는 JIRA와 Confluence Wiki를 이용하는 것을 선호합니다..
      Google AP의 경우 이런 프로젝트 환경 (PPMS라고 하나요?)을 셋업하는 시간과 Learining curve에 대한 cost가 높을때는 사용하면 좋을것 같습니다.

  3. 조정래 2008.09.25 16:19  댓글주소  수정/삭제  댓글쓰기

    Google Calendar - 일정에 맞게 무료 문자로 알려주는 서비스가 한국에서도 제공된다는 것도 강추할 만 하죠!

  4. 놀새~ 2008.09.26 13:25  댓글주소  수정/삭제  댓글쓰기

    지금 내부에서도 구글 관련 서비스를 이용하고 있는데 보안 성격이 강한 것들에 대해서는 모두 atlassian으로 관리중이에요. 구글의 다른 것들도 한번 살펴봐야겠네요..

    • 조대협 2008.09.26 14:01  댓글주소  수정/삭제

      http://www.zoho.com 이것도 보세요. 구글보다 더 강력한 기능들을 제공합니다.

  5. kenu 2008.09.27 09:17  댓글주소  수정/삭제  댓글쓰기

    구글앱을 사용할 때의 가장 기본적이고 중요한 이슈 중 하나는 기업의 정보에 대한 외부 시스템 의존입니다. 가장 근원이 되는 정보보안에 대한 신뢰가 보장이 되어야 사용할 수 있는 서비스입니다.
    세일즈포스닷컴의 CRM서비스와 연동이 되어서 유료로 서비스를 하는 것을 보면 우리 나라를 제외하고 미국 등지에서는 이 신뢰감이 형성된 것 같습니다.

  6. jerry 2008.09.28 12:18  댓글주소  수정/삭제  댓글쓰기

    구글 캘린더는 우리 팀에서도 사용하기로 했는데...
    문제는 이런 툴이 한 번 쓰기 시작하면 다른 툴로 마이그레이션이 거의 불가능해서
    (물론 이론적으론 가능하지만...)
    선택이 항상 고민이넹 ㅡ.ㅡ;;

  7. lovemaeng 2008.09.30 11:52  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 올려주신 내용들, 정리 잘 해 주신 것 같아 감사합니다.
    저는 구글 캘린더만 쓰고 있는데, 이유는 (1)정보 보안 중 가장 약 보안성, (2) 아웃룩으로 싱크가 되고, 피차 공유가 되기 때문에 이 중에는 현 상황에서 가장 유용하다고 판단됩니다.
    구글 Apps들 어케하면 잘 쓸 수 있을지 저도 요즘 설레설레 고민 중입니다.
    좋은 정보 많이 공유해주세요. 감사합니다.

  8. Kris 2008.11.05 16:37  댓글주소  수정/삭제  댓글쓰기

    와.. 이런 조합 죽이는데?? ㅎㅎ

첫 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  댓글주소  수정/삭제  댓글쓰기

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

Code Complexity 측정 도구

ALM/Task Management | 2008.08.12 01:13 | Posted by 조대협
LOC계산과 Cyclomatic complexity를 계산해준다는 툴인데..
쓸만 할려나?
http://www.geocities.com/sivaram_subr/codeanalyzer/description.htm
물론 꽁짜툴!!

Cyvis
http://cyvis.sourceforge.net/screenshoots.html

이것 괜찮다. JAVA 기반으로 Cyclomatic complexity 계산도 해주고 ANT TASK 지원은 물론이고
결과를 XML이나 HTML로 Generate 해준다.
Test Coverage이나 Complexity vs Defect 비율 계산에 유용할듯


http://www.onjava.com/pub/a/onjava/2004/06/16/ccunittest.html
Code complexity 분석을 통한 코드 향상 기법
여기 보니 PMD로도 Complexity 분석이 가능하다

그리고 여기에도 흥미로운 툴들이 많다. 이클립스 기반의 도구들
http://linuxne.springnote.com/pages/1460384
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

국내에서도 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, 실루엣

댓글을 달아 주세요