atlassian JIRA 를 활용한 이슈 및 프로젝트 관리

1. 정광섭 LESSTIF@GMAIL.COM
JIRA 를 활용한 업무 공유 및
프로젝트 관리

2. Agenda
프로젝트 관리의 어려움
이슈 관리 시스템
JIRA 의 특징
JIRA 101
JIRA Anti Pattern

3. JIRA 를 도입할 때 도움이 될
작은 정보들을 정리해
보았습니다.

4. 프로젝트 관리는 왜
어려울까?

5. 삼국지에서 제갈공명은…
공명: 장군, 이런 일이 닥치면 파란 주머니를, 저런 일이
닥치면 빨간 주머니를 열어 보게.
장군은 저런 일이 닥쳐서 빨간 주머니를 열고 그 안에 있는
계책대로 일을 처리한 후에…
장군: 아 승상은 이 모든 걸 다 예측하셨구나(감탄)…

6. 하지만 현실은…

7. 헬무트 폰 몰트케(Helmuth von Moltke) 장군
비스마르크와 함께 독일 통일을 이룩하고 독일
제국을 수립한 명장
수천 가지 요인을 고려한 상세한 전투 계획으로 유명
하지만 “적과 만나는 순간 전투 계획은 쓸모
없어진다” 라는 말을 남김
출처: 위키피디아

8. 드와이트 아이젠하워(Dwight Eisenhower)
2차 대전의 명장으로 미국의 34대 대통령
초기 계획에 매몰되지 말고 상황 변화에 따른
유연한 대응 강조
"plan is nothing, planning is everything”
라는 명언을 남김

9. 프로젝트 관리 계획 = 전투 계획 ?
실전에서 어떻게 반응할지 모르는 적처럼 초기 계획대로
프로젝트가 진행되는 경우가 없음

10. 만약 프로젝트가 초기 계획대로 진행되고 있다면 다음중 하나의 상황
• 계획한 사람이 미래를 정확하게 예측하는 예언가
- 그렇다면 이번 주 로또 번호 좀 찍어주세요….
• 프로젝트가 정말 단순하고 계획이라 할만한 복잡한 게 아예 없음
• 주위의 변화하는 환경에 대응하지 못하고, 목표에서 심각하게
벗어난 SW 프로젝트가 완성되는 중
“프로그래머로 사는 법“ 중

11. 프로젝트의 3대 특성
• 일시적(Temporary) – 기한이 있음
• 고유함(Unique) – 고유의 결과물(건물, SW, 제품등)
• 점진적 구체화(Progressive Elaboration) - 프로젝트 범위와
산출물은 초기에 개괄적으로만 정의되었다가 진행하면서 구체화
될 수 밖에 없으며 이로 인해 초기의 계획이 어긋나게 됨.
“PMBOK(project management body of knowledge) “

12. 대표적인 프로젝트 방법론 –폭포수(Waterfall) 모델
• 일련의 절차에 따라 진행하는 프로젝트 관리 방법론
• 각 단계별 일정 계획을 수립하고 이해하기가 쉬움
• 분석, 개발등 파트별로 업무를 분장하고 관리 용이

13. 폭포수(Waterfall) 모델의 문제
• 낮은 품질 - 프로젝트 종료 시점에는 시간이 부족하므로 납기를 위해
테스트를 줄여서 품질이 낮아짐
• 낮은 가시성 - 고객은 프로젝트의 종료 시점에야 구동하는 제품을 볼 수
있으므로 실제 원했던 제품과 괴리가 발생
• 변화에 대응하기 어려움 – 현실은 설계가 완료되었어도 개발/테스트
단계에서 설계를 수정해야 하는 경우가 자주 발생

14. 폭포수 방법론과 Excel 로 프로젝트 관리를 할 경우…

15. 과연 마지막 버전의 파일명은?

16. 이력 관리와 산출물 문제
산출물
소스 코드, 매뉴얼등 산출물은
어디에서 확인? 파일 서버?
진척률
담당자가 제시한 진척률
13.5%는 무엇을 기준으로 했나?
추적
진행중인 일이 환경(구현
난이도 증가, 외부 솔루션 버그
발견등)에 따라 변경될 경우
이력 관리는?

