이슈 트래킹, 프로세스, 개선, 변화, 기타 등등에 대한 이야기

0 0

이 문건은 회사 내부에서  이슈추적과 개발 프로세스와 관련한 의견을 취합하기 개인적으로 작성했던 문서로, 겸사겸사 스스로의 생각도 정리하자는 의미에 비중을 둔 문서였다. 여러가지 사정으로 문서 자체는 지금 현재로써는 회사 내부의 여러사람들에게 묵살당한 모양이지만, 행여나 비슷한 고민을 하는 분들이 계시다면 한번 생각을 공유해 보았으면 하는 생각에 전문을 올려본다.

—-

이슈 트래킹을 왜 쓰는가에 대한 고민과 어떻게 쓰는가에 대한 고민이 필요하다고 생각 함.

1. 일차적 이용 목적
   • 버그 발견 시 해당 버그에 대한 단일 리포트 창구 필요
   • 취합된 버그에 대한 발견-처리-결과에 대한 개별 프로세스별 정확한 통제(Control) 및 관리(Management) 목적
   • 문제가 되는 이슈의 통계 처리를 통한 개발 진척사항 및 마일스톤의 관리 – 업무 중복의 회피
   • 커뮤니케이션의 극대화
2. 쓸 수 있는 App
   • 맨티스(Mantis) : 전형적인 이슈 트래킹 어플리케이션. 이슈 리포트에 대한 세부적인 옵션 컨트롤이 가능하며, 간단한 기능과 한글화가 장점. 단점으로는 지나치게 많은 리포트 옵션과 시각적으로 깔끔하지 못한 인터페이스-현재 사내 서버에 Mantis가 설치 되어 있으나 사실상 용도 폐기 상태 임.
   • 트랙(Trac) : 이슈 트래킹 및 프로젝트 매니지먼트 기능 등이 결부되어 있는 어플리케이션. SVN과 연동하여 개발 소스에 대한 열람이 자유롭고, Wiki를 통한 프로젝트 문서화가 손쉽다는 점, 마일스톤 및 연표 기능으로 프로젝트 진행 상황 확인이 용이하며 인터페이스가 깔끔함. 단점으로는 현재 최신 버전에 대한 한글 버전이 존재하지 않음(한글화는 Ver 0.10.4에서 종료. 현재 릴리즈 된 버전은 0.11.4, Ver 0.12 부터 다국어 지원 예정)-대표적인 Trac 사용 프로젝트(국내)의 예로 태터 앤 컴퍼니의 텍스트 큐브 개발 페이지(http://dev.textcube.org/) 및 제로보드 개발 페이지(http://trac.zeroboard.com/trac/wiki).
   • 버그질라(Bugzilla) : 해외 오픈소스 계열 이슈 트래킹 어플리케이션 중 가장 유명한 어플리케이션으로 모질라 재단, NASA 등의 프로젝트에서 사용중이며, 강력한 통계 처리 기능이 장점. 사용이 복잡하고 한글화가 전혀 되어있지 않다는 점이 가장 큰 단점
3. 프로세스 중 적용 범위 (1차)
   • 이슈 트래킹 : 버그 및 개선 사항에 대한 ‘보고 – 처리 과정 – 결과 확인’ 의 프로세스에 대한 통제
   • 제품 품질 완성도에 대한 정량적인 측정 : 버그 발생 및 처리, 잔여 이슈에 대한 정략적인 측정
   • 난립되어 있는 문서의 통일 : 각종 양식의 버그 리포트의 통폐합
4. 프로세스 최종 적용 범위
   • 프로젝트 별 난립되어 있는 문서의 템플릿 통일화
   • 수동적이고 책임 회피적인 업무 진행에서, 전체 구성원의 책임감 고양 및 자발적인 업무 참여 유도
   • 전체적인 프로젝트 제작 프로세스에 대한 재 검토 및 효율화를 위한 개선
   • BPR(Business Process Reengineering)
5. 도입 시 장기적으로 예상되는 문제점과 해결 방안
   • 관리자 부재로 인한 개점휴업 상태 발생 : 관리 담당자의 지정 및, 각 프로젝트 참여자의 의무 사용 독려(자율적인 참여 방식과 더불어 강제적인 사용 의무화 방안도 포함 되어야 함 : 갱신 사항에 대한 메일링 리스트 확인, RSS 리더의 강제 등록 등으로 이슈가 발생하고 등록되는 즉시 각 구성원이 최대한 빠르게 파악 할 수 있는 시스템 구성은 별도의 문제임)
   • 발생된 이슈에 대한 사용자 전체의 적극적인 참여를 어떻게 이끌어 낼 것인가? : 이슈 트래킹을 이용하는 기본 프로세스는 상명하달 식의 업무 구조가 아닌, 개인이 각자 일을 찾아서 진행하는 ‘자발적 참여’를 전제로 함. 수동적이고 피동적인 조직 문화를 변경해야 할 필요가 발생 할 수 있음.
   • 변화에 대한 지속적인 수용력 필요 : 이슈 트래킹을 도입하는 것은 작게는 버그 트래킹 프로세스의 변화에서 부터 크게는 전체 프로세스의 변화를 필연적으로 가져오게 될 수 있으나, 각 구성원 전체에 변화에 대한 인식 수용이 없이는 ‘변화에 대한 저항’이 발생할 가능성이 아주 높음. 지속적인 변화 및 개선에 대한 전 구성원의 공감대가 필요한 사항이며, 관리계층은 이를 뒷받침 해 줄 수 있는 능력을 확보해야 함.
   • 프로젝트 일정에 따른 프로세스 통제가 불가능하게 될 경우 : 일단 그런 상황이 발생하지 않도록 만들어야 하며, 만약 통제 불가피한 상황이 발생할 경우라도 기본적인 프로세스는 유지한다는 의지가 필요

—-

아무것도 없는 상태에서 이런 이야기를 꺼내는것도 어려운 일임에도 불구하고 내밀었건만, 이를 관철시키는 것은 더욱더 힘든 이야기라는 사실에 오늘도 잠깐 우울한 기분이 들었던 하루.