Jira + Confluence를 활용한 Agile 프로젝트 관리 (feat. ZenHub + Notion)

10 minute read

세상 일 계획대로 되는 일 하나 없다. 아무리 생각을 열심히 한 꼼꼼한 계획이라해도 변수가 생기고 어떤 일들은 생각했던 것보다 훨씬 오래걸리는 일이 되어 계획을 망치게 된다. 그런 측면에서 짧은 간격으로 반복, 점진적이게 일들의 우선순위를 조정하고 계획을 수정해나가는 Agile의 컨셉은 비단 업무가 아니더라도 일상에도 적용할 수 있는 훌륭한 개념이라고 생각한다.

이번 포스트에서는 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대응하기를 중요한 가치로 여기는 Agile 개발 방법론을 기반으로 Jira와 Confluene를 통한 프로젝트를 관리에 대해 알아본다. Agile 방법론과 Jira, Confluence의 모든 기능을 활용하기보다는 최소한으로 필요한 개념과 기능을 차용해 구성했다.

Why Agile & Jira?

Waterfall & WBS의 문제점 - 불가능한 완벽한 계획, 이슈 관리의 어려움, 문서 작업 지옥

많은 프로젝트는 WBS라는 계획표로 전체 기간에 대한 계획을 세우고 계획에 맞춰 순차적으로 진행된다. 흔히 Waterfall 모델이라고하는 이 접근 방식은 정형화된 기능 개발을 위한 프로젝트에서 효과적으로 작용했었다. 하지만, 분석 모듈을 포함한 최근의 프로젝트들은 정형화된 기능 개발을 다루지 않는다.

WBS로 처음 만들어 보는 AI 시스템을 만드는 프로젝트를 한다고 상상해보자. 계획을 먼저 열심히 세운다. 완벽한 계획 같았지만 생각지 못한 이슈가 계속 발생하고 WBS의 데드라인에 맞추기 위해 야근을 하게 된다. 이슈에 대해 커뮤니케이션을 위해 문서를 작성하고, 이슈를 리스트업하기 위한 문서를 작성하고 계획하지 않은 문서 작업이 계속 늘어난다. 프로젝트 종료일, 정해진 요구사항에 맞춰 열심히 개발을 했지만 최종 결과물이 원하는 방향이 아니었다는 질타를 받게 된다.

극단적인 예시지만 요구사항 변경이 잦고 경험치 못한 이슈가 많이 발생하는 최근 분석 프로젝트에서 Waterfall과 WBS를 활용한 접근 방식의 단점을 단적으로 보여준다.

Agile & Jira - 반복적 계획과 점진적 결과물, 이슈 기반 프로젝트 관리, 서로를 위한 문서 작업

Agile 방법론에서는 기본적으로 전체 프로젝트에 대한 계획을 세우지 않는다.

먼저 중요 마일스톤을 정하고 첫번째 2주 스프린트에 대한 목표와 해결해야 할 이슈를 정의한다. 팀원들은 개발해야 할 이슈에 집중해 개발을 진행하고 2주가 지난 후 개발된 결과물과 스프린트 진행 과정에 대해 리뷰한다. 추가적으로 발생한 이슈나 미처 해결하지 못한 이슈는 다음 스프린트에 포함되고 개발에 있어 장애가 된 부분은 팀과의 토의를 통해 빠르게 발견되고 해결된다. 이슈 기반으로 소통이 이루어지기에 중간중간 서로의 이해를 돕기 위해 Wiki 형식의 문서 작업 외에 불필요한 문서 작업을 수행하지 않는다. 스프린트가 반복됨에 따라 개발 결과물은 점진적으로 나아지게 되고 만족스러운 최종 결과물로 이어지게 된다.

반대로 이상적인 예시지만 Waterfall과 WBS를 활용한 방법론과 비교하면 근본적으로 새로운 무언가를 만드는 프로젝트를 운영하기에 더 편리하고 자연스러운 방식임을 알 수 있다.

Agile: Scurm vs Kanban

Jira에서 주로 사용하는 Agile 방법론은 크게 Scrum과 Kanban이 있다.

둘 다 이슈를 기반으로 진행 중인 일을 공유하고 이를 관리함으로써 효율적인 프로젝트 운영을 추구한다는 공통점이 있으나 세부적인 운영 방향에서 차이가 존재한다.

Scrum

/assets/images//scrum-and-kanban-with-jira.jpg

Scrum은 2~4주 단위의 짧은 주기의 iteration인 스프린트가 반복되며 기간 동안 이슈를 진행하고 보완점을 찾아 그 다음 스프린트를 진행하는 방식으로 프로젝트를 수행한다. 이 과정에서 위 그림에서처럼 개개인의 역할, 수행하는 이벤트, 관리하는 아티팩트가 규정되어 있다.


