Jira를 이용하여 프로젝트 하기

(*)Jira는 무척 훌륭한 제품입니다. 개인적으로 오랜 기간 사용하였습니다. Starter License이었기때문에 비용 부담은 없었습니다. 그렇지만 규모가 커지면 비용은 점증합니다. 100여명 일 때 몇 백만원을 지불하였습니다. 이럴 때 이용자의 활용능력이 떨어지면 본전 생각이 나게 합니다. 쉽지 않습니다. 특히 SI프로젝트를 할 때 도입하기란 쉽지 않습니다. 저와 같은 경우 라이센스비용도 있고 해서 레드마인으로 바꾸었습니다. 서버도 24시간 운용을 고려하여 라즈베리파이서버로 하였습니다. 이와 같은 경험을 기반으로 한 글이 아래입니다. 관련한 기술적인 지원이 필요하시면 연락주세요.

USB부팅하는 라즈베리파이 서버 만들기
레드마인에 Hipchat을! Rocket.chat 설치

1.
Jira를 사용한지 오래입니다. 2005년 어둠의 세계에서 도움을 받아서 설치한 이후 쭉 사용하고 있습니다. 회사 내부의 R&D가 아닌 외부 프로젝트에서 공식적으로 사용한 적은 두 번입니다. 두 회사 모두 전사적인 PMS(Project Management System)를 가지고 있습니다. 그렇지만 실무에 적합하지 않았습니다. 한번은 부분적으로 이슈관리만을 위하여 사용했지만 요즘 하는 프로젝트의 경우 분석단계부터 시작하여 시험단계까지 전 과정을 Jira로 프로젝트를 관리하고 있습니다. 물론 RFP에는 프로젝트관리도구 제안이 없습니다. PM으로서의 필요에 의해 제안사를 설득하여 설치했습니다. 만약 Jira가 구매방식의 가격정책을 취했으면 힘들었을 듯 합니다. 기간단위의 이용료방식으로 가격정책을 바꾸면서 적정한 가격에 도입할 수 있었습니다.

10여년이 넘은 Jira 경험이지만 이번처럼 Jira의 시작부터 끝을 해본 경우는 처음입니다. 그래서 저의 경험 몇가지를 공유합니다. 물론 여러가지 문서상에 나왔던 것이지만 경험이고 기록을 위한 정리입니다.

Jira를 Standalone으로 설치한 이후 가장 먼저 고민한 것은 ‘Jira를 프로젝트에 어떻게 적용할지’입니다. Jira는 Issue Tracking System에서 출발하였습니다. 그럼 Issue는 무엇으로 정의할 수 있을까요? Jira라는 시스템적 시각으로 보면 ‘특정한 사람과 사람이 함께 일할 때 누군가가 주어진 기간내에 해결하여야 하는 것’이라고 생각합니다, 그래서 Assingee와 Reporter가 있고 Due Date로 일정을 관리합니다. 이런 개념으로 이해하면 IT만이 아니라 일반적인 프로젝트 모두에 적용할 수 있습니다. 그중 저는 소프트웨어개발과 관련한 프로젝트와 관련한 고민에 국한합니다. 일반적으로 외부에 발주한 소프트웨어개발프로젝트는 검수를 위하여 ‘분석-설계-구현-시험-가동’이라는 단계에 따라 진행합니다. 저도 마찬가지입니다. 각 단계에 Jira을 어떻게 적용할지를 정리해야 했습니다. 하나의 프로젝트로 구성할지, 여러개의 프로젝트로 구성할지를 선택해야 했습니다. 저는 각 단계별로 프로젝트를 만드는 방식을 선택하였고 아래와 같이 적용하였습니다.

