티스토리 툴바


[OSLC] Reportable REST API 사용법

IBM Rational 2011/04/05 00:04 Posted by 아름프로
API 정리 사이트 : https://jazz.net/wiki/bin/view/Main/ReportsRESTAPI

  1. 시작 지점 : https://사이트주소:포트/ccm/rpt/repository
    예> https://my.jazz.net:9443/jazz/rpt/repository
    https://my.jazz.net:9443/jazz <-- 각자의 RTC URL
    * 웹 브라우져 상에서 위의 주소를 넣고 실행
    실행 결과 :

    <resources Version="1.0.0">
      <resource href="https://my.jazz.net:9443/jazz/rpt/repository/scm"/>
      <resource href="https://my.jazz.net:9443/jazz/rpt/repository/build"/>
      <resource href="https://my.jazz.net:9443/jazz/rpt/repository/foundation"/>
      <resource href="https://my.jazz.net:9443/jazz/rpt/repository/apt"/>
      <resource href="https://my.jazz.net:9443/jazz/rpt/repository/workitem"/>
      <resource href="https://my.jazz.net:9443/jazz/rpt/repository/generic"/>
    </resources>

  2. 위의 결과로 뽑을 수 있는 것들
    - foundation: Common artifacts (project areas, team areas, contributors, iterations, links)
    - scm: Source Control artifacts (streams and components, as well as stream sizing deltas)
    - build: Build artifacts (build results, build result contributions, build definitions, build engines)
    - apt: Agile Planning artifacts (team capacity and resource schedules, absences)
    - workitem: Work Item artifacts (work items, categories, severities, priorities)

  3. 해당 REST API 사용방법
    https://my.jazz.net:9443/jazz/rpt/repository/scm?fields=
    https://my.jazz.net:9443/jazz/rpt/repository/buil?fields=
    https://my.jazz.net:9443/jazz/rpt/repository/foundation?fields=
    https://my.jazz.net:9443/jazz/rpt/repository/apt?fields=
    https://my.jazz.net:9443/jazz/rpt/repository/workitem?fields=
    https://my.jazz.net:9443/jazz/rpt/repository/generic?fields=



    위의 URL에 아래 이미지 상의 리소스를 조합.

    예>
    https://my.jazz.net:9443/jazz/rpt/repository/scm?fields=scm/workspace
    https://my.jazz.net:9443/jazz/rpt/repository/buil?fields=build/buildDefinition
    https://my.jazz.net:9443/jazz/rpt/repository/workitem?fields=workitem/workItem

    Properties 활용 예>
    https://my.jazz.net:9443/jazz/rpt/repository/workitem?fields=workitem/workItem/id
    https://my.jazz.net:9443/jazz/rpt/repository/workitem?fields=workitem/workItem/summary

    Properties와 type ... type: com.ibm.team.workitem.Comment 조합 예>
    https://my.jazz.net:9443/jazz/rpt/repository/workitem?fields=workitem/workItem[id=1]/comments/creator

    리소스, Properties, type 에 대한 상세한 정보는
    https://jazz.net/wiki/bin/view/Main/ReportsRESTAPI 참조

  4. 활용 예제 : https://jazz.net/wiki/bin/view/Main/ReportsRESTAPI#Examples


     

'IBM Rational' 카테고리의 다른 글

OSLC Data Structure (Work Item, Build)  (4) 2011/04/08
[OSLC] Reportable REST API 사용법  (8) 2011/04/05
JAZZ ressources for Extensions  (6) 2011/04/03
RTC Build API 관련 정보들  (2) 2011/04/03
TAG OSLC, RTC

댓글을 달아 주세요

  1. essays and term papers 2011/12/03 00:36  댓글주소  수정/삭제  댓글쓰기

    This particular content is fantastic. I am making a homework paper concerning the similar matter and your web page has been incredibly useful. Thank you.

  2. non-plagiarized term papers 2011/12/28 08:38  댓글주소  수정/삭제  댓글쓰기

    I agree with the source. You administered to deal with the actual subject very effectively. I really like the important points and information supplied. My bro is actually doing work on a homework paper dedicated to the area and I will give him or her the address of your online site to dig for information and facts. With thanks again!

  3. Write writer 2012/01/03 14:00  댓글주소  수정/삭제  댓글쓰기

    난 단지 블로그에 우연히와 정말 블로그 게시물을 읽고 즐길 것을 말하고 싶었어요. 어쨌든 내가 피드에 가입이되고, 난 당신이 곧 다시 게시 바랍니다.

  4. research paper writer 2012/01/10 21:31  댓글주소  수정/삭제  댓글쓰기

    이것은 정보를 게시합니다. 게시물이 공유를 주셔서 감사합니다.

  5. tiffany jewelry Outlet 2012/01/13 14:50  댓글주소  수정/삭제  댓글쓰기

    I really appreciate your way of presenting this post with a excellent suggestion. I want some more about this article. Since I am the frequent visitor to this web.
    http://www.discounttiffanyshop.com/
    http://www.discounttiffanyshop.com/tiffany-necklaces/
    http://www.discounttiffanyshop.com/tiffany-rings/
    http://www.discounttiffanyshop.com/tiffany-bracelets/

  6. replica watches 2012/01/13 14:53  댓글주소  수정/삭제  댓글쓰기

    Oh!Big Surprise!Hot Selling replica watches sale!! We know that Wearing right accessories like Rolex replica watches will improve our personality.Now you could spend less moeny to buy discount watches than usual ,So you can buy watches online. You can visit to http://www.cheapwatchmarket.com
    http://www.cheapwatchmarket.com/mens-replica-watches-2.html
    http://www.cheapwatchmarket.com/swiss-collection-watches.html http://www.cheapwatchmarket.com/ladies-watches.html

  7. Non-Plagiarized Essays 2012/01/18 06:53  댓글주소  수정/삭제  댓글쓰기

    Fantastic website. I like writing comments on information sites, i am sorry regarding my English language, but I appreciate your website. Very good work. Once issue I don't understand is the reason you need the password?

  8. Term Papers for Sale 2012/02/07 10:18  댓글주소  수정/삭제  댓글쓰기

    Very good web site. Nice commenting system. I am sorry for the off-topic post, nevertheless I had been pretty astounded with Djokovic\'s play in the final of the Aussie OPen this yr. The guy is simply unbeatable. He exhibited he was as formidable as iron. Just imagine about he he can overcome Nadal who had been so motivated to succeed as well as really was so energized up in the 5th set. I\'m starting to feel that Djokovic is doing some psychic work to take some aids on his side that assist him win such matches against the best players in the world. What do you think in relation to Rafa's game?

