JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #1
IT에서 일하고 있다면 Jira에 대해서 한 번쯤 들어 보셨을 겁니다.
Jira | Issue & Project Tracking Software | Atlassian
Plan, track, and manage your agile and software development projects in Jira. Customize your workflow, collaborate, and release great software.
www.atlassian.com
개발자던 QA이던 구인 공고 단골 Job Description이기도 합니다.
보통 기업 혹은 개인이 JIRA를 사용한다고 하면 BTS(Bug Tracking System)로 많이 사용을 하고 있습니다.
하지만 JIRA Software는 단편적으로 BTS로만 사용하기에는 너무도 아까운 시스템이기 때문에 버그 트래킹뿐만이 아니라 실제로 실무에서 확장성 있게 어떻게 적용을 해야 하는지에 대해서 말씀드리고, 어느 부분부터 적용하는 것이 효율적인지에 대해서 말씀드리려 합니다.
😅 아래 글은 필자가 경험한 10여 년 간의 경험을 바탕으로 작성되었으며, 정답은 아닙니다.
조금이라도 아래와 같이 적용을 생각해 보셨거나 하고자 하는 의지가 있으시다면 꼭 실천해 보시기 바랍니다. 개발 프로세스 품질이 좋아질 것이고, 출시 후 품질도 향상되실 겁니다.
JIRA에 대한 자세한 설명 및 기능에 대한 정보는 아래 사이트를 확인해 보세요.
ALM Space Home - CURVC ALM Space - Confluence
배너의 맨 끝으로 배너의 맨 처음으로 ALM Space Home 메타 데이터의 끝으로 건너뛰기 설진호 이사님이 작성, 2020-10-07에 최종 변경 메타 데이터의 시작으로 이동 Welcome! 커브에서 운영하는 ALM Service D
confluence.curvc.com
개요 - 우린 BTS로만 쓰려고 Jira 구입한 것은 아닌데?
이미 아틀라시안에서는 가장 효율적인 프로세스를 하나의 이미지로 설명하고 있습니다.
아래와 같이만 구축하고, 프로세스가 잘 수행되고, 정책도 잘 지켜진다면 따로 얘기하지 않고도 개발 품질이 정말 좋아질 겁니다. 왜? 아틀라시안의 수많은 전문가들이 아래와 같이 쓰라고 권장했기 때문이죠.
추천하는 도구는 Confluence, Jira, Bitbucket, Bamboo 4가지입니다.
간단하게 요약해서 말씀드리면 Confluence는 보통 산출물이나 보고서, 커뮤니케이션을 위한 도구이고, Jira는 프로젝트를 관리하고, 이슈를 트래킹 하기 위한 도구입니다. Bitbucket은 형상을 관리하기 위한 도구이며, Bamboo는 빌드를 관리하기 위한 도구라고 생각하시면 됩니다.
위와 같이 권장함에도 적용하지 못하는 이유는 보편적으로 아래와 같습니다.
- 비용적인 문제
- 도구 사용법의 문제
- 시스템 도입 후 운영 문제
Jira를 도입하기 위해서는 우선 돈이 필요합니다. 딱 잘라서 250 user로 Confluence / Jira만 사용하게 되더라도 VAT 포함 1억(Data Center / Cloud / Server(2021.03 서비스 종료) 정도 생각하시면 됩니다. 도입 환경과 밴더사 별로 가격의 차이가 있음은 감안해 주세요.
또한, 도구를 도입하고 밴더사로부터 교육을 받았지만 막상 사용을 하려고 보니 막막하기만 합니다. 이게 현실입니다. 회사에 아무도 사용해 본 사람이 없습니다.(저희 회사 같은 경우 100명 중 사용 경험자 저를 포함해 2명) 좀 극단적인 예시 기는 합니다.
시작도 못했는데 운영을 하려니 더더욱 막막해집니다. 무엇부터 손을 대야 하는지 알 수도 없습니다.
그나마 이슈 만들고, 밴더사에서 만들어준 워크플로우대로는 사용이 가능하니 결국은 BTS로 밖에 사용하지 못하는 상황이 발생하는 것입니다.
접근 - 무엇을 먼저 시작해야 할까?
가장 먼저 해야 할 일은 분석입니다.
분석이라고 해서 엄청 거창하거나 그런 일은 아닙니다.
Jira를 통해 무엇을 할지부터 명확히 해야 합니다.
그러기 위해서는 기존의 프로세스에서 무엇을 사용하고 있었는지 어떤 점들을 Jira에 녹일 것인지를 정리해야 합니다.
현재 프로세스를 분석해서 Jira로 구축을 했으면 하는 부분들을 엑셀에 정리하였습니다.
크게는 사용자 / 이슈 유형 / 워크플로우 / 해결책이고, 가장 중요한 부분은 이슈 유형의 정리입니다.
지금까지 여러 부서와 협업을 했기 때문에 어느정도는 무슨일을 하고 있는지 알고 계실겁니다. 그것을 추상화 개념으로 정리를 하는 것인데요.
이슈 유형은 TASK 즉, 담당자가 할 일을 구분해 놓은 구분자로 예를 들면, 개발자가 신규 기능을 개발해야 한다면 이슈 유형으로 "신규 아이템" 등과 같은 이슈 유형이 존재해야 하는 것입니다.
앞으로 이슈 유형은 워크플로우라는 프로세스를 탈 것이며, 프로세스 간 상태 별 다른 화면을 볼 것이고, 최종적으로 이슈가 종료되기까지 어떠한 과정을 거치는지에 대해서 확인하게 될 것입니다. 이번 시간은 개요이기 때문에 이슈 유형에 대해서는 다음 글에 상세히 설명드리도록 하겠습니다.
또한, Jira는 굉장히 논리적인 시스템으로 A를 만들기 위해 A-1, A-2가 등록되거나 작성되어 있지 않으면 A를 만들 수 없게 되어 있습니다. 반대로 이야기하면 A를 지우기 위해서는 A-1과 A-2를 삭제 후에 A를 삭제할 수 있다는 이야기도 됩니다.
유효성✔이 아주 강하게 적용된 시스템이라 생각하시면 됩니다.
📌 "유효성(validation)"이란 특정 요구사항이 충족되었다는 것을 객관적 증거의 조사 및 제공에 의해 확인하는 절차를 말한다.
대략적으로 기존 프로세스에 대해서 분석하고, 필요한 요소들이 정리되었다면 시스템을 어디에 적용할지 범위를 정리합니다. 전 간단하게 도식화했습니다.(아틀라시안에서 권장하는 영역을 조직에 맞게 도식화)
위와 같이 범위까지 정리되었다면 첫 번째로 정리한 이슈 유형들을 어떻게 사용할지 정리를 해야 합니다. 처음 Jira를 도입하게 되면 이슈에 대한 개념도 그냥 이벤트로만 생각할 수 있습니다. 내가 할 일이 이슈라는 것을 먼저 인식시켜야 합니다. 교육을 통해서도 좋고, 정기적인 메일로 리마인드 해도 좋습니다. 전 교육도 진행하면서 개별적으로 알려 드리면서 인식시켰습니다.
이렇게 이슈에 대한 개념이 잡히게 되면, 기본적으로 사용하는 이슈 유형에 대해서 설명이 필요하게 됩니다. Jira 프로젝트를 생성하게 되면 기본적으로 큰틀(에픽) / 이야기 / 신규 아이템 / 버그 / 개선 사항 / 작업 / 부작 업이 생성되게 됩니다.
특히, 에픽과 이야기에 대한 이슈를 잘 모르는 경우가 많습니다. 사실 필수 항목은 아니기 때문에 꼭 써야 한다 이런 것은 아닙니다. 향 후 리포트에 대한 데이터를 정재 하기 위해서는 아주 좋은 정보로 유용하게 쓰일 수 있다는 것만 알고 계시면 좋을 것 같습니다. 자세한 설명은 이슈 유형 정리할 때 말씀드리도록 하겠습니다.
위 도식은 요구사항이 이슈(할 일)로 만들어질 때 어떻게 만들어지는지에 대해서 표시해 둔 것입니다.
명세 1은 에픽 1로 만들어지는 건데요. 예를 들어 알려 드리도록 하겠습니다.
| 명세1 | 에픽 1 | 포함된 이슈(할 일) | 이슈 상세 작업 |
| 로그인 기능 개발 | 로그인 기능 | Story : 로그인 시나리오 | |
| New Feature1 : ID 입력란 | Task1 : 기능 개발 Sub-Task1 : DB 구성 |
||
| New Feature2 : Password 입력란 | Task2 : 기능 개발 Sub-Task2 : DB 구성 |
||
| Bug : 로그인 버튼 안눌림 |
이렇게 요구 명세로부터 이슈들 간의 링크가 생성되게 되면 최종 산출물에서는 이슈들 간의 추적성이 생기게 되고, 요구 추적이라는 활동을 할 수 있는 환경이 구축되게 됩니다. 요구 추적이 왜 중요한지는 마지막 장에서 다루겠습니다.
요약 : 현 상태를 분석하고, 무엇이 필요한지 정리하자.
Jira를 도입하기 전 위와 같이 정리하였고, 미리 공지하여 필요한 요소나 플로우가 있는 경우 회신을 달라고 요청하였습니다. 사실 Jira를 사용해 보지 않은 조직은 몰라서 무엇을 요청해야 할지도 모르는 상황이 대부분입니다. 부담 없이 "앞으로 이런 거 할 건데 필요한 것 있으면 얘기해" 정도의 가볍지만 가볍지 않은 메일을 공유하시기 바랍니다.
위의 정리한 정보들은 정답은 아니고, 정확할 필요도 없습니다.
참고할 만한 수준으로 작성하시길 바라며, 이후 진짜 시스템에 내용을 적용할 때는 실 사용자들에게 이슈 유형(할 일)에 대한 요구사항을 취합✔하여 어떤 부분이 필요한지 피드백을 받아야 합니다.
📌 이슈 유형에 대한 요구 사항 취합 : 담당자들이 무슨 일을 하는지에 대해 조사하고, 카테고리화 하여 이슈 유형으로 정리해야 합니다.
이제 시스템을 도입하기 전까지 준비작업이 완료되었습니다.
다음 글에서는 정리된 내용을 시스템에 어떻게 적용하였는지에 대해서 설명드리도록 하겠습니다.
요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, 아틀라시안, 지라, 컨플루언스, jira, 업무 프로세스 관리
'PROCESS > ALM(FEAT.JIRA)' 카테고리의 다른 글
| [지라 기본 가이드 - Chap.1] 야 너두 Jira 할 수 있어(feat.Confluence) (0) | 2022.03.17 |
|---|---|
| [실무적용편 - Chap.4] JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? (0) | 2021.06.11 |
| [실무적용편 - 테스트 요청] 필요한 정보만 요약해서 요청서 작성하기(feat.Confluence) (0) | 2021.05.20 |
| [실무적용편 - Chap.3] JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? (0) | 2021.05.04 |
| [실무적용편 - Chap.2] JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? (0) | 2021.04.20 |