첫째 분석 단계일 경우 핵심 업무는 요구사항정의서입니다. 요구사항정의서를 작성하기 위하여 AS-IS분석과 현업인터뷰를 하고 회의를 합니다. 이 때 요구사항을 둘러싼 이슈가 발생합니다. 주로 범위과 기능입니다. 이를 관리하는데 사용하기로 하였습니다. 각 이슈에 따른 산출물과 회의록 등을 attachment로 관리하고 결과를 기록합니다. Jira가 부여하는 ID를 그대로 이슈관리대장에 기록하고 보고를 합니다.

둘째 설계 단계가 가장 쉽지 않았습니다. 그래서 내린 결론은 분석단계와 같이 이슈를 중심으로 적용하였습니다. 보통 요구사항정의서를 작성합니다만 상세하게 작성하지 못하고 설계단계에 구체화하는 경우가 많습니다. 이 때 새로운 이슈들이 나옵니다. 설계에 영향을 주고 기간에도 영향을 주는 이슈들입니다. 이를 관리하기로 하였고 분석단계와 동일한 방식으로 진행하였습니다.

셋째 구현 단계의 경우 설계단계 산출물을 프로그램 목록을 모두 Issue로 등록하여 관리하는 방식을 택하였습니다. 이 때 Jira와 Fisheye 및 SVN을 연동하여 각 프로그램이 진행상황을 확인할 수 있도록 하였습니다. 이렇게 한 이유는 버전관리의 필요성 뿐 아니라 진척도 관리를 위한 목적도 있었습니다. 더불어 시험단계에서 발생할 결함과 프로그램을 연결할 계획도 있었습니다. 프로젝트가 끝난 이후 소스를 이관할 때 결함해소이력이 담긴 자료를 넘겨서 운영상 도움을 주기 위한 고려도 했었습니다.협업을 했던 개발자는 몇 십명입니다.

넷째 시험 단계는 당연히 시나리오를 등록하였습니다. 대략 사 천개정도의 시나리오를 등록하였습니다. 결함은 시나리오의 sub-task로 등록하도록 규칙을 만들었습니다. 발생한 결함도 무척 많았지만 운용에 불편하지 않았습니다. 흔히 결함을 버그로 이해하지만 버그보다는 기능상의 보완인 경우가 대부분입니다. 100% 완벽한 상세설계를 하지 못한 상태에서 시험을 통해 보완하기 때문입니다. 그동안 시험결과를 엑셀을 통해 공유하고 결함조치를 취했던 프로세스를 노력을 해서 Jira로 바꾼 경우입니다. 함께 했던 시험자와 개발자가 백여명이 넘었습니다.

2.
Jira를 프로젝트에 적용한 사례였습니다. 이제 각 사례에 따라 도움을 받았던 플러그인과 팁(Tip)입니다.

보편적인 분석과 설계의 경우 특별히 고민하지 않았습니다. 주어진 기본기능을 적절히 사용하면 되었습니다. 다만 구현단계부터 사용할 환경을 이 때 준비를 해놓아야 합니다. 구현단계에 적용한 Fisheye와 SVN입니다. 저의 경우 Jira와 Fisheye의 동시사용수가 달랐습니다. 같은 수의 라이센스를 구매하면 좋겠지만 에산이 많이 듭니다. 그래서 어쩔 수 없이 Jira은 사용자별 라이센스를 적용하였고 fisheye는 그룹별 라이센스를 적용하였습니다. Fisheye는 가장 기본적인 라이센스로 구매하였습니다. 년단위로 몇 만원입니다. 이렇게 차이가 나더라도 운영상에 문제가 없었습니다. Fisheye가 제공하는 라이센스는 User에 해당합니다. User와 Committer가 동일하도록 하면 라이세스 비용이 올라가므로 User를 업무그룹으로 하고 Committer는 그룰별 개발자로 정의하였습니다. Committer는 SVN의 User이므로 개발자가 Commit을 할 경우 SVN Server에 기록이 남습니다.

