이슈관리 공학도구(Trac) 소개 및 예제화면, FAQ

Full Size Guide 를 만들었습니다만, 우선 간단한 소개와 FAQ를 먼저 공유하기 위해 정리해 보았습니다.

적용소감을 간략히 이야기 드리자면

- 사용방법이 매우 간단해서 별다른 설명 없이도 직관적으로 사용할 수 있다

- 이슈 공지(Notification)가 자동적으로 전달 되기때문에 이슈관리 대장(엑셀파일)을 계속 확인하거나 폴더들을 드나들 필요가 없다

- 이슈의 흐름과 진척상황이 보인다.

입니다.

기타 아래에 있는 FAQ에 상세한 내용을 담았습니다

---------- started here ------------

이슈관리 공학도구(Trac) 소개 및 예제화면, FAQ

1. Trac 소개

Trac은 이슈의 관리와 할당/추적을 지원하는 오픈소스 제품입니다.

기존의 툴들(버그질라, 맨티스)이 버그 추적(Bug Tracking)에 중점을 두었었다면, Trac 은 업무(task or issue)와 버그를 통합한 형태로 관리합니다. 한가지 독특한 점은 trac에서는 버그나 이슈를 티켓(Ticket)이라는 형태로 통칭해서 부르고 있다는 점입니다. 한글에서 동음 반복문이 좋은 표현이 아니라는 것처럼 issue the issue 라는 표현을 재치 있게 issue the ticket(티켓을 발행)이라는 형태로 표현하였습니다.

2 Trac 활용 화면 샘플

A. 텍스트 큐브 개발 환경 (권장)
i. http://dev.textcube.org/wiki
ii. http://blog.tattertools.com/153 (팀 디자이너의 사용후기)

B. 교육용 환경 샘플 (그냥 참고 정도로만 보세요^_^)

3. Trac FAQ

A. Trac 사용의 이점은 무엇입니까?

이 내용은 Trac 이라기 보다는 이슈 트래커 사용의 이점이 무엇인지에 대해 이야기 하는 것이 맞는것 같습니다.
이슈 트래커의 대표적인 장점은, 프로젝트 이슈의 투명성, 공동작업에 효율성 증진, 지식축적, 릴리즈관리, 소스연동을 통한 접근성 강화 등이 있습니다. 이슈(=장애, 버그, 기능개선 요청 등)를 관리하는 전통적인 방식인 엑셀 파일관리나 웹 게시판 등의 방법은 이슈의 라이프사이클 제대로 제공하지 못하며, 결국 경험의 축적이 자산화로 연결되지 못하게 되는 흔한 경우를 만든다고 보시면 되겠습니다 프로젝트의 이슈는 프로젝트에서 정의한 이슈 작업흐름(work flow)에 따라 생성에서 종료까지가 이슈의 상태기반으로 담당자와 작업이 유기적으로 연결되어야 하며, 그 과정이 투명하게 보여야 하고, 이력(history)으로 남겨질 수 있어야 하겠습니다. 이슈 트래커들은 그 과정을 시스템 적으로 지원합니다.

B. Trac 은 어느 정도 규모에서 사용가능 한가요?

Trac 에서 제공하는Category(=component) 의 한계상 다층 깊이의 hierarchy는 제공하고 있지 않습니다. 따라서 부서와 파트가 많아지고 모듈이 많아지면 복잡도가 증가할 수 있습니다. 하지만 그 규모의 수준이란게 기반 프로젝트을 어떻게 하위 프로젝트로 사이징 할 수 있느냐에 따라 달라질 수 있습니다. 국외 사례는 제외 하더라도, 국내에서 대표적으로 알려준 케이스를 꼽자면, DAUM 에서는 Trac 을 전사적 기본 이슈 관리도구로 사용했으며, 최근 구글에서 인수한 TNC(태더&컴패니)의 유명한 블로그 툴인 Tatter Tools (Tistory 기반툴) 개발에 Trac 이 사용되었습니다. (여담으로 이야기 드리자면, 최근 DAUM은 JIRA라는 상용 제품으로 이슈 관리도구를 변경한 것으로 알고 있습니다. NAVER는 JIRA가 예전부터 표준 툴이었다고 들었습니다.) 우선은 Trac 이나 Mantis등의 오픈소스 툴을 사용하고, 상용툴로의 이전은 복잡도와 프로젝트 상황에 맞추어 가면 될 것 같습니다.

