| | 1 | [[PageOutline(1-5, 목차, inline)]] |
| | 2 | = Trac 사용시 주의사항 = |
| | 3 | |
| | 4 | Trac을 도입한 원래 목적은 |
| | 5 | 1. 프로젝트와 관련된 자료를 한군데 모아놓자. 최신 버전 기획안, 디자인 등을 찾아 헤매는 일이 없도록 하자. |
| | 6 | 1. 프로젝트 진척 사항을 한 눈에 볼 수 있게 하자. |
| | 7 | 1. 누가 어떤 일을 처리했는지 기록으로 남겨놓자. |
| | 8 | 1. 소스 코드 버전 관리를 하자. |
| | 9 | |
| | 10 | 등등입니다. |
| | 11 | |
| | 12 | 사실 홈페이지 만들어놓기만 하고 끝날 거라면 이런게 다 부질없는 일일 수도 있습니다. 다만, 향후 계속 유지되어야 할 시스템이라면 언젠가는 담당자가 바뀌어서 업무 인수인계를 해야 하는데, 관련 자료들이 흩어져 있고 인수인계가 제대로 되지 않아 숱한 비효율을 경험해왔습니다. 소스 코드조차 어디 있는지 몰라서 처음부터 다시 개발해야 하는 경우도 있었고요. |
| | 13 | |
| | 14 | 그런 문제점이 있다는 걸 동의하신다면, 그 다음부터는 일을 어떻게 하는게 잘 하는 것인가를 끊임없이 고민하면서 프로답게 합리적으로 일을 할 수 있는 방향으로 규칙을 세워나가면 되는 것 같습니다. 아래 내용은 협의를 통해 충분히 바꿔갈 수 있습니다. 단지 하나의 제안이라고 생각해주시면 좋겠습니다. |
| | 15 | |
| | 16 | == 티켓 == |
| | 17 | |
| | 18 | === 티켓을 사용해야 하는 경우 === |
| | 19 | '''프로젝트와 관련된 모든 작업 요청''' |
| | 20 | |
| | 21 | - 티켓은 원래 소스 코드(변경, 추가, 삭제)와 관련된 요청에 사용하도록 만들어졌습니다. 왜 Trac에 소스 브라우저 메뉴가 포함되어 있는지 생각해보시면 될 겁니다. |
| | 22 | - 그러나, 요청하는 사람의 입장에서는 요청하는 내용이 소스 코드와 관련이 있는 작업인지 아닌지 알기 어렵습니다. |
| | 23 | - 요청자가 이를 잘 구분해서 요청한다 하다라도 개발자 입장에서는 소스 코드와 관련이 없는 작업은 다른 경로(예를 들어 메일)도 확인해야 전체 작업 내용을 알 수 있게 됩니다. |
| | 24 | - 따라서, 티켓에는 프로젝트와 관련된 작업 요청이 모두 들어가 있는게 좋다고 생각합니다. 그래야 처리해야 하는 사항이 몇 개 정도 남아있고, 몇 개는 처리가 됐는지 알 수 있으므로 진척도도 짐작할 수 있으리라 봅니다. |
| | 25 | - 2번의 목적에 비춰봤을 때는 한꺼번에 여러 개의 요청 사항을 뭉뚱그려서 하나의 티켓에 넣으면 여러 요청 사항이 모두 완료되기 전까지는 그 티켓이 닫혀지지 않으므로, 일부 요청 사항이 처리가 되었다고 해도 진척률은 0%일 수밖에 없습니다. 전체적인 진행 상황을 확인하는데 애로가 있으므로 원래 목적에는 부합되지 않는다고 봅니다. 따라서 '''하나의 티켓에는 하나의 요청 사항만''' 입력해 주십시오. |
| | 26 | |
| | 27 | |
| | 28 | === 티켓을 사용해야 하지 말아야 하는 경우 === |
| | 29 | '''별도의 추가 작업이 필요가 없는 사항''' |
| | 30 | |
| | 31 | - 별도의 추가 작업이 필요없는 '''단순한 질문과 대답'''인 경우 메일이나 전화로 해도 충분하지 않을까 싶습니다. |
| | 32 | - 그러나 단순한 질문과 대답이라 할지라도 질문한 사람 외에 다른 사람도 참조해야 할 가능성이 있다면 위키(티켓이 아니라)에 올려놓는 것이 좋을 듯 합니다. |
| | 33 | |
| | 34 | 티켓을 포함해서 Trac을 어떻게 활용하는가에 대한 예제는 [http://dev.tattertools.com/ 테터툴즈 개발자 홈페이지], [http://trac.edgewall.org/ Trac 개발사 홈페이지] 등을 참고하시면 좋겠습니다. |
| | 35 | |
| | 36 | == 기획안과 디자인 == |
| | 37 | |
| | 38 | 기획안과 디자인은 메일로 주고 받는 것이 아니라 여기(위키)서 관리했으면 합니다. 수많은 메일 중에서 기획안과 디자인을 찾아 헤매본 일 없으세요? 기획안이나 디자인에 버전 관리가 필요없는 경우(즉, 최신버전만 있으면 되는 경우)에는 여기다 올려놓는 것이 좋겠습니다. |
| | 39 | |
| | 40 | 만약 버전 관리가 필요하다면 서브버전을 이용하면 될 겁니다. |
| | 41 | |
| | 42 | == 기타 == |
| | 43 | |
| | 44 | === 마일스톤 설정 === |
| | 45 | |
| | 46 | 마일스톤은 일정 계획하고 관련이 있습니다. 어떤 항목이 마일스톤에 어울리는가 아닌가를 보려면 완료 날짜까지 지정 가능한가를 보시면 됩니다. |
| | 47 | |
| | 48 | 즉, '개발 일정표'는 특정 날짜와 관련이 없으므로 마일스톤 항목으로는 적절하지 않다고 봅니다. |
| | 49 | |
| | 50 | 그러나 '개발 일정 확정'이라면 언제까지 확정을 해야 한다고 날짜 지정이 가능하므로(날짜를 지정할 필요는 없습니다. 날짜 지정이 가능하기만 하면 됩니다.) 마일스톤에 어울리는 항목입니다. |
| | 51 | |
| | 52 | ---- |
| | 53 | |
| | 54 | [WikiStart 처음으로] |
| | 55 | |
| | 56 | |
| | 57 | |