구현단계일 경우 가장 큰 어려움을 프로그램목록을 등록하는 일이었습니다. 대략 몇 천개가 넘는 자료를 수작업으로 입력할 수 없었습니다. CSV를 이용한 Import기능을 적용했지만 UTF-8과 같이 한글이 걸림돌이었습니다. 이를 해결한 것은 Google의 Spreadsheet입니다. UTF-8을 정확히 지원합니다. 한글이 전혀 깨지지 않았습니다.

사실 Jira의 막강한 기능을 확실히 느꼇고 적용한 단계는 시험단계입니다. 우선 다양한 이해관계에 맞는 워크플로우를 정의해야 했습니다. 아울러 입력화면과 조회화면도 바꿔야 했고 결함을 부르는 명칭도 새롭게 정의해야 했습니다. Jira는 이를 위한 기능이 준비되어 있었습니다. 관리자환경을 보면 Issue Type, Workflow, Screen, Field와 같이 이용자가 입맛에 따라 바꿀 수 있도록 기능을 제공합니다. 작업을 해야 하는 순서가 조금 복잡합니다. 그렇지만 문서상에 나온 것을 하나씩 따라하면 누구나 할 수 있습니다. 한국과 같이 표준적인 환경보다는 내 입맛에 맞도록 최적화된 환경을 종아하는 경우 효과를 볼 수 있습니다. 저의 경우 새롭게 만든 워크플로우가 10여개가 넘습니다. Jira가 제공하는 워크플로우를 대신하여 Marketplace에 있는 워크플로우를 분석해서 사용했습니다.

Development Workflow

workflow, Issue를 최적화한 후 남은 과제는 화면입니다. Jira가 기본으로 제공하는 필드외에 새로운 필드와 필드값이 필요한 경우가 있습니다. 예를 들면 시험시나리오를 시험할 사람이 복수일 경우 이를 시나리오에 기록하고 화면에 보여줄 필요가 있습니다. 이 때 관리자화면 Custom Filelds를 이용하면 필요로 하는 필드를 만들 수 있습니다. 저의 경우 20여개 필드를 추가로 만들었습니다. 그리고 customware parent issue Summary을 이용하여 Sub-Task인 결함에서 Parent의 Summary를 볼 수 있도록 했습니다. 어느 시나리오에서 발생한 결함인지 확인할 수 있습니다.

여기까지 하면 운영을 위한 기본적인 준비가 끝났습니다. 이제 개발자와 시험자를 위한 환경을 만들어주어야 합니다. 구현이든 시험이든 가장 중요한 것이 Assignee입니다. 내가 할당받은 이슈를 볼 수 있도록 해주어야 합니다. 이를 위한 표준적인 작업이 Dashboard입니다. Jira가 모든 이용자에게 제공하는 가장 기본적인 Dashboard는 System Dashboard입니다. 관리자가 만들어서 제공합니다. 이용자는 이것을 이용하여 자신만의 Dashboard를 만들 수 있습니다. Dashboard를 만들 때 두가지가 필요합니다. 보여주려고 하는 데이타를 정하는 Filter와 데이타를 보여주는 Gadget입니다.

3.
Filter는 Jira가 관리하는 데이타를 검색하여 결과를 볼 수 있도록 하는 기능입니다. 메뉴선택식으로 데이타를 검색하는 방법도 있지만 JQL을 이용하면 무척이나 편리하게 다양한 데이타를 검색할 수 있습니다. 저도 100여개 넘는 필터를 만들어 사용했습니다. 그런데 내가 찾고자 하는 데이타를 검색할 때 제공하는 Query가 부족할 때가 많습니다. 이를 보완하기 위하여 상용 혹은 무료의 플러그인을 설치해야 하니다. 저는 무료로 제공하는 ScriptRunner for JIRA를 설치했습니다. 기본환경에서 설치할 경우 enable할 때 오류가 발생하는 경우가 있습니다. 저도 그랬습니다. 이 때 Java 환경변수중 메모리와 관련한 값을 바꾸어야 합니다. 관리자화면에 있습니다. 제공하는 script중 가장 애용한 것이 subtaskof와 parentof입니다. 일정관리를 위해 필요한 통계를 만들 때나 특정한 단계에 있는 업무를 집중 요청할 때 사용했습니다

