Friday, August 21, 2009

애자일 개발 방봅을 따른다면, 팀은 보통 고정된 시간을 갖는 반복되는 개발 주기를 정하고 각각의 주기에 작업들을 할당한다. 따라서 누군가는 모든 개발자들에게 개발 주기 종료일까지 얼마만큼의 가용 시간이 있고, 또 할 일들은 어느 정도 남아 있는지를 알려줄 필요가 있다. 애자일 플래닝 툴은 남아 있는 작업 항목들의 예측 시간과, 당신이 개발 주기 내에 일할 수 있는 시간을 기반으로 이 정보를 계산해준다.

부하량(Load) 은 앞으로 가용한 업무 시간과 남아 있는 작업들의 예상 소요시간에 대한 정보이다. 이렇게 생각하면 간단하다. '남은 시간 동안, 이번 개발 주기에 내게 할당된 일들을 다 끝낼 수 있을까?' 이 부하량 정보는 팀 멤버중 누구에게 부하가 걸려있는지를 빠르고 쉽게 알려주므로 결함 선별 과정에서 반드시 참조되어야 하는 자료 중 하나이다. (역자주: 결함 선별 과정에 대한 정보는 여기를.. (중요) Bug Triage Meeting - Severity & Priority )
진척도(Progress) 는 남은 일뿐 아니라, 완료된 일들까지 함께 고려된다. 간단히 완료된 작업과 남은 일들의 비율로, 이렇게 읽으면 될 것 같다. '이번 개발 주기의 모든 일들을 고려해볼 때, 나는 지금 어디쯤 온 걸까?' 지난 일들과 남은 일들의 시간 기록이 잘 되어 있다면 진척도는 앞으로의 진행까지 예측해준다. 기본 가정은 지금까지 완료한 작업 속도와 동일한 속도로 앞으로도 일을 처리한다는 것이다. 그래서 만약 당신이 3시간 예상한 일을 9시간 만에 끝냈다면, 남은 일들도 예상치보다 3배씩 더 오래 걸릴 것이라 가정한다. 이렇게 계산된 값이 당신의 가용 작업 시간보다 작다면 당신은 스케줄을 앞지르고 있는 것이고, 더 크다면 뒤쳐진다는 뜻이다.

아래 그림들은 부하량 막대와 진척도 막대이다. 막대 아래의 레이블(Load vs. Progress)과 그 내용을 보면 어떤 막대인지 쉽게 구분할 수 있다.

부하량(Load) 막대
	총 가용한 104 시간 중 18 시간 만큼의 업무가 할당되어 있다. 레이블과 흰색 부분이 아직 86 시간 치의 가용 시간이 남아 있음을 알려준다.
	남은 작업량이 가용한 업무 시간을 초과하고 있다. 총 137 시간치 작업이 할당되어 있으나, 가용 시간은 104 시간뿐이다. 초과 할당된 33 시간이 레이블과 붉은 막대로 표시된다.
진척도(Progress) 막대
	총 219 시간의 작업들 중 48 시간치가 완료되었음을 보여준다. 예상 정보는 나타나지 않고 있다.
	예상 정보를 함께 보여주는 진척도 막대이다. 총 80 시간의 작업량 중 45 시간치를 완료했으며, 이번 개발 주기에서 예상보다 빠른 페이스를 보이고 있다. 밝은 녹색 부분이 목표치보다 앞서 있다는 것을 나타낸다.
	5 시간만큼 뒤쳐져 있다. 21 시간의 업무량 중 4 시간 분량을 완료했다. 하지만 총 9 시간치의 일을 완료했어야 하는 시점이라 남은 부분이 붉은 색으로 칠해져있다.

Why accumulating Estimates and not counting Work Items?

작업의 기준으로 작업 항목의 숫자 대신 예측 시간을 사용하고 있는데, 다음과 같은 장점 때문이다.

예측의 정확성이 높아진다. 복잡한 기능 구현 작업 하나와 간단한 결함 수정 작업이 하나가 계획되어 있다고 가정해보자. 기능 구현에는 2일 정도 예상되고, 결함 해결은 2시간이면 될 것다. 그 중 기능 구현을 완료한 시점이다. 만약 항목 수를 기준으로 한다면 당신은 전체 작업 중 절반밖에 완료하지 못한 것으로 계산된다.
예측의 유연성이 높아진다. 한 작업 항목을 처리하던 중 그 일이 원래의 예상보다 더 오래, 혹은 간단히 해결될 수 있음을 알게 되었다. 이럴 때 간단히 그 작업 항목의 예상 소요 시간을 갱신해주면 관련된 전체 부하량/진척도 막대가 자동으로 갱신된다.

이렇게해서, 작업 항목의 수보다는 예상 시간을 사용하는 것이 훨씬 유연하고 현실적인 플래닝을 가능하게 해준다. 하지만 예상 시간을 통한 계산은 얼마나 많은 작업 항목들에 예상 시간을 입력해 놓았느냐에 좌우된다. 그래서 우리는 계획의 품질을 높여야 한다.

What is Quality of Planning?

앞서 살펴봤듯, 일(Work)이란 작업 항목들의 예상 소요시간들을 누적한 값이다. 작업 항목에 예상 시간을 입력하는 것은 필수가 아니기 때문에, 예상치를 입력한 작업 항목들의 비율은 그 누적 예측값이 직접적인 영향을 미친다. 더 많은 작업 항목들에 예측값을 입력할 수록 계산의 정확도는 향상된다. Rational Team Concert 에서는 이를 계획의 품지(Quality of Planning)이라 부른다. 모든 작업 항목들이 예측 시간이 입력되어 있다면 품질은 excellent 로, 대다수가 입력되어 있다면 good 과 같은 형태로 표현된다. 시각적으로는 예측치를 입력한 항목의 비율이 높아질 수록 막대가 높이 채워지도록 만들었다(fill-level). 즉 부하량/진척도 막대의 높이가 높아질 수록 예측치가 입력된 항목이 많음을 의미한다. 예측된 항목이 하나도 없다면, 막대가 전혀 보이지 않는다.

	예측된 작업 항목의 수가 양호한 상태이다. 막대는 거의 끝까지 차있고, 정확한 수치는 레이블에 적혀있다 (80%).
	20%의 작업 항목들만이 채워져 있어 빨리 개선해야할 상황이다. 나머지 80% 항목들의 예측치를 입력하고나면 일이 초과 할당되어 있을 가능성이 높다.
	50% 정도가 채워진 진척도 막대이다. 역시, 막대의 높이가 한참 부족하다.

