2015년 5월 28일 목요일

JIRA의 visualization에 대한 개선 아이디어




JIRA의 대시보드와 가젯을 통한 가시화 기능은 정말 편리하다. 
필터를 자기 입맛에 맞게 정의하기만 하면, 가젯에서 필터를 불러들인 후 각종 차트나 테이블, 리스트까지 보여주는 형식도 다양하게 설정이 가능하다. 자동 갱신기능이나 wallboard로 표시해주는 등 사용자를 많이 배려하고 있음이 느껴진다.

하지만, 시간이 지나 JIRA에 적응하고 난 후에는 아쉬운 점들이 눈에 띄기 시작한다. 아쉬운 마음에 플러그인들을 찾아보지만 정작 내가 원했던 형태의 플러그인을 찾을 수 없거나, 찾았다 하더라도 가격이 너무 비싸고 필요하지 않은 기능들까지 제공하고 있어 선뜻 구매하기 어려운 경우도 겪게 된다.

최근에 회사에서 프로젝트 수행 및 모니터링의 수준으로 높이고자 PMO를 운영하기로 결정하여서, 전사차원에서 프로젝트 진행을 관리 및 모니터링 해야할 필요가 생기게 되었다. 일반적인 경우에는 전문적인 PMS 솔루션을 도입하는 방법이 아무래도 편하겠지만, 나의 회사에서는 JIRA를 중심으로 업무시스템을 구성한다는 목표를 가지고 있어서 JIRA를 활용하기로 결정하고 프로젝트를 어떻게 관리하면 좋을지 고민을 시작하게 되었다.

회사 전체의 프로젝트에 대한 통합 view도 있어야 하겠지만, 먼저 개별 프로젝트의 상황을 어떻게 보여줄지부터 시작하기로 했다. 단순하게 생각해보니 프로젝트에는 달성목표가 있고 발생하는 이슈가 있고 리스크가 있었다. (PMBOK에는 더 많은 항목들이 있으나 단순화하여 설명을 돕기 위해 3가지만 다룸)

프로젝트 관리에 사용할 이슈타입으로 PJT_GOAL, Issue, Risk를 만들고 PJT_GOAL에 Issue, Risk를 이슈링크를 통해 연결했다. 여기서 JIRA가 가지는 문제점은 한 화면에서 링크된 이슈에 대한 상세항목까지는 확인이 불가능하다는 점이다. summary나 우선순위정도가 보일뿐이고 그나마 5개가 넘어가면 강제로 접혀서 버튼을 눌러야 모든 링크된 이슈를 확인할 수 있다. 

예전부터 이슈링크에 대한 JIRA 자체 표현의 한계를 느끼고 있던 터라, 이번 기회에 코딩을 조금 하게 되더라도 원하는 모습으로 표현을 해보기로 했다. (떄 마침 상사분이 미국으로 일주일 넘게 다녀오셔야 하는 행운인 상황도 큰 도움이 되었다.)
JIRA가 REST API를 제공하는 것은 진작부터 파악하고 있던 내용이었지만 JIRA에서 어떻게 데이터를 끌어오고 형식은 무엇인지 그리고 간단하게 웹을 통해 UI를 제공할 방법이 있는자가 문제였다. 


가장 많이 사용하는 tomcat이나 nginx, node.js 등 여러 솔루션을 찾을 수 있었는데 예전에 AJAX 개발을 했던 경험이 있어 친숙한 Javascript로 돌아가는 backend 기술인 node.js로 구현을 해보기로 결정했다.

플랫폼 node.js기반에 HTML5로 하기로 결정하니 나머지는 그냥 검색으로 많은 정보를 얻을 수 있었다. 
먼저 JIRA의 REST API를 호출할 방법을 찾아보니 GitHub에서 여러 라이브러리를 찾을 수 있었다. jira-node, node-jira를 찾을 수 있었는데 여기서는 jql 쿼리를 보내고 결과만 받으면 되기 때문에 심플한 jira-node를 사용하기로 했다.


소스코드는 아래를 참조
https://github.com/e-conomic/jira-node