17. 상사가 프로젝트 진척률을 물어볼 경우 Tip!
출처: nounproject
• 체계적으로 관리되고 있는 것처럼 보이기 위해 진척률은 2나 5로
나누어 지지 않는 숫자를 정하고 임의의 소수점 2자리를 붙이세요
• 15% (X)
• 13.75 % (0)
• “진척률의 근거” 를 물어보는 경우는 없었으니 안심하세요.
• 어차피 저거 다 의미 없는 숫자인 데 안심이라도 시켜드려야죠.

18. 협업과 공유 문제
피드백
참여자들끼리 피드백을
교환하고 이를 계획에
반영하려면?
공유
피드백과 구체화된 내용은
어떻게 공유 ?
일정계획표-최종-final-마지막-
#5.xlsx 만들어서 메일로 전송?
구체화
실제 진행하면서 구체화되는
내용 관리 필요

19. 변화에 적절하지 않은 도구 – Excel
• 엑셀은 최고의 스프레드 시트 프로그램 (저도 좋아합니다)
• 변화하는 환경에 대응이 어려운 나쁜 프로젝트 관리 도구
• 협업과 수정/배포가 어렵고 추적이 불가능

20. 변화에 대응하고 관리할 수 있는 방안 필요
• 유연하고 검증된 방법론과 프로세스 도입
• 방법론과 프로세스를 잘 구현한 실용적인 좋은 도구
"당신이 가진 도구가 망치뿐이라면 모든 문제는 못으로 보일 것이다.”
- Abraham Maslow

21. 이슈 관리 시스템
Issue Tracking System

22. 이슈(Issue)란?
• 오류, 버그 및 '새로운 기능', 작업요청, 사소한 질문이나 의견등
제품에 관해 회사에서 대화의 대상이 되는 거의 모든 것.
• 이슈 종류에 따라 개발자의 구현이 필요 없는 경우도 상당수 있음
“글로벌 소프트웨어를 꿈꾸다." 김익환. p.48

23. 이슈(Issue)란?
• 버그나 Problem은 이슈 종류중 하나
• 새 기능, 개선, 작업, 의견, 문의등 프로젝트에서 발생하는 모든 것
• 특정 시스템(Ex: Trac)에서는 Issue를 Ticket 이라고 하기도 함.

24. 이슈 관리 시스템(ITS; Issue Tracking System)
• 초기 계획에 매몰되지 않고 변화에 대응하기 위한 방법론과
프로세스를 구현한 제품
• S/W 공학의 정수로 형상 관리와 더불어 프로젝트의 핵심 인프라
• 일반적으로 Web 기반이라 별도의 설치없이 손쉽게 사용 가능
• Mantis, BugZilla, Redmine, YouTrack, JIRA 등 다양한 제품 존재

25. 도입시 고려 사항
• 회사의 프로세스, 이력, 지식이 쌓이는 핵심 자산이므로 장기적인
관점에서 검토
• 비 개발 부서도 적극 참여 필요
• 이를 위해 사용이 쉬워야 함
• 입력 화면 필드 최소화등 유연한 Customization 기능 필요
• 형상 관리, 지속적인 통합, 메신저등 다양한 제품과 통합을 위한
REST API, Web Hook 제공 필요

26. Mantis
• Bug Tracking System
• 설치와 사용은 간단하나 기능이 부족하고 UI 부실
• 형상관리 연계 부족
• 비 IT 부서원들에게 사용을 권하기는 많이 부족

27. BugZilla
• Mozilla 웹 브라우저용 Bug Tracking System
• RedHat 사에서도 사용중
• Mantis 보다는 낫지만 전사 이슈 관리로 권장하지 않음

28. Redmine
• 괜찮은 Issue 관리 시스템
• 깔끔한 UI 와 간결한 기능, 자체 위키 내장
• 전사 이슈 관리로 사용하는 것도 괜찮지만 Issue 가
많아지면 급격히 속도가 저하됨
• Free 다 보니 리포팅 및 관리 기능 부족

29. YouTrack
• 제가 정말 좋아하는 훌륭한 개발툴을 만드는
JetBrains 사 제품
• 개발팀을 위해 설계
• 비 개발자가 사용하기는 좀 어려움
• Work Flow Customizing 난이도 높음
• 외부 서비스와 Integration 이 부족하고 Market Place
부재

30. JIRA
• 협업 전문 도구 Atlassian 의 Issue 및 프로젝트 관리
시스템
• 깔끔한 UI 와 강력한 기능, 좋은 기술 지원 제공
• 자사 제품과 강력한 통합 지원(Confluence, Bamboo,
BitBucket)
• 매년 많은(?) 비용 발생 – 매년 Subscription 비용
도입가의 50%