Progress Bars in Release Plans

릴리스 계획의 기본은 상위 레벨의 작업들을 가려내는 것이다. 수행 항목(execution item)에 집중하는 반복 계획(iteration plan)과 달리, 릴리스 계획은 계획 항목(plan item)들에 집중한다. 일반적으로 계획 항목들은 너무 모호하여 정확한 시간을 예측하기 어렵기 때문에 시간 예측을 하지 않는다. 그래서 추상적인 예측 단위가 사용되는데, 그 좋은 예가 스토리 포인트(story point)가 될 수 있다. 이 방법은 계획 항목들의 복잡도를 비교하는데 좋은 척도가 되지만, 얼마만큼의 시간이 걸릴지 고민하지 않아도 된다. 종종 그것은 불가능하기도 하다.

진척도 막대는 계획 항목들의 예상 시간이 아닌 복잡도를 기준으로 그려진다. 기본적으로 복잡도는 스토리 포인트를 기준으로 하지만, 필요하다면 커스터마이징할 수 있다 (자세한 설명은 이곳을 참조 - Planning Customization).

레이블과 툴팁 외의 표현 방식은 동일하다. 유일한 차이는 시간이 아닌 스토리 포인트를 기준으로 진척도를 표현하고 있다는 것. 읽는 방법은 이렇다: 총 11 스토리 포인트 중 7 만큼이 완료되었다.

릴리스 계획의 진척도 막대 역시 계획의 예상 진도를 추산해준다. 예를 들어, 한 개발 주기의 절반이 넘어섰으나 (40 작업 시간 중 30 시간이 지났다 치자), 완료된 스토리 포인트는 1/3 뿐이다 (30 포인트 중 10). 그럼 3/4 의 작업 시간이 지났으나 완료된 스토리 포인트는 이제 1/3 이므로, 스케줄에 뒤쳐진 상태가 된다.

Where is the next Bar?

부하량과 진척도 막대는 곳곳에서 찾아볼 수 있다. Plan 에디터는 윗쪽에 전체 진척도를 보여주고, Planned Items 페이지에는 각 그룹별로 부하량과 진척도를 보여준다. 그리고 Team Central 뷰의 Team Load 섹션은 팀원별 현 개발 주기의 업무 부하량을 표시해준다. 부하량은 My Work 뷰의 Current Work 섹션에서도 찾아볼 수 있다. 이곳은 현재 로그인한 사용자의 부하량 보여준다.

Rational Team Concert 2.0 의 My Work 뷰 활용

By Agile Planning Component Team

Last modified June 25, 2009

Build basis: Rational Team Concert 2.0

Translated by Wegra Lee

Original Article: http://jazz.net/library/article/198

Summary
Tracking and Organizing My Work
Reading Work Items
Modifying Work Items
Quick-Find, -Filter and -Colorize Work Items
Colorize
1. Group by Color
Quickly Create Your Own Tasks
Accessing Plans
Simulating Schedule Risk Assessment

Summary

My Work 뷰는 자신에게 할당된 작업 내역들을 계획/구정/관리할 수 있도록 도와주는 뷰이다. 이 글에서는 My Work 뷰의 기능들에 대한 간략한 설명하고, 그 기능들을 시의 적절하게 활용하여 최대한의 효과를 볼 수 있게 도와주는 다수의 팁들을 제공한다.

Tracking and Organizing My Work

My Work 는 자신에게 할당된 작업 항목 관리의 중심이 되는 뷰이다. 나의 작업 항목들을 가장 가까 눈에 잘 띄는 곳에 노출시켜줄뿐 아니라, 이들을 추적하고 조직하는데도 도움을 준다. My Work 뷰는 Team Contral 뷰의 인스턴스이기 때문에, 똑같은 방식으로 커스터마이징할 수도 있지만, 기본적으론 아래 세 섹션을 제공한다.

Current Work: 현 개발주기에 계획된 일들이 보여진다. 그리고 단기(하루, 이번주, 다음주 등) 계획에 포커싱할 수 있도록 도와준다. 대부분의 시간은 이 섹션을 바라보며 일하게 될 것이다.

Future Work: 미래의 개발주기나 아직 명확히 계획되지 않은 작업 항목들이 보여진다. 내가 앞으로 해야할 일들의 backlog 이다.

Inbox: 다른 사람이 내게 새로 할당한 작업 항목들이 보인다. 새로 할당된 일들을 검토해보고 대응하기 위해 마련된 섹션이다.

Current Work

현 개발주기에 계획된 모든 작업 항목들은 이 Current Work 섹션에 추가되어 있다. 이 섹션은 이들 작업 항목들을 보다 상세히 관리하기 위해 다음과 같은 개념들을 제공한다.

Working List: 지금, 그리고 앞으로 진행해야할 나의 작업 항목들이다. 이를 가장 효율적으로 활용하려면, 가장 첫(위) 작업부터 차례로 해결해나가도록 해야한다. 물론 작업 항목들은 언제든 새로 추가하거나, 제거 또는 순서를 바꿀 수 있으니, 우선순위에 맞춰 정돈해두자.

My Work 뷰는 각 작업 항목들의 예측 시간과 나의 근무 시간, 휴가/근태 일정을 참고하여, 내가 언제 그 일을 끝낼 수 있을지를 계산해준다. 그 결과, 대략적인 시작 시간에 맞춰 Today, Tomorrow, Next Week의 시간대별로 자동 그룹핑된다.

부가적으로, 이 뷰에는 내가 지금 하고 있는 일과 앞으로 할 작업들을 잘 정돈되어 있기 때문에 팀원과의 커뮤니케이션 효율성은 높여주는 장점도 있다.

Note: My Work 뷰가 내 작업 시작 시간을 보다 정확히 계산하도록 하려면, 모든 선행 작업들의 예측 시간을 입력해주는 것이 좋다. 시간 예측이 되어 있지 않은 작업 항목들 앞에는 작은 경고 아이콘이 표시될 것이다.

Past Work: 현 개발주기 중 완료된 작업 항목들 역시 My Work 뷰에 표시된다. My Work 뷰는 기본적으로 현재 진행중인 작업 항목을 가장 위에 보여주기 때문에, 완료된 작업들을 보고 싶다면 Current Work 섹션을 위로 스크롤해야 해주자.

