스스로 해보기2012.06.15 22:42

이슈트래커를 도입한건 약 2~3년전.. 


이슈트래커를 팀내에서 야침차게 도입해 보았지만 어느새 뜨뜻 미지근하게 사용이 줄더니 이제는 문서 관리 용도로 사용중이다.

개발자 둘, 기획자 둘로 이루어진 내가 속한 작은 팀은,  기민한 구석도, 기민할 필요도 별로 없는 조직이었다.

수년간 유지해온 서비스를 유지보수만 하면 되었고,  슈퍼갑들의 잠깐의 만행 아니면 급할일도 별로 없었기 때문이다. 

유지보수 업무를 같은 구성원이 10년 가까이 진행한다는 것은 참 지리하거나 뻔한 일들의 나열이 될 가능성이 높다.

실제로 나의 팀도 같은 양상으로 분위기가 조성되어 있다. 


기획,개발 각 파트에서 선임자격으로 일하게 되는 각 1명씩. 그밑에 실무자 형식으로 협업을 진행하는 각 1명씩.

기획파트의 선임은 또 회사 전체 조직내에서 선임격이었고 (가장 대빵으로 여겨지는..) 진행하는 일을 따오거나, 가끔 외부 연락을 한다거나 발만 살짝 담근 정도 였고, 실무자는 그 밑의 기획자와 나머지 개발자 둘이었다.


이슈를 공유하고 업무를 전달하는 방법은, 이메일과 메신저 그리고 가끔씩 구두하는 식이었는데.

블랙홀이 하나 있었다. 실무 개발자중 한 명이,  이멜일을 통한 답장(Re), 전달(Fw)등의  커뮤니케이션을 전혀 진행하지 않았다.

개발이 완료가 되면 메신저로 한마디 날리고 끝이고 어쩔때는 메신저로 통보도 하지 않는 경우도 있었다. 

또한 선임 개발자를 통해서 자신에게 온 경우에는 업무 진행상황이나 처리 결과들을 이메일 또는 간단하게 메신저라도 공유를 하여야 업무를 넘긴 입장에서도 진행사항을 파악 할수 있는데 전혀 그런게 없었던 것이다.


책 '자바프로젝트 필수 유틸리티'에서 처음 구경하게된 이슈트래커 Trac은 이러한 문제점을 해결해줄 좋은 도구로 생각되었다.

이슈트래커로 가능한 것들중에 매력적이어던 몇가지를 소개하면, 


첫번째로, 역시 공유기능이다.

업무를 생성하여, 업무를 전달(할당)된 이력과 진행 상황 그리고 완료여부를 체킹만 제대로 해준다면 모튼 관련 팀원들이 쉽게 공유가 가능하다.


두번재는,  관련 자원을 쉽게 구분해 낼수 있다는 점이다.

진행중인(active) 업무(Task라고 칭함)는 이슈트래커 내에서 진행중이라는 체킹을 해주게 되면,  진행중인 상태에서 Task가 접근한 자원을 구분해 낼수 있다. 진행중인 상태에서 접근 자원을 기록한다는 체크만 해두면 해당 자원의 목록을 그 Task자체가 기억을 할수다 있다. 간단하지만 매우 편리한 기능으로, 그 Task에 대한 작업이 다시 이루어지거나, 다른 팀원이 어떤 자원들이 이 작업에 쓰이거나 필요한지 알고 싶다면 해당 Task열어 보기만 하면 되는 것이다.


세번째는, 히스토리 기능으로,

첫번째 두번째 항목을들 활용하여 시스템이나 프로젝트의 훌륭한 이력관리 시스템이 될수 있다는 점이다.

첨부 파일도 자유롭게 첨부가 가능하고, 위키 문법도 지원이 되기 때문에 팀원들이 관심을 두고 같이 사용해 준다면 효과가 아주 좋은 시스템이 될수 있는 시스템이었다. 


거기에다가, 상부에 결제가 필요없는 무료이니 얼마나 매력적이었는지.


'자바 프로젝트 필수 유틸리티'라는 책을 구매한후 시스템을 적용해 나가기 시작했다.

책의 내용은 따라하기를 따라가기만 하면 되는 구조여서, 따라하면서 흔히 만나는 현행 버전과 책이 불일치 하는 문제를 제외하고는 큰 문제없이 시스템을 적용해 나가기 시작했고, 시스템자체와 몇가지 플러그인 그리고 알람 기능을 위한 서버 설정등과 컴포넌트 및 마일스톤을 회사 시스템에 맞게 커스터마이징 하고 난후에는 회사에서는 쓸만한 이슈트래커 시스템을 완성하게 되었다. 


