[Jira] 이슈 트래킹 시스템을 활용한 프로젝트 만들기

Zero·2023년 10월 28일

[협업] 의미있는 프로젝트를 위해서

목록 보기

2/4

🧐 들어가기에 앞서

새로운 프론트앤드 스터디 팀을 구성하게 되면서 지금까지 했던 스터디와 프로젝트를 돌아보면 협업이 적극적으로 이루어지지 않은 느낌이 있었습니다. 데일리 스크럼을 진행하여도 한명이 안쓰면 이후부터 다른사람도 가볍게 생각하고 쓰기 시작하였고 중간에 흐름이 끊기는 현상이 많이 발생하였습니다. 이에 지난 프로젝트와 달리 실무에서까지 사용하는 협업툴을 사용한 프로젝트를 사용하고 싶었습니다.

🙄 지난 실수 다시보기

지난 협업에서의 실수는 다음과 같습니다.

데일리 스크럼 수준이 낮아져 갑니다. 한명 또는 여럿이 대충 작성하거나 준비를 하거나 본인 차례에 발표할 때 끼어드는 등의 행위로 팀 분위기 혹은 발표 분위기가 나빠지는 문제가 있었습니다.
파트분배를 하지 않고 작업을 시작하면서 효율성과 조직성이 부족해졌습니다. 사전에 정해둔 것이 없을 경우에 한명이 로그인 구현을 완료하였는데 다른 사람은 로그인이 만들어진지 모르고 작성하는 경우도 있었습니다.
코드리뷰 문화의 망가짐. 다른 개발자의 승인이 있을 경우에만 브랜치에 병합이 되도록 하였습니다. 하지만 점점 귀찮아져가고 문제를 확인을 안하고도 바로 병합하는 경우가 있었습니다. 이를 통해 배포된 사이트와 개발하는 사람들에게 까지도 코드가 실행이 안되는 문제도 생겼습니다.

🤕 어떻게 해야할까?

데일리스크럼과 같이 회의를 할 때의 스크럼 마스터와 스크럼 프레임워크(규칙)의 도입입니다.

스크럼 마스터를 통해서 스크럼 멤버들에게 참여를 독려하고 불편한 분위기를 해소할 수 있고 스크럼 프레임워크를 이해하는데 도움을 줌으로서 효과적으로 스크럼을 진행할 수 있습니다.

❓스크럼 마스터는 조장인가요?

스크럼 마스터는 조장이 아닙니다. 스크럼 마스터는 팀의 프로세스와 협업을 관리하며 팀원들에게 스크럼 프레임워크를 준수하도록 도와주는 역할을 합니다. 팀원을 지시하거나 통제하는 역할이 아닙니다. 스크럼 마스터는 주로 지원과 조언을 통해 팀의 성과와 개선을 돕는 역할을 합니다.
파트분배의 문제점을 해결을 위해 플래닝 포커 방식을 도입을 해 볼 생각입니다. 이를 통해 전체 팀원이 설득이 될 때까지 진행을 하여 최선의 방법과 시간을 생각하여 파트를 분배를 할 생각입니다.

❓플래닝 포커 방식이란?

사용자 스토리 또는 기능에 관해서 개발 기간을 투표합니다. 0, 1, 2, 3, 5점 (ex : 2일이 걸리는 경우 2점)
이후 가장 높은 점수의 사람과 가장 낮은 점수의 사람의 의견을 물어봅니다. 가장 높은 점수의 경우 해당 사람이 놓친 부분이 있을 수 있고 가장 낮은 점수의 경우 빠른 개발 방식을 알 수 있습니다. 이를 이용하여 다른 사람들과 생각이 모여졌을 때 해당 점수를 부여하고 파트 분배때 점수를 통해서 분배를 할 수도 있습니다.
코드리뷰의 문제점을 해결하기 위해서 병합전 코드리뷰의 형태로 진행할 생각입니다. 이를 통하여 강제로 코드리뷰를 해야하고 해당 코드를 병합후의 문제가 생길시에는 피어(리뷰어)와 커미터(작성자)에게 책임을 묻습니다.
⭐ 코드리뷰에서 확인할 것

코드 리뷰에서는 다음과 같은 부분을 확인하면 좋습니다.
1. 코드의 코드 컨벤션이 지켜졌는가?
2. 코드의 가독성이 좋은가?
3. 해당 코드는 효율적이며 불필요한 반복과 같은 부분이 없는가?
4. 해당 코드의 문제는 없는가, 에러가 발생하지 않는가?
5. 모듈화와 재사용성과 같이 중복기능을 피해서 올바르게 작성이 되었는가?