Tip: 작업 보고서(e.g. 주간 보고)를 작성할 때 아주 유용하게 활용할 수 있다. 앞으로의 작업들과 마찬가지로, Early Today, Early This Week, Past Week 등 시간대별로 그룹핑해준다.

Tip: Show Today 아이콘을 클릭하면 지난 작업들을 위로 숨기고 다시 지금 하고 있는 일로 되돌아온다.

작업 항목들의 순서를 재조정하라면 단순히 원하는 위치에 Drag & Drop 해주면 된다. Ctrl 이나 Shift 키를 누른 상태로 클릭하면 멀티 셀렉션도 가능하다.

Note: 작업 항목을 중간에 삽입하거나 제거, 혹은 예측 시간을 변경하면 전체 시간이 다시 계산되어 뒤따르는 아이템들의 예상 시작 시간이 자동으로 갱신된다.

또한 Plan For 컨텍스트 메뉴를 통해 순서를 조정할 수도 있다. Today, Next Week 등 작업을 끝내고픈 시간대를 선택하면 작업 항목이 그 위치로 옮겨진다.

Note: Plan For 메뉴에서 선택할 수 있는 항목은 현재 계획 상태와 개발주기의 종료일 등에 따라 달라질 수 있다. 예를 들어, 개발 주기 종료일 이후나 마지막 아이템의 예상 종료일 후의 날짜는 선택 메뉴로 나타나지 않는다.

Note: 여러 작업 항목들을 특정 시간대에 추가하려 할 경우, 일부가 계속 밖으로 밀려나는 현상을 목격하게 될 것이다. 이는 해당 시간대의 최대 가용 작업 시간보다 할당된 작업 항목들의 예측 시간의 합이 크기 때문이다. 작업 항목들의 중요도와 시급성을 잘 고려하여 작업 순서를 현실적으로 조정하라는 신호이다.

Future Work

Future Work 섹션은 아직 명확히 계획되지 않은 작업이나 차후 개발 주기에 해야할 일들을 보여준다. 이 역시 작업 항목들을 개발 주기에 따라 그룹핑시켜준다.

Tip: 섹션 메뉴를 통해 정렬 순서를 변경할 수 있다. (우선순위, 수정시간)

Tip: 이곳으로도 역시 Drag & Drop 이 가능하여, 개발 주기 간 작업 조정이 가능하다.

Tip: My Work 뷰뿐 아니라, Rational Team Concert 어디에서건 Current Work 나 Future Work 섹션으로 작업 항목들을 끌어다 놓을 수 있다. 이 때, 내게 할당되지 않았던 항목들은 자동으로 내게 할당되게 된다.

Inbox

누군가가 내게 일을 할당하면, 그 작업 항목은 가장 먼저 나의 Inbox 에 추가된다. 따라서 그 일이 무엇을 의미하는지 재고해볼 수 있는 아주 좋은 위치인 셈이다. Inbox 를 잘 주시하는 것만으로, 나는 항상 새로 할당된 일들을 놓치지 않고 파악할 수 있게 된다.

더 나아가, 새로 할당된 일을 검토하면서 현재 계획을 상세화/갱신하고, 기존의 다른 작업들과 연관지어 시간을 예측해보거나, 혹은 태그와 범주(category)를 설정할 수 있다. Inbox의 작업 항목들은 가능한 빨리 선별/분류하는 것은 프로젝트 일정 관리와 협업을 위한 좋은 습관이다.

Inbox 의 작업 항목을 Current Work 나 Future Work 로 옮기려면 Accept 컨텍스트 메뉴를 클릭하자.

Note: Inbox 에 새 항목이 추가되면, My Work 뷰의 아이콘이 반짝인다.

Note: 내가 할 일이 아니라고 판단되면, Owner를 적당한 담당자로 변경해주자.

My Work Load

Current Work 섹션에는 나의 업무 부하량 막대를 추가할 수 있다. 원한다면 Current Work 섹션 메뉴에서 My Work Load 를 선택해 원하는 개발 라인을 선택하자. 한 번에 하나의 개발 라인만 볼 수 있다.

Note: Team Load 섹션이나 Iteration Plan 에디터와 달리 My Work 의 부하량 막대는 Current Work 섹션의 작업 항목들만 합산해서 보여준다. 즉, 현 개발주기에 잡혀 있지만 아직 내가 수요(accept)하지 않은 Inbox 의 항목들은 계산에서 제외된다.

Setting Work Time

작업 항목을 직접 열 필요 없이, My Work 뷰에서 바로 예상/실제 소요 시간을 수정할 수 있다. 작업 항목의 컨텍스트 메뉴에서 Show Work Time 을 선택하거나, Alt-Right 키로 이를 활성화시킬 수 있다. (역자주: RTC 버전 혹은 프로세스 템플릿에 따라 달라지는 듯 싶다. 좌측이 원본 기사, 우측이 현재 사용중인 RTC 2.0 RC1 버전의 화면이다.)

Reading Work Items

My Work 뷰는 작업 항목의 속성 중 summary, priority, id 등 가장 중요한 정보만 압축해서 보여준다. 그 외 상세한 전체 정보를 확인하는 방법을 알아보자.

Preview Slide-Out: 컨텍스트 메뉴의 Show Details 를 선택하거나 F4 키를 누르면, 현재 선택된 작업 항목의 오버뷰를 보여주는 창이 나타난다. 창이 나타난 상태에서 다른 작업 항목을 선택하면 그 항목의 내용으로 갱신된다.

Preview Section: Preview slide-out 과 동일한 정보를 보여주는 My Work 뷰 내의 한 섹션이다. 이 섹션을 표시하려면 My Work 뷰 툴바에서 Visible Sections > Preview 를 선택하자.

Work Item Editor: My View로부터 작업 항목 에디터를 여는 방법은 크게 다음의 네 가지가 있다. 더블 클릭, 엔터키, 작업 항목 ID 클릭, 컨텍스트 메뉴의 Open 메뉴.

Hover tooltip: 클릭없이 작업 항목 ID 에 마우스 커서를 위치시켜면 툴팁이 나타난다.

My Work 뷰는 선택된 작업 항목 단위의 최근 변경 정보 보여주어 항상 최신 상태를 유지할 수 있도록 도와준다. 이 기능은 Team Central 뷰의 Event Log 섹션과 유사하다. Show Recent News 컨텍스트 메뉴를 선택하거나 Shift-F4 를 클릭하면 현재 선택된 작업 항목의 변경 정보를 보여주는 창이 나타난다. 좌우 화살표키로 변경 순서대로 살펴보거나 Space 키로 읽음 여부를 변경할 수 있다.