31. JIRA
• Issue 관리 시스템은 기업의 핵심 인프라
• 초기에 비용이 발생하더라도 장기적으로는 JIRA
같은 상업용 제품을 쓰는 것이 장기적으로 이익
• Open Source 제품은 매뉴얼과 기술 지원이
부실하거나 없으므로 이에 소요되는 시간과 비용이
상당함

32. JIRA 101
시작하기

33. JIRA 에서 Issue 란
• 개선점, 버그, 새로운 기능 요청, 기술 지원, 협의 등 이력 관리
및 추적이 필요한 모든 사항
• 중요도, 완료일, 다른 이슈와 관계등 다양한 필드 설정 가능
• 개별 이슈는 구분하기 위한 unique key 가 있음(PROJECT –
일련번호 형식)
• TEST-42
• PROJ-671 등

34. Issue 등록 화면

35. Issue 등록시 주요 필드
• Summary: 대략적인 이슈 내용을 짐작할 수 있도록 요약해서 기술
• 이슈 공유합니다. (X)
• 요청 사항입니다. (X)
• IE 11 사용시 일일 정산 및 통계 기능 미작동 (O)
• Type: 이슈의 유형(Bug, 개선, Task 등) 지정
• Description : 상세한 이슈 내용 기록
• 비개발 직군의 참여를 높이기 위해 등록시 필수 항목은 최소화하고 추가 입력
항목은 화면 아래에 배치(관리자가 Screen Scheme 설정 필요)

36. Project
• JIRA 프로젝트는 이슈 들의 집합
• 소프트웨어 개발 프로젝트
• 마케팅 캠페인
• 웹사이트 개선 요청 시스템
• Project 는 Sub-Project 를 가질 수 없음(redmine 과 차이점)
• 보통 하나의 제품은 하나의 프로젝트에 매핑

37. Project 의 예
출처: jira.Atlassian.com

38. Component
• 이슈의 논리적인 집합으로 Sub-project 개념으로 사용 가능
• 문서 작업
• 백엔드 구성
• 고객 교육등
• 모든 Issue 는 하나 이상의 컴포넌트를 가질 수 있음

39. 기본 담당자 할당
• 프로젝트와 Component 마다 담당자를 지정해두면 이슈 등록시 자동
할당되므로 이슈 등록시 편리

40. Issue 의 Component

41. Version
• SW 의 기능이나 개선점등의 논리적인 묶음
• V1.0, V2.0-alpha 등
• 제품과 프로젝트의 과거 주요 변경 내역과 앞으로 나아갈 방향을 손쉽게
만들고 공유 가능
• 개별 Issue 는 버전 관련 2가지 필드를 설정할 수 있음
• Affect Ver: 버그등의 경우 발생하는 버전
• Fix Ver: 해당 이슈가 해결된 버전

42. Version 필드 적용 예

43. Version 과 Release 정보로 프로젝트 진행 파악

44. 이슈 상태(Status)
• 이슈가 life cycle(work flow)내에 어떤 상태인지를 의미
• 일반적으로 이슈는 생성(Open) 후 처리되고 종료되지만 프로젝트의
유형에 따라 다른 work flow 를 가질 수 있음
• 종료된 이슈라도 다시 열릴 수(Reopened) 있음(예: 버그 재발생)
• Reopen이 될 수 있다는 것은 실제 프로젝트의 현실을 반영하며 이에
따른 유연한 대응이 가능

45. 이슈 처리 상태(Resolution)
• 이슈가 어떻게 종료되었는지 구체적인 사유를 표시하는 항목
• 일반적으로 Fixed 나 Closed 로 해결된 이슈인 것을 표시
• 현실적으로 등록된 모든 이슈를 종료할 수는 없고 프로젝트의 우선
순위에 따라 선별하여 처리
• 자체적으로 처리할 수 없는 이슈(OS 버그, 브라우저 버그 등)일 경우
Won’t fix 등으로 변경

46. 작업 흐름(Workflow)
• 이슈 관리 시스템의 가장 중요한 기능
• 이슈 lifecycle 이 완료될 때까지의 각 상태(Status)로의
전이(transition) 관리 및 추적 가능
• 대부분의 ITS 는 Workflow 생성/관리 기능 내장
• 프로젝트의 특성에 맞게 임의로 설정 가능

47. 작업흐름 – Simple Work Flow

48. 작업흐름 – Simple Software Devel Work Flow

