These are my links for October 14th through October 15th:

• Visual Understanding Environment – 무료 컨셉맵 툴… 괜찮은 것 같다.
• Sync, Play & Send to BlackBerry, PSP, iPod, iPhone with doubleTwist – 아이튠즈의 대항마인가? 향후 법적공방도 재미있을 듯
• 빛을 담고 세상 넓히기 » Blog Archive » Daum 제주의 ‘캐빈 문화’ 소개 –
• REST – 위키백과, 우리 모두의 백과사전 – REST (Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다.
• RtcSdk20 < Main < TWiki – Integrating and Extending Rational Team Concert 2.0 (the SDK)
  아… 이걸로 만들고 싶은 거 참 많은데…
• Artotems iFrame in iWeb – iWeb으로 만든 녀셕을 Wordpress에 넣기 위해서는 iFrame으로 만들어야한다. 야호~
• www.iWebFAQ.com – iWeb에 관한 많은 팁을 얻을 수 있다.
• [알라딘]4시간 – 4시간이면 충분하지 암.. 그렇고 말고… ㅡㅡ;
• 함께하는 세상, 하니TV – 김제동 '사람이 사람에게'
  "상식이 통하는 세상" 나의 가치관인 "기본을 지키자", "기본이 바로 선 나라"와 일맥상통? 한다. ㅎㅎㅎ
• 구글 웨이브 단축키 정리 , 한국 구글 웨이브 사용자 리스트 | 구루 / Guru –

Related posts:

1. Bookmarks for October 15th from 14:06 to 14:06
2. Bookmarks for October 15th through October 19th
3. Bookmarks for October 7th through October 13th

These are my links for September 17th through September 25th:

• Agile2009 content on InfoQ – 차근 차근 살펴보아야겠다. 다녀오신 분들의 리뷰와 함께…
• 실천가를 위한 실용주의 프로젝트 관리 7WEEKS – Daum 책 – 개발자에서 관리자로 올라가는 사람들을 위해 쓰여진 책
• Project Coin: Final Update List for JDK 7 | Java.net – 코딩에서 멀어져 있는 사이.. JDK가 7까지 갔구나… 으흐흐
• ProjectGames/TheKanbanGameEn – やっとむのサイト – 칸반게임을 다운받아서 사용할 수 있다.
• The Galaxy: Woo-Gon’s Blog – Xper 정기모임 – Agile 2009 Conference 공유회를 마쳤습니다. – 아흐… 부러움이 더 컸던 공유 모임… 칸반 게임으로 팀에 뭔가 활력소?를 함 줘 봐야겠다. ㅋㅋ
• 아이엠그라운드 | [column] 한국은 IT강국인가? – 구구절절 올은 말만 하셨다. 역시 기득권 세력들이 지배를 하면 단점이 너무 많다. 작은 장점으로 큰 단점/잘못하는 걸 가려버리지만…
• InfoQ: Burndown Analysis for Managing Productivity & Schedules –
• 시민광장 > 시민토론방 > “역사의 밀물이 들면 진보개혁의 모든 배들이 함께 떠오를 것” –
• PredefinedProcessTemplateComparison < Main < TWiki – Eclipse Way, Scrum, OpenUP template 간의 비교
• Iphone Paper Dock / Stand on Vimeo – 두꺼운 종이를 어디서 구한담… ㅋㅋ 마분지라도 하나 사러 가야겠다…
• 맥의 워런티 확인하기 – 워런티가 얼마남았는지 , 언제까지 AppleCare를 사야할 지 궁금하다면 지금 바로 가자. 라잇 나우~
• Jazz Community Site – Jazz Team Blog » OSLC and Rational Team Concert –
• 맥박 회고 – Google 문서도구 – 주기적으로 하는 일 공유하기
• Wibiya | Homepage – 블로그에 툴바를 달 수 있다.

Related posts:

1. Bookmarks for August 17th through August 22nd
2. Bookmarks for September 10th through September 17th
3. Bookmarks for August 23rd through August 26th

RTC를 사용하면서 한 눈에 비교하기 힘들었는데 잘 정리 된 것이 있었네요. ^^;

원문 : http://jazz.net/wiki/bin/view/Main/PredefinedProcessTemplateComparison

Process templates are available for RTC that can help you start with a useful process in your project right away. The following table highlights some of the differences between the templates

Related posts:

1. links for 2009-05-15
2. Bookmarks for August 26th through September 1st
3. Bookmarks for August 17th through August 22nd

These are my links for August 26th through September 1st:

• Eclipse’s Culture of Shipping – 프로젝트 투명성… 에릭감마의 이야기를 통해서 느낄 수 있는 이클립스에서 RTC 까지… 감마형아가 최고…
• Snow Leopard, 개발자들의 생각 1 – AppleForum – 곧 쏟아질 레오파드용 앱들이 기대된다.
• Test Driving Your Code with OCUnit –
• SuperMegaUltraGroovy » Blog Archive » Unit Testing and Code Coverage with Xcode –
• lovesera.com: ART of VIRTUE :: [마인드맵] 트위터 & SNS 빅뱅 세미나 2009 발표 내용 정리 –
• Cocoa Samurai: Xcode Shortcuts Updated for Xcode 3.2 on Mac OS X 10.6 Snow Leopard – 크게 프린트해서 집에 붙혀놓아야겠다. ^^;
• Unit Testing and Code Coverage with Xcode | BYU CocoaHeads – Xcode에서 Unit Test하는 것에 대해서 정리를 하려는데 영 짬이 안 난다. 일단 Inbox에 넣고 노력해야겠다.
• Things 1.2: Fasten Your Keyboards! | Things Blog | Cultured Code – Things를 조금 더 편리하게 사용할 수 있게 되었다. 업무용으로도 사용하면 참 좋은데…훔…
• Jazz Community Site – Jazz Team Blog » Sprint alignment for developers and testers – 개발과 테스터가 이런 환경에서 프로젝트를 진행한다면 정말 도움이 많이 될 것이다. 물론 어떻게 운영하냐가 중요하겠지만… 아… 이런 환경에서 프로젝트 해보고 싶다. 맨날 밤 새도 즐거울텐데…
• Article info : Writing Better Defect Reports – Why do some testers get a much better response from development than others? Part of the answer lies in the defect report. Following a few simple rules can smooth the way for a much more productive environment. The objective is not to write the perfect defect report, but to write an effective defect report that conveys the proper message, gets the job done, and simplifies the process for everyone. This paper focuses on two aspects of defect reports: 1) the remarks or description and 2) the abstract.