Modifying Work Items

My Work 뷰에서 변경된 정부는 짧은 시간 간격을 두고 자동으로 저장된다. 만약 My Work 이외에서 같은 작업 항목이 동시에 수정 중이거나, Work Item Editor 가 열려 있다면, 다른 모든 에디터가 닫히고 나서야 저장이 된다. 자동 저장 기능을 비활성화 하려면 My Work 뷰 메뉴에서 Automatically Save Changes 를 해제하면 된다.

Note: My Work 뷰 내에서 수정 후 아직 저장되지 않은 작업 항목들은 별표(*)로 표시된다.

Quick-Find, -Filter and -Colorize Work Items

My Work 뷰는 작업 항목을 빠르게 찾기 위한 3가지 필터를 제공한다. Edit > Find/Replace 메뉴나 Ctrl+F 키가 이를 활성화시킨다. 참고로, 이들 필터는 My Work 뷰의 모든 섹션에 영향을 미친다.

Find: 입력한 검색식(expression)과 매칭되는 첫 작업 항목이 선택된다. 우측의 Next/Previous 버튼으로 그 외 매칭되는 항목들을 차례로 확인할 수 있다.

Tip: 특정한 하나의 작업 항목을 찾고자 할 때 가장 유용하다.

Filter: 매칭되는 작업 항목만 보여준다.

Tip: 관련 작업 항목만 집중해서 보고 싶을 때 활용하자.

Colorize: 매칭되는 작업 항목들만 선택된 색상으로 표시된다.

Tip: 다른 항목들 사이에서 매칭되는 항목만 부각시켜준다.

Tip: Group by Color 옵션이 활성화된 상태라면, 매칭되는 항목들만 따로 그룹핑되어 다른 작업 항목들 위에 나열된다.

입력란에 문자를 입력할 때마다 필터는 극각적으로 적용된다. 공백(white space)으로 복수의 단어 입력도 가능하며, 검색 대상은 summary 뿐 아니라 description 도 포함된다. 다음의 문법을 이용해 속성별 상세 검색도 가능하다.

attribute:value

예를 들어, 아래는 우선순위가 높은 것만을 찾는다.

priority:high

그리고 아래는 예측 소요 시간이 하루를 초과하는 항목을 의미한다.

estimate>1d

내용 추천 (Ctrl+Space) 기능으로 선택 가능한 속성들을 확인할 수 있다.

Colorize

앞서 살펴본 필터 기능으로 잠시간 특정 작업 항목들에 색상을 부여할 수 있긴 하지만, 영구적으로 고유의 색을 할당하고픈 요구도 많을 것이다.

My Work 의 Colorize 메뉴를 통해 위의 같이 만들 수 있다. 아래와 같은 설정 창이 뜨면 적절한 표현식을 입력하고 색상을 입혀보자. 표현식의 문법은 앞서 설명한 Quick-Colorize 와 동일하다. 한 항목이 두 개 이상의 표현식과 일치할 경우, 아래 설정창에 나열된 순서가 적용되어, 가장 먼저 매칭되는 색으로 나타난다. 선언 순서는 Up/Down 버튼으로 조정할 수 있다.

Tip: 범주(category)나 태그를 기준으로 색상을 지정해보자.

Tip: 매우 긴급한 결함과 같이 매우 특별한 주의가 필요한 항목에 관한 규칙들을 만들어 리스트 상단에 넣어두자.

Note: Quick-Colorize 규칙이 항상 Colorize 규칙에 우선한다.

Group by Color

Inbox 와 Future Work 섹션의 작업 항목들은 색상 순으로 그룹지을 수 있다. 색상별 그룹핑을 활성화하면 색상이 다른 정렬 기준보다 우선된다.

Tip: 범주(category)나 태그를 기준으로 색상을 지정해보자.

Tip: 매우 긴급한 결함과 같이 매우 특별한 주의가 필요한 항목에 관한 규칙들을 만들어 리스트 상단에 넣어두자.

Quickly Create Your Own Tasks

컨텍스트 메뉴를 이용해 빠르게 새로운 작업 항목을 추가할 수 있다. 단순히 항목을 추가하고픈 그룹 위에서 컨텍스트 메뉴를 호출해보자. Add Work Item 하나만 나올 것이다.

자동으로 열리는 Work Item Editor 를 이용해 summary 와 description 등을 입력하자.

아래처럼 선택 항목 전/후에 새 항목을 추가할 수도 있다. (역자주: 이 기능은 2.0 정식 버전의 기능인 듯 하다. 2.0 RC1 에서는 기본적인 Add Work Item 메뉴만 나타난다.)

Accessing Plans

Current Work 섹션의 Open 버튼을 클릭하면 현 개발 주기와 관련된 계획들을 손쉽게 확인할 수 있다.

(역자주: 이하는 역자가 임의로 추가한 섹션임)

Simulating Schedule Risk Assessment

별도의 Schedule Risk Assessment 플랜을 새로 만들지 않고, My Work 뷰에서 자신의 일정에 대한 위험도를 시뮬레이션해볼 수 있다.

다음과 같이 Schedule Risk Assessment 기능을 활성화 후, Run Simulation 메뉴를 선택하면 현 계획에 기반해 위험도를 분석해준다. Current Work 섹션에 나열된 순서(top-down)로 일을 진행한다고 가정했을 시, 붉은 색이 진해질 수록 현 개발 주기에 끝마치기 어렵다는 것을 의미한다.

Tip: 붉게 표시된 항목 중 이번 개발 주기에 반드시 끝마쳐야할 중요한 작업이 있다면 작업 순서를 조정하여 중요한 작업을 먼저 진행하도록 하자.

Note: 시뮬레이션을 가능한 정확히 하려면 모든 항목들의 예상 소요 시간을 입력해 두어야 한다. 별도 방법을 통해 최소/최대 예상 시간을 지정할 수 있으나, 특별히 지정하지 않았을 시에는 입력한 예상 시간의 1/2 ~ 2배의 값을 최소, 최대로 계산한다.

Sunday, July 5, 2009

죽어가는 조직..