😌 좀 더 나은 프로젝트를 위해서

이전 글에서 깃허브를 사용하여 프로젝트와 이슈를 관리하는 방법에 대해서 정리를 하였습니다. 작은 규모의 프로젝트의 경우 깃허브를 통해서도 파트분배가 가능하였습니다. 하지만 업무흐름도나 애자일과 같이 협업에 관해서는 더 좋은 이슈 트래킹 시스템(ITS)들이 존재합니다. 이를 이용하여 간단하게 실시간 업무 진행상황을 볼 수도 있고 이슈트래킹에 용이합니다.

❓이슈 트래킹이 뭔가요?

프로젝트에서의 이슈는 개발할 새 기능, 수정해야 하는 결합, 문제가 된 이슈 등을 통틀어서 말합니다. 이것을 티켓, 이슈, 테스크, 케이스라고 부릅니다. 이슈 트래킹 시스템은 이런 이슈를 생성하고 담당자를 지정하여 해결하도록 하는 시스템을 말합니다.

그럼 이렇게 생각할 수도 있습니다. 이슈 트래킹 그거 필요한가요?.

“The secret of crisis management is not good vs. bad, it’s preventing the bad from getting worse.” — Andy Gilman, president & CEO of Comm Core Consulting Group
프로젝트에서 발생하는 문제들은 나쁜 것이 아니다. 이는 이러한 문제가 제때 보고되고 추적되지 않을 때 문제가 누적되기 시작하여 궁극적으로 프로젝트의 성공과 비즈니스 평판을 해칠 수 있는 엄청난 위기로 번지기 시작한다.

문제가 됐을 때의 해결을 위해 이슈 트래킹을 사용하는 것이 아니라 문제를 제때 발견하고 위기가 되기 전에 관리하기 위해 미리 사용하는 것이 이슈 트래킹을 사용하는데에 있어서 이유가 아닐까 라는 생각이 듭니다.

이슈 트래킹 시스템이 필요한 이유는 다음과 같습니다.

성공적인 프로젝트 관리
이슈 트래킹 툴을 사용하면 어떤 일이 발생하였는지, 어떤 이슈가 아직 해결이 되지 않았는지를 알 수 있습니다. 이를 이용하여 이슈를 관리하는 체계화된 방식을 제공하여 팀원 모두가 문제를 효율적으로 해결할 수 있게 돕습니다.
프로젝트 진행 확인과 협업
모든 팀원이 자신이 완료해야 하는 일이 무엇인지, 이일이 완료되면 다른 팀원은 무엇을 해야하는지, 자신과 팀 구성원의 역할을 알려주고 프로젝트의 중앙 허브가 되어 팀원 간의 정보 격차를 줄여줍니다.
이슈 DB화
이슈가 잘 정리되므로 나중에 똑같은 문제가 발생하였을 때 예전 자료를 참고하여 더욱 쉽게 처리할 수 있습니다.

📘 이슈 트래킹 시스템(Jira)을 활용한 프로젝트

jira

지라는 애자일 기반 프로젝트 관리의 최적화가 되어있는 프로젝트 관리 툴입니다. 로드맵으로 목표와 진척도를 가시화하며, 유형 별로 이슈를 등록하고 스크럼 혹은 스프린트 별로 분류하여 일감 처리하기 쉽습니다. 스크럼 칸반 보드 기능으로 프로젝트 안에서 할일, 진행 중, 완료 업무를 한눈에 파악할 수 있고, 스프린트 분석을 통해 어떤 유형의 업무들을 얼마나 진행했는지 분석해서 볼 수 있습니다. 백로그에 쌓인 일감들을 어떻게 처리할지 논의하기도 쉽습니다.

😎 이슈 트래킹 시스템 워크 플로우

프로젝트 매니저(PM)의 경우 Jira를 통해 프로젝트와 이슈를 만들어야합니다. 우리가 연간 계획을 세우는 것 처럼 (분기별 목표 -> 달 목표 -> 이번주 목표) 프로젝트도 똑같이 만들면 됩니다. (Project -> Issuse -> Task -> SubTask)
RoadMap

