[최종 프로젝트] Jira 도입기 ( + 회고)

✅ 도입계기

예전에 학교에서 프로젝트를 진행하면서 잠시나마 Jira를 사용해본적이 있었다. 그때는 왜 사용하는지는 잘 몰랐고 그저 실무에서 많이 사용한다는 조원의 추천을 통해 사용을 해보게 되었다.

사용하면서 나름 편리하다는 생각을 했었다. 하지만 그 프로젝트에서 사정상 나오게 되었고 아쉬움이 남았었다.

 

이번 최종 프로젝트는 백엔드뿐만 아니라 프론트엔드와 디자인팀까지 함께 구성된 팀으로 진행된다. 이렇게 서로 다른 배경지식을 가진 사람들이 모였을 때, 최고의 협업 방법은 자주 소통하며 각자의 작업 현황을 신속하게 공유하는 것이라고 생각한다. 또한, 팀원 모두가 이제 막 커리어를 시작한 개발자들로, 실수가 잦고 프로젝트 요구사항이 자주 변경될 가능성이 높다고 예상된다. 이러한 이유로 Agile 프로젝트 관리 도구인 Jira가 팀의 협업에 매우 적합하다고 판단하여 팀에 추천하게 되었다.

 

✅ Jira와 애자일(Agile)이란

✔️Agile?

💡 빠르게 변화하는 요구사항에 민첩하게 대응할 수 있도록 프로젝트를 소규모 작업 단위로 짧은 주기의 반복 개발을 강조

✔️ Jira?

💡Agile 프로젝트 관리 툴
➡️ 비슷한 서비스: Github, Trello 등
장점
- 애자일한 프로젝트 관리 도구 제공
  ➡️ 칸반, 스크럼 등의 개발 방식간략한 UI/UX, 타앱과의 연동성(Github, Slack등)
- 이슈 관리
  ➡️ 이슈를 세분화하여 다양한 업무를 계층화할 수 있다.

 

✅ 스크럼 

✔️ 스크럼이란?

애자일 개발 방법론 중 하나로 복잡한 문제를 효과적으로 해결하고, 생산성을 극대화하는 데 도움을 준다. 
스크럼은 작은 팀이 자율적이고 협력적으로 작업할 수 있는 환경을 만든다.

 

우리 팀은 다음과 같은 스크럼 프로세스를 채택했다.

1️⃣ 스프린트 플래닝

• 스프린트 단위: 1주일
• 쉽게 생각하면 이번주에 뭐할지 계획 짜기
• 이번 주에 할 일을 Jira 이슈에 추가
• 추가한 것들을 이야기 나누어보면서 문서로 정리

2️⃣ 스프린트

• 계획한 것들 수행하기

3️⃣ 데일리 스크럼

• 하루 한 번 10~15분 정도(수업 시간 활용)
• 그날 컨디션, 어려웠던 부분, 앞으로의 계획 등 간단하게 이야기 나누기

4️⃣ 스프린트 리뷰 & 회고 / 다음주 스프린트 플래닝

• 스프린트 종료일에
• 회의를 통해 이번 스프린트 리뷰하고 다음 스프린트 계획
• 이 과정이 프로젝트 끝날 때까지 반복.

 

물론 실제 스크럼은 이것보다 훨씬 더 많은 요소들이 존재하지만 프로젝트의 기간이 한달이라는 점, 팀원들이 모두 스크럼이 처음이라는 점을 고려해 간략하게 수정하였다.

 

✅ Jira 컨벤션

효율적으로 Jira를 사용하기 위해 컨벤션을 설정하였다.

 

✔️ 이슈

이슈 구조 

Epic
 ├── Story
 |     └── Subtask(option)
 ├── Dev
 |     └── Subtask(option)
 ├── Hotfix
 ├── Bug
 └── Doc

[Epic 없음]
     Story
      └── Subtask
     Dev
      └── Subtask(option)
     Bug
     Doc

 

각 이슈별 작성 가이드

🥇 1 Tier
⦿ EPIC
• 제일 큰 업무. 여러 Sprint에 걸쳐 종료됨
• 주로 Major Feature들을 중심으로 정의
• 해당 이슈의 출처와 목적을 분명하게 하기 위해 ~~으로서, ~~이 필요합니다 이런식으로 작성하는 것을
권장
• 예시:
  ‣ 서비스 사용자로서 매일 흥미롭고 다양한 질문을 받을 수 있는 기능이 필요합니다.
  ‣ 개발자로서, 프론트엔드 개편에 따른 서비스 페이지 수정이 필요합니다.

 

🥈 2 Tier

⦿ 스토리(Story)
• 사용자에게 가치를 줄 수 있는 한 개의 작은 기능
• 기술적 전문 용어가 아닌 비즈니스 언어를 사용함 사용자 요구사항 적듯이 적는걸 권장
• 예시:
  ‣ 사용자는 매일 00시에 새 질문을 받을 수 있어야 한다.