팀이 죽어가고 있다. 세상의 흐름에 역행해가며.. 바른말을 하는 사람에게 오히려 핀잔을 준다.
팀원들은 슬슬 의욕을 잃고 있고(원래부터 의욕은 별로 없었지만), 스스로 저렇게 하면 안된다고 하던 다른 조직의 모습과 점점 닮아가고 있다.
변화를 외치는 사람들이.. 정작 자신들은 그 변화의 본질을 모르고 있는 거 같다. 그걸 모르는 사람들이 인정을 받고.. 그런 사람들이 조직의 새로운 리더로 성장해간다.
이런 조직에서.. 사람들의 마인드와 문화를 바꿔보려 너무 진을 뺐다. 그 기간 동안 나를 발전시켰다면 지금과는 아주 다른 내가 되어 있었을 것이다. 애초부터 힘 없는 몇 몇 사람들이 덤벼볼만큼 만만한 조직이 아니었다. 이제 자신의 길을 찾자..

Saturday, May 9, 2009

RTC versus Jira/SVN/CruiseControl

Source: https://jazz.net:443/forums/viewtopic.php?t=4383&sid=b1b8f1f9950e2b0766aedd278bfc5044

Translator: Wegra Lee

꾀 전에 사내 네트워크에 포스팅한 블로그인데, 혹 다른 사람들에게도 도움이 될까 싶어 여기 다시 올려본다.

-- Roman Smirak, Tieto

최근 Rational Team Concert (RTC)를 Jira와 Subversion 에 CruiseControl/Maven/Hudson 와 같은 빌드 시스템과 같이 쓰는 경우와 비교해달라는 요청을 받았다.

두 솔루션 비교에 대한 사람들의 관심이 높아짐에 따라, 나는 서로의 경험을 공유하고 다른 이들의 견해도 들어보고자, 이 블로그를 작성하기로 마음먹었다.

나는 몇 년 전에는 Bugzilla와 CVS, Ant 를 조합 사용했었고, 꾀 괜찮았다.

다음엔 Bugzilla와 CVS를 {Java + SVN + CruiseControl} 로 갈아탔고, 그것은 멋진 경험이었다. 사용성과 통합성 면에서 개선되었고, 새로운 기능들과 확장성.. 멋지군!

그리곤 다시 1년 반쯤 전부터 Jazz 를 파일롯 형태로 사용해보기 시작했는데, 그 결정으로 인해 나는 한 단계 더 진보한 환경을 개발 환경을 맛볼 수 있게 된 것이다. 가히 '환상적'이었다. 2007년 EclipseCon 에 참석해 Jazz의 동작 데모를 보고 갈채를 보냈던 기억이 난다. 자! 그럼 이제부터 나의 개인적인 경험과 견해들을 공유해본다.

RTC 의 단점들

열거할 거리가 몇 개 안 되니 금방 끝날 터이니 단점들부터 시작해보자. 솔직히.. 단점이 맞는지 스스로 좀 의심스럽다.

최근에 RTC 1.0 이 공식 릴리스 되었고, 짐작되었듯 공짜는 아니었다. 그리고.. IBM 이지 않은가? Jira 역시 상용 제품이긴 하지만, RTC의 가격은 거의 ClearCase 수준이었다. 하지만 총 소유비용(TCO, Total Cost of Ownership) 관점에서 생각하면 이야기가 달라질 수 있다. 시스템 구축, 유지보수, H/W, OS, DB 가격, 다른 시스템과 통합 문제, 서비스 지원을 받기 위한 추가 비용 등을 다 고려한다면.. 글쎄, 내가 정확한 수치를 제시할 수는 없고, 뒤이어 나올 장점들을 고려하면서 여러분 스스로 RTC의 투자 효용성(ROI, Return Of Investment)을 따져보기 바란다.

두 번째 '잠재적' 단점은 무엇일까? Jira, SVN, CruiseControl/Maven/Hudson 과 같은 툴들은 시장에 등장한 지 벌써 몇 년이 되어, 이미 안정성 검증이 거의 끝났고 사용되고 있는 곳 또한 많다. 그래서 경험 있는 사람 찾기도 어렵지 않다. 뿐만 아니라 Jira와 CruiseControl의 경우엔 꾀 많은 plug-in 들을 제공한다. (단, open source 의 특성상, 커뮤니티에 의해 잘 검증/관리되는 plug-in들이 있는가 하면, 자칫 잘못하면 대재앙으로 변해버리는 plug-in 들도 있으니 주의가 필요하다) 우리는 RTC의 정식 버전이 나오기 전부터 마일스톤 빌드 (정식 버전이 아니라서 안정성 면에서 조금 부족함) 를 다운받아 사용했기 때문에, 종종 결함들과 맞딱뜨렸다. 하지만 다행히도, 우리 말고도 이미 많은 곳에서 RTC를 테스트 중이었고, 잘 활성화되어 있는 Jazz 커뮤니티 덕분에, 운영에 큰 어려움은 없었다. 그리고 Eclipse Way라는 iterative 어프로치로 개발된 1.0 버전은 아주 성숙하고 안정적인 제품으로 평할만 했다.

RTC 의 장점들

장점들은 몇 개의 챕터로 나눠서 기술할 생각인데.. 음.. RTC가 제공하는 수많은 멋진 기능들 중에서도 우리가 일하는 방식에 가장 큰 영향을 주는 특성들에 포커싱해 보았다.

장점 #1: 애자일 플래닝과 자원 관리

Jira는 '비공식적인 Bugzilla의 후계자'라 할 수 있다. 이 말인즉.. 그 중심 사상이 결함 관리에 있음을 뜻한다. Jira는 작업 항목을 모두 '문제(Issue)'로 바라본다. - 내 친구중 하나가 최근 이런 질문을 했드랬다: 너희팀이 '모든 게 다 문제다'라는 개념을 수용한다면.. 그게 어떤 반향 (social impact)을 불러 일으킬까? :-) 뿐만 아니라 모든 UI 는 개인 개발자/사용자가 제기하고 수정한 문제들에 맞춰 디자인되었다. 이런 환경에서 팀이 애자일 프로세스를 따른려 한다면 어떻게 될까? 스크럼(Scrum)이 제안하는 집단 계획 (collective planning) 방식을 취해보고 싶다면? 음.. 생각해보자. 우리는 7명으로 구성된 팀이다. Iteration 계획 회의 열어 이번 iteration 의 주요 기능들, 그에 따른 세부 작업 항목과 결함들에 대해 논의/계획하고, 개발자들에게 할당한다. 그런데 전체 팀 관점에서의 뷰(view)나 개발 주기와 같은 정황 정보(context) 는 어디서 찾아봐야 한단 말인가. 결국 작업 항목 DB와 별도로 추가 자료를 만들 수 밖에.. 그래서 MS Word 나 Wiki 같은 것을 이용해, 우리 팀의 목표는 무엇이고, 위험요소는 뭐고, 우리가 하는 일을 어떻게 평가할 지, 또 iteration 테스트 전략은 무엇인지 등을 작성해 놓는다.