이 포스트에서 넷플릭스를 만들 것입니다. 가장 먼저 Jira를 통해서 Netflix 프로젝트를 만들어줍니다.
프로젝트 생성하기

다음 부분에서 바로 리포지토리를 만들거나 이미 만들어져있는 리포지토리를 선택할 수도 있습니다.
리포지토리 선택

이슈트래킹 시스템을 사용하기전에 다음 용어를 알고있어야합니다.

Epic : 스토리의 집합
Story : 사용자 중심의 기능 목록 (동사 형태로 만듭니다.)
Chore : 사용자 기능 중심이 아닌 기술적인 Task
Issue : 담당자가 관리하는 사용자 중심의 기능을 말합니다.
Bug : 버그들을 나타냅니다.
Sub-Task : Task들의 세부적인 Task를 나타냅니다.

제일 먼저 프로젝트를 만들게되면 만들어야할 Epic을 생성해줍니다.

Epic으로 인해 프로젝트가 만들어지므로 큰 범위로 생각하여 만들어줍니다. 예를 들어 넷플릭스에서는 메인 페이지, 검색 페이지, 마이 페이지로 구성이 되므로 각각 Epic으로 만들어줍니다.

이제 해당 Epic내에서 작성해야할 Story들을 작성을 해줍니다.

메인 페이지의 경우 다음과 같은 스토리들이 있을 수 있습니다. 사용자가 선호하는 장르에 따른 프로그램을 추천하기. 사용자가 최근 시청한 프로그램들을 맨 위에 보이기.

사용자와 사용자의 목표를 명확하게 이야기 해주기 위해서 아래와 같이 작성합니다.

As a { user }, I want to Something // 나는 사용자로서 무엇을 한다.

Story

Story 작성을 하였고 Task를 통해서 해야할 일을 적어준다. 여기서 Task는 다음과 같다. 최근 시청한 프로그램을 맨 위에 보이게 하기 이를 하기위한 Sub-Task로는 API를 통한 사용자 정보 수집 및 저장, 프로그램 정렬 기준 선택, 사용자 선호도 고려등 많아집니다.

Sub-task 작성

그럼 이제 같이하는 개발자들이 초대하여 프로그램을 개발을 해보겠습니다.

협업시작

담당자를 선택하면 옆에 Epic 옆에 해당 담당자가 나오게 되면서 확인을 할 수 있습니다.

타임라인을 통해서 만들어야할 Epic 과 구성하는 Story를 만들었으니 백로그를 통하여 스프린트를 만들어보겠습니다.

스프린트 : 아직 완료가 되지않은 해야할 Story 들을 이 기간동안 하자! 와 같이 정해두는 것입니다.

스프린트 추가

기존에 만들어두었던 Story를 추가하고 이를 통하여 목표인 스프린트를 만들 수 있습니다.

이를 통하여 칸반 보드를 통해서 현재 진행중인 스프린트에 대한 정보를 알 수 있습니다.

칸반보드

이슈를 추적하는 방법

이슈를 추적하려면 해당 이슈 번호를 알아야합니다.
고유번호

다음 빨간색 글씨가 이슈 번호입니다. 해당 이슈 번호를 통해서 Jira에서도 깃허브를 볼 수 있습니다.

이슈번호

지라 이슈번호 자동으로 등록하기

github 액션으로도 사용이 가능하지만 husky를 이용하여 설정을 해주겠습니다.

husky 라이브러리란 보다 Git hooks를 쉽게 적용할 수 있도록 도와주는 라이브러리 입니다.

허스키 설정하기

npm install husky jira-prepare-commit-msg --save-dev && npx husky install

훅 생성하기

npx husky add .husky/prepare-commit-msg 'npx jira-prepare-commit-msg $1'

훅 수정하기

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx jira-prepare-commit-msg $1

package.json 수정하기

 {
  "jira-prepare-commit-msg": {
    "messagePattern": "[$J] $M",
    "jiraTicketPattern": "([A-Z]+-\\d+)",
    "commentChar": "#",
    "isConventionalCommit": false,
    "allowEmptyCommitMessage": false,
    "gitRoot": ""
  }
 }
 
 
 ---
 
JIRA prepare commit msg > start
JIRA prepare commit msg > The JIRA ticket ID is: JT-11
JIRA prepare commit msg > done
[JT-11-design/rootLayout 1c3d3e4] [JT-11] jira test
1 file changed, 1 insertion(+), 1 deletion(-)