주니어의 JIRA를 이용한 협업하기

회사에서 대부분의 직무는 협업을 기반으로 한다. 특별하게도 개발자라는 직무는 애자일방법론을 기준으로 협업을 진행하는 경우가 많다. (기업규모, 목표에 따라 방법론이 달라질 수 있다. 다른 방법론으로는 린스타트업 방법론 등이 있다.)

멋쟁이 사자처럼에서 팀프로젝트를 만들기 위해 우리팀은 협업툴로 JIRA를 선택했다. 내가 JIRA를 사용하는 데 크게 동의했던 이유는 지인의 실무 협업툴이 JIRA였으며, 옆에서 일하는 것을 잠시 지켜보았을 때 확실히 객관적이고 명확한 업무툴처럼 느껴졌다. UX,UI가 간단해보이는 것도 좋아보였지만 이슈관리, 확장성, 연동되는 앱 등을 보았을 떄 굉장히 간단해 보이며, 접근성이 높아 보였다. 또한, 누가 어떻게 일하는지 모두 확인이 가능하다. 개발팀은 특히나 정확성과 통일성을 요구하게 된다. 효율(시간 사용)을 극대화 해야할 필요가 있다. 정리하자면, 협업을 하고 현상관리, 상태관리를 하며 추적이 가능하고 좀 더 명확하고 객관적으로 관리가 가능하기에 JIRA를 사용한다고 보면 되겠다.

(JIRA 관련 녹화본 in 팀 미팅 첨부드립니다. 이런 게 있구나 정도로 참고만 하시면 될 것 같습니다.)
(여러 협업 툴과 연동이 가능하다.)

(잠시 다른 이야기로 빠지자면, Atlassian이라는 회사는 100% 원격근무를 진행하고 있다. 그야말로 가장 현대적인 언택트시대에 걸맞는 회사이지 않을까 싶다. 회사의 철학이 JIRA app에도 많이 녹아있는 것을 확인할 수 있다. )

우리는 JIRA로 개발 업무 진행을 실시간으로 확인하고 커뮤니케이션이 더 필요한 경우, Slack을 통해 소통하기로 했다.

목적에 부합하는 채널을 만들어 각 채널별 소통을 진행하고, client단(Front-End)과 server(Back-End)단의 채널을 나눠 각 채널에 github, JIRA를 연동시켰다.

JIRA에서 생기는 모든 이슈변화를 슬랙에 자동적으로 연동시켜 실시간으로 팀원들이 변동에 대한 notification을 확인할 수 있도록 했다.

github을 연동한 이유는 우리 팀원들은 개인 프로젝트와 레포지토리들을 github으로 관리를 해왔기 때문에 앱에 대해 익숙해져 있으며, 편리하게 서로 프로젝트를 확인할 수 있다고 생각해서이다.

또한, JIRA에서 이슈를 발급할 때 레포지토리를 연결해 브랜치와 커밋, PR(Pull Request)등을 진행할 수 있다.

실제로 JIRA를 접속해 하나씩 알아보자.

(현재 만들어진 프로젝트는 모두 예제입니다.)

Caffeine Market이라는 프로젝트를 진행한다고 예를 들어보자.
크게 보면 메뉴바에 로드맵, 백로그, 보드 세 가지가 있다.
로드맵과 보드는 명칭으로 대강 용도를 파악할 수 있지만, 백로그는 생소한 사람이 있을 수 있다고 생각한다.
'백로그'란 한 팀이 일정 기간 또는 일정 시간 안에 해야 할 모든 업무를 작성한 문서이다. 이를테면 업무 개선 아이디어부터 제품 개발 관련 업무, 회고, 학습 리뷰, 사후 분석까지 모두 백로그에 들어간다.

위의 백로그 페이지를 자세히 확인하면 CM 1 스프린트, CM 1 스프린트 2, CM 1 스프린트 3, 백로그 이렇게 토픽이 나눠져있는 것을 확인할 수 있다.

스프린트는 과연 무엇일까?

스프린트를 알기 위해선 스크럼과 애자일에 대한 약간의 이해가 필요하다. 애자일 방법론에는 스크럼이라는 애자일 방법론의 프레임워크가 있다.

