[u] Story 의 naming convention 을 Story 방식으로 변경함.
팀 내 Rational Team Concert 적용을 위한 가이드 제작 중 유용한 팁이 있어 공유한다.
RTC 에서 Scrum 템플릿을 사용할 경우, 플래닝에 사용되는 work item 타입은 기본적으로 (범위가 큰 것부터 차례로) Epic, Story, Task, 이렇게 세 가지이다. Scrum에 문외한인 사람들뿐 아니라, Scrum 에 나름 익숙한 사람들도 계획을 잡기에 익숙해지기까지는 제법 많은 난관에 부딪힌다. 이에 내 경험을 바탕으로 나름의 노하우를 정리해보았다. 이 방식을 잘 익히고 따른다면 계획을 잡는데 많은 도움이 되리라 확신한다.
덤으로..
추가로..
스크럼이나 유사 Agile 방식에 익숙하지 않다면 Story 의 naming 이 생소할 수 있다. 생각해보면 간단하다. ‘고객/사용자가 이 제품(Product)으로 무엇을 할 수 있다.’ 의 형태이다. Story 를 이렇게 작성할 때 얻게되는 대표적인 이점은 아래와 같다.
혹 스크럼 형태의 Story 네이밍에 익숙하지 않다면 아래와 같은 방식도 시도해볼 수 있다. 하지만 처음 러닝 커브는 작을 지라도, 경험상 정통 스토리 방식이 더욱 효과적이다.
최근 조사 결과를 바탕으로 간략히 현 시대의 소프트웨어 개발 프로세스와 툴의 현황을 공유해본다.
먼저 소프트웨어 개발에 활용중인 프로세스들의 비중을 살펴보자.
다음은 조직내에서 Agile 이 어느 정도 받아들여지고 있느냐에 대한 설문이다.
마지막으로.. Agile 을 지원하는 툴로써 현 시대 제품들을 평가해본 결과이다.
RTC 를 처음 시작하려는 사람들에게 좋은 자료들을 정리해보았다.
한 팀에서 처음으로 RTC 를 사용해 과제를 진행해보고자 한다면, 팀원들을 한 자리에 모아놓고 아래대로 쭉~ 학습해보자. 중간중간 대화와 검색 등의 시간을 합쳐 총 2시간 정도의 workshop 이면 충분할 것이다. 물론 최소 1명은 RTC를 직접 사용해본 경험자가 필요하다.
1. (10분) 다음은 RSSOwl 이라는 오픈소스 프로젝트에서 RTC 를 사용하는 모습을 아주 간략히 보여주는 동영상이다. RTC 가 도대체 무엇을 제공해주는 툴인지, 그 전반을 짧은 시간 내에 훑어보기에 좋다.
2. (15분) 다음으로는 직접 RSSOwl 사이트를 방문하여 위의 짧은 동영상에서 놓친 세세한 부분들을 점검해보자.
RSSOwl – Reader for RSS | RDF | Atom Newsfeeds
데시보드도 훑어보고, 각 반복주기별 태스크 관리, 소스 코드와 결함, 빌드 상황들이 어떻게 보이고 관리될 수 있는지 체크해보자.
* 참고로, 포럼은 오픈 소스 프로젝트 운영에 필수 요소 중 하나이지만 RTC 가 제공하지는 않고 있다. 포럼이 필요하면 취향에 맞는 프리 포럼을 찾아 설치하자.
3. (1시간) 이제 아름프로님이 제작해주신 동영상 강의를 들어보자. 아래의 강의를 시작으로 총 7편, 약 1시간 분량이다.
툴 세팅에서 시작해 프로젝트를 만들고 일정 계획, 작업 내용 작성, 팀원에게 분배하고 과제를 진행하기 직전까지의 내용을 다룬다. 즉, 이 동영상을 잘 따라갔다면 RTC와 함께 과제를 시작할 준비까지 된 상태가 된다.
* 위 동영상은 Scrum 에 맞춰 작성되어 Scrum 에 익숙치 않은 사람들은 용어가 낯설 수 있다. 하지만 툴의 활용성을 파악하는데는 지장이 없을 터이니 걱정하지 말자.
4. (20분) 마지막으로 팀에서 작업할 실제 환경에서 RTC 클라이언트를 설치하고 서버에 연결하는 과정을 직접 시연 & 수행해보게 하자. 간략히 이곳저곳 기능을 살펴보며 궁금한 것들을 답해주자.
5. (10분) 작업 서버에 바로 붙어 이것저것 테스트해보기 부담스러워하는 팀원들이 있다면 누구나 테스트해볼 수 있는 Sandbox 사이트를 소개해주자.
Rational Team Concert Sandbox
미리 실제 과제 환경과 유사하게 프로젝트를 세팅해두면 좋고, 처음부터 다 해보고 싶은 사람은 직접 새로운 사이트를 만들어볼 수 있다. (풍차님의 설명 참조)
자~ 이 정도면 빠르게 시작하기 위한 기본은 어느정도 공유가 될 것이다. 이후부터는 사용해보면서 하나하나 배워나가는 기쁨을 누려보도록 하자.
새로 옮긴 팀에 Rational Team Concert [1] (이하 RTC) 를 적용하기 위해 노력 중이다. 지난 팀에서는 이러저런 이유들로 보수적인 성향이 너무 강해 중도 포기했었지만, 지금의 팀은 가능성이 높아 보인다. 특정 툴을 적용하다는 것이 중요한 것이 아니라 적절한 인프라를 구축하여 팀의 협업 능력을 극대화시킨다는데 목적이 있고, 현 시점에서 가장 훌륭한 툴이 Rational Team Concert 라 판단되어 진행중이다[2].
최근엔 지난 팀에서 RTC 를 전파할 때 한꺼번에 너무 많은 것을 이해시키려 한 경향이 컸었다는 생각이 든다. 따라올 수 있는 사람들은 따라왔지만, 제법 많은 사람들은 너무 많은 변화에 기겁을 하고 섵불리 도전하지 못했을 수도 있다. 여기에는 RTC 의 다양한 기능뿐 아니라 방법론과 사상도 포함된다. 예를 들어, 기본적인 개발 방법론에도 익숙치 않은 사람들에게 애자일이니 스크럼이니 하는 이야기까지 짧은 시간에 전파하려 한 것은 좋지 않은 시도였던듯 싶다.
그래서 이번엔 이런 이질적인 내용을 최소화하는 방법을 채택해보기로 하였다. 팀에서 업무를 진행하며 이루어지는 실제 활동들을 use case 로 잡아, RTC 를 사용했을 때의 모습을 긴 시간에 걸쳐 조금씩 보여주려 한다. 현재 잡아놓은 use case 들은 아래와 같다.
기본적인 활용에 익숙해지면 여러 동영상 자료들도 활용해 볼까 생각중이다.
팀 내의 커뮤니케이션이 제대로 이루어지지 않으면 팀의 생산성에 치명적인 영향을 미침은 모두가 잘 인지하고 있는 사실이다.
제때 피드백을 받지 못해 엉뚱한 일을 하거나, 잘못 (혹은 부족하게) 전달된 정보로 인해 엉뚱한 방향으로 진행되어 낭비하는 시간은 오히려 가볍게 여겨진다.
조직이 커질 수록 다른 문제들이 더 크게 부각되는데, 얘를 들면 이러하다. 관리자는 자신의 역할(관리)를 충실히 하기 위해 수시로 현황 보고를 요청하고, 개발자들은 산재한 정보들을 취합해 보고용 자료를 만드느라 일할 시간일 뺏긴다. 작성해 놓은 정보가 검색이 안되어 사람들이 매번 물어본다. 메일 공지로도 뿌리고 직접 설명해주지만, 당장 필요한 사람이 아니면 귀담아 듣지 않아 같은 일이 무한 반복된다.
이런 문제들을 미연에 방지하기 위해 우리는 다양한 협업 툴들을 활용한다. 하지만 이 툴들을 잘못 선택하면 득보다 해가 되는 경우도 심심치 않으니 많이 알아보고 신중히 정하는 것이 좋다. 당장 사용할 인프라가 급하다면 할 수 없지만, 지속적으로 시장을 모니터링하여 더 나은 솔루션을 발견하면 언제든 변경할 수 있다는 자세를 유지하는 것이 좋다.
툴 선택을 잘못했을 시 발생할 수 있는 문제를 실례를 바탕으로 살펴보자.
다음 표는 A Team 에서 선택해 사용하던 툴들과 Rational Team Concert (RTC) [1] 사용을 고려중인 팀의 상황을 비교하고 있다.
* 파란색은 비교 우위, 적색은 반대를 의미한다. (by feature/usability)
보다시피 A 팀은 제대로 연동되지 않는 10여개의 툴들을 사용하고 있고, 더욱이 각각의 툴의 사용성 또한 좋지 않은 경우가 많다.
여기서 쉽게 예상되는 사태는 ‘정보 분산’ 과 ‘분산된 정보를 취합하기 위한 엄청난 노력’ 이다. 그 노력의 대부분은 당연히 실무자들의 몫이다. 관리자들은 ‘상황을 정리해서 보고하라’ 는 말 한 마디로 보기 좋게 정리된 보고서를 받아볼 수 있다. 관리자의 의욕이 불탈수록 실무자들은 보고를 위해 정작 중요한 업무 진도는 못나가는 사태가 벌어진다.
심각한 문제가 하나 더 있다. Excel 에 정리되어 있는 요구사항은 몇 달에 한 번 꼴로 꺼내어 보고, 태스크는 체계적으로 관리되고 있지 못하다. 업무 부하량도 측정할 길이 없으니 위에서는 생각나는데로 새로운 일을 꽂아준다. 이렇게 일이 진행되다 보면 내가 이 일을 왜 하고 있는지, 옆 사람은 지금 저 일을 왜 하고 있는지 점점 오리무중이 되어간다. 실무자들은 context-unaware 상태에서 수명 업무만을 처리하는 수동적인 자세로 변해간다.
반면 RTC 를 사용하려는 팀은 2~3 개 정도의 툴만으로 훨씬 많은 요소들을 커버하고 있다. 대부분의 데이터는 하나의 DB 에 통합 관리되며사용성 또한 월등히 뛰어나다. 실무자들은 보고에 신경쓰지 않고 열심히 일에 집중한다. 관리자들은 개발자를 방해할 필요 없이 언제건 툴에서 실시간으로 자동 생성해주는 비주얼한 리포트들을 볼 수 있다.
나아가 내가 작업하고 있는 태스크는 어떤 요구사항에서 나왔는지, 관련된 일은 무엇무엇이 있고, 진척률은 어느 정도이고, 우선 순위는 어떻게 되는지 등 자신이 하고 있는 일의 위치를 항시 정확하게 파악할 수 있다. 어떤 요구사항에 결함이 몇 개 있고, 어떤 빌드에 수정본이 반영되어 있는지까지 쉽게 쉽게 추적이 가능하다.
케이스 별로 자세한 work flow 들을 비교해볼까 하다가 너무 길어져서 생락한다.
몇달 전에 프로젝트 투명성(Project Transparency)에 대한 글[1]을 올린 적이 있다. 당시에는 프로젝트에 투명성을 부여함으로써 얻을 수 있는 장점을 중심으로 설명하면서, 이를 읽은 프로젝트 팀들에서 투명성 확보를 위해 노력해주길 바라며 글을 적었다. 하지만 최근에 들어서는 관리자들이 일부러 과제를 불투명하게 만들고 있는 것이 아닌가 하는 의구심이 들기 시작했다. 아니! 감시 받는게 아니냐는 느낌을 떨치기 어려운 실무자들도 아니고, 오히려 현 상황을 정확히 알고 싶어할 듯한 관리자들이 도대체 왜? 지금부터 천천히 이야기 해보기로 하자.
나는 Rational Team Concert (RTC) [2] 라는 Application Lifecycle Management 시스템은 팀 내에 소개/교육/운영하고, 몇 차례에 걸처 그 결과를 공유한 적이 있다. 당시 (지금까지도) 우리 팀은 과제 시작 후 크고 작은 릴리스 중 단 한 번도 목표일을 지켜본 적이 없었고, 지연 기간도 들쑥날쑥 예측이 어려웠다. 릴리스가 끝나고 나서야 비로서 ‘아! 이번엔 이만큼 지연됐구나’를 알 정도였다[3].
수 개월 동안 몇 차례의 릴리스 기간을 거치면서 RTC 가 보여주는 정보는 항시 일관적이고 명확했다. ‘현 상태로는 일정을 맞출 확률은 0% 이다.’ ‘당신의 팀은 task를 끝내기도 전에 끊임없이 새로운 task들을 더 추가한다.’ ‘당신 팀의 업무 수행 능력은 이 정도이다.’ ‘따라서 목표를 다 이루려면 x 일 정도 지연될 것이다.’ ‘일정에 맞추려면 a, b, c 등의 task 를 뒤로 미뤄야 한다.’ 이런 정보들을 한 눈에 확인할 수 있는 실시간으로 그래프를 제시해준다. 대표적인 그래프인 burndown chart 의 예[4]는 아래와 같다.그림과 같이 프로젝트의 현 상황과 진행 추이, 예상 완료 시점 등을 바로 확인할 수 있는 그래프를 전체 팀은 물론 서브팀별로 만들어주고, 누구나 보고 싶으면 언제든 웹을 통해 접근할 수 있다.
(Note: 위 그림은 우리 과제에서 얻은 실제 데이터 도, RTC 가 생성한 그래프도 아니다. 이해를 돕기 위한 단순 참고용이다. 또한 burndown chart 의 개념은 RTC 라는 특정 툴에 종속적이지 않다. Agile/Scrum 쪽에서 널리 활용하는 프로젝트 관리 기법으로 툴 없이도 쉽게 만들어 활용할 수 있다. RTC는 단지 이를 지원할 뿐..)
자! 어떤 결과가 예상되는가? 실무자들 중에는 사용해보고 싶다는 사람들이 조금씩 늘어났다. 반면 관리자들 중에서 관심을 가지는 사람은 거의 전무했다(그나마 계정만 만들고 실제 사용은 안함). RTC 라는 새로운 환경에 적응하기 위해 가장 많은 변화와 노력을 기울여야 하는 실무자들이 관심을 더 보이는 이유는 무엇일까? 역으로, 프로젝트의 목표와 일정을 세우고, 우선 순위를 조정하고, 업무 부하를 관리해야 하는 관리자들은 도데체 무엇 때문에 관심 자체를 보이지 않았던 것일까?
실무자들이 쓰는 이유는 주로 이러했다.
관리자들이 쓰는 이유는 알 수 없다. 쓰는 사람이 없으니 -_-a
그렇다면 관리자들이 외면하는 이유는? 물론 수많은 요인들이 복합적으로 작용했고, 사람들마나 차이도 많다. (Note: 설문조사를 한 것은 아니고.. 대부분은 이런저런 주변 정황과 평소의 대화들을 토대로 유추해본 것 뿐이다.)
투명해지면 안된다고 생각하는 사람들은 상위 지배층과 외부 사람들(stakeholder, customer 등)을 대하는 사람들일 경우가 많다. 이들에게 투명한 과제가 장점을 발휘하려면, 그 과제가 정말 잘 진행되고 있어야 한다는 전제가 깔린다. 이러저러한 문제들이 산적한 상태에서 잘못 공개되면 지원이 줄어들고 대기 수요가 빠져나간다. 이들에게는 안좋은 것을 숨기고 희망찬 메시지만 전달해주어야 한다. 단번에 ‘3달쯤 지연될 겁니다’라고 얘기하면 ‘그렇게까지는 못 기다립니다’라고 하지만, ‘1주일만 더 기다려주세요’를 여러차례 반복하면 ‘이왕 기다린 거, 이번엔 꼭 된다니깐 조금만 더 기다려보지. 등 돌리기도 늦은 것 같고..’ 하는 반응을 이끌어낼 수 있다.
위와 같은 이유로 의도적으로 투명성을 제한하려는 사람들이 있다고 믿는 근거는.. ‘팀 리더로써 가장 중요한 것은 프로젝트를 부러뜨리지 않는 것’ 이라거나, ‘이런 건 누구누구가 알면 안되는데’ 라며 정보 공개를 불편해하는 발언 등을 하는 윗 사람들을 종종 보았기 때문이다. 프로젝트를 계속 유지하는 것은 물론 중요하다. 하지만 외부에 알려진 것 대비 심각하게 안좋은 상황에서도 무리하게 정보를 숨기는 것은 과연 어떨까? 상황을 만회하기 위해 뒤에서 열심히 고생하는 개발자들과 이를 믿고 투자하는 사람, 제품을 기다리는 고객 모두에게 악영향을 미치게 된다. 투자자가 개발팀이 속한 회사 자체라면(내부 프로젝트), 그 팀은 프로젝트를 유지할 수록 회사의 경쟁력을 떨어뜨리게 된다.
다른 관점에서도 불투명한 과제가 (부정적인 의미에서) 도움이 될 때가 있다. 우리 팀의 모습을 앞서의 그림에 맞춰 비유해보면, 윗사람은 day 10 에 ‘자! 내일이 드디어 릴리스 날입니다. 오늘 저녁까지 남은 일들을 모두 완료해 주시고, 검증이 완료될 때까지 자리를 지켜주세요.’ 라고 당당히 요구하고, 또 그것이 개발자들에게 먹힌다. ‘얼마나 걸릴까요?’ 라는 질문은 없다. ‘반드시 끝내세요.’ 라는 요청이 전부이다. 실무자들은 불만이 있어도 드러내놓고 표출하지도 못하고, 밤 늦게나 자정을 넘어서까지 일을 한다. 당연히 기적은 일어나지 않는다. 만약 위와 같은 정보가 다 공개되어 있다면? 윗사람이 앞서와 같은 요구 자체도 할 수 없겠지만, 만약 그런 요구를 한다면 ‘당신은 눈이 없소?’ 라고 반박해도 할 말이 없을 것이다. 즉 과제가 투명해지면 지금까지와 같은 무리한 명령을 내릴 수 없다.
이상의 이유들로, 수단 방법을 가리지 않고 과제를 살리려 한다거나 전통적(?) 지배체제를 유지하고자 한다면, 프로젝트가 투명해지는 것은 커다란 위험요소가 될 수 있다. 이에 해당하는 사람들은 의도적으로 진행상태를 숨길 수 있다.
만약 이런 현상이 정말로 의도적으로 이루어진 것이라면 개선하기란 정말 쉽지 않다. 앞서 언급했듯, 팀을 이렇게 만든 사람들은 대부분 프로젝트 방향을 좌지우지할 수 있는 힘있는 사람들이기 때문이다. 자료를 아무리 제시해도, 개선의 움직임이 보이긴 커녕 거들떠도 보지 않는다면 실무자들도 제풀에 지쳐 변화를 포기한다. 힘있는 자들의 마인드가 바뀌지 않으면 조직의 문화를 바꾸는 것은 거의 불가능하다.
정리: 관리자들 대부분이 이와 같다는 의미는 절대 아니지만, 그 중 일부가 이런 생각을 어느 정도 가지고 있는 것은 분명한 것 같다. 따지고 보면 비단 특정 팀이나 회사, 소프트웨어 개발에만 국한된 현상도 아니다. 정보를 통제하는 언론, 기업의 홍보 부서, 조직의 대변인, 심지어 모든 사람 개개인이 외부로부터 자신을 지키기 위해 어느 정도는 이런 성향을 가지고 있다. 하지만 숨기는 대상에 외부 경쟁자들뿐 아니라 자신들을 믿고 따르는 조직원들까지 포함시켜 그들에게까지 희생을 강요하는 상황에 이른다면 문제는 심각하다. 이런 조직에서 과연 얼마나 많은 사람들이 진심으로 자신의 역량을 모두 쏟아 부어줄까? 하나의 팀이라고 말하기조차 부끄럽다.
RTC/Jazz 를 사용하면서 아쉬웠던 것 몇 가지를 뽑자면, 어설픈 통합 메신저와 텍스트 위주의 빈약한 편집 기능이었다.
Lotus Sametime 등 별도 외부 메신저를 쓸 수 없는 사람들을 고려해서 자체 메신저를 좀 더 보강해준다면 더 없이 좋을 터인데.. 그쪽은 아직 우선순위가 높지 않은 듯 하다.. 한창 3.0 계획중이니 요구사항을 올려봐야겠다.
편집 역시 Wiki 정도의 풍부한 표현력을 보여준다면 한층 호응도를 높일 수 있을 것이다. Project Plan 등에서 이미 Wiki 를 사용하고 있어서 이를 work item 편집에도 반영해달라는 요청이 몇 번 있었는데, 이러저런 이유로 당시엔 거절했었다.
아무튼.. Google Wave 소개 동영상을 보고 있자니 RTC 의 단점들을 보완해줄 훌륭한 기술들이 확실해 보인다. 문제는 다른 회사이고 아직은 서로 자신들의 일에 집중하느라 벌써부터 협업을 바라기에는 무리이지 싶다.
IBM Rational 도 소셜 개발이라는 측면을 전혀 고려하지 않는 것은 아니다. RTC 3.0 계획에 이미 OpenSocial 연동 등이 item 으로 잡혀 있고, 지난 8월 25일에 있었던 “Working smarter:Enriching the Jazz environment with social software” (mp3, transcript)라는 텔레컨퍼런스에서도 관련 주제로 이야기가 오갔다. IBM 에선 당연하게도 자사 제품인 Lotus Connections 를 1차 대상으로 삼고 있다.
Google Wave 가 어찌될 진 모르겠지만.. Connections 는 아무래도 상용 제품이다보니 RTC/Jazz 와 잘 융합된다해도, 나와같은 사람은 그 혜택을 얼마나 누릴 수 있을지 짐작하기 쉽지 않다. 또한, Connections 는 Blog, Wiki, Profile 등 기존 유명 소셜 기능들을 잘 묶어놓았다는 느낌 정도이지만, Wave 는 혁신을 함께 수반한 훨씬 멋진 제품이 될 것 같다.
결론은.. 오픈 프로젝트를 하는 사람들이 참 부럽다. 좋은 툴들은 부담없이 사용해볼 수 있고, 접목할 수 있으니.. 나처럼 손가락만 빨고 있을 필요는 없지 않은가. ^^
드디어 RTC 2.0.0.1 이 릴리스되었다.
버전 넘버로만 봐서는 아주 작은 변화이지만, 여타 소프트웨어의 0.0.0.1 변화와는 차원이 다른 진보를 보여준다(New and Noteworthy). 기능적인 변화들도 물론 훌륭하지만, 그 중 내 눈에 가장 들어오는 것은 바로 라이선스 정책의 변화이다.
기업에 이를 적용하려 시도할 때 가장 큰 걸림돌이 바로 라이선스 비용이었다. 심지어 이것 때문에 툴이 얼마나 유용한가 테스트(trial)도 안해볼 정도로 보수적이다. 아래는 이번 릴리스에서 완전 공짜 버전인 Express-C 를 사용할 경우의 라이선스이다.
위 조건이면 소규모 개발팀에서는 프로젝트에 필요한 거의 모든 솔루션이 RTC 하나에 다 묶여 있다는 의미이다. Contributer 라이선스가 무제한이기 때문에, 이를 인터넷에 오픈하면 그대로 고객/개발자간 소통의 장이 된다. 심지어 대규모 개발팀에게도 직접적인 개발을 제외한 기능들이 다 포함되게 된다. 물론 공짜로 말이다.
현 우리 팀에도 다시 한 번 홍보를 해볼 생각이다. 워낙 보수적이고 발등에 떨어진 일 처리에만 급급해서 정말 도입되리란 기대는 많이 않지만 ‘아쉽지~’ 라는 생각은 해볼 수 있게 될 듯.. ^^ 우리 팀에 적용되면 다음과 같은 일들을 처리할 수 있다.
물론 위에 나열한 모든 항목들 각각이 지금 우리 팀에서 사용하고 있는 것보다 훨씬 효율적이고, 서로 유기적으로 연동되어 있다.
Ref: Rational Team Concert 2.0.0.1 released!
WolfPoker 라는 RTC/Jazz 용 Planning Poker 플러그인을 소개해본다.
아직 개발 단계이고, 또 1.x 대 버전만 지원하고 있어서 직접 테스트는 해보지 않았지만 재미있을 듯 하다. 직접 마주 앉아 게임을 진행하는 것이 의사소통면에서 훨씬 빠르고 효율적이므로, 위 플러그인은 아무래도 개발자들이 물리적으로 떨어져 있는 상황이 아니면 크게 활용되진 않을 것 같다. ^^
RTC 2.0 은 Eclipse 3.5 와 거의 같은 시기에 출시되었는데, 아쉽게도 이전 버전인 Eclipse 3.4 버전을 기반으로 하고 있다. 또한 OS X 는 레퍼런스 플랫폼이 아니라 공식적인 지원이 없는 상태이다.
하지만 Linux/Solaris 등 Unix 계열 플랫폼을 이미 지원하고 있고, 다행히도 Eclipse 3.5 와 3.4 의 호환 수준도 높아 몇 가지 간단한 수정만으로 둘 모두와 연동시킬 수 있다.
두 개의 레퍼런스가 있는데, 서로 커버하는 영역이 조금 달라서 모두 소개한다.
크게 보면 위의 것이 둘 모두를 다르고 있지만, repotools 동작 문제에 대해 다루지 않고 있다. 나도 처음에 위의 아티클을 따라 설치 후 사용하고 있었으나, 방금 repotools 수행에서 막혀 정보를 찾아보던 중 두 번째 자료를 발견했다.