RTC Report/BIRT 관련 자료들 모음

IBM Rational 2010/12/03 22:56 Posted by 아름프로
RTC Online Help
Jazz.net
Jazz Wiki
DeveloperWorks
RTC에서 제공하는 Chart API 관련 정보

(1) Jazz Flash charting engine
=> Client-side technology powered by Flash
=> Used by Work Item Statistics viewlet
=> No API. Strictly internal
=> No documentation

(2) BIRT charting engine
=> Server-side technology powered by Java/Eclipse
=> Used by Reports Web UI and Trend Reports viewlet
=> Public API
=> Documentation:
http://www.eclipse.org/birt/phoenix/

(3) DojoX charting engine
=> Client-side technology powered by JavaScript/CSS/HTML
=> Not used by any component at the moment
=> Public API
=> Documentation:
http://docs.dojocampus.org/dojox/charting/
http://api.dojotoolkit.org/jsdoc/1.3/dojox.charting

Tech Notes





TAG BIRT, report, RTC

댓글을 달아 주세요

  1. replica watches 2012/01/13 14:58  댓글주소  수정/삭제  댓글쓰기

    Choose a birthday gift for her is an art. But I still am wondering about the birthday gifts that would make her happy in this important day. I am happy to tell that watches for men is best choose, There’s no doubt that any young girl would like to receive a best replica watches on a special day. Wear cheap replica watches and any young girl will feel like she's the most important girl in the world. If you’re looking for a great birthday gift to make your girlfriend happy like me, you have to know much about best watches, which are special, chic and accurate.


지난 7월 30일(목) 에 개최되었던
"코드 중심 개발자를 위한 모델 중심 개발(MDD)솔루션 제안" 세미나 자료입니다.

http://www-01.ibm.com/software/kr/rational/mddseminar/vconf.html

MDD인데 RTC를 연계해서 이야기 해달라고해서 좀 난감했지만, 한 세션 발표했습니다.
혹시라도 듣고 싶으신 분들은 참고하세요. ^^;;;
(차트가 많은데 해야할 이야기는 많고.. 이번 역시도 말이 빠릅니다. 제 스스로 한번 들어보고 있는데 고쳐야 할 것이 많네요. 휴~~ )

http://www.onbinet.tv/ibmkorea/2009/mdd/loading.asp?email=ibm@ibm.co.kr&firstname=ibm&sessionid=2
TAG MDD, RTC, 세미나

댓글을 달아 주세요

  1. maigrir des cuisses 2012/01/15 02:38  댓글주소  수정/삭제  댓글쓰기

    아름다운 사무실 좋은 주 . .

오늘 고객으로부터 너무도 감사하고 소중한 선물을 하나 받았다.
IBM으로 옳긴 이후 가장 감동먹은(!) 일중에 하나가 아닐까 한다.

아래에 링크되어 있는 글이 jazz.net 에 올라와 화재가 되고 있는 가운데 (고객이 작성한),
오늘 이 글을 다시 번역한 글을 고객이 다시 나에게 보내준 것이다.
"툴 저변에 도움이 되라는 ..." 짧은 인사말과 함께 말이다.

마음 같아선 성함까지 언급하며 감사의 글을 남기고 싶지만, 아직 이에 대한 확답까지는 받지 못한 상황이라
회사와 성함은 다음에 기회로 미룰까 한다. (복받치는 감정을 추스리기 위해 급히 이렇게라도 글 남기고 있다.)

...
1년여 RTC라는 제품을 위해 시간과 노력을 들이며... 나름 힘든 시간과 고민의 나날을 보내고 있는 가운데
이 선물은 더운 여름으로 가며 지칠 수 있는 나에겐 너무나도 시원한 한여름의 소나기와도 같은 것이 아닐까 한다.

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

