늘상 있는 일이지만 SI 프로젝트를 진행하다보면(혹은 다른 개발 프로젝트를 진행) 사람이 프로그램에 치이는게 아니라 사람이 사람에게 치여 프로젝트가 산으로 가는 일이 많아 진다.
물론 프로그래머의 업무 중 대부분을 차지하는 것이 개발업무지만 사람 피곤하게 산출물을 뽑아내는 것에 많은 시간을 소비하곤 한다.
오늘 감리사에게 대판 깨지고 온 나는! (흑...) 어떻게 하면 협업을 통해 산출물에 대한 개발자의 부담 및 산출물 관리자의 부담을 덜까 생각하다 설치만 해놓고 팀원들의 무관심 속에 잊혀져 가는 Trac(... 설치하는데만 3일을 소비했다)을 이용한 협업능력 강화 및 산출물 자동화를 방안을 내놓고 까먹지 않기 정리하고자 한다.
Trac에 대한 설치가이드는 웹상에 이미 널려있으니 알아서 참고하기 바라고(사실 까먹어서 기억도 안난다) 당근 Trac은 소스관리툴인 SVN과 연동되어 있는 것을 기본으로 한다. 단 SVN은 프로젝트 통합 버전관리툴로 사용하여 사용자들의 각각의 PC에 tortoiseSVN이 기본으로 깔려있으면 좋고, 없으면 산출물 관리자 및 PM은 필수적으로 깐다.
repository 의 구조는
trunk
ㄴ 웹시스템소스
ㄴ DB
ㄴ 산출물
같은 3단 메인으로 진행하며
웹시스템소스에는 기본적으로 웹개발소스가(java, jsp, js 등등) 버전관리가 진행되고,
DB에는 펑션, 프로시져, 패키지 등(오라클 기준) 협업 필요성이 있는 스크립트가 버전관리 된다. 이 부분의 버전관리는 Quest사의 Toad를 쓰면 매우 편리하게 협업코딩이 가능하다(토드를 쓴다면 거의 필수다. 찾아보니 국내에는 팀코딩 기능을 써먹는 사람이 없거나 자기만 알고 남들한테는 안알려주는거 같다. ㅡ.,ㅡ;; 난... 전자다... 앞으로 후자가 되려한다)
산출물에는 산출물 관리자가 산출물에 대하여 문서의 버전관리를 한다.
먼저 PM은 프로그램 개발 일정의 기본틀을 잡아놓고 일정표를 짠다.
여기에 모듈 혹은 단위 시스템의 마일스톤을 설정할 수 있다.
예를 들자면 경영정보시스템의 개발일정이 6개월 동안이고 개발 착수는 1월 1일 개발 완료는 6월 30일까지라 하고, 인사, 회계, 예산, 자산, 급여 등의 단위 모듈이 개발된다.
PM은 장기 목표를 MIS의 완성, 단기 목표를 인사, 회계 등등 단위 모듈의 완성으로 잡고 단기개발목표 기간을 설정해준다.
1) 인사 1월 1일 ~ 1월 31일
2) 회계 2월 1일 ~ 2월 28일
...
이제 Trac을 개발용 협업서버에 설치하고 SVN 저장소 설정 및 개발참여자에게 ID와 패스워드를 부여하고, 진행 프로젝트 정보(Component)와 Milestone 정보를 입력해준다.
후에 개발환경을 구축하여 시스템기초소스 및 UI설계서(산출물) 등의 기초 정보를 SVN저장소에 Import시켜준다.
이렇게 임포트 된 데이터들은 SVN에서 각 데이터들의 버전을 부여하고 Trac이 이 버전을 Wiki링크로 연결시켜주는 저력(이게 왜 저력이 되는지는 아래글을 읽어보면 된다.)을 발휘하게 된다.
임포트가 끝나면 Trac의 프로젝트 메인 페이지에 개발 참고사항 (개발자 연락처, 위험관리, 개발 환경 설정)에 관한 정보를 입력하여 놓고 변경사항이나 추가 사항이 있을 때 개발 참여자 누구나가 수정이 가능하게 한다. (당근 수정사항에는 수정 이력이 붙게된다.)
이제 일정표와 개발범위표를 놓고 PM은 해당 마일스톤의 프로그램 모듈(인사라면 인사기본정보, 인사정보 조회 등등)에 Ticket을 부여한다.
티켓의 예제를 들자면
제목 : 인사기본정보 개발
작성자 : PM
상세한 설명 :
인사기본정보에는 사용자에 입력에 대한 에러관리에 주의하여 개발하시기 바랍니다.
인사기본정보 UI설계서
인사기본정보 회의록
type : 신규개발
Prioriy : 보통
Milestone : 인사시스템
Component : MIS 시스템
Version 1.0
Severity : 3
Keyword : 인사기본정보, 기본정보, 인사, MIS
Cc :
다음 사람에게 할당 : developer1
첨부파일 없음
이런 식으로 수시 혹은 일괄적으로 개발자에게 업무를 부여할 수 있고 위의 밑줄 친 부분은 앞서서 임포트 시켰던 산출물의 자료의 Wiki링크가 되겠다. 그럼 개발자는 알기쉽게 개발 업무를 하달 받게 된다. (산출물 파일 다운로드를 포함해서)
개발자는 개발PC에서 이클립스의 MyLyn으로 Trac을 연동하여 프로그램을 작성하거나 DB 스크립트를 작성하여 Trac에 피드백을 시켜주고 이것의 type을 '개발 완료'로 설정하여 품질관리자에게 Ticket을 다시 할당한다.
후에 개발자는 품질담당자에게 개발테스트를 할 환경 및 시간을 주고 품질관리자는 완성된 프로그램의 품질을 체크한 후 프로그램이 완성 됐을 경우 간단히 완성이라고 코멘트만 추가하고 ticket을 닫거나 에러가 발생한 경우 type을 결함발견으로 바꿔서 에러내역을 기재하여 참고할 만한 위키가 있을 경우 링크시켜주고 다시 개발자에게 할당하거나 다른 개발자에게 할당할 수 있다. 여기에 단계를 추가하면 테스트가 문제 없이 끝났을 경우 품질관리자는 산출물 출력 여부의 타입을 부여하여 산출물 관리자에게 티켓을 다시 할당하고 산출물 관리자가 개발완료를 찍으면서 미리 보기에 나오는 화면을 출력하여 개발산출물로 출력할 수 있게 하는 방법도 있다(출력물 스크립트 수정이 가능하다면 완전 거저먹기다)
Wiki를 통한 개발참조물의 손쉬운 링크 및 Trac시스템 내에서 개발 변경 사항(소스 변동 사항을 바로 확인)의 손쉬운 확인, PM의 일정이력관리, 숨어있는 강력한 Trac 플러그인 등 Trac을 중심으로 협업이 된다면 구성원간의 업무소통에 큰 도움이 될 뿐더러, 품질관리와 산출물 관리에도 큰 도움을 줄 수 있을 것이다.
지금까지는 구상한에 대하여 주섬주섬 써놓았고, 다음 번 프로젝트에 이 운용방안을 적용하여 프로젝트를 진행하여 보겠다. 그 때는 화면 캡쳐 및 내용을 구성을 좀 더 섬세하여 많은 분들이 도움받을 수 있도록 구성하겠다.
이 자료는 퍼가실 때 출처를 명확히 해주시고 링크를 꼭 달아주시기 바랍니다.
제가 새벽에 잠못자가면서 쓴 글입니다.
Trac의 다른 운용법이나 더 좋은 기능, 운영과 관련된 더 디테일한 사례가 있으면 트랙백이나 댓글 부탁드리겠습니다.
Comment 0