역할

  • Product Owner
    • 비즈니스적인 제품 방향성을 정하고 이해당사자 간 의견을 조율하는 제품 담당 책임자
  • Scrum Master
    • Sprint 진행 중 진척 상황을 보며 팀의 문제 해결과 목표 달성을 돕는 조력자 (관리자 x)
  • Team
    • 제품 개발을 위해 역량을 갖춘 멤버들로 구성된 자율적으로 일하는 팀

이벤트

  • Sprint Planning
    • 스프린트의 목표와 해야 할 일(What)과 방법(How)를 정의
  • Daily Stand-up
    • 한 일을 업무 계획을 공유하고 장애 요소에 대한 해결 방법을 도출하기 위한 짧은 일간 회의
  • Sprint Review
    • 스프린트 결과물에 대한 리뷰
  • Sprint Retrospective
    • 스프린트 진행 방식에 대한 리뷰로 개선점을 도출해 다음 스프린트에 반영

아티팩트

  • Product Backlog
    • 제품 개발을 위해 필요한 모든 할 일들의 목록
  • Sprint Backlog
    • 스프린트 내에 해야 할 모든 일들의 목록
  • Shippable Product
    • 스프린트 결과로 나온 실행가능한 제품의 중간 결과물


이를 바탕으로 세부적인 업무가 수행되는 방식은 다음과 같다.

  1. Product Owner가 제품을 만들기 위해 필요한 일들을 Product Backlog에 등록
  2. 팀이 모여 Sprint에 해야 할 목표와 업무 목록을 정리하고 Sprint Backlog에 등록
  3. Scrum Master가 10분 정도의 Daily Stand-up을 진행하며 한 일과 이슈 사항을 공유하며 스프린트 진행
  4. 스프린트 후 개발 결과물에 대한 Sprint Review와 개발 과정에서 개선점에 대한 Sprint Restropsective를 수행
  5. 위 과정을 계속 반복하며 제품 개발 진행

Kanban

Kanban에서는 스프린트가 강요되지 않는다. 개발에 필요한 일들을 Product Backlog에 등록하고 리스트로부터 개인이 자신의 업무로 자율적으로 직접 가져오며(pull) 업무를 진행하는 방식만을 규정하고 구성원들에게 부여된 특정한 역할은 없다. 더 간단하고 적용하기 편해 Scurm이 복잡하다면 Kanban만으로도 Agile 방법론의 장점을 느낄 수 있다고 생각한다.

본 포스트의 Jira 구성 예시는 Scrum을 기반으로 한다.

개념 및 용어

Jira를 이용해 Agile 방법론을 적용하기 위해서는 Jira에서 사용되는 개념과 용어들에 대해 알아볼 필요가 있다.

이슈 - 단계

Jira에서 이슈는 프로덕트 백로그에 등록하는 개별 할 일들의 단위이다. 이슈에는 단계가 존재한다.

  • 에픽 (Epic) [Lev 1]
    • 여러개의 하위 사용자 스토리나 태스크로 나눌 수 있는 업무의 큰 분류
    • 하나의 스프린트에서 끝나지 않고 프로젝트 기간 동안 여러 스프린트에 걸쳐 완료됨
    • e.g. 뉴스 기능 개발
  • 스토리 (Story) [Lev 2]
    • 서비스가 고객에게 줄 수 있는 기능을 중심으로 서술된 이슈
    • “[사용자]로써, [무엇]을 하고싶다” 와 같이 비즈니스 언어로 작성하는 것을 원칙으로 함
    • e.g. 포탈 사용자로써, 뉴스 리스트를 조회하고 싶다.
  • 태스크 (Task) [Lev 2]
    • 개발 업무의 관점으로 해야 할 일이 서술된 이슈
    • 어떤 곳에서는 스토리의 하위 레벨로 분류하기도 함
    • 이번 포스트 예시에서는 Lev 2는 스토리만 사용하고 태스크는 사용하지 않음
    • e.g. 뉴스 리스트 조회 기능 개발
  • 서브태스크 (Sub-Task) [Lev 3]
    • 스토리의 하위 단위로 스토리를 위해 해야 할 세부적인 업무
    • 반드시 작성될 필요는 없음
    • e.g. 뉴스 DB 생성

이슈 - 타입