이제 프로젝트 및 태스트들에 대한 이력관리 및 공유가 제대로 굴러가기라 기대 했지만, 몇가지 문제가 있었다. 


시스템을 구축한후 간단한 프리젠테이션을 통하여 이제 부터 이 시스템을 사용하여 업무를 공유할것이며 자원및 이력 관리를 할 예정이라고 간단한 회의를 마쳤다. 


이때 마주친 첫번째 난관은 기획자의 적응여부 였다. 

이슈트래커 시스템은 기본적으로 웹인터페이스 기반으로 사용하게 된다. 하지만 웹UI가 그다지 사용자와 친숙하지 않은 것이어서 복잡한 UI를 사용해 본적이 없는 기획자는 적응하기가 힘들었다. 시스템 자체가 영문화 되어있고, 커스터마이징이 일정부분 가능하긴 하지만, 이에 대한 한글화 및 커스터마이징을 진행하기에는 시간과 자원이 너무 많이 소모될 것 같았다. 


그래서 이클립스의 플러그인을 사용하도록 했다. 이클립스의 새로운 IDE를 붙여서, Trac을 사용할수 있는데 오히려 웹 인터페이스보다는 이클립스의 플러그인 UI 가 간단하고 게시판 모양과 흡사하게 이루어져 있으져 친숙했다. 이클립스를 설치해주고, (다른 기능은 필요없으므로) 플러그인을 설치하여 사용법을 익히도록 하였다. 실무 기획자는 곧 적응 할수 있었고, 문제는 끝난 것으로 보였다. 


그후의 가장 치명적인 문제는 그룹 구성원에게서 나왔다. 

하나는 실무 개발자에서 나왔으며, 두번째는 선임 기획자로투 부터 나왔다.

업무관련 커뮤니케이션에 최선을 다할 의지가 없었던 개발자는 트랙 시스템에도 쉽게 적응할 의지가 보이지 않았다. 

실제로 이슈를 관리하기 위해서는 자신이 생성한 태스크나 자기가 타인에게 할달하거나 타인에게 할당 받은 태스크를 주의 깊게 관리를 해주어야 한다. 할당받은 경우에는 해당 태스크의 이력을 살펴본다거나, 관련 구성원등을 살펴보는 행위. 태스트를 진행하면서 관련 자원을 체크해주는 일, 진행 과정에 따라 상태를 기록해 두는 일등이 필요한데,  귀찮게 생각하면 마냥 귀찮기만 한 일인 것이다.  이 개발자는 그의 '이력'대로 진지하게 이슈를 관리하기에 참여하지 않았고, 기획자는 계속 되는 불성실한 커뮤니케이션 태도(구성원과의 친밀도를 위한 것이 아닌 업무를 위한)에 분통을 터트리기 시작했다. 


나머지 하나의 문제는, 선임 기획자에서 나왔다. 

이 기획자는 시스템 사용을 처음부터 거부했는데, 이유는 그냥 '복잡 한것 싫다'였다. 직위상으로 더 높은 위치였기 때문에, 강제로라도 시스템을 이용하도록 할수가 없었다. 실용적으로 생각해 보아도, 직접적인 기획 업무는 하지 않더라도 업무를 갑이나 협력사로부터 가져오는 위치 였기 때문에, 이슈를 등록해주는 시발점적인 역활을 할수 있는 위치였음에도 불구하고, 진행상황 관리와 이력 관리에 관심이 없었던 것이다. 가장 높은 직위의 구성원이 시스템을 거부하고 참여하지 않게 되면서, 시스템은 구성원들에게 위력을 잃기 시작했다. 실제적으로 지시하는 위치에 있는 팀원이 이슈나 컴포넌트를 정의하고 생성하여 세부사항이나 관련 문서들을 업로드하여 업무를 시작하면 가장 이상적인 모습인데, 그 밑의 기획자가 구두나 메신저로 전달받고, 다시 메일을 자신이 읽고 파악하고 이슈를 생성하고 이력관리를 시작하는 이중부하가 걸리기 시작했다. 


권위를 잃어버린 시스템은 점차 힘을 잃기 시작했다.  이슈관리 수는 서서히 줄기 시작했고, 이제는 업무 관련 문서들을 저장해 놓는 역할로만 사용 중이다. 


그 뒤에도 다른 팀 또는 다른 부서에 적용하려는 시도가 있었지만, 번번히 실패로 돌아가고 말았는데, 