Related posts:

1. Bookmarks for August 17th through August 22nd
2. Bookmarks for August 23rd through August 26th
3. Bookmarks for September 1st through September 2nd

These are my links for August 23rd through August 26th:

• theunarchiver – Project Hosting on Google Code – 알집 파일도 한글 깨짐없이 지원된다고 한다.
• Scrum Checklist – Crisp AB – Henrik Kniberg가 업데이트한 체크리스트. 리마인드 차원에서 체크해보면 좋을 것 같다.
• Main Page – Gambit wiki – The Gambit Scheme system is a complete, portable, efficient and reliable implementation of the Scheme programming language.
• jlongster – software – Gambit iPhone Example – scheme를 이용한 iphone 개발.
• Snow Leopard Compatibility: Mac OS X 10.6 Snow Leopard Compatibility List – 내가 주로 사용하는 건 대부분 호환이 된다. 야호~
• Eclipse Galileo 살펴보기 – RTC를 사용하면서 항상 Eclipse를 사용하고있지만… 코드는 없다.. 이런… 코드를 함께 사용해 보고싶다.
• Open Services for Lifecycle Collaboration open community. open interfaces. open possibilities. – Open Services for Lifecycle Collaboration (also known as OSLC or Open Services) is a community effort to help software delivery teams by making it easier to use lifecycle tools in combination. The OSLC community is creating open, public descriptions of resources and interfaces for sharing the things that software delivery teams rely on, like change requests, test cases, defects, requirements and user stories.
• Outsider’s Dev Story :: Erich Gamma와 함께 여는 개발자 세상 세미나 #2 –
• Outsider’s Dev Story :: Erich Gamma와 함께 여는 개발자 세상 세미나 #1 – 육아 때문에 정리 못했더니.. 벌써 누가 이렇게 정리했다.
• Dr. Spark’s Columns – 박순백 박사의 홈페이지… 본받을 것이 많은 분이군…

Related posts:

1. links for 2009-08-24
2. links for 2009-08-25
3. Bookmarks for August 17th through August 22nd

These are my links for August 17th through August 22nd:

• Rational Team Concert 2.0 Process Template Add-ons Downloads – Jazz Community Site – 1.0 버젼대에서 제공되던 EclipseWay와 Agile Process Template이 2.0에서는 빠져 있다. 이 녀석들은 여기서 다운받아 Import 할 수 있다.
• Jazz Community Site – Jazz Team Blog » Sprinting towards Scrum – 회고만 잘 하면 내가 현재 하는 것과 거의 같다… 냐하하.. 기분좋다… ^,.^;
• Representational State Transfer – Wikipedia, the free encyclopedia –
• Web As Platform :: REST(Representational State Transfer)에 대해서 –
• InfoQ: Deployment is the Goal –
• InfoQ: The Dancing Agile Elephant: IBM Software Group’s Transition to Agile and Lean Development –
• 한국 developerWorks : developerWorks Column : 교육과 애자일, Part 1: 유치원과 애자일 –
• iSimulate – Testing Multi-Touch, Accelerometer and GPS using Xcode Simulator –
• Eugenia’s Rants and Thoughts » Blog Archive » The smartphone wives – 아이폰, 안드로이드, WM, WebOS, 블랙베리, S60 을 아내에 비유한 글
• Usefuldocuments – 트위터 인맥! TwitMe – 잘 정리된 트위터에 관한 글

