이전 글에서 Issues와 Issue Tracking System란 무엇인가? 와 Jira 1. 무료 플랜 소개와 프로젝트 생성과 초기 설정 팁을 알아보았습니다.
이번 글에서는 사이드 프로젝트에서 GitHub Issues 대신에 Jira를 사용하게 된 이유와 후기를 소개하려 합니다.
상황, 사건의 개요
실무 경험이 없는 팀원(Only 개발자)이 모여 사이드 프로젝트를 하고 있습니다.
그동안 했던 프로젝트들은 기획/디자인이 사전에 준비되어있었습니다. 맘 편히 개발만 하면 되었습니다.
하지만 첫 기획부터 디자인까지 모두 담당한 사이드 프로젝트 남달랐습니다...🥹
협업을 위해 팀원 모두가 익숙한 도구를 사용했습니다.
사용한 도구
프로젝트 일정 / 위키 문서 관리 : Notion
디자인 : Figma
요구사항 분석 : Google 도구(docs, slides, sheets)
버전 관리 시스템 : Git, GitHub
이슈 트래킹 시스템 : GitHub Issues
메신저 : Discord
프로젝트 시작 3주가 지나고 팀원 모두 불편함을 느끼게 되었고 공통된 문제점을 발견하였습니다.
문제
case 1) 노션과 이슈 트래킹 시스템(GitHub Issue)의 연결의 어려움
예를 들어 아침 회의를 하며 "리뷰 작성 API에 00 버그가 있어요"란 안건이 나왔습니다. 노션 회의록 문서에 해당 문제를 작성합니다. 해당 일은 BE 팀 담당이니 BE 팀원이 노션 회의록 페이지 내용을 보고 GitHub Issue를 별도로 생성합니다. 생성된 issue 링크를 노션 회의록 문서에 re-링크합니다.
GitHub Issues의 issue 링크들을 하나하나 노션 문서에 넣는 것은 매우 번거로운 일이었습니다.
만약 BE 팀 담당이 깜빡하고 issue를 생성하지 않았다면 회의에 나온 안건이 늦게 issue화 되거나 심한 경우 잊어버리는 문제가 발생합니다.
case 2) 일정 관리
노션으로 개발 일정 관리를 하고 있습니다. case1에서 살펴보았듯이 노션과 GitHub Issue의 연결이 번거롭다 보니 자연스레 일정 관리 문서와 이슈 사이의 싱크도 불일치하게 되었습니다. 일정 관리하는 팀장은 한 번에 개발 상황을 인지하고, 매니징 하기 어려웠습니다.
case 3) GitHub Issues의 아쉬운 기능 (상/하위 계층 구조, 이슈 생성이 번거로움)
예를 들어 "비회원은 서비스 사용을 위해서 회원가입을 원한다"라는 큰 범주의 유저 스토리(에픽)가 주어졌다고 가정해봅시다.
이는 하위의 유저 스토리와 하위의 테스크들로 쪼갤 수 있습니다.
에픽(1개) : "비회원은 서비스 사용을 위해서 회원가입을 원한다'
유저 스토리(2개) : '비회원은 카카오톡으로 회원 가입하기 원한다.' / '비회원은 자체 이메일로 회원 가입하기 원한다'
하위 테스크(7개) : 'FE팀 : 카카오톡 회원가입 버튼 기능' / 'FE팀 : 회원가입 페이지 View' / 'BE팀 : 카카오 OAuth 회원가입 API' / 'BE팀 : 자체 로그인 서비스 API' / 'BE 팀 : 회원 DB 설계' / 'FE 팀 : 인수 테스트' / 'BE 팀 : 단위 테스트'
위 작업을 GitHub Issues에서 이슈를 만든다면 에픽, 스토리, 하위 테스크를 모두 이슈로 만들기 애매했습니다. 만든다 하더라도 이슈 간 계층 구조 설정이 간편하지 못했습니다.
또한 GitHub Issues에서 이슈를 만들 때 많은 이슈를 만들 때 직접 버튼을 클릭해서 만드는 방법이 번거롭고 시간이 오래 걸렸습니다.
case 4) 비 개발직군을 위하여
멀지 않은 미래에 디자이너 합류하게 됩니다. GitHub Issues가 익숙하지 않은 디자이너에게 'GitHub에서 이슈 발행해서 작업해주세요.'의 협업 제안에 어려움이 있습니다.
case 5) 우리의 목표는 개발!
노션을 작성하다 보면 지금 내가 개발을 하려는 것인지, 노션을 작성하려는 것인지 헷갈릴 때가 있습니다. 노션 문서 작성은 수단일 뿐이지 목적이 아닙니다.
Jira를 쓰기 전 상황
재발 방지를 위한 조치 항목
1. "이슈"에 대한 이해
프로젝트에서 대화/일의 대상이 되는 모든 것을 "이슈"라고 가정했을 때
모든 것을 "이슈"로 만들고 이를 잘 관리/추적하자
2. "이슈 트래킹 시스템" 중심으로 일해보자.
3. "이슈 트래킹 시스템"과 "위키"의 구분을 명확히 하자
변경한 도구
프로젝트 일정 관리 / 이슈 트래킹 시스템 : Notion, GitHub Issues -> Jira
디자인 : Figma
버전 관리 시스템 : Git, GitHub
wiki(회의록, 기술 문서, 사용자 시나리오...) : Notion, Google 도구 -> Notion 또는 Confluence (고민 중)
메신저 : Discord
의사 결정
Jira를 사용하게 된 이유는 다음과 같습니다.
1. 팀원 모두 Jira에 호기심이 많다.
2. 실무 환경에서 Jira를 많이 사용한다.
3. 프로젝트/일정 관리를 함께할 수 있다.
4. 에자일 도구를 사용할 수 있다.
5. 상/하위 계층 이슈 생성이 가능하다.
6. 이슈 생성이 간편하다.
7. 비개발자도 사용하기 쉽다.
사용 후기
1. 장점) 프로젝트/일정 관리
이슈의 범주를 에픽/스토리/하위 테스크로 구분하였습니다.
가장 상위의 에픽 이슈를 만들고, 지라의 로드맵 기능을 활용해 에픽 단위로 마감 기한을 정하였습니다.
이렇게 구분하니 에픽 별로 개발 전체 일정이 한눈에 보였고 관리하기가 보다 쉬웠습니다.
무엇보다 팀원 모두 현재 개발 상황을 이해하기 좋았습니다.
2. 장점) 팀원 별 테스크 진행 / 관리
Jira Software가 제공하는 Agile 프로젝트 관리 기능 중 Kanban 템플릿을 사용하였습니다.
Scrum 템플릿과 고민하였지만 Scrum으로 프로젝트 관리 경험이 없기 때문에 Kanban 보드를 사용하여 팀원이 모두 함께 에픽/스토리/하위 테스크를 만들고, 정해진 기간 동안 테스크를 모두 완수하는 것은 어렵지 않게 느껴졌기 때문입니다.
2.1. 팀원 별 테스크 진행
2.1.1. 먼저 팀원 모두 모여 에픽/스토리/하위테스크를 정하고 대략적인 일정을 정합니다.
2.1.2. 팀장이 일정을 확인하여 우선순위에 맞게 백로그에서 진행할 스토리들을 보드에 옮겨 일을 시작합니다.
2.1.3. 각 팀원은 보드에 있는 할 일 테스크들을 본인의 일로 설정하고, 진행 중으로 옮겨 일을 시작합니다.
2.1.4. 진행 중 -> 테스팅 & 코드 리뷰를 걸쳐 완료로 모든 일이 끝나면 또 다른 일을 맡는다.
2.2. 팀원 별 테스크 관리
보드 판에 "담당자" 기준으로 필터링 검색 기능이 있습니다.
현재 특정 팀원이 어떤 일을 담당하고, 진행 사항이 어느 정도 인지 확인하기 쉬웠습니다.
무엇보다 팀원들이 모두 현재 진행 사항을 파악할 수 있는 장점이 있습니다.
3. 장점) GitHub PR과 Jira의 자동 연결
GitHub PR 제목 또는 Git commit에 Jira 이슈 번호만 남기면 자동으로 Jira에서 인식하여 손쉬운 자동화 연결을 할 수 있었습니다.
4. 장점) Jira Automation 자동화 기능, 칸반 보드 자동 이동 또는 특정 이벤트 기반 알림 기능
Jira는 반복적인 수동 작업을 자동화 할 수 있는 Jira Automation 을 제공합니다.
칸반 보드 자동 이동
칸반 보드에서 지라 이슈들을 손으로 옮기는 것이 아닌 자동으로 옮길 수 있습니다.
- 지라 이슈 번호로 commit/브랜치 생성된다면 해당 이슈를 직접 할 일 -> 진행 중으로 자동으로 옮긴다.
- PR 시 진행 중 -> 테스트, 코드 리뷰로 옮긴다.
- merge 시 테스트, 코드 리뷰 -> 완료로 이동한다
상위 이슈(에픽/스토리)가 종료하면 하위 이슈 전체 종료 기능
알림 기능
현재 메신저로 디스코드를 사용하고 있습니다.
GitHub 이벤트 기반 알림은 GitHub Webhook을 사용해 PR open, merge 나 GitHub Actions를 활용해 테스트 성공/실패 시 자동으로 디스코드 채널로 알림 오도록 설정하여 사용하고 있습니다.
여기에 추가로 Jira Automation 활용해 알림 기능을 추가하였습니다.
예를 들어 BE팀은 코어 타임 때 PR이 올라온다면 30분 이내에 코드 리뷰 해주기로 약속하였습니다.
약속을 지키기 위해서는 PR이 언제 올라오는지, 시간이 얼마나 남았는지 알림 기능이 필요했습니다. (만들어준 팀원 Jay 🙇♂️)
GitHub Webhook이나 GitHub Actions에서 직접 discord webhook을 통해 메시지를 보낼 수 있지만 이 과정 모두를 Jira에서 한 번에 관리할 수 있어 보입니다. 하지만 아직 모두 옮기진 못했습니다.
+a) Jira Automation에는 유용한 Slack 기반 자동화 규칙이 많지만 글 작성 시점 디스코드 전용 Automation이 많지 않습니다. 직접 Discord webhooks로 메시지를 보내고 있는 아쉬움이 있습니다.
5. 단점) Jira 무료 플랜에서 외부 공개 문제
Public repo 기준 GitHub Issues는 누구에게나 공개되어있습니다. 사이드 프로젝트를 포트폴리오 목적으로 사용한다면 외부에 개발 진행 상황을 알려 홍보할 수 있는 장점이 있습니다. 하지만 Jira Software 무료 플랜 상 Jira 프로젝트를 외부에 공개하려면 결제해야 합니다.
6. 고민) 그래서 GitHub Issues를 사용하지 않는 건가?
Jira를 사용하게 된 이유 중 상/하위 계층 구조의 이슈들(에픽/스토리/하위 테스크)을 묶어 관리하는 점이었습니다.
하지만 단점도 있었습니다.
예를 들어 "BE팀 전역 예외처리 리팩터링" 이슈가 있습니다. GitHub Issues에선 해당 이슈를 하나 만들고 구현하면 됩니다.
하지만 현재 사용하고 있는 Jira 구조에서는 해당 하위 테스크가 어떤 에픽/스토리 하위에 있는지 구분하기 어렵습니다. "전역 예외처리"는 로그인 기능, 리뷰 작성 기능, 리뷰 조회 기능 등 모든 기능에 포함되어있는 이슈이기 때문입니다.
Jira 상/하위 계층 구조의 이슈는 이슈대로 만들고 GitHub Issues 도 만들어 연결하여 사용할 수 있습니다. (Jira 이슈 발행 시 GitHub Issues에 자동으로 이슈 생성도 가능하지 않을까? 생각해봅니다.)
현재 GitHub Issues는 사용하지 않기로 하였지만 다른 이유로 바뀔지 모르겠습니다.
실무에서 어떤 방법/조합으로 Jira를 사용하는지 궁금하게 되었습니다.
마치며
- 무에서 유를 만드는 사이드 프로젝트는 어렵습니다.
- Jira를 처음 사용해보았습니다. 좋은 경험이었습니다.
- GitHub Issues에서 Jira로 옮겼을 때 적극적으로 참여해준 준 팀원 모두(제이, 포키, 럼카, 호이) 감사합니다.
다음 글에서는 Jira와 GitHub 연결과 smart commit를 소개하려 합니다.
다음 글 : Jira 2. Jira와 GitHub 연결하기, smart commit 사용하여 시간 추적하기
⛓ Reference
'🧘🏻♂️ 생각, 개발 일반' 카테고리의 다른 글
| Jira 2. Jira와 GitHub 연결하기, smart commit 사용하여 시간 추적하기 (0) | 2022.08.20 |
|---|---|
| GitHub Branch Protection Rule 적용하기, 예를 들어 PR merge 하려면 팀원 최소 2명은 approve 해야 merge 할 수 있는 기능 (0) | 2022.08.18 |
| Jira 1. 무료 플랜 소개와 프로젝트 생성과 초기 설정 팁 (2) | 2022.08.11 |
| Issue(s)와 Issue Tracking System란 무엇인가? (0) | 2022.08.10 |
| 회고 방법 : 포스트모템(postmortem) (1) | 2022.06.12 |
댓글