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







저작자 표시
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 영겁회귀
Android2012/04/16 16:37

<supports-screens> 설정시 xlargetScreens를 추가하고서 validate 한 문서가 되지 않을때.



빌드 타켓을 허니컴(Android 3.0)이상으로 세팅.


저작자 표시
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 영겁회귀

Mac OSX 1대, 윈도우 3대로 웹 작업 협업중인데, 

각자 프로젝트의 Preference의 기본 인코딩이 다르고, 개별 파일 인코딩도 달라서

서로 올린것들이 CVS를 통해 내려 받아 열어보았을때, 한글이 깨져 각자 인코딩을 따로 해줘야 하는 짜증나는 상황이 발생하였다.

모두 기본 인코딩을 통일하여도, 같은 문제가 발생하여서 일일이 지정하였다.

소스 저장소와 동기화 하면서 setting 폴더안에 파일이 하나 있어 변경 내용을 보니,

개별파일의 인코딩을 설정 변경 내용이었다.

encoding=UTF-8 

식으로 전체 프로젝트의 인코딩도 지정할수 있고, 그림 처럼 개별 파일의 인코딩도 설정할수 있다.

파일을 직접 편집할 필요는 없고, 자원에서 우클릭하여 Properties에서 변경해주면 된다.

저작자 표시
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 영겁회귀

티스토리 툴바