단계별 분류 외에 스토리, 태스크와 같은 레벨로 다음과 같은 정의되어 있는 이슈 타입이 있다. 회사나 프로젝트에 따라 별도 이슈 타입을 만들어 관리하기도 한다.

  • 버그 (Bug) [Lev 2]
    • 릴리즈된 버전 사용 시 문제가 되는 이슈를 서술
    • 스토리와 마찬가지로 “[사용자]로써, [무엇]을 하고싶다” 와 같은 형식을 원칙으로 함
    • e.g. 포탈 사용자로써, xx 사이트의 뉴스를 조회할 수 없다.
  • 핫픽스 (Hotfix) [Lev 2]
    • 긴급하게 발생해 당장 수정이 필요한 이슈
    • 스토리와 마찬가지로 “[사용자]로써, [무엇]을 하고싶다” 와 같은 형식을 원칙으로 함
    • e.g. 포탈 사용자로써, 뉴스 탭 클릭 시 블로그 목록이 나온다.

이슈 - 우선 순위 선정

Agile에서는 이슈와 태스크를 진행하는 우선 순위가 있다.

  • Highest
  • High
  • Medium
  • Low
  • Lowest

일반적인 기능 추가와 관련된 스토리는 Medium으로 분류하고 바로 수정이 필요한 버그나 핫픽스는 High로 분류한다. 나머지는 중요도에 따라 새로운 스프린트를 시작하면서 팀원들과 토의를 통해 우선순위를 정한다.

이슈 - Story Point

Story Point는 개별 이슈를 해결하는데 소요되는 예상 시간을 의미한다.

  • 1 Point = 1 Hour

Story Point를 기반으로 팀원 각각이 해야 할 스프린트 이슈를 분배한다. 예상보다 많이 걸리는 스토리의 경우에는 조정을 하기도 하며 개인의 업무 강도를 조절한다.

이슈 - Components

해당 프로젝트를 구성하는 요소이다. 구성 요소별로 책임자가 할당되어 있을 때 업무를 분배하기 위해 사용된다.

  • e.g. Database, AI Model, iOS, Android, Web

이슈 - Labels

블로그 태그와 같은 기능이다. 추후 이슈 조회 시 사용될 수 있다.

  • e.g. Kafka, Spark, Pytorch, Tensorflow, Spring, Django, React

기타

이 외에도 Jenkins 등 CI/CD 도구와 연결해 테스트 및 배포에 이용되는 Versions, 담당자 관리와 관련된 Assignee, Reporter 등 이슈와 관련된 여러 요소가 존재한다. 모든 기능을 이용하기보다는 프로젝트에 따라 취사선택해 사용한다.

Jira 환경 설정

/assets/images//jira-project-diagram.png

Jira, Confluence를 기반으로 형상관리 도구 Github와 메세징 앱 Slack을 활용해 Agile 프로젝트를 구성하는 방법을 다룬다. 제한적인 기능을 사용했으며, 튜토리얼 식의 자세한 설명보다는 중요 기능들을 구성하는 방법 위주로 작성했다. 자세한 설정 방법은 “Jira Git 연동”, “Jira Slack 연동” 등의 키워드로 검색하면 잘 작성된 많은 글들을 찾을 수 있다.

Jira - 기본 설정

/assets/images//jira-initial-screen.png

Jira에 가입을 하고 Scurm으로 처음 프로젝트 생성을 하려하면 다음과 같은 화면이 나온다. 오른쪽 상단에 Board settings를 누르게 되면 프로젝트 관리를 위한 설정값들을 조정할 수 있다.

  • 상태별 이슈 갯수 설정

/assets/images//jira-issue-count.png

먼저 상태별 이슈의 갯수를 조정할 필요가 있다. 프로젝트 스프린트 진행 시 이슈를 계속 등록하며 해야 할 일을 계속 쌓아가기만 한다면 Jira나 Agile을 쓸 이유가 없다. Column 탭의 Column Constraint를 통해 상태별 이슈 갯수의 제한을 걸어두면 프로젝트 진행 시 프로젝트 전체의 업무량을 적절히 조율할 수 있게 된다.

  • 상태 추가

/assets/images//jira-column-management.png

빨간색으로 표신 Add column 버튼을 누르게 되면 추가적인 상태를 정의할 수 있다. 개인이 개발한 결과물은 보통 팀원들의 리뷰를 요하게 되고 이럴 때 Under Review라는 상태를 만들어 놓는다면 어떤 이슈가 리뷰를 기다리는 지 쉽게 파악이 가능하게 된다.

  • 이슈 관리 요소 설정

/assets/images//jira-issue-setting.png

Issue Detail View 탭을 가게 되면 이슈를 통해 관리하게 될 필드들을 정의할 수 있다. 프로젝트에 따라 꼭 필요한 필드들만 정의하고 관리에 오버헤드를 일으키는 필드들은 과감히 정리해서 관리하는 것을 추천한다.

