목차
Trac 사용시 주의사항
Trac을 도입한 원래 목적은
- 프로젝트와 관련된 자료를 한군데 모아놓자. 최신 버전 기획안, 디자인 등을 찾아 헤매는 일이 없도록 하자.
- 프로젝트 진척 사항을 한 눈에 볼 수 있게 하자.
- 누가 어떤 일을 처리했는지 기록으로 남겨놓자.
- 소스 코드 버전 관리를 하자.
등등입니다.
사실 홈페이지 만들어놓기만 하고 끝날 거라면 이런게 다 부질없는 일일 수도 있습니다. 다만, 향후 계속 유지되어야 할 시스템이라면 언젠가는 담당자가 바뀌어서 업무 인수인계를 해야 하는데, 관련 자료들이 흩어져 있고 인수인계가 제대로 되지 않아 숱한 비효율을 경험해왔습니다. 소스 코드조차 어디 있는지 몰라서 처음부터 다시 개발해야 하는 경우도 있었고요.
그런 문제점이 있다는 걸 동의하신다면, 그 다음부터는 일을 어떻게 하는게 잘 하는 것인가를 끊임없이 고민하면서 프로답게 합리적으로 일을 할 수 있는 방향으로 규칙을 세워나가면 되는 것 같습니다. 아래 내용은 협의를 통해 충분히 바꿔갈 수 있습니다. 단지 하나의 제안이라고 생각해주시면 좋겠습니다.
티켓
티켓을 사용해야 하는 경우
프로젝트와 관련된 모든 작업 요청
- 티켓은 원래 소스 코드(변경, 추가, 삭제)와 관련된 요청에 사용하도록 만들어졌습니다. 왜 Trac에 소스 브라우저 메뉴가 포함되어 있는지 생각해보시면 될 겁니다.
- 그러나, 요청하는 사람의 입장에서는 요청하는 내용이 소스 코드와 관련이 있는 작업인지 아닌지 알기 어렵습니다.
- 요청자가 이를 잘 구분해서 요청한다 하다라도 개발자 입장에서는 소스 코드와 관련이 없는 작업은 다른 경로(예를 들어 메일)도 확인해야 전체 작업 내용을 알 수 있게 됩니다.
- 따라서, 티켓에는 프로젝트와 관련된 작업 요청이 모두 들어가 있는게 좋다고 생각합니다. 그래야 처리해야 하는 사항이 몇 개 정도 남아있고, 몇 개는 처리가 됐는지 알 수 있으므로 진척도도 짐작할 수 있으리라 봅니다.
- 2번의 목적에 비춰봤을 때는 한꺼번에 여러 개의 요청 사항을 뭉뚱그려서 하나의 티켓에 넣으면 여러 요청 사항이 모두 완료되기 전까지는 그 티켓이 닫혀지지 않으므로, 일부 요청 사항이 처리가 되었다고 해도 진척률은 0%일 수밖에 없습니다. 전체적인 진행 상황을 확인하는데 애로가 있으므로 원래 목적에는 부합되지 않는다고 봅니다. 따라서 하나의 티켓에는 하나의 요청 사항만 입력해 주십시오.
티켓을 사용해야 하지 말아야 하는 경우
별도의 추가 작업이 필요가 없는 사항
- 별도의 추가 작업이 필요없는 단순한 질문과 대답인 경우 메일이나 전화로 해도 충분하지 않을까 싶습니다.
- 그러나 단순한 질문과 대답이라 할지라도 질문한 사람 외에 다른 사람도 참조해야 할 가능성이 있다면 위키(티켓이 아니라)에 올려놓는 것이 좋을 듯 합니다.
티켓을 포함해서 Trac을 어떻게 활용하는가에 대한 예제는 테터툴즈 개발자 홈페이지, Trac 개발사 홈페이지 등을 참고하시면 좋겠습니다.
기획안과 디자인
기획안과 디자인은 메일로 주고 받는 것이 아니라 여기(위키)서 관리했으면 합니다. 수많은 메일 중에서 기획안과 디자인을 찾아 헤매본 일 없으세요? 기획안이나 디자인에 버전 관리가 필요없는 경우(즉, 최신버전만 있으면 되는 경우)에는 여기다 올려놓는 것이 좋겠습니다.
만약 버전 관리가 필요하다면 서브버전을 이용하면 될 겁니다.
기타
마일스톤 설정
마일스톤은 일정 계획하고 관련이 있습니다. 어떤 항목이 마일스톤에 어울리는가 아닌가를 보려면 완료 날짜까지 지정 가능한가를 보시면 됩니다.
즉, '개발 일정표'는 특정 날짜와 관련이 없으므로 마일스톤 항목으로는 적절하지 않다고 봅니다.
그러나 '개발 일정 확정'이라면 언제까지 확정을 해야 한다고 날짜 지정이 가능하므로(날짜를 지정할 필요는 없습니다. 날짜 지정이 가능하기만 하면 됩니다.) 마일스톤에 어울리는 항목입니다.