(이미지 출처 : https://brainhub.eu/library/differences-lean-agile-scrum)
스크럼 방식에서 스프린트라는 작업 단위를 사용해 업무를 진행한다. 일단은 이 정도로 이해하고 넘어가면 좋을 것 같고, 애자일 방법론에 대한 이야기는 따로 자세히 다루어보도록 하겠다.
(스크럼 진행과정에 대해 자세히 알고 싶다면 클릭해주세요.)

다시 돌아와서, 백로그 메뉴 내의 백로그는 개개인의 업무, 이슈를 추가할 수 있다. 그리고 개발팀 및 기획팀 등과 미팅 협의 이후 스프린트들을 결정하고 진행하게 된다. 그리고 본인의 백로그에 들어 있는 본인의 업무를 각 스프린트, 각 스케쥴에 맞게 분배해서 넣어주면 된다. (ex. Lead said : 다음주부터 2주간 CM 1 스프린트 들어가겠습니다. 스프린트에 본인의 업무 스케줄을 추가해주세요. -> 개개인별 백로그를 CM 1 스프린트에 추가한다.) 그리고, 스프린트 명칭과 내용은 모두 변경가능하다.

내 백로그 이슈를 스프린트로 이동하게 되면 위와 같은 알림이 뜬다. 스프린트는 협업으로 사용되는 곳이기 때문에 변경사항이 생길 시 조심할 필요가 있다.

그렇게 CM 1 스프린트가 완성되면 2주간 개발이 진행되게 된다.

그렇다면 현재 진행중인 보드를 살펴보자.

현재 각 팀원들의 백로그를 CM 1 스프린트에 옮겨둔 상태이고 OPEN 즉, 해야 할 일 위치에 보관되어 있는 상태이다.

예를 들어, 피드페이지 만들기를 작업중이라면 진행 중으로 옮겨주면된다.
(물론 모든 작업명은 변경가능하다.)

그리고 문제없이 완료가 되는 경우 IN TEST로 옮겨주면 된다.
(혹시나 혼자 해결하기 힘든 문제가 발생하는 경우, 팀원에게 도움요청을 하기 위해 '이슈 협업 필요' 라는 공간을 만들었다.)

왜 바로 완료로 가지 않고 IN TEST 공간으로 이동시켰을까?

완료는 정말 완성된 최종본을 이야기한다. (혹시, 최종최종최종.ppt를 아는가?)
그 전에 QA팀 혹은 기획팀에서의 검수가 필요하다. 서비스를 진행하기 전 기획팀에서 원하는대로 기능이 구현되는지 요청건을 정확하게 수행했는지 검사가 필요하다. 그래서 In TEST 공간으로 이동시킨다. 그렇다면,

문제가 생길 경우 기획팀과 어떻게 커뮤니케이션을 진행할 수 있는지 확인해보자.

피드페이지 만들기 백로그를 클릭했다.

아래 댓글란을 보면 QA팀에서 에러에 관한 댓글을 남긴 것을 확인할 수 있다.
그 전에, IN TEST에 있던 '피드페이지 만들기' 이슈는 이미 QA팀에서 직접 OPEN으로 다시 넘길 것이다. (이건 Team By Team이라고 생각한다.)

그러면 위와 같이, 우리는 Slack 앱과 연동시켜뒀기에 Slack Front-End 채널을 통해 IN TEST에서 OPEN으로 이동했음을 확인할 수 있으며, JIRA에 들어와 자세한 내용을 확인하게 될 것이다.

이슈가 슬랙과 연결이 안된 경우, 아래와 같은 방법으로 연결시키면 된다.

다시, OPEN에 있는 이슈를 수정사항을 반영해 IN TEST로 옮기는 작업을 반복한다.

이런식으로 스프린트, 백로그, 보드를 활용할 수 있다.

그리고 github 연동에 대해 좀 더 알아보자.

우리는 git을 사용해 코드를 기록하고 협업한다. 그리고 여러 목적성에 부합하는 브랜치를 나눠 기능별로 제작한 뒤 수정하고 피드백한 뒤, Merge를 통해 최종본을 만들어낸다.
('git flow로 알아보는 브랜치의 역할'에 관한 글도 곧 업로드 하겠다.)

이처럼 각 이슈들은 특정한 브랜치에 부합되어 나눠질 수 있다. 실습을 통해 알아보자.

피드페이지 만들기를 브랜치를 만들어 팀원 모두 깃헙에서 확인할 수 있도록 연동시켜보자.

앱관리에 들어가보면 여러 앱들을 JIRA와 연동시킬 수 있다.

새 앱 찾기에서 'github for jira'를 검색하면, github 관련 많은 어플이 뜰 것이다. 나는 staff pick이 되어있는 github for jira를 다운받았다.

그리고 설치가 완료되면 앱 관리에 이런식으로 뜰 것이다.
이제 이슈에 깃헙을 연동하고 활용할 수 있게 되었다.

위와 같이 브랜치만들기, 커밋만들기를 사용할 수 있게 되었다.

그 전에, 이 프로젝트의 레포지토리를 만들어주고 git을 연결해주어야 한다. (깃 레포지토리 연결하기 - 참고 링크)

나는 미리 팀프로젝트 레포지토리를 연결시켜두었다. 그래서 브랜치를 바로 만들어주면 될 것 같다.

브랜치 만들기를 클릭하면 아래와 같이 copy가능한 git 명령어가 등장한다.
git CLI에 익숙한 사람들이라면 checkout과 같은 명령어를 알고 있을 것이다. 직접해도 상관없지만 JIRA를 통해 간편하게 할 수 있다고 생각하면 좋을 듯 싶다.

이미 로컬에 'caffeineMarket' 이라는 폴더를 clone 해놓은 나는 터미널을 통해 브랜치를 제작한다.

간단하게 이슈이름과 같은 브랜치가 제작됨을 알 수 있다.

그리고 위와 같이 push를 통해 팀 레포지토리에 브랜치를 추가한다.

그리고 이슈를 확인하면 위와 같이, 1개 브랜치 라고 뜨는 것을 알 수 있다.
클릭해서 상세 내용을 확인해보자.

위와 같이, 브랜치, 레포지토리, 풀 리퀘스트 등을 자세히 확인할 수 있다.

또한, 팀 깃헙 레포지토리에도 브랜치가 잘 만들어진 것을 확인할 수 있다.

JIRA를 활용할 수 있는 방법은 무궁무진하다고 생각한다. 더 다양하게 효율적으로 활용이 가능할 것이다. 설명한 내용은 극히 일부분이기에 더 많은 기능들에 대해서는 실무에서나 학습을 통해 배울 수 있다고 생각한다. 이 블로그 기고를 통해 JIRA에 대해 조금은 친숙해졌으면 하는 목적이 있다. 도움이 되었길 희망한다. (위 상황은 모두 예시였으며, 회사별, 팀별로 다를 수 있다.)