49. 작업흐름 – Fulfilment with Approvals workflow

50. 이슈별 작업 흐름(Workflow) 보기

51. 새로운 Workflow 가 필요할 경우
• 관리자 권한으로 새로운 workflow 생성
• 또는 Market place 에 올라온 workflow 검색 & 설치

52. 이슈 연결(Link)
• PMP 의 PDM (Precedence Diagram Method) 보다 더 실용적으로
이슈간 관계 및 우선순위를 관리하는 방법
• https://www.lesstif.com/pages/viewpage.action?pageId=51282196

53. 이슈 검색
• 살아있는 프로젝트 진행 정보를 다양한 조건으로 검색 가능
• 강력한 검색을 위한 전용 언어 JQL (JIRA Query Lang) 제공
• 개별 담당자는 보고를 위한 자료를 만들 필요없이 개별 Issue 만 최신 정보로
갱신하면 되며 아래와 같은 요청 최소화
• 금주 주간업무 작성해 주세요
• 주요 업무 현황 보고 바랍니다.

54. 이슈 검색

55. 이슈 검색

56. JQL 로 이슈 검색
• https://www.lesstif.com/pages/viewpage.action?pageId=18220188 참고

57. 이슈 필터 및 구독
• 자주 사용하는 필터를 저장하고 공유
• https://www.lesstif.com/pages/viewpage.action?pageId=18220186 참고

58. Smart Commit
• 형상 관리 커밋 메시지와 JIRA 이슈 연결
• 커밋 메시지에 특정 키워드(예: fixed, close 등) 가 있을 경우 자동으로
JIRA 이슈 상태 변경
• https://www.lesstif.com/pages/viewpage.action?pageId=18220186 참고

59. Smart Commit
• 형상 관리 커밋 메시지와 JIRA 이슈 연결
• 커밋 메시지에 특정 키워드(예: fixed, close 등) 가 있을 경우 자동으로
JIRA 이슈 상태 변경
• https://www.lesstif.com/x/SIEOAw참고

60. JIRA Anti Pattern

61. JIRA 사용이 정답은 없지만
개인적으로 권장하지 않는
사용법을 정리했습니다.

62. Issue 삭제
• 중복등의 이유로 이슈를 삭제하는 것
• 동일한 버그라도 사용자 관점에서는 다른 증상으로 나타날 수
있으므로 삭제보다는 ISSUE Link 사용하며 관계를 중복으로 설정
• 이슈를 삭제할 경우 이슈 등록자는 무시당했다는 느낌을 가질 수
있음

63. 우리 프로세스는 남다르다는 생각
• 우리 프로세스는 달라서 JIRA 나 redmine 등의 도구를 사용할 수
없다는 생각
• 프로세스가 다른 이유는 정형화되어 있지 않기 때문일 수 있음
• 이런 제품을 쓰지 못한다면 프로세스를 재검토해볼 필요가 있음
• workflow 가 다른 건 회사나 팀마다의 특징이며 이는 JIRA 의
workflow 에디터를 사용하여 재정의 가능
• 기타 알림 정책, 보안 정책등은 JIRA 의 WebHook 등으로 대처 가능

64. Issue 별 엄격한 Worklog 기록
• 작업 시간 기록을 세밀하게 관리하는 것에 거부감을 갖는 담당자가
많음(지나친 통제를 받는다고 느낌)
• 해당 이슈를 처리하는 데 드는 시간 기록이 정말 필요한지 용도와
목적을 면밀히 검토 및 내부 조율
• 담당자들에게는 Worklog 기록 용도를 상세히 설명

65. Issue 처리 내역을 댓글로 하지 않고 본문 수정

66. Issue 처리 내역을 댓글로 하지 않고 본문 수정
• 해당 이슈를 처리한 이력과 변경사항은 댓글로 기술하면 한 눈에
이력이 표시됨
• 위키처럼 변경 이력을 이슈의 Description(본문) 부분만 수정하여
최종본만 남기는 경우 처리 이력을 보기가 어려움
• History 탭을 클릭해서 변경 이력을 확인해야 하나 가독성이 떨어짐
• 지라는 해당 이슈를 처리한 이력도 중요하기 때문에 최근 버전이
필요한 위키처럼 사용하면 안 됨.

67. PHP 에서 JIRA 와 연동 필요시
https://github.com/lesstif/php-jira-rest-client 추천

68. 정광섭 | LESSTIF@GMAIL.COM
Thank you!