Related posts:

1. Bookmarks for August 26th through September 1st
2. links for 2009-08-19
3. Bookmarks for August 23rd through August 26th

현재 업무에 사용하고 있지만 개인 정리 차원에서 설치 부터 팁까지 정리해 볼까합니다.

대부분 Jazz.net에 있는 내용이 주가 될 것 같습니다만,

설치하거나 사용하면서 문제가 있었던 것들과 유용하다고 생각되었던 팁/사례 위주로 정리해 볼까합니다.

기회가 되면 Jazz 다른 제품군들도 함께 정리를 해보도록 하죠.

Related posts:

1. Using Scrum with Agile Estimating and Planning

Jazz 와  RTC 관련 내용을 정리하기에 앞서 링크부터 공유합니다.

jazzlab.net도 많이 찾아주시고 가입해서 함께 배워나가요..

Related posts:

1. Rational Team Concert를 정리해 볼까 합니다.
2. Bookmarks for August 17th through August 22nd
3. links for 2009-05-14

후배 Wegra가 많은 사람들이 RTC를 알고 사용해서 행복해졌으면 하는 맘에 번역을 한 것입니다.

jazz team blog 에 에릭 감마도 맘에 들었는지 소개한 글입니다. 고객에게 감동 먹었나요? (wegra는 좋겠다.  에릭 감마가 ‘Thanks’래… ^^)

오늘 고객으로부터 너무도 감사하고 소중한 선물을 하나 받았다.

IBM으로 옳긴 이후 가장 감동먹은(!) 일중에 하나가 아닐까 한다.

아래에 링크되어 있는 글이 jazz.net 에 올라와 화재가 되고 있는 가운데 (고객이 작성한),

오늘 이 글을 다시 번역한 글을 고객이 다시 나에게 보내준 것이다.

“툴 저변에 도움이 되라는 …” 짧은 인사말과 함께 말이다.

마음 같아선 성함까지 언급하며 감사의 글을 남기고 싶지만, 아직 이에 대한 확답까지는 받지 못한 상황이라

회사와 성함은 다음에 기회로 미룰까 한다. (복받치는 감정을 추스리기 위해 급히 이렇게라도 글 남기고 있다.)

…

1년여 RTC라는 제품을 위해 시간과 노력을 들이며… 나름 힘든 시간과 고민의 나날을 보내고 있는 가운데

이 선물은 더운 여름으로 가며 지칠 수 있는 나에겐 너무나도 시원한 한여름의 소나기와도 같은 것이 아닐까 한다.

OOO님, 선물 너무나도 감사합니다. *^^*

더 많은 분들이 RTC를 알았으면 좋겠습니다.

꼭 툴을 알았으면 하는 것은 아니고 더 재미나고 효율적으로 일하는 방법에 대해서 공유하였으면 합니다.

Jazz 와 RTC에 녹아든 철학을 보고 느끼는 것만으로도 신나는 일이죠.

그럼 함께 보시죠.

————————————————————————————————-

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 –

Related posts:

1. Rational Team Concert를 정리해 볼까 합니다.
2. Using Scrum with Agile Estimating and Planning
3. [RTC] Comparing the predefined process templates

현재 폴란드에 출장와서 Scrum과 RTC를 이용해서 과제를 진행하고 있습니다.
지난해 Scrum으로 개발할 때와 다르게 이번엔 개발과제도 아닌 테스트관련해서 프로세스와 테스트 케이스를 개선하는 작업에서도 어떻게 활용하였는지를 소개해 볼까 합니다. 아래는 jazz.net의 자료입니다. 어떻게 운영되는지 한 번 보시면 좋을 것 같습니다. ^^:
Jazz와 Scrum이 생소하신 분은 이것을 먼저 읽어 보시면 좋을 것 같습니다.

https://jazz.net/pub/learn/videos/data/Scrum-RTC-Video/Scrum-RTC-Video-cleared.html

Related posts:

1. The Thinking Tool called Agile
2. Jazz & RTC 관련 링크
3. Rational Team Concert를 정리해 볼까 합니다.