+++++++++++++++++++++++++++++++++++(본문)+++++++++++++++++++++++++++++++++++

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를 {JIRA+ 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 동작 시연 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 --

댓글을 달아 주세요

  1. 정의의소 2009/05/14 10:54  댓글주소  수정/삭제  댓글쓰기

    복연 선임이 제가 뿌린 씨앗중 가장 잘 자라서 꽃을 피우고 또 씨를 뿌리고 있네요.
    ㅎㅎㅎ 더 뿌려야겠어요... ^^;
    참 데모용 시나리오 인스톨버전이 있다고 하셨죠? 혹시 주실 수 있으세요? 있으시면 답글이나 메일로 연락 주셔요... 사내 데모할 때 제가 하고 있는 프로젝트로 보여주긴 하는데 좀 약한 것 같아서요.. 시나리오도 그렇고...

    근데 다들 나보고 IBM 영업사원 같다고 하네요.ㅋ

  2. Corrie 2012/01/27 04:58  댓글주소  수정/삭제  댓글쓰기

    나는 찾고 있었어 이미 분 전 . 이 사이트를 읽을 때로는 !

IBM에 와서 경력이 쌓이며 좋은 것 중에 하나가 다양한 고객층의 다양한 이야기를 들을 수 있다는 점이다.
업체들의 면면을 보면 끊임없는 노력을 통해 지속적으로 최선의 환경을 만들어가려고 노력하는 업체가 있는가 하면 어떻게 이러한 환경에서 개발이 이루어지고 있는가? 라고 생각될 정도로 열악함에도 꿋꿋이 유지되고 있는 굳건한(!) 업체까지 다양한 업체들을 보게 된다.

그래도 최근 몇년간 업체들은 나름 많은 투자와 관심을 가지고 이를 개선하기 위해 투자하고 있는 분야가 소스관리, 버그(이슈)관리 분야다. (형상. 변경관리라는 용어를 사용하고 싶기도하지만, 최소한 내가 보는 관점에서는 분명히 구분이 되어 보여 용어는 이렇게 써봤다.)
이러한 시스템을 도입하려(또는 도입한) 업체들을 보게되면 그 도입 이유는 다 다르다 할 수 있겠지만, 몇가지 공통점을 찾아볼 수 있다.

- 개발의 진행을 좀 더 절차적, 표준적으로 만들어보려는 이유 (중구난방식의 개발 방지)
- 변경된 내용에 대한 절저한 관리
- 관리를 통한 통제/관리
- 문제에 대한 빠른 처리 및 현황 파악/관리
- 앞선 내용들을 통한 개발 생산성 증대 및 품질의 향상
... 등등...

그런데, 이러한 이유에서 도입된 버그관리, 소스관리 도구들이 과연 얼마나 제 역할을 하고 있을까? 또 한다고 생각되는가?
이에 대한 대답은 내가 경험한 바로는 누구한테 이러한 질문을 했는가에 따라 그 답변이 확연히 달라 진다는 것이다.
- 관리직에 있는 사람, 운영자, 관리자, 매니저, 기획자, 개발자 ... 모두 다른 답변을 한다는 것이다.
그렇다면, 과연 누구의 눈높이를 맞춰야하는가? 누구의 만족도를 높여야 할 것인가? 물론, 모두의 눈높이를 맞추는 것이 가장 좋은 것이겠지만 그렇지 않다면 어느 집단을 우선순위로 개선해 나가야할 것인가? ... 최고의 결과가 아니라면 최선의 방법이란 것은 무엇일까?

나의 제언은 이러한 상황에서는 그 눈높이는 우선적으로 개발자들이 그 대상이 되어야한다는 것이고, 더욱 중요한 것은 그 대상이 되는 개발자란 것도 사람 자체이어야하는 것이지, 개발업무가 되어서는 안되다는 것이다. 또 한가지 첨언하고 싶은 것은 개발자라는 것은 개발만을 하는 대상만이 아닌 개발에 깊이 있게 참여하는 주요대상의 사람들까지도 포함한다. (PM, 아키텍쳐, 개발자 등..)

개발을 위한 방법론이 생기고, 개발을 위한 도구가 생기고 관리를 위한 관리도구가 생기고.. 하는 과정에서 언제부터인가 사람들은 이러한 것이 누구를 위해서 등장한 것인지를 잊고 있는건 아닌가 하는 생각도든다. 개발을 더욱 잘하기 위한 수단들이 오히려 개발자들을 관리하는 수단/도구로써만 역할을 통해 이들의 족쇄를 채우는 역할만을 하는 경우를 보게 되는 것이다.

그러한 측면에서 최근에 유행처럼 많이 도입하고 있는 버그(이슈)관리 시스템들에서 아쉬운 모습을 찾아보게 된다.
과연 누구를 위해 만들어졌는지 조차 모호한 제품도 많이 등장하고, 좀 괜찮다 싶은 제품은 도입하는 측에서 의도와 다르게 도입하여 사용하고 있는 경우도 허다하고 ... 이래저래 아쉽기는 마찬가지인 상황을 참 많이 보게 된다는 것이다.

개인적으로 가장 아쉽게 생각하는 부분은, 이러한 시스템들의 특징들은 웹에서 주로 내용들을 관리하게끔 되어져 있다는 것이다.(또는 별도의 어플리케이션으로.) 더한 경우는 소스관리시스템(SCM)과 연계하여 그 소스까지도 웹에서 보여주면 변경된 내용을 보여주기도하며 훌륭한 관리가 된다고 이야기까지 한다는 것이다. 물론, 이러한 시스템이 없던 시스템의 시절에 비한다면 분명 이러한 정보는 중요한 것이고 좋아진 환경일 수 있겠지만... 과연 이러한 것이 개발 실무자들에게는 얼마나 도움이 된다고 보는가?

보는 이들에게는 좋아보일지 모르고, 관리하는 사람의 입장에서 관리가 될 것처럼 보일 수는 있을지 모르겠지만,
관리라는 이유에 묻혀 개발자들이 얼마나 많은 시간낭비와 희생을 감수하고 있는지에 대해서는 잘 모르는 경우가 많은 것 같다.
결국, 개발자의 편의성을 무시된 시스템은 개발자들의 사용성을 떨어뜨리게 되고 더 나아가 이 시스템은 사용자체가 흐지부지하게 되는 결정적인 이유를 제시하게 된다. (억지고 강제해서 사용하게 하면 된다?라고 말하고 싶다면 ... 회사에서 가장 아끼는 개발자가 당장 내일이라도 떠날 수 있음을 고려하지 않고 하는 이야기일 것이다.)

개인적으로 RTC라는 제품을 릴리즈 되기전부터 관심을 가지고 된 결정적인 이유 중에 하나는 다음의 문장이 참 마음에 들어서이기도 하다. "People building great software, together" .
이 문장에서 보듯이 좋은 소프트웨어가 탄생되는 것의 중심엔 이를 직접 만드는 사람 있어어야 한다는 것이다.
결국엔, 그 사람이 제대로 개발을 할 수 있도록 방법과 환경을 최적화 해주는 것이 중요하다는 것이다.
(여기에 좀 더 진보해서 이들간의 협업까지도 이어지지만 여기까지 어여지기도 전인 사람 중심의 환경 조차도 제대로 안되고 있는 경우가 많은 것이 현실인듯 싶다.)

지금 소프트웨어 개발을 하고 있고, 더 나은 소프트웨어를 만들고자하는 의욕이 있다면
우선적으로 가장 실무단에서 일하는 사람부터해서 어떠한 환경에서 개발을 하고 있는지를 살펴보았으면 하고,
그러면서 차차 사람들을 넓혀 이들이 어떻게 함께 어울려져 일하고 있고, 할수 있는지를 고민해 보았으면 한다.

무엇보다 관리자의 기준과 눈높이에서 개발팀을 관리하려는 시선과 관점을 버렸으면 한다.
우선은 개발팀 중심의 환경을 고려하고 ... 관리는 그 속에서 쌓여지는 결과 또는 과정의 데이터를 통해, 관리라는 관점보다는 관심의 형태로 함께 어울려져 일할 수 있는 분위기를 만드는 것이 중요할 것이다.
TAG RTC, 차이점

댓글을 달아 주세요

  1. 정의의소 2009/04/17 21:12  댓글주소  수정/삭제  댓글쓰기

    RTC를 사용하고 설명하면서 가장 많이 들은 말이... 이거 너무 빡시게 관리되겠네요... 였습니다. Scrum daily meeting에서도 보고가 아닌 서로에 대한 약속이라는 것을 이해하는데도 시간이 꽤 오래걸렸습니다. 관리자의 마인드 변화도 중요하지만 기존 관리당하는? 방식에 익숙한 각 팀원들도 변화해야겠지요.

    • 아름프로 2009/04/21 13:20  댓글주소  수정/삭제

      좋은 지적이십니다.
      현재 제가 겪는 고민중에 하나이고요.
      개발자들이 더욱 관리 당하는 것은 아닌가하고 걱정부터하는...
      저는 RTC를 Top-Down이 아닌 Bottom-UP으로써 개발자 스스로가 변화를 원하고 즐길 수 있게 해주는 툴로써 자리 매김하게 히고 싶지만, 개발자들의 위축된 현 마인드를 변화시키기엔 저의 이런 진행방식이 오히려 변화를 더더디게 하는건 아닌가 .. 하는 생각도 해보고 있는 요즘이랍니다.

    • 정의의소 2009/04/21 18:07  댓글주소  수정/삭제

      그래서 저도 그런 마인드를 스스로 바꿀 수 있게 다양한 문화활동이나 언더그라운드? 활동을 해 볼까합니다. 물론 업무 외적으로요... (이렇게 적고나는 제가 멋있군요... 업무와 상관없이 회사와 동료들을 걱정하다니..ㅋㅋ) v^^;

    • 아름프로 2009/04/26 23:16  댓글주소  수정/삭제

      그러한 문화활동과 언더그라운드 .. 어떤것이 있을까요? 재밌는 것 있으시면 살짝 귀뜸해주셔도 좋을 것 같은데요. ^^

IBM은 왜 재즈에 흠뻑 취했을까?

IBM Rational 2008/10/07 16:05 Posted by 아름프로
7월달에 Bloter.net 도안구기자님과 인터뷰 한 내용을 이제서야 발견(!)하여 남겨본다.
내가 이런 말을 했던가? ㅡㅡ; 라는 생각이 들기도 한다. ㅎㅎ

기사원본 : http://bloter.net/archives/4272

=====================================================================================

IBM은 왜 재즈에 흠뻑 취했을까?

  도안구 2008. 07. 17 사람들, 테크놀로지 |

IT 분야에 웬 재즈(Jazz)?

앞으로 재즈에 대해서 자주 소개할 수 있을 것 같다. IBM 때문이다.

재즈(www.Jazz.net)는  협업 소프트웨어 제공을 위한 IBM의 차세대 기술이다. 개방형의 협업적 라이프사이클 관리 통합 플랫폼으로서, 소프트웨어와 임베디드 시스템 개발과 구현을 위한 협업 방식을 혁신적으로 변화시키는 것을 목표로 하고 있다.

사용자 삽입 이미지

전세계 흩어져 있는 IBM의 개발 조직들이 웹 2.0 환경에서 오픈 소스 소프트웨어의 장점인 개방성과 신속한 제품 업데이트, 전세계 수십만의 개발자들과의 끈끈한 유대관계 등을 적극 수용하면서 새로운 도전에 나서고 있다.

재즈는 소프트웨어 개발 프로젝트와 관련된 인력과 프로세스, 자산을 실시간으로 통합하고 동기화할 수 있는 확장형 프레임워크다.

재즈 공연처럼, 재즈 플랫폼은 소프트웨어 구축을 위한 협업 방식을 개선해 보다 생산적으로 상호 협력을 효과적으로 달성할 수 있도록 도울 예정이다.

한국IBM 소프트웨어사업본부 래쇼날 팀 이현찬 과장(사진)은 “독일과 캐나다, 미국에 흩어져 있는 IBM의 개발팀들이 어떻게 협업하면서 관련 제품을 개발해 나가는지 직접 고객들에게 보여줍니다”라고 전하고 “상용 패키지 개발 업체가 오픈 소스 커뮤니티의 장점을 적극 활용해 고객에게 보다 신속하고 검증된 제품을 전달할 수 있을 것으로 기대됩니다”라고 말했다.

재즈 프로젝트는 상용 패키지 개발 업체들은 물론 전세계 수많은 연구 조직을 운영하고 있는 많은 기업들에게도 많은 시사점을 던져준다.

재 즈 프로젝트(Jazz Project)의 일환으로 예정된 협력형 소프트웨어 개발 툴의 개발작업에 오픈 소스 형식의 프로세스를 도입키로 했다. IBM은 Jazz.net을 통해 고객들이 제품 필수요소(requirements)에 액세스할 수 있게 함으로써 개발작업에 기여토록 할 방침이며, 개발 툴의 연관 문서자료 역시 비치할 계획이다.

여기에는 약간의 설명이 필요하다. 재즈는 OCSD(open commercial software development)라는 새로운 접근방식에 따라 개발되고 있다. 기존 상용 버전들의 경우 고객들은 제품이 출시되는 당시에 그 제품에 대한 내용을 파악할 수 있었다. 하지만 재즈는 Jazz.net에서 어떤 기능이 추가되고 있고, 고객들이 개선을 요구한 사항들이 현재 어떤 책임자에 의해 어떻게 수정돼 제품에 업데이트 되고 있는지 눈으로 확인할 수 있다.

고객들은 제품 개발 상태를 실시간으로 파악하고 또 자유롭게 다운로드할 수 있다. 소스의 소유권은 IBM에게 있지만 오픈 소스 커뮤니티의 운영 방식을 채용한 것이다.

이현찬 과장은 “이클립스를 공개한 후 IBM이 내부적으로 많은 변화를 시도하면서 채용한 또 하나의 새로운 방법이 바로 OCSD입니다”라고 설명했다.

사용자 삽입 이미지

고객들로서는 초기 제품 개발부터 적극적으로 참여해 관련 제품의 사상과 구현 방식, 다양한 제품들과의 통합 등을 사전에 숙지할 수 있다. 이렇게 되면 새로운 프로젝트를 진행하는 시간 자체를 대폭 줄일 수 있다.

특 히 이번 프로젝트는 앞서 밝힌대로 분산된 조직들간의 협업을 통해 협업 솔루션을 만들어 내고 있다는 점에 주목할 필요가 있다. 동일한 분산형 조직을 가진 기업들은 이 프로젝트에 참여하면서 자연스럽게 자사의 협업 시스템을 점검해보고 개선해 나갈 수 있다. 말 그대로 산교육장인 셈이다.

재즈 기술에 기반한 첫번째 IBM 제품도 이미 선보였다. 바로 래쇼날 팀 콘서트 익스프레스(Rational Team Concert Express). 고객들은 이 제품의 베타 버전을 무료로 다운로드할 수 있다. 소스도 확인할 수 있다.

IBM은 합법적인 오픈소스 프로젝트를 구현중인 팀과 대학 커뮤니티에 래쇼날 팀 콘서트 익스프레스 1.0을 무료로 제공할 계획이다. 산학협동에도 힘을 싣겠다는 뜻이다.

모든 프로젝트는 협업이 반드시 필요하다. 협업의 수준과 속도에 따라 프로젝트의 성패가 달라진다. 어떻게 협업하느냐가 프로젝트의 성패를 좌우하는지 고객들은 이미 수많은 경험들을 통해 익히 알고 있다. 소프트웨어 개발을 위한 협업 프로젝트이지만 고객들이 주목해야 할 이유가 바로 여기에 있다.

한국IBM은 오늘 오후 협업 기능이 강화된 애플리케이션 라이프사이클 관리(ALM; Application Lifecycle Management) 솔루션인 ‘래쇼날 팀 콘서트(Rational Team Concert)’를 국내 시장에 처음 소개한다.


댓글을 달아 주세요

  1. 정의의소 2008/10/07 18:30  댓글주소  수정/삭제  댓글쓰기

    인물 좋으신데요? ㅋㅋ

  2. 아름프로 2008/10/07 23:20  댓글주소  수정/삭제  댓글쓰기

    헉... ~~
    ㅡㅡ;; 긁적긁적

  3. perdre du poids rapidement 2012/01/14 02:35  댓글주소  수정/삭제  댓글쓰기

    웹사이트 삼일 ! 이 블로그를 다시 읽어 이 사이트를 읽을 자주 !

 
   
     
   
     
   
     
   
     
   
     
   
     
 




 
     

 
 
f

댓글을 달아 주세요

RTC에서 Scurm Process Template 사용하기

IBM Rational 2008/06/30 01:06 Posted by 아름프로

한글화를 마무리하고 오픈하려 했는데, 귀찮니즘에 그냥 일단 오픈해봅니다.
====================================================================================

Scrum Process Template

스크럽은 애자일 방법론(Scrum in wikipedia) 내에 프로젝트를 관리하기 위한 가장 인기있는 방법이다.
내용 요약 :
  • 스크럽을 위한 프로세스 템플릿
  • 이 템플릿으로 Rational Team Concert 에서 스크럽 프랙티스와 룰을 어떻게 하면 잘 사용할 수 있는가.

Scrum Template Overview


프로세스 템플릿에는 '반복 구조', '역할과 권한', '워크 아이템 타입', '쿼리'를 정의

반복 구조 (Iteration structure)

스크럼내 하나의 릴리즈에는 다수의 고정된 스프린트(Sprints)가 세분화 되어 있다. 스크럽 프로세스 템플릿은 다음과 같은 초기의 반복 구조를 정의한다 :
사용자 삽입 이미지








역할과 권한 (Roles and permissions)

스크럼은 다음의 관련 된 권한을 가지는 몇가지 역할이 정의되어 있다.
사용자 삽입 이미지

워크 아이템 (Work items)

다음의 워크 아이템 타입들은 스크럼 아티펙트들을 나타내기 위해 정의되어 있다 :
  • Product Backlog item - 하나의  product back log 아이템은 사용자 스토리에 의해서 도출되고, 스토리들은 타스크로 나눠지거나 스프린트로 할당된다.
    • Attributes : 스토리 포인트(Story Points), 인수 테스트(Acceptance Test)
    • States : Not Done, In Progress, Ready for Sprint Review, Done, Deferred.
  • Sprint Backlog Task - 스프린트 백로그 타스크는 타스크에 의해서 토출되고, 하나의 스토리는 스토리를 구현하기 위해 필요한 다수의 작은 타스크들로 구성된다. 하나의 스토리 및 이것의 타스크들은 부모/자식 링크를 사용하여 서로 관련 된다.
  • 장애물(Impediment) - 진전의 방법을 얻는 것을 추적하기 위해 사용된다.
  • 고찰(Retrospective) - 스프린트 고찰 미팅을 통한 발견을 포착하기 위해 사용된다.
  • 결함(Defect) - 장애, 버그를 추적하기 위해 사용되고, 하나의 결함은 Product 및 Sprint 백로그에 추가될 수 있다.

스크럽 템플릿을 사용하여 프로젝트에 사용 가능한 워크 아이템의 리스트

사용자 삽입 이미지








쿼리 (Queries)

사전 정의 된 쿼리들 :
사용자 삽입 이미지


















규칙/선결조건 (Rules/Preconditions)

개발 업무는 스크럼의 범위 밖이지만, Jazz 프로세스 템플릿에서는 가능하게 되어 있다.
그래서, 스크럼 프로세스 템플릿은 딜리버리 변경을 위한 다음의 선결조건이 추가되어 있다.
  • Clean workspace - 컴파일 에러가 있는 상태에서는 딜리버리 할 수 없음.
  • Descriptive changesets - change sets은 현재의 interation/sprint를 위해 계획 된 워크 아이템과 연계되어야 한다.
    사용자 삽입 이미지

Reports

The template provides a set of built-in reports, that are not specific to Scrum. The following reports are of particular interest when using Scrum:
  • Sprint Burndown: a burn down report.
  • Story Point by Iterations: a report that shows the story points completed per iteration.
These reports are also available in the dashboard.

The Sprint Burndown reports is shown on the charts tab of the iteration plan editor.

Dashboards

The Scrum template defines the following dash board templates:
  • Project: shows open impediments, statistics of stories, burn down across teams, story points by iteration
  • Team: burndown chart for the team
  • Personal: assigned work items and tasks.
    사용자 삽입 이미지

Process description

This description that explains how to use the Scrum process template.

스크럼 프로세스 템플릿의 사용



스크럼을 위한 프로젝트 영역 설정하기

스크럼 프로세스 템플릿을 이용하여 새로운 프로젝트 영역을 생성하기
  • Follow the initialization work items to set-up the project area, define the team members, additional sprints etc.
    사용자 삽입 이미지

  • Add the Product Owner and ScrumMaster as members of the project area, they will be in charge of also administering the project.
    사용자 삽입 이미지

  • Add the team members as members of the corresponding team area:
    사용자 삽입 이미지

  • The scrum template creates an initial category Backlog. You can add additional categories to organize your work items as needed.
    사용자 삽입 이미지

  • Define the start and end dates of the release and the sprints.

The product owner creates the initial Product Backlog

Create a product back log plan for Release 1:
  • Expand the Plans node of your project in the Team Artifact Navigator and select "Release 1.0" and create a plan for the release
    사용자 삽입 이미지







  • Add Stories to the plan. This best done with the presentation "Folders", "User Defined Order" (this settings can be changed in the right sidebar).
  • Use "Add Work Item" from the context menu or CTRL+ENTER to add a Story to the plan.
  • You can sketch the items directly in the plan, typing enter creates a new item etc. and you can enter summary and description directly. Select "Edit Plan Item" from the context menu (ALT+Enter) to get into the sketching mode.
    사용자 삽입 이미지

  • The product owner can order and rank the stories using drag and drop, the context menu, or ALT+Arrow Up/Arrow Down to change the ordering.

Sprint Planning Meeting

  • Before the meeting:
    • The product owner prepares for the planning meeting and updates the Product Backlog
    • Creates new stories or reorders them as described above, assigns priorities.
    • The acceptance criteria/tests for the story can be defined on the "Acceptance Test" tab
      사용자 삽입 이미지




















    • In addition to the Backlog Plan it is always possible to use queries to find particular work items.
    • Create a corresponding Sprint plan for the sprint to be planned.
      • Notice If you have multiple teams working on the product you can create a sprint plan for each team.
    • Expand the Plans node of your project in the Team Artifact Navigator, select Sprint 1 and create a new Plan.
      사용자 삽입 이미지








  • First segment of the meeting: Selecting items from the Product Backlog for the Sprint.
    • Open both the Sprint Backlog and the Product Backlog, both with the presentation "Folders", "User Defined Sort Order".
    • In the Product back log group the candidate stories for a sprint into a folder, for example, Sprint 1 candidates.
  • Second segment of the meeting: Preparing the Sprint Backlog. In this segment of the meeting the team breaks the stories into tasks, team members sign-up for a task, and estimate the effort.
    • The stories are broken down into tasks in the Product back log plan.
    • From the Product back log plan the tasks can be moved to the appropriate team's sprint plan. The tasks can be moved using drag and drop or using the "Plan for" context menu action. When using drag and drop you should arrange the editors accordingly:
      사용자 삽입 이미지

    • Team members are now ready to sign-up for work. To do so, switch the Sprint Backlog to the Group by "Owner" presentation.
    • Team members can now sign-up for tasks and they can be allocated to team members. The bar indicates how the load increases/decreases for a team member during the sprint.
      사용자 삽입 이미지

    • You can reassign work using drag&drop or using the context menu action "Assign to Owner", the submenu shows the team members.

Sprint

  • Team members organize their daily work using the My Work view.
    • Team members can also use queries to find Sprint related work items and sort and group them as needed.
    • They might use the_colorize_ feature to further emphasize work items in the My Work view.
  • They regularly update the estimate and "Time Spent" field in their assigned Task work items. This can be done directly in the My Work View using "Show Work Time" (ALT Right) from the context menu
    사용자 삽입 이미지















  • Scrum encourages minimizing work in progress. Team members continuously update the "Done" status of the Stories using the state field of a Story work item. A story shows the progress on its child tasks (see the progress field).
    사용자 삽입 이미지

  • To prepare for the stand-up a team member can find out what they did since the last scrum by opening the event log on their work:
    사용자 삽입 이미지






















  • If there is an impediment uncovered during the stand-up that needs attention the Scrum Master creates an Impediment work item. If the impediment blocks a particular task then a "blocks" link between the task and impediment is created
    사용자 삽입 이미지

    The list of open impediments shows up on the project's dashboard.
  • Plans are live as work item get closed the status is updated.
  • The Scrum Master consults the sprint burndown chart in the dashboard or the charts tab of the plan to see the progress and the remaining work.

Sprint Review meeting

  • Open the Sprint Backlog to show the achievements
  • Notes from the Sprint Review meeting can be attached to the Sprint Backlog plan directly. To do so create an additional pages for the plan:
    사용자 삽입 이미지

Sprint Retrospective Meeting

  • The ScrumMaster creates a Retrospective work item to capture what went well, and what could be improved
    사용자 삽입 이미지

    • Tasks can be extracted from this page.

댓글을 달아 주세요

제가 jazzlab.net 에 작성한 내용을 다시 제 블로그로 옮겨 온 내용입니다.
비몽사몽 정리하다보니 좀 횡성수설한 감이 없지않아 있지만, 이미지보시면 무엇을 이야기하려는
쉽게 이해하실 수 있을 것 같습니다. (차후 맨정신에 조금식 수정해 나가겠습니다.^^)
링크 : 원본1, 원본2
==============================================================================
"린(Lean) 소프트웨어 개발" 의 첫번째 내용인 "낭비를 제거하라" 는 내용을 Jazz/RTC를 가지고 접목 시켜보았습니다.
그중에서도 "도구1 : 낭비 찾아내기" 관련 7가지 항목(관리활동 포함 8개)에 촛점을 맞추어 적용사례 형태로 화면 캡춰야여
구성해 보았습니다. 업무에 도움 되길 기원하며 시작해봅니다

1. 미완성 작업(Partially Done Work)
1-5.jpg
  • 해당 Iterate Plan 기간내에 마무리되지 못한 작업 내역을 "Plan 관리 화면을 통해서 본 내용입니다.
  • 이를 토대로 해당 기간내에 미완성 된 내역에 대해 분석하여 낭비의 요소를 제거하는 작업을 진행합니다.
  • 우측의 조건을 이용하여 좀 더 다양한 결과도 도출 가능합니다.
@ 추가 내용 (개발팀원의 Working Day 등록 내역 확인)
1-1.jpg

1-2.jpg

    1주일간의 실제 작업 가능 시간을 사전에 정의해 놓을 수 있습니다. (예> 5일 : 40시간)

1-3.jpg

    자리를 비워야하는 경우에는 개발 가능 일정에서 빠져야 할 겁니다. 그것을 대비한 스케쥴 등록 화면입니다.

1-4.jpg

    해외출장으로 작업 가능 시간이 줄어든 것을 확인할 수 있습니다.

2. 가외 프로세스(Extra Processes)

요구사항이 문서화되어야 하고 개발된 코드가 추적 가능하다면, 이 일은 가치를 부가하는 활동으로 간주된다는 점에서
다음과 같은 내용이 가능할 것 같다.

1-6.jpg

    요구사항이 반영된 Work Item 에 관련 소스, 연관 Work Item 등과 같은 관련 정보가 링크되어 연동되어 있어 변경내역등을
    쉽게 알 수 있다.

1-7.jpg

    해당 work item의 연계된 소스의 Change-set 정보를 통해 해당 요청에 따른 변경 소스 내역을 바로 확인 가능하다.

1-8.jpg

    이렇게 연관된 소스는 소스 변경의 내역까지 상세히 비교하여 확인해 볼 수 있다.

1-9.jpg
    해당 Work Item은 위와 같이 변경 내역에 대한 히스토리를 확인할 수 있다.

3. 가외 기능(Extra Features)


    새로운 기능을 넣고 싶은 것의 유혹에서 벗어나는 것이 그 핵심이지만, 시스템의 수정에 따른 추적, 컴파일, 통합, 테스트가
    가능한 환경이라면 어느정도의 가외 기능 추가에 따른 걱정은 덜 수 있을 것이다.
    1-20.jpg  
    하나의 개발환경에서 이 모든 것이 가능하며, 추적이 가능하다면 언급된 가외 기능도 어느정도 허용해줄 만 하지 않을까 싶다.

4. 직무 전환

    팀의 이동 및 업무의 전환에 따른 기존 업무가 방해 된다면 이러한 것 자체를 하지 말라/자제하라는 내용이다.
    하지만, 다른 프로젝트의 일원으로써 작업할 수 있는 여건이 좀 더 개선이 된다면, 아예 하지말라보다는
    현실적인 접근해서는(현실적으로 여러 일을 해야만 하는경우가 많기에..) 개선의 여지가 있을 것 같다.
  1-10.jpg
   즉, 어느 팀에 소속되어 있으며, 무슨 일을 하고 있으며, 그러한 일의 업무량이 얼마나 되는지 체크가 가능하다면 ...
    직무 전환에 따른 리스크를 좀 더 줄일 수 있을 것이다. (물론, 이렇게 안하는 것이 좋다고 이야기하지만... )

5. 대기
  
    결국 대기라는 상태인 것을 팀원들이 공유하고 있는 자체가 가장 중요할 것 같다.
    현실적으로 대기를 함에 있어서도 그것이 대기 상태인지 조차 인지 못하는 것이 가장 큰 문제라면 문제일 것이다.
    1-11.jpg
   앞서 잠시 나왔던 내용이지만, 이러한 것을 통해 대기상태에 대한 관리가 가능해지며, 업무의 치우침 현상도 막을 수 있다.

6. 이동
  
    문서화되어 전달되고, 공유하는 것에 따른 시간적 낭비, 업무 조율을 위해 움직이는 실제 움직이는 시간들의 낭비를 지적하고 있다.
    1-12.jpg
   이 문제는 Web2.0 시대의 산물중 하나인 챗팅기능을 통해 어느정도 해소 할 수 있다.
    실시간 업무 조율 자체를 채팅으로 진행할 수 있으며, 문서 역할을 하는 작업내역이나 소스내역서, 빌드내역서 등을 해당 채팅창에
    가볍게 드래그앤드랍 만 시켜도 링크가 될 수 있도록하면 놀라운 협업 가능 메커니즘이 탄생하게 된다.
    (링크 된 내용은 클릭하면 하면 해당 내역서를 바로 띄워준다.)

7. 결함
  
    긴말이 필요없는 내용인듯 싶다. 테스트와 통합, 릴리즈를 빠르고 효율적으로 할 수 있게 해주는 내용이다.
    1-13.jpg
   빌드 관련 내역 중심으로만 설명했지만, "3.가외기능" 설명에 있는 모든 내용이 이러한 결함 관리의 중요 내용이다.

8. 관리활동
   
    프로젝트와 팀에서 일어나는 일들을 한눈에 볼 수 있는 환경을 얼마나 제공하는지가 중요한 요건이 될 것이다.
    즉, 투명성의 확보다. 이를 통해 팀원 모두가 일관된 팀 작업이 가능토록 해주는 원동력이 된다.
    1-14.jpg

    팀 아티펙트라는 윈도우를 통해 팀에서 일어나는 모든 일들을 다양한 형태로 볼 수가 있다. (변경도 얼마든지 가능하다)
    또한 유사한 형태로 My Work 를 관리해주는 윈도우 또한 가지고 있어 나 자신의 관점에서도 관리가 가능하다.

1-15.jpg

       eclipse 개발환경 뿐만이 아닌, 웹 Ui형태로도 모든 작업이 가능하다. 더욱이 중요한 것은 DashBoard 기능을 통해
       프로젝트의 내역을 한눈에 볼 수가 있다. (보고자하는 내용을 자유롭게 변경하여 구성도 가능하다.)

1-16.jpg
   
    리포트(차트) 형태로 한눈에 알기 쉽게 현 상황을 모니터링 해준다. (이 역시도 변경이 가능하며 결과를 위한 쿼리 역시 쉽게
    생성 가능하다)

1-17.jpg

    좋은 프로젝트 결과에 있어서 가장 중요한 요소로 뽑히고 있는 Feed 도 한눈에 볼 수 있도록 제공 가능하다.

================================================( 끝 )==============================================
TAG jazz, Lean, RTC,

댓글을 달아 주세요

  1. 아름프로 2008/05/08 03:30  댓글주소  수정/삭제  댓글쓰기

    카피를해서인지 이미지 확대가 제대로 동작을 안하네요.
    더 자세한 것은 보시려면 원본링크를 참조하세요.

  2. 정의의소 2008/05/11 11:13  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 테스트 업무를 하다 올해 초 부터 Eclipse Plugin 개발을 하고 있습니다.
    5월 말 릴리즈 후에 RTC를 적용하게 되었습니다. 회사 적용에 대한 검토 과제로 선정되었습니다. 이제 본격적으로 관심을 가지려고 하는데 아름프로님의 블로그와 jazzlab.net을 알게 되어서 기쁘네요. 많은 정보 교류 있었으면 좋겠네요.

    요즘 Test에서 개발의 전환으로 현 생활과 블로그 생활을 못 하고 있었는데 다시 힘을 얻을 수 있을 것 같아 기쁩니다.

    자주뵙죠..^^

  3. 아름프로 2008/05/21 10:48  댓글주소  수정/삭제  댓글쓰기

    에고~ 댓글이 늦었네요.
    정의의소님 만나뵙게 되서 반갑습니다. ^^

정말 오랜동안 블로그에 글 자제하며 차분이 jazz를 준비하였답니다.
jazz라는 것 자체에 대한 이해, 이어서 나오는 RTC(Rational Team Concert)라는 제품...
라이센스 정책 등등... 저 조차도 개념잡느라 시간이 좀 걸린 듯 합니다.

이 시점에 분명히 말씀드릴 수 있는 것은 "실제 보시게 되면 좋아하게 될꺼라는 확신" 입니다.

몇가지 간단히만 소개해 드리면...
  1. Jazz/RTC라는 녀석 하나만 있으면 복합하게 구성해야했던 개발환경을 하나로 가능합니다.
    (SCM, Build, Work Item, Team 커뮤니케이션, ALM 등등)

  2. Agile Practices에 기반합니다.

  3. Eclipse의 성공 모델인 Open Community 정책에 따른 jazz.net 사이트를 통해 IBM의 주옥같은 개발자들과 직접만나 볼 수 있습니다.

  4. 규모에 따른 획기적인 라이센스 정책이 도입되었습니다.
    -> 현 시점에서 공개하기는 어려움이 있습니다. 힌트만 드린다면 Express-C 버젼이 있다는 겁니다.
    (IBM 제품의 Express-C 제품의 의미가 무엇인지 아시는 분은 이해가 가실 겁니다.)

  5. IBM Jazz팀의 개발내역 오픈. 개발팀의 개발 내역을 Jazz/RTC 자체를 이용하여 jazz.net 의 'development 를 통해 완전히 공개하여 진행합니다. 영어에만 자신 있다면 직접 참여도 가능합니다.
    (오늘 현재 5만4천4백여 work item등록된 상황... )

  6. OSGi 기반 커널로 구성된 서버(middleware)의 구성은 다 제품등과의 확장성을 제공합니다.
    -> 툴도 이제는 middleware 기반에서 통합할 수 있는 시대의 시작

  7. eclipse개발의 주역인 에릭 감마가 깊숙히 참여 (포럼과 work item에서 만날 수 있습니다.)

  8. jazz.net 사이트에 방문하시면 무료가입가능하며 현재 개발버젼 다운로드 가능합니다.
    (2월말에 일반인에 오픈)

    등등등...
최근 북미와 유럽중심의 인기몰이(사이트 폭주)로 사이트 증설도 지난주에 진행되기도 하였지만, 국내에서는 아직 홍보 활동을 하지 않아 잠잠한 상황입니다. 정식 릴리즈가 6월말로 발표되었고, 라이센스관련해서도 곧 완료 발표될 예정이라 국내에서도 홍보활동이 조만간 이뤄질 예정입니다.

저 개인적으로는 http://www.jazzlab.net (한국 Jazz 사용자 그룹) 사이트를 오픈한 상황입니다.
(이 사이트는 회사와는 별개로 저 개인의 관심에서 시작한 사이트이니 오해는 않으셨으면 합니다.)
몇몇 분에게만 공개한 상황인데 이제 정식적으로 활동을 시작하려 합니다.
관심있으신 분들의 많은 참여 환영합니다. @^^@
TAG jazz, RTC

댓글을 달아 주세요

  1. Candelaria 2012/01/22 10:03  댓글주소  수정/삭제  댓글쓰기

    블로그 !처럼 우리는 이것이 정말 내 중 하나입니다 사실은 아주 간단에 .