C. 이슈 관리의 단점은 없습니까?

i. 이슈 관리의 단점이라기 보다는 이슈 자체에 대한 잘못된 해석이 건강한 이슈관리를 훼손할 수 있습니다. 이를테면, '이슈를 많이 만드는 팀은 문제 있는 팀' 이라던가, '결함이 많이 발견되는 모듈 개발자는 능력이 다소 부족한 개발자' 같은 시각으로 일련의 '평가'와 이슈를 결부시키려고 하는 경우가 있습니다. 이것은 프로젝트의 이슈(=위험, Risk)자체를 투명하게 이끌어내어서 적극적으로 관리하고 경험으로 축적하고자 하는 이슈 트랙 시스템이 가진 선의의 의지와 상반되는 형태로 이슈 자체의 은폐를 조장할 가능성이 있습니다. 따라서, 절대로 이슈는 해결해야 하는 Task 그 이상도 이하로도 여기지 않는 풍토를 만드는 것이 중요합니다.

D. 기존 시각에서 볼 때 새로운 툴이라는 것에 대한 부정적인 시각은 어떠한가요?

저는 생산성을 높이기 위해서라면 사용할 수 있는 자원은 최대한 사용해야 한다고 봅니다. 한 사람이 고생해서 2사람 이상이 편해 질 수 있다면(즉, ROI가 맞는다면), 누군가는 해야 합니다. '툴은 툴일 뿐!'이라는 담언은 툴을 사용하지 말라는 담언이 아닙니다. 최대한 잘 사용하되 의존적이어서는 안된다는 이야기라는걸 모두들 아실 겁니다. 최초에 컴퓨터가 사무업무 기반을 대체할 수 있다고 생각한 사람은 많지 않았습니다. 하지만 그 생산성을 당해낼 수 없었기에 따라갈 수 밖에 없었으며, 중요한 점은 조기에 얼마나 혼란 없이 받아 들일 수 있는가가 관건이라 생각합니다.


E. 기타 이슈 관리 툴에는 어떠한 것들이 있나요?

i. MANTIS, 정확히는 MANTS BT (버그 트래킹), MANTIS BTS 등으로 불립니다. 버그 수집에 초점이 맞추어져 있었는데, 최근에는 보고서 기능을 필두로 이슈 관리쪽으로도 사용된다고 합니다. 데모는 http://www.mantisbt.org/demo/my_view_page.php 에서 보실 수 있습니다.

ii. JIRA, 정확히는 Atlassian JIRA 입니다. 상용 툴로써 현재까지는 가장 활발히 이용되고 있고, 가장 발전된 형태라고 칭해지고 있습니다. http://www.atlassian.com/software/jira/screenshots/default.jsp 에서 화면을 보실 수 있습니다. 요즘은 대부분 JIRA로 가는 추세인 것 같습니다. http://jira.springframework.org/browse/SPR 링크는 스프링 프레임워크의 이슈 트랙화면입니다. 마찬가지로 JIRA로 구성되어 있습니다.

iii. Bugzilla, 가장 오래된 툴입니다. https://landfill.bugzilla.org/bugzilla-tip/request.cgi 에서 살펴보실 수 있습니다. 인터페이스가 다소 고전적이고, 버그 추적에 집중되어 있으며, 세분화된 항목들로 인해 이슈 등록 시에 다소 혼란스러울 수 있습니다.

iv. 비교 관련 글로는 http://www.ibm.com/developerworks/kr/library/s_issue/20071127/를 참조하시면 되겠습니다.

v. 이 외에도 다양하게 존재하고 있으며, 좀 더 머리가 복잡해 지고 싶으시면 http://www.michaelflanakin.com/Articles/Comparisons/WebBasedIssueTrackers/tabid/198/Default.aspx 에 들러서 본격적으로 살펴보시는 것도 나쁘지 않은 선택이라 봅니다.


---------- endd here ------------