이상으로 만든 Filter는 Dashboard에서 유용합니다. Dashboard는 ‘내게 필요한 정보를 시각적으로 적절한 방식을 통하여 집중해서 보여주는 도구’입니다. 로그인을 하면 처음 만나는 화면이기 모든 개발자나 시험자 혹은 프로젝트관리자에게 쉽게 노출됩니다. Dashboard Gadget은 여럿입니다. 상용도 많습니다만 저는 기본적으로 제공하는 것만 사용하였습니다. 가장 많이 사용한 것이 Issue statistics와 Issue filters 및 Two dimension filter statistics입니다. Dashboard는 여러개를 만들어 사용할 수 있습니다. 관리자가 만들어주거나 이용자가 직접 만들어도 됩니다. 저의 경우 개발자들이 요청하면 다 만들어주었습니다. Filter를 같이 작업해야 하기때문에 시간 절약하기 위함이었습니다. 사실 개발자의 관점, 관리자의 관점, 고객의 관점, 현업의 관점이 같을 수 없습니다. 보고싶은 데이타도 다릅니다. 그렇기 때문에 Filter와 Dashboard는 무척이 중요합니다.

4.
이상으로 Jira의 경험을 정리했습니다. 거의 1년이상을 사용한 경험을 짧게 정리했습니다. 지내온 시간을 되돌아 보면 아쉬운 점이 있습니다.

첫째 개발 및 시험단계의 소스 관리가 쉽지 않습니다. 개발자들에게 친숙한 개발환경은 단말입니다. 소스관리도 디렉토리로 합니다. 이것은 몇 십년된 습관입니다. 이를 프로젝트하는 시간에 고치기 힘듭니다. 개발-시험-결함으로 이어지는 경험이 담긴 소스를 만들고 싶었는데 100% 이루지 못한 원인입니다.

둘째 최초 구상은 요구사항정의서 – 설계단계산출물 – 구현단계산출물 – 시험단계산출물인 이슈(Jira의 Issue)를 서로 연결하여 요구사항추적표처럼 기능할 수 있도록 해보고 싶었지만 뜻을 이루지 못했습니다. 혼자 하다 보니 입력할 것이 많아서 쉽지 않네요. 혹 REST-API등을 이용하여 프로그램을 처리할 시간이 있었으면 배치프로세스를 만들어 자동으로 입력해서 연결시킬 수 있었지만 시간도 없고 공부를 하지 못했습니다.

셋째는 품질관리입니다. 몇가지 보완을 했으면 품질관리를 위한 더많은 결과를 내놓을 수 있었지만 이점이 아쉽네요. 예를 들어 Fisheye를 이용하여 P2P리뷰를 하는 일입니다. 결함이 수정된 내역을 보면서 설계를 되돌아 보는 일도 있었습니다. 모두 시간이 필요합니다만 시간이 없었습니다.

요즘 프로젝트와 운영를 구분하기 힘듭니다. 무한개발, 무한운영입니다. 그래서 Devops라고 합니다. 이럴 수록 환경이 중요합니다. 지난 시간동안 Jira를 100% 사용했다고 할 수 없지만 Jira를 이용하여 프로젝트의 관리를 효율적으로 했다고 느낍니다. 특정한 회사를 홍보하는 글인 듯 하지만 훌륭한 제품입니다. Control-M처럼 소리없이 강한 제품입니다. 아니 시끌벅적한 제품입니다.

참, mimul님이 엑셀로 만들어진 WBS에서 공개한 엑셀도 잘 사용하고 있습니다. MS Project를 사용했던 때가 있었지만 지금은 Mimul님의 것을 수정해서 사용합니다.

Jira컨설팅을 해볼까?(^^)