여기서 끝나지 않는다. 이렇게 작성해 놓은 팀 계획이 얼마나 짜임새 있는지 궁금하지 아니한가? 일정에 맞춰 끝낼 수 있을 지, 특정 팀원에게 너무 많은 일이 몰려 있지는 않은지. 중간에 계획을 재조정할 필요는 없는지 등등.. Jira는 자원 관리 기능 또한 누락되어 있어 다른 툴을 따로 쓸 수 밖에 없는데.. 주로 MS Project 나 Excel 같은 것을 택할 것이다. 결과적으로 정보는 더욱 분산되게 되고, 이것들을 다 동기화해가며 관리하려는 시도는 엄청난 고통과 시간 소비를 동반한다. 또한 팀원의 휴가 일정도 거의 고려되지 않는데.. 사실 종종 큰 문제를 야기하는 문제이기도 하다. (최근 직접 경험하기도 했는데) 팀은 팀원들의 휴가 계획이 미칠 영향을 고려하지 않고, 자리를 비워 문제가 터진 후에야 상황 파악에 나서게 된다. "할 수 없지. 누구도 그 일을 쉽게 대신할 순 없겠어." - 당연히 제때 끝마치지 못했다.

RTC는 언제든 전체 팀에 대한 정보를 한 눈에 볼 수 있는 팀 뷰(team view)를 제공한다. - 팀 중심(team first)은 Jazz 설계의 핵심 사상 중 하나인 것이다. 일원화된 자원 관리로 팀원들이 일에 투입할 수 있는 시간, 휴가 일정, 그 지역의 시간대 까지 고려된 계획을 세울 수 있다. 이런 정보들을 바탕으로 우리는 개발 계획의 품질을 실시간으로 확인 가능하다. 과다한 업무로 도움이 필요한 사람이 누구인지, 누가 그 사람을 도와줄 여력이 있는지.. 그래서 우리 팀이 무사히 제 시간에 목표한 개발을 끝마칠 수 있는지를 한 눈에 확인할 수 있다. 그리고 이 뷰는 개발이 진행되면서 실시간으로 업데이트된다.

그림 1: RTC의 Iteration 계획 화면

RTC를 사용하게 되면서 가장 먼저 접하게 될 것은 바로 Iteration과 Iteration 계획이다. Iteration 은 시작 날자와 끝 날짜를 속성으로 갖고, (RUP 방식을 따른다면) phase 별로 그룹지을 수 있다. Iteration 계획의 개요 페이지는 앞서 언급한 모든 정보들을 담는다. 목표, 위험 요소, 평가 기준, 등등.. 그리고 테스트 계획 등 필요하다면 다른 페이지를 추가하는 것도 가능하다. 별도로 작성하던 Word 문서로부터의 해방이다.

사용성 역시 두말할 필요가 없다. 마우스 조작만으로도 전체 요구사항 리스트(product backlog)에서 이번 Iteration 으로 작업 항목들을 끌어다 놓을 수 있다 (Drag & Drop). Jira에 GreenHopper 플러그인을 써서 꾸며놔 봐야 Eclipse 기반의 강력한 UI로 무장한 RTC는 비교조차 거부한다. 직접 양 플랫폼에서 동일 작업을 수행해보고 클릭 수를 세어보라. Jira로는 Iteration 간에 작업 항목들을 옮겨보고, resolve 시키는데 필요한 마우스 클릭과 웹 페이지 다운로드 수만 해도 상당함을 느낄 수 있을 것이다. 하찮은 장점이라 생각할 지 모르지만, 매일매일의 작은 차이가 쌓여 큰 플러스를 안겨줄 것이다.

장점 #2: SCM 기능 내장

앞서 얘기했듯, 우리는 몇년 전에는 CVS를 사용했었다. 단순하지만 강력했다. 후에 Subversion (SVN) 으로 옮겨 타면서 향성된 속도와 바이너리 파일 처리, 리비전 넘버라는 사랑스런 개념들을 경험하게 되었다. 태그 다는 것은 더이상 필요 없었고, 각각의 빌드마다 리비전 넘버만 저장하면 끝!! 마법이 따로 없었다.

그러다 처음 RTC로 옮겨탄 1년 전에는 무척 혼란스러웠다. Commit, update 같은 익숙했던 개념은 어디로 사라지고, deliver 같은 생소한 개념들과 친해져야했다. 하지만 겨우 이런 작은 이슈로 쇼를 그만 두는 것은 어리석은 짓! 진화의 과정에선 꼭 거쳐야만하는 관문이 아닌가 말이다.

그래서 새 개념들에 대해 숙고하기 시작했고.. 와우!! 드디어 그 위력을 깨달았다. 변경 셋(change-set)과 흐름(flow), 리파지토리 서버가 관리해주는 내 워크스페이스(my workspace), 개인 빌드(private build)와 통합(integration) 등등..

자신의 코드를 리파지토리에 체크인하는 작업을 SVN/CVS 와 비교해보겠다. 보통 우리는 코드 작성을 마치고 스스로 빌드까지 성공했다면 나름 최선을 다했다 생각하고 리파지토리 서버로 체크인한다. 하지만 잠시후 빌드 실패 통지가 날아온다. 아마도 최근에 수정한 동료의 코드를 미처 반영하지 못했을 것이다. 아니면 단순히 자신의 변경 사항 일부를 빼놓고 체크인했을 수도 있고.. 원인이야 얼마든지 있을 수 있다. 어쨌든 문제를 파악해 코드를 약간 더 수정한 후 빌드 & 체크인.. 앗!! 또 실패하고.. 몇 차례 반복하다보면 자잘한 변경에 대해선 더 이상 리비전 주석을 달지 않게 된다. (나중에 머지나 롤백이 필요할 때 혹독한 결과를 낳겠지만..)

전형적인 시나리오다. 그렇지 않은가?

그에 반해.. Jazz는 리파지토리에 개인 워크스페이스을 만들어준다 (SVN의 브랜치와 유사하다). 이건 개인 PC의 로컬 공간이 아니라 서버 상에 존재한다. 이 공간에서의 변경은 상위 스트림(팀의 통합 스트림)에 영향을 미치지 않기 때문에, 개인은 언제든 부담없이 이 공간에 체크인하고 서버에 빌드를 요청할 수 있다.