가장 큰 원인은 구성원의 관심 또는 참여가 부족했던 이유었던거 같다. IT일이라는 것이 각자 파티션안에서 결국 자신의 개별적인 도구(컴퓨터)에서 이루어지는 개인적인 작업이기 때문에, 구성원의 참여가 절대적이다. 실제로 이메일이나 구두 또는 메신저로 진행하는 것은 당시에는 편하지만, 결국에는 다시 떠올리기, 다시 뒤져보기 같은 이중작업, 소모적인 작업이 반복되기 마련인데. 이슈나 태스크에 대한 관리를 귀찮아 하여 눈앞에 귀찮음 때문에 시스템을 외면한것 같아서 아쉬운 부분이다. 







저작자 표시
신고
Posted by 영겁회귀
trac 구축 중 템플릿 엔진인 Genshi 설시치에
Python2.5용 Genshi를 설치시 Genshi 사이트에서는 0.5버전의 윈도우용 링크가 없다.
못찾을 경우엔 아래 URL에 모든 버전이 리스트업되어있으므로, 필요한 대로 다운로드 받는다.

http://ftp.edgewall.com/pub/genshi/
저작자 표시
신고
Posted by 영겁회귀
TAG genshi, Trac
이클립스의 Mylyn 플러그인을 통해 Trac서버와 연동하게 되면, 개발자는 웹페이지를 통해 Trac의 내용을 따로 열람할 필요없이
이클립스 하나로 Trac관련 작업을 모두 할수 있게 된다. 

Trac서버와 Mylyn이 연결되는 방법은 2가지로 HTTP와 XML-RPC 이지만, HTTP방식은 Trac 0.10 버전까지만 지원한다고 하니 xmlrpc 플러그인이 되어있어야 한다.

1) Mylyn 플러그인 이클립스에 설치하기

Eclipse 메뉴바 > Help > Software Updates.. 를 선택하면
설치되어있거나 설치 가능한 업데이트를 찾아 볼수 있는데  협업 도구 도중에 다음 5개를 선택하고
install 한다.


Eclipse Ganymede 버전에서는 기본적으로 Mylyn 플러그인이 딸려온다.
이미 설치되어 있다고 알린후, 업데이트할것이 있으면 업데이트를 시행한다.
동의화면이 나오고 동의를 선택하면 설치/업데이트를 수행한다.

다음으로,
Trac과 Mylyn을 연결하기 위해 필요한 connector를 설치한다.
설치할 플러그인의 URL은
http://download.eclipse.org/tools/mylyn/update/extras/
위와 같다.

Help > Software Updates.. 에서 Available Software 탭에서 'Add Site' 메뉴를 통해
플러그인의 URl을 입력한다.

Mylyn integration > Mylyn Connector:Trac을 설치한다.
 
설치한다.

설치 도중 다음과 같은 에러를 만날 수도 있다.
Cannot complete the request.  See the details.
Cannot find a solution satisfying the following requirements Match[requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.ui.workbench/[3.4.2.M20090127-1700,3.4.2.M20090127-1700]].
3.4의 플러그인 설치시 가끔 일어난다고 하는 문제로
가장 간단하고 확실한 해결방안은 Ganymede SR2 버전으로 IDE를 교체하는 것이다.
http://www.eclipse.org/downloads/packages/release/ganymede/sr2 에서 sr2 버전으로 IDE를 교체한다.


2) 이클립스에서 Mylyn 플러그인 사용하기

이클립스 메뉴바 > Window > Open Perspective > Planning 선택

Planning Perspective는 로컬 Task나 공유하고 있는 Task등을 관리할수 있는 곳이다.
Trac 서버를 Task Respository로 지정하기 위해서 Query를 하나 작성한다.

Query를 생성하려고 하면 Repository를 선택하여야 한다.
'Add Task Repository..'로 저장소를 새로 등록한다. 

Mylyn Connector : Trac이 설치 되었기 때문에, XML-RPC를 통하여 Trac과 연결할수 있다.

Server의 주소 IP와 Password등을 넣고 연결한다.

연결이 정상적으로 이루어 진다면 새 쿼리 작성이 가능하다.

Task를 조회 할 여러가지 조건이 나타난다.

조건을 설정 검색을 완료하면
조건에 해당하는 Task의 목록을 볼수 있다.

다음은 Task를 생성하는 화면으로, Trac 서버의 웹화면과 동일하다.


마찬가지로, assign, accept, 수정등의 Task와 관련된 모든 작업을 Task list를 통하여 진행할수 있다.



저작자 표시
신고
Posted by 영겁회귀

티스토리 툴바