⦿ 개발(Dev)
• 기능과는 동떨어진 스토리외의 기술적 관리적 업무
• 개발자가 사용하는 기술적인 용어를 사용
• 예시:
  ‣ CI/CD 파이프라인 구축, RDS 생성 등

⦿ 긴급(Hotfix)
• 현재 스프린트 계획에 없었거나 긴급하게 발생한 것들.
• 예시:
  ‣ 환경변수 추가

⦿ 버그(Bug)
• 서비스에서 발생하는 문제점 또는 리포팅된 버그
• 예시:
  ‣ 로그인 페이지에서 사용자 인증 실패

⦿ 문서(Docs)
• 프로젝트에 있어서 필요한 문서 작업
• 예시:
  ‣ 와이어 프레임, ERD 다이어그램, 요구사항 명세서, API 명세서 등

 

🥉 3 Tier
⦿ 하위 작업(Sub Task)
• 2 Tier 이슈들의 하위 작업
• 커밋이라고 생각하면 됨
• 2 Tier 이슈들에 깃허브 브랜치가 연결되어 있는 경우 사용하지 않는 것을 추천

 

✔️ 이슈 상태 워크 플로우

이슈 상태

• TO DO: 작업이 아직 백로그에 있는 상태
• IN PROGRESS: 작업이 시작된 상태
• IN REVIEW: 작업이 완료 돼 리뷰 중인 상태
• DONE: 리뷰가 완료된 상태

워크 플로우

• 각 상태에서는 다음 상태로만 전환이 가능. (건너뛰기 불가)

 

✅ 타앱과의 연동

1️⃣  Github

💡 이슈와 연동시 반드시 이름 및 제목에 이슈번호가 포함돼야 함

• 브랜치 - 2Tier 이슈(스토리, 개발, 버그 등) 연동 (브랜치 명에 이슈번호가 포함돼야 함)
  예시: hotfix/QFEED-154-fix-error
• 커밋 - 소속된 브랜치내의 커밋과 연동.(커밋 메시지 내에 브랜치와 연동된 이슈 번호가 포함돼야 함)
  예시: [QFEED-154] fix: 질문 생성 오류 수정
• 풀리퀘스트 - 해당 브랜치에 대한 PR과 연동
• 빌드 - 해당 브랜치 내에서 이루어진 actions와 연동

Jira Automation 기능을 통한 PR이벤트에 따른 이슈 자동 전환

1. PR 생성 시 해당 이슈 자동으로 IN REVIEW(검토 중)이동

 

2. PR 닫을 시 해당 이슈 자동으로 다시 IN PROGRESS(진행 중)으로 이동

 

3. PR 병합 시 해당 이슈 자동으로 DONE으로 이동

 

2️⃣ Slack

Jira -> Slack: 이슈관련 슬랙알람

• 이슈가 생성됐을 때
• 이슈가 리뷰 중으로 이동했을 때
• 이슈가 완료됐을 때

 

✅ 문서작업 - Notion

Jira를 사용하는 경우 문서작업은 보통 Confluence를 많이 사용하지만, 프로그래머스에서 Notion에 문서화를 진행하라는 요구사항이 있었기 때문에 Notion을 사용하였다.

 

✅ 회고 (프로젝트 종료 이후)

스크럼과 Jira를 도입하기 전부터 사실 걱정은 있었다. 팀원들은 물론 소개하는 입장인 나조차도 처음 해보는 것들이기 때문에 이게 잘될까 싶은 생각이 많았다.

우선 결론부터 말하면 스크럼은 소규모 프로젝트에선 적합하지 않다고 생각한다. 소규모 프로젝트는 보통 짧은 기간안에 빠르게 개발해야하는 경우가 많기 때문에 스크럼의 활동인 데일리스크럼, 스프린트 플래닝 등의 짧은 활동도 부담이 된다. 게다가 아직 나를 비롯한 팀원들은 프로젝트 경험도 부족한 주니어 개발자이기 때문에 더더욱 그 부담이 컸던 것 같다. 개발 초기단계에서는 스크럼 일련의 활동들이 어느정도 잘 지켜지는 듯 했지만 스프린트가 거듭될수록 일정이 바빠지면서 스크럼이 거의 이루어지지 못했고 아쉬움이 남았다.

Jira는 매우 편리했다.

빠르게 다른 팀원들이 하고 있는 활동들을 확인할 수 있었고 팀의 남은 목표를 확인하기도 편리했다. 또한 Jira Automation이나 Github, Slack과의 연동 등 제공되는 유용한 기능이 많아 개발하는데 많은 도움이 됐던 것 같다.

이번 프로젝트를 하면서 가장 크게 깨달은 것이 하나있다. 프로젝트 전까지만 하더라도 좋은 협업이란 좋은 협업 방식과 좋은 협업 Tool을 사용하는 것이라고 생각했었는데 프로젝트를 해보면서 진짜 좋은 협업이란 팀의 상황과 프로젝트 규모를 고려한 협업 방식이라는 것을 깨달았다. 이번 경험을 좋은 본보기로 삼아 다음 프로젝트부터는 더욱 더 좋은 협업을 해야겠다.