빌드 엔진과의 통합이 무엇을 의미하는지 짐작되는가? 동료의 리뷰/승인 내용, 단순한 커맨트에서 질문들까지, 모든 변경 내용들은 자동적으로 당신의 작업 항목과 연결된다. 따라서 각 작업 항목은 어떤 논의 과정을 거쳐, 무슨무슨 파일/코드들이, 어떻게 변경되었는지에 대한 모든 정보를 담게 된다. 물론 역으로 변경 셋에서 관련 작업 항목을 찾아볼 수도 있다. 코딩 하나를 하더라도 관련된 모든 정황 정보(context)들 속에서 작업할 수 있는 환경이 마련되는 것이다.

그림 2a: 작업 항목에 변경 셋 연결짓기

그림 2b: 변경 셋과 연결된 작업 항목

개인 빌드 성공했다면 여타 모듈들과의 모든 통합이 끝났고, 유닛 테스트 성공, 여타 룰들에 모두 다 만족했음을 뜻한다. 이제 개인의 변경 내용이 전체 빌드를 깨먹지 않을 거라고 안심해도 좋다. 그리고 다른 팀원에 의한 리파지토리 변경도 곧장 통보되기 때문에, 필요한 것들을 그 때 그 때 반영하기도 쉽니다. 이렇게해서 팀의 리파지토리를 엉망으로 만들어버리는 실수는 훨씬 줄어들게 된다.

이쯤이면 아마도 '우리도 Jira와 SVN은 연동해서 쓰고 있어' 라고 말할 사람들이 있을 것 같다. 좋다. 하지만 Eclipse 기반의 UI 를 간과해서는 안된다. 최근, 여전히 Jira 를 사용해 일하고 있는 친구를 봤는데.. 옆에서 지켜고 있는 것마져도 고통스러웠다. 수많은 클릭, 못생긴 인터페이스. 더욱이 정황 정보들의 통합 기능까지 흉내내려면, Mylyn 같은 추가 툴을 이용하거나, 아니면 모든 Jira 이슈 ID를 모든 리비전 커맨트에 복사해 넣도록 모든 개발자들을 다그쳐야 한다. 고통은 말할 것 없고.. 몇 달이나 지속할 수 있다고 보는가?

자! 이제 코드도 다 짰고, 빌드와 테스트도 잘 마쳤으니 팀 스트림에 넣어보자(deliver). 그 즉시 당신의 변경 사항을 다른 동료들이 볼 수 있게 된다. (앞서 설명한 것처럼) 이 과정에서 실수가 현격히 줄어드는 것 외에도, 당신의 작업에 의한 변경 사항(delta)을 확인하는 것도 무척 간단하다. 반면 Jira-SVN 조합에서는, 그 작업과 관련해 일어났던 모든 커밋(commit) 들을 찾아서 일일이 컴파일해본 후라야 무슨 일이 발생했는지 전체 그림을 볼 수 있다. 이것 그냥 '어렵다' 수준이 아니라, (별도의 툴 도움 없이는) 거의 불가능에 가깝다.

변경사항을 팀의 통합 스트림(한 단계 상위 스트림)에 딜리버리. 이로부터 통합이 완료된 완정된 증분을 얻게 되면, 똑같은 방식으로 다시 수정하고 상위 스트림에 밀어 넣고. 단순하면서도 강력하다.

규칙을 지정해 리더의 승인 없이는 누구도 딜리버리하지 하지 못하도록 강제할 수 있음도 잠시 가볍게 언급해 두고 싶다. Jazz 의 또 다른 강점이다. 하하.. 일일이 다 열거하기도 힘들다. (더 자세히 알고 싶으면 여기로)

장점 #3: 중앙 통제형 빌드 시스템 내장

나는 꾀 오랫동안 CruiseControl 을 사용해왔다. 솔직히 이 시절엔 빌드 관련 정보를 관리하기 위해 별도의 wiki 를 두어야만 했다. 빌드 레이블마다 (빌드 성공, 검증 완료, 고객 수용 여부, 정식 릴리스 번호 등의) 빌드 상태 정보를 기록하고, 어떤 고객이 가져가 사용하고 있는지를 기록했던 것이다. 물론 수작업으로 작성할 수 밖에 었었으니 종종 오류가 발생하는 것은 피할 수 없었다. 특히 릴리스 직전의 분주한 시기에 집중적으로 ˆˆ; 그리곤 나중에 고객이 전화를 걸어 버그에 대해 문의해오면, 이럴 때를 대비해 개인 PC에 지우지 않고 남겨둔 이전 워크스페이스를 열어본다. (이 시점이면 보통 새로운 버전 개발에 착수했거나, 유지보수로 변경 사항이 많을 테니) 하지만 곧 수많은 컴파일 에러들을 마주하고는 그 워크스페이스를 지워버린다. 다시 정확한 리비전을 확인해보고 해당 소스들을 리파지토리로부터 체크 아웃.. 어라라. 그런데 그 당시 쓰던 라이브러리 X의 버전이 몇이었지? 이렇게 한 시간쯤 허비하고도 아직 워크스페이스 복원은 오리무중이다. 결국 포기하고, 잘 돌고있는 최신의 워스크페이스로 회귀. 헛!! 여기선 문제가 재현되지 않잖아! 젠x -_-;;

Jazz 는 변경 정보들, 관련 작업 항목, 테스트 성공/실패 여부 등의 빌드와 관련된 모든 정보들을 자동으로 취합해주고, 원클릭으로 당시의 워크스페이스를 정확하게 복원해준다.

그림 3: 빌드 결과 화면

빌드별 태깅도 가능해 나중에 검색도 된다. 테스터가 특정 빌드에 해당하는 결함을 등록할 때도 역시 원클릭. 가히 21세기 UI 라 하겠다. 조금씩 조금씩, 하루가 끝날 즈음엔 막대한 시간이 절약되었음을 느낄 수 있을 것이다.