node-jira가 더 많은 API를 지원하고 문서도 좀 더 자세하게 작성되어 있기는 하다. 다시 말하지만, 지금은 그저 JQL로 필터처럼 조건을 JIRA에 보내서 결과를 JSON으로 받기만 하면 되고, 받은 JSON 데이터를 가공해서 원하는 화면의 위치에 표시해 주기만 하면 되므로 jira-node를 사용하였다. 

모든 웹서비스(XML Webservice, REST API)가 다 그렇듯 맨 처음 호출할 때는 시간이 오래걸리지만 2회 이상에서는 그다지 느리지 않게 결과 데이터를 받을 수 있었다. (체감 속도 비교 => 1회차 : 8~10초, 2회차 이상 : 2~3초)

사실 여기서는 backend 기술이라고 부르기도 민망할 정도로 간단하게 끝나는 상황이고, 받은 JSON를 요리조리 가공해서 원하는 view로 웹을 통해 보여주는 작업이 더 시간을 많이 필요로 했다. 

다시 처음의 그림을 가지고 설명하자면,
JQL 쿼리의 결과로 받은 JSON 데이터에서 등급으로 분류하여 왼쪽의 바에 해당 등급의 PJT_GOAL들을 보여주고 클릭하면 그 PJT_GOAL의 상세내용과 이슈링크 되어 있는 Issue, Risk 아이템까지 끌어와서 한 화면에 전부 다 보여주었다. 





다음에 기회가 된다면 직접 작성한 node.js코드와 frontend 코드를 소개하고 싶다. 현재는 프로토타입이라 생각하고 짜임새 있게 코딩된 상태가 아니라서 당장 공개할 수는 없지만, 코드가 정리되는 대로 GitHub를 통해 공개할 생각이다.

JIRA를 2년 넘도록 관리자, 사용자로서 사용해 오면서 항상 아쉬웠던 점이 JIRA안에서 무엇이든 할 수 밖에 없었다는 것이었는데, 이번 기회를 통해서 그 한계를 뛰어넘을 수 있다는 자신감을 가질 수 있었다는 느낌이다. 

JIRA는 매우 훌륭한 솔루션이고 그 유연함은 항상 감동을 안겨주지만 Atlassian 또는 3rd party 제작사에서 채워주지 못하는 부분 또한 있는 것이 현실이다. 나 자신도 JIRA를 커스터마이징 하는 방법은 직접 플러그인을 만드는 방법만 있을 것이라 잘못 생각하고 있었는데, 직접 코딩을 해야 하는 부담은 있지만 데이터만 꺼내서 자신있는 개발언어, 플랫폼에서 자신이 원하는 모습으로 만들어 내는 것도 큰 보람을 느낄 수 있고 오히려 더 효율적이라는 점을 깨달을 수 있었다.

프론트엔드 동작 동영상





태그 :  , , , ,   With No comments 

2015년 5월 23일 토요일

ALM

ALM


현재 회사에서 사용하는 ALM과 관련된 사내시스템에 대한 구성을 정리해 본 자료

상용제품과 오픈소스 솔루션을 엮여서 구성함.


간단히 설명하자면,

이슈관리시스템이자 업무기반시스템으로 Atlassian사의 JIRA제품을 사용하여 업무 커뮤니케이션의 중심으로 삼아 Rawdata를 축적하고,

같은 Atlassian의 Confluence제품을 사용하여 전사차원의 정보 공유를 위한 장으로 활용,

개별 프로젝트를 진행할 때에는 
형상관리용도로 Alfresco Community로 오피스 문서위주의 바이너리 파일을 사용, Stash(Git)로 소스코드관리를 사용함, 
Stash와 연동하여 Jenkins를 통해 자동빌드, 배포관리를 수행하고 jenkins에 sonarqube를 연동시켜 코드 정적분석을 수행함.

그 밖에 사내의 교육 동영상, 버그리포트 동영상등 외부에 공개해서는 안되는 동영상을 사내한정으로 스트리밍으로 제공하기 위한 red5도 사용함.

상용제품 : JIRA(플러그인: JIRA Agile, JIRA Service Desk, Structure, TEMPO), Confluence, Stash
freeware : SourceTree, HipChat
오픈소스 : Alfresco Community, sonarqube, red5

실제로 동작하는 모습은 아래의 동영상과 실제로 거의 유사함

태그 :  , , , , , , , , , , ,   With No comments 

2015년 5월 17일 일요일