Jira Automation 및 Slack 연동

/assets/images//jira-slack.png

Jira에는 업무 편의성을 위해 마련된 다양한 Automation 기능이 존재한다. 그림 왼쪽에서 보는 것처럼 When: Values change for 이나 Then: Send Slack message 같은 블럭들을 조합해 이슈 담당자 지정/변경 시 슬랙 메세지 전송 같은 자동화 룰을 적용할 수 있다. 예시에서는 Webhook을 통해 Slack을 Jira와 연동했고 Jira Smart Value를 사용해 이슈의 담당자명이나 종류 등을 불러왔다.

Github 연동

/assets/images//jira-github.png

Git을 연동해서 이슈에 해당하는 개발 커밋이나 풀 리퀘스트들을 맵핑해서 볼 수 있다. Github 개인 계정이나 조직과 연동해 커밋이나 Git 활동에 이슈 번호가 있으면 해당 이슈에 Git의 활동이 보이게 된다.

Confluence 활용

/assets/images//confluence.png

Confluence는 문서 관리를 위한 툴이다. Confluence에 작성한 글을 Jira 이슈에 링크를 걸어 다른 사람이 참조하게 하거나 프로젝트 공통으로 공유해야 할 내용들을 작성해 팀 위키로 관리할 수 있다.

/assets/images//confluence-document.png

Create을 통해 문서를 작성하게 되면 오른쪽에 보이는 템플릿들 중 원하는 템플릿을 선택해 빠르고 깔끔하게 문서를 작성할 수 있다.

Jira 사용 가이드

위의 환경 설정을 바탕으로 Jira를 사용하는 방법은 다음과 같다. 간단한 방식으로 같이 일하는 팀들과 사용하기 위한 가이드를 가져왔다.

백로그 이슈 등록

/assets/images//jira-backlog.png

  • 개발 필요 사항에 대해 백로그 이슈 등록
  • Epic > Story > Subtask
    • Epic 밑에 Story가 오고 더 세부적인 내용을 Subtask로 생성해 관리
    • 기본적으로 할 일이 생기면 Story 를 생성하고 Epic 에 맵핑
    • Story point 는 1을 1시간으로 생각하고 20 밑으로 개당 Story 작업량을 관리
    • Assignee 를 지정해 담당자를 선정
    • Sprint 는 Sprint 시작 시 backlog 에 이슈를 Sprint로 이동
    • Priority 는 Bug 같은 경우만 아니면 Medium 으로 그대로 설정
    • [필수x] Components로 특정 영역을 맵핑
    • [필수x] Labels로 정보성 태그 맵핑
    • [필수x] Fix versions는 버전 관리를 위해 Epic처럼 만들어서 맵핑

스프린트 생성 및 관리

/assets/images//jira-sprint.png

  • 백로그에서 스프린트 생성
  • 스프린트로 백로그의 이슈를 이동해 스프린트 시작
  • Active Sprints 창에서 TODO → IN PROGRESS → UNDER REVIEW → DONE 으로 이동시키며 업무 진행
  • 개별 업무 진행 시 Story 에 Description 이나 Link 등을 업데이트하며 진행 과정 기록 (필요시)
  • Story 나 Subtask 단위의 이슈에 git commit, merge 등을 진행하며 이슈 티켓 단위로 업무 진행

개발 커밋

/assets/images//jira-development-1.png

  • Commit 후 Jira와 연동이 되면 이슈 밑에 Development로 유관 브랜치, 커밋, 풀리퀘스트가 생성됨
  • Origin 에 Push 해야만 적용되어 Jira에 표시됨
  • Commit 메세지 안에 이슈 넘버 (e.g. PPP-5) 가 포함되면 Jira 에 연동되어 나옴
  • Feature branch 의 경우에도 PPP-5-news 처럼 지정하면 develop 과 merge 시 이력으로 남을 수 있음
  • Git Command 예제

로드맵

/assets/images//jira-roadmap.png

  • Epic에 대한 타임라인을 관리하며 프로젝트 주요 일정 관리

업무 진행 방식

다음은 시간 순으로 실제 업무를 진행하는 방식의 예시이다.

스프린트 시작 전

  • 스프린트 목표 설정
  • Backlog에서 목표에 맞는 이슈 스프린트에 등록
  • 우선순위 및 스토리 포인트 산정
  • 업무 분배