사용자 친화적 인터페이스 외에, 아키텍쳐적 관점에서도 장점이 크다. Jazz는 중앙 제어 서버와 빌드 엔진이 분리되어 있다는데.. 그래서 어떤 장점이? C, C++, Visual Basic, Java, Flash 등을 혼용하는 제품을 개발하면서 continuous integration 을 적용하기가 얼마나 어려운지 잘 알 것이다. 제품의 조각조각을 각자에 맞는 이질적 플랫폼에서 빌드하고 테스트하고 이 결과들을 종합해야 한다. 모두를 한 곳에서 처리하려면 컴파일에 들어가는 시간만으로도 기가 꺾일 것이다.

Jazz 를 이용한다면, 하나의 서버에 여러 빌드 엔진들을 등록해 사용할 수 있다. 필요하면 수십개도 거뜬히 ^^ 각각의 엔진들은 서로 다른 플랫폼, 머신에서 동작하기 때문에 필요한 만큼 나누어 병렬 빌드가 되는 것이다. 멋지지 않은가?

Windows 용과 Linux 용 빌드를 병렬로, 그러면서도 제어와 결과 관리는 한 곳에서 이루어진다. (더 자세히 알고 싶으면 여기로)

장점 #4: 통합 플랫폼, 그리고 공개 표준

'괜찮네. 그래도 난 지금의 Jira-SVN-CruiseControl (또는 다른 무엇이 되었건) 솔루션으로도 족해. 뭐.. 그정도까진 좋지 않을 수 있지만, 그래도 잘 쓰고 있잖아." 혹시 아직도 이런 생각을 하고 있는가?

그럼 난 이렇게 얘기해주고 싶다. '정말 큰 문제는 세세한 곳에서 숨어 있다(the devil is in the detail)'고.. 직접 써보고 그 차이를 스스로 느껴보길 권한다. Jazz는 설계 단계에서부터 의도적으로 이러한 모든 기능들을 조화롭게 융합시켜 놓았다. 서로간의 충분한 고려 없이 독립적으로 제작된 제품들을 나중에 합치려고 하는 것과는 분명한 차이가 있다. 후자의 방식은 필연적으로 이러저러한 한계에 봉착할 수 밖에 없다.

신규 인력에게 작업 환경을 세팅해주는 것도 훨씬 간단하다. 신참이 들어오면 IDE 와 모든 플러그인들, 모든 라이브러리들을 다운로드 받아 설치해야 해야 하고. 음.. 또 추후 원활한 작업을 위해선 몇몇 URL 들은 모두 북마크해둘 필요도 있다. Jazz가 아니더라도 물론 필요한 모든 프로그램들의 다운로드 링크와 설치 순서 같은 가이드라인을 만들 수는 있고 별로 어려운 일도 아니다. 하지만 정신없이 바쁜 와중에 (즉, 거의 언제나ˆˆ) 이들을 최신 상태로 유지하기란 결코 만만치 않다.

최근에 신참 한 명이 팀에 합류했다. 내가 해준 일은 서버에 그 친구의 계정을 새로 추가하는 것 뿐이었다; Jazz 는 그 즉시 환영 메일을 보낸다. 신참은 자신의 PC에 RTC 클라이언트만 다운받아 설치하기만 하면 모든 것이 끝!! 워크스페이스, 프로젝트 일정/계획, 빌드, 다양한 리포트 등등.. 한 자리에서 클릭 몇 번으로 모두 확인할 수 있는 상태가 되는 것이다. 자! 자! 이제 일 시작하자. :-)

Jazz는 Open Collaboration Lifecycle 이라 불리는 오픈 표준을 제공하여, 다른 소프트웨어 밴더 누구라도 이와 연동되는 제품을 개발할 수 있게 문을 활짝 열어놓았다. 글을 쓰는 현 시점에도 이미 SVN, ClearCase, Microsoft SharePoint 등이 이 표준을 통해 연동되고 있는 상태이다. 만약 당신이 여러 소스에 분산되어 있는 데이터들을 수집/통합하는 이슈로 골머리를 앓고 있는 CTO라면 Jazz를 한 번 고려해보길 권한다. 이를 통하면 더 이상 특정 기술이나 소프트웨어 밴더 하나에 억매여 있을 필요가 없어진다.

나는 이것이 다양성을 가능케 하는 핵심이라 믿는다. 우리 회사는 지금 독일의 오스트라바에 위치한 연구소에서 새 프로젝트를 시작하는데 어려움을 겪고 있다. 다른 팀들과 같은 툴과 환경을 갖춰줘야 하는데.. 그쪽 사람들은 자신들에게 익숙한 툴들을 더 이상 쓰지 못하는 처지이고, 새로운 툴들의 라이선스를 취득해야만 한다. 정상화가 되기까지는 시간이 꾀 걸릴 것이다.

관리자 입장에서도 문제가 많다. 부서나 프로젝트마다 완전히 다른 환경을 쓰게 된다면 여러 부서와 여러 프로젝트들을 어우르는 지표를 도저히 뽑아볼 수가 없는 것이다.

그래서 요즘 우리는 파일럿 프로젝트를 하나 진행 중이다. 그 결과로 Jazz 를 이용해 기존의 Jira 와 연계시키고, 서로 다른 소스들로부터 데이터들을 취합해 지표를 뽑아내는 것을 시연해볼 생각이다.

장점 #5: 풍부한 자료와 훌륭한 지원 시스템

Jazz 와 Rational Team Concert 는 이제 갓 시장에 데뷔한 제품답지 않게, 이미 수준 높은 자료들이 많이 공개되어 있다. 몇 가지 나열해보자.

* Jazz 의 기본 기능: https://jazz.net/pub/capabilities/

* Jazz 란 무엇인가: https://jazz.net/learn/LearnItem.jsp?href=content/docs/welcome/what-is-jazz.html

* Jazz 동작 시연 by Erich Gamma: Jazz Update from EclipseCon with Erich Gamma

* 다른 동영상 자료들: https://jazz.net/learn/videos/videos.jsp

* 오픈 포럼: open forums at
jazz.net - 가입만 하면 아주 색다른 지원을 받을 수 있을 것이다 (이미 Eclipse 커뮤니티에 익숙한 사람은 제외). 내가 겪고 있는 문제에 대해 전혀 이해하지 못하고, 이것저것 끊임없이 캐묻기만 하는.. 그런 속터지는 고객 지원 부서의 친구들은 잊자. 이 포럼에서는 Jazz의 개발자들이 직접 여러분을 상대해준다. 아마 이렇게 빠르고 정확한 지원 서비스는 처음일 것이다.

-- Roman Smirak, Tieto --

Wegra Inside Your Memories

Recent Posts

Recent Comments

Labels

My Blog List

Followers

Friends