Daily

  • 어제 한 일 공유 및 이슈 사항 논의 (Max 15분)
  • 할당된 이슈 개발
  • 추가로 개발 필요한 내용 Backlog 등록 (필요 시 추가 개발)
  • 이슈 관련 공유하고 싶은 내용 있으면 이슈에 링크나 코멘트로 작성
  • 작업한 업무가 끝나면 Status 변경

스프린트 끝난 후

  • 만들어진 개발 결과물 리뷰
  • 스프린트 운영 개선 방향 논의

ZenHub + Notion

Jira 말고도 Agile 프로젝트를 관리할 수 있는 도구는 여러가지가 있다. 그 중 Zenhub와 Notion의 조합이 괜찮은 선택으로 보인다. Slack의 경우 메세징 앱으로서 똑같이 활용된다.

Zenhub

/assets/images//zenhub-sample.png

Zenhub는 Jira를 대체할 수 있는 이슈 관리 툴이다. Jira처럼 단계/타입별로 이슈 생성이 가능하고 Estimates를 통해 이슈에 대한 Story Points도 관리가 가능하다. 위 그림에서 보는 것과 같이 상태별로 이슈들을 조회할 수 있으며, Product Backlog를 관리한다거나 담당자를 지정하는 등 Agile 프로젝트를 하는 데 있어 필요한 거의 모든 기능을 지원한다. UI도 깔끔하고 GitHub와 직접적으로 연동되기 때문에 GitHub로 형상관리 시 이점이 있다.

Notion

/assets/images//notion-roadmap.png

/assets/images//notion-wiki.png

Notion은 마크다운으로 작성된 메모를 기반으로 일정 관리나 문서 관리를 한 곳에서 수행할 수 있는 All-in-one 앱이다. 테이블 형식으로 메모를 관리하며 각 메모에 태깅을 달 수 있는데 이를 활용하면 위 로드맵 같은 형식의 일정 관리 템플릿 등 다양한 템플릿을 만들어 활용할 수 있다. 다만, 개발 이슈들을 관리하기에는 부족해 이 부분은 전문 이슈 트랙킹 도구인 Jira나 ZenHub 등을 쓰는 것이 선호된다. Engineering Wiki 템플릿으로 Confluence를 대체하는 문서 관리 도구로는 ZenHub와 함께 훌륭히 사용할 수 있다.

Jira + Confluence 와 비교

Zenhub와 Notion은 기본 설정이 간단한 편이다. https://www.zenhub.com/ 를 통해 앱 설치를 하면 GitHub에서 ZenHub 탭을 통해 바로 활용할 수 있다. Notion도 사이트 가입만 하면 제공되는 기본 템플릿들을 통해 별도의 설정 없이 사용할 수 있다. 하지만, Jira에서 제공하는 커스터마이즈된 기능들보다는 상대적으로 적은 기능들을 지원한다는 단점이 존재해 큰 프로젝트에서는 Jira를 많이 활용하는 것으로 보인다.

규모가 작은 프로젝트이거나 Jira의 커스터마이징 기능들을 많이 사용하지 않는다면 Zenhub + Notion의 조합은 충분히 휼륭하다고 생각한다. 복잡하게 도구를 활용하는 것을 선호하지 않는데, 이슈 트랙킹 기능을 조금 포기하고 로드맵 템플릿과 위키 템플릿을 활용해 Notion만으로 프로젝트를 관리하는 것도 하나의 방법이 될 수 있지 않을까 생각한다.

마치며

간단하게 Jira 프로젝트를 구성한 예시를 공유하려는 글이 많이 길어졌다. 필자는 Agile에 대한 전문가는 아니다. 하지만, 여러 글들과 개인적인 경험과 이해를 바탕으로 최대한 올바른 내용으로 구성하려 했다.

포스트 후반부의 예시는 Jira를 활용하는 표준을 모두 따르지는 않았다. 스토리에 작성에 있어서는 이슈명을 생각하는 시간을 줄이기 위해 “사용자로서~”의 형식을 지키기보다는 서로가 이해하는 선에서 작성하도록 했고, components나 versions 같은 부분의 관리를 강제하지 않았다. 필자 나름의 이해로 업무 환경에 맞게 적용한 예시로 봐주면 좋을 것 같다.

매번 Agile에 대해 어렴풋이 알고 이상한 방향으로 적용했던 것 같은데 직접 프로젝트를 구성해보고 글을 작성하며 이해도가 높아진 기분이다. 참조 문헌에 글을 작성하며 도움이 되었던 글들을 첨부했다. 국내 메이저 IT 회사에서 Agile을 활용하는 법을 알고 싶다면 링크 중 카카오와 네이버의 발표 자료를 참조해보자.

References

Leave a comment

You may also enjoy