애자일 관리도구 <Jira 지라> 살펴보기 !

지라(JIRA)

 

지라(JIRA)는 Atlassian이 개발한 버그 추적 시스템(BTS-Bug Tracking System), 프로젝트 관리 소프트웨어이다. 버그 추적, 이슈 추적, 프로젝트 관리 기능을 제공하고 있다. 무료로 제품을 사용할 수 있고 인원수가 일정 수 이상 넘어가면 돈을 지불하고 소프트웨어를 사용할 수 있다.

 

애자일 조직에서 소위 '애자일한 환경'을 만들기 위해 노력의 일환으로 다양한 도구들이 활용하고 있다. 스타트업의 채용공고에서 '애자일'을 강조하는 많은 기업이 'Slack', 'Jira' 'Asana' 'Trello'와 같은 협업툴을 선택해 실무에서 사용하고 있고, 채용공고 우대사항에 해당툴 유경험자를 기입하는 경우도 종종 있다. 동시에 회사소개에서 '정보의 투명성'을 회사의 특성으로 강조하는 경우도 찾을 수 있다.

 

원티드 트랜비 PO 채용공고

Slack, Jira는 조직내 정보 공유를 활성화 해 투명성을 향상시킨다는 공통점을 가지며 Slack은 커뮤니케이션, Jira는 공식사이트 소개처럼 '애자일 팀을 위한 프로젝트 관리'에 특화된 도구이다. 오늘은 Jira를 간략히 소개하고자 한다. 처음 Jira에서 프로젝트를 만들 때 스크럼, 칸반, 버그추적 크게 3가지 템플릿을 선택가능하며 프로젝트 관리자에 따라 팀, 회사로 나누어 유형을 설정 할 수 있다.

---

애자일을 돕는 Jira의 상세 기능들

 

1. 투명하고 수평적인 정보공유 기능

 

Jira에서 프로젝트를 관리하는 모든 팀원은 모든 스크럼 보드에 액세스할 수 있다. Jira를 통해 모든 팀원들이 작업 진행상황을 빠르게 실시간으로 공유할 수 있다. 크게는 프로젝트의 에픽 정의부터 각 일감(tssk) 별 담당자, 업무 기한, 진행 상황, 피드백 댓글까지 모두 공유한다. 이는 Jira가 추구하는 SSoT(Single Source of Truth) 특성과 연결된다. 국문으로 '단일 진실 공급원'으로 번역되는데 Dropbox에서는 모든 비즈니스 데이터를 하나의 공간에 저장하는 것이라고 정의하고 있다. 데이터를 하나의 공간에 저장하고 모든 팀원이 접근이 가능하다면 접근 가능 데이터를 바탕으로 중요한 비즈니스 의사 결정을 내릴 수 있다는 것이다.

 

출처: Jira

 

2. 프로젝트에 집중할 수 있는 스크럼 보드

 

 

Jira에서 프로젝트를 생성할 때 대표적인 애자일 프레임워크인 칸반(Kanban)과 스프린트(Sprint) 두 가지 템플릿을 선택할 수 있다. 이 외에도 두 방법론에 기반한 혼합 방법론 또한 선택 가능하다. 두 템플릿 모두 스크럼 보드 디스플레이를 제공해 프로젝트를 관리할 수 있는데, 에픽, 담당자, 프로젝트, 스웜레인 등의 기능을 손쉽게 사용할 수 있다.

 

스프린트 템플릿을 통해 조금 더 상세하게 설명하자면, 스프린트 기한을 지정하여 마감기한을 놓치지 않도록 돕는다. 스프린트 내에서 모든 일감(이슈)을 백로그에서 드로그앤드롭하여 진행상황을 정렬하고 스토리 포인트를 통해 일감별 우선순위를 지정할 수 있다. 중요한 일감은 해당 특성을 포함한 일감에 대해 퀵필터를 생성해 표시되도록 할 수 있다. 

 

온라인 기반으로 가장 최신 버전을 공유하게 되기 때문에 버전관리가 수월하다. 버전, 기능, 잠재적 문제 등 진행상황을 지속적으로 트래킹 할 수 있다.

 

버전관리: 버전, 기능, 진행상황 트래킹이 가능하다. 버전을 클릭하여 이슈, 개발 데이터 및 전체 상태를 확인 할 수 있다.
백로그 정리: 사용자 스토리 및 버그 우선순위 재지정이 쉽다. 백로그는 드로그앤드롭으로 쉽게 이동/정렬할 수 있고 퀵필터를 생성해 특성에 따른 이슈를 표시해 관리할 수 있다. 
스토리 포인트: 작업 복잡성, 작업량, 위험, 불확실성과 관련하여 스토리 포인트를 부여해 추적하고 향후 스프린트에서 팀의 정확성을 개선한다. 

 

 

 

3. 스크럼 보고서, 회고를 위한 데이터 시각화자료 생성

 

스크럼 팀은 매일 데일리 스크럼 미팅을 갖는다. 팀원들이 어제의 업무 진행상황과 이슈, 오늘의 업무를 간략히 공유하는 회의로 프로젝트 진척상황을 파악하고 직무 별 소통을 위한 과정이다. 스프린트가 끝난 후 마무리 미팅으로 회고 시간을 갖고 개선점을 공유하게 되는데, 데일리 스크럼 미팅과 회고 모두 마감 기한에 맞춰 빠르게, 효율적으로, 문제상황을 개선하며 일을 진행하기 위함이다. 이 때, 애자일 프로세스에 대한 데이터 시각화자료를 이용하면 직관적인 이미지로 팀원들의 이해를 돕고, 데이터 중심 의사결정이 가능하다. Jira는 다양한 애자일 보고서를 제공해 스프린트에서 개선할 영역을 직관적으로 파악할 수 있게 돕는다. 

 

출처 : Jira

 

스프린트 보고서: 스프린트에서 과도한 범위 확장을 판단하고 완료한 작업을 파악한다.
번다운 차트: 스프린트 진행 상황을 추적하여 관리하기 위한 차트다. 
릴리즈 번다운: 프로덕트의 릴리즈 날짜에 맞춰 스프린트를 추적 및 모니터링하여 작업이 예상 일정에 맞추어가는지 트래킹한다. 
속도 차트: 스프린트마다 작업 시간을 추적하여 팀의 속도를 파악한다. 스프린트 팀의 작업 능률을 파악해 다음 스프린트를 개선할 수 있다.
누적 흐름도: 지정된 상태별로 증가한 이슈 개수를 확인해 블로커를 찾는다. 
컨트롤 차트: 제품, 버전 또는 스프린트에 대한 주기 및 리드 타임을 추적해 향후 성능을 파악할 수 있다.

이 외에도 대시보드, 다양한 종류의 데이터 시각화 기능을 제공하고 있다. 

 

애자일의 12가지 원칙과 JIRA에 적용되는 원칙

 

 

제 1원칙: 초기부터 지속적으로 고객 만족

우리의 최우선 순위는 가치(value) 있는 소프트웨어를 초기부터 지속적으로 제공(배포)함으로써 고객을 만족시키는 것입니다. 초기부터 개발물을 제공하는 것이 Risk도 감소하고 Value가 증가합니다.

제 2원칙: 요구사항 변경 수용

개발 후반부에 변화하는 요구 사항의 수용을 환영합니다. Agile 프로세스는 변화를 수용하며 고객의 경쟁력을 돕습니다. 쏜 곳으로 정확히 날아가는것도 중요하지만, 움직이는 사물(고객/시장)을 맞추기 위해서는 변화에 대응 할 수 있어야 합니다.

 

Jira는 구성원들 모두가 편집할 수 있고 사용할 수 있다. 그렇다보니 이슈가 발생하거나 변화를 줘야 되는 부분들을 팀원 모두가 한번에 확인할 수 있고 소통을 원활하게 도와준다. 그렇기 때문에 요구사항등을 빠르게 알리고 변경할 수 있다고 생각했다.

 

제 3원칙: 짧은 배포 간격

소프트웨어를 짧은 주기(2주에서 2달까지)로 동작하는 소프트웨어를 배포하되 더 짧은 주기를 선호합니다.

여러 개발자가 개발한 SW를 초기부터 조금씩 통합/검증하는 것이 한번에 통합/검증 보다 낫습니다. 미리 예측한 요구사항(계약)을 따르기 보다는, 변화하는 고객/시장에 따라 요구사항도 변해야 합니다. 만약 상호 검수를 위해 요구사항만 중시한다면 Output은 만족시키겠지만 Outcome은 만족시킬수 없습니다. 프로젝트 초반 보다 팀원의 지식은 증가하고 그 사이에 고객/시장의 눈높도 증가합니다.

 

제 4원칙: 함께 일하기

비즈니스 담당자와 개발자는 프로젝트 전체 기간동안 매일 함께 일해야합니다. 비즈니스 가치가 있는 소프트웨어를 개발하기 위해서는 비즈니스 담당자가 원하는 소프트웨어를 함께 개발해야 합니다.

 

2원칙과 겹치는 부분들이 있는데 팀원 모두가 프로젝트 상황을 공유한다는 점이다. 누가 어떤 일을 얼만큼 진행했고 어떤 일을 언제까지 끝내기 위해서는 어떤 것들이 필요한지 Jira에 입력해놓기만 하면 모두 확인할 수 있다. 또한 댓글이나 이슈를 통해서 서로에게 필요한 점들이나 얘기하고자 하는 것들을 바로바로 전달할 수 있는 점이 도움이 된다고 생각한다.

 

제 5원칙: 동기부여된 팀원들로 프로젝트팀 만들기

동기가 부여된 개인들 중심으로 프로젝트를 구축합니다. 그들에게 필요한 환경과 지원을 제공하고 업무를 완수 할 것을 믿습니다. 구성된 팀의 목표나 동기가 서로 다르다면 성공적인 결과를 내기 어렵습니다.

 

Jira는 사용자를 추가해 스크럼 프로젝트를 공유할 수 있다. PM부터 디자이너 개발자 등 다양한 팀원이 한 팀이 되어 일하는 애자일 프로세스에서는 함깨 일하는 것이 중요하다. 스크럼 프로젝트를 공유하는 기능을 통해서 각 팀원들은 투명하게 서로의 모든 작업과 상황을 공유할 수 있다.

 

제 6원칙: 얼굴보고 대화하기

개발 팀에 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다. 얼굴 보고 대화하는 것이 가장 효과적이고 효율적인 Communication입니다. 그냥 얼굴 보고 이야기하면 될것을 서로 등지고 문서로 전달하려고 하지 않나요?

 

제 7원칙: 동작되는 소프트웨어로 진도 측정

작동하는 소프트웨어가 진척의 주요 척도입니다. 전체 100%의 모든 기능을 80% 수준으로 완성해도 진척률은 80%이고, 80%의 기능이 100% 완성되어도 진척률은 80%입니다. 실행해보고 배우고 개선하기 위해서 Agile은 후자를 선호합니다.

출처 : Jira

다양한 시각화 차트를 통해 애자일 진척도를 확인할 수 있다. 진척도를 통해 지금 현재 상황이 문제없이 계획대로 진행되고 있는지 파악할 수 있다.

스프린트 보고서: 스프린트에서 과도한 범위 확장을 판단하고 완료한 작업을 파악한다.
번다운 차트: 스프린트 진행 상황을 추적하여 관리하기 위한 차트다. 
릴리즈 번다운: 프로덕트의 릴리즈 날짜에 맞춰 스프린트를 추적 및 모니터링하여 작업이 예상 일정에 맞추어가는지 트래킹한다. 
속도 차트: 스프린트마다 작업 시간을 추적하여 팀의 속도를 파악한다. 스프린트 팀의 작업 능률을 파악해 다음 스프린트를 개선할 수 있다.
누적 흐름도: 지정된 상태별로 증가한 이슈 개수를 확인해 블로커를 찾는다. 
컨트롤 차트: 제품, 버전 또는 스프린트에 대한 주기 및 리드 타임을 추적해 향후 성능을 파악할 수 있다.

이 외에도 대시보드, 다양한 종류의 데이터 시각화 기능을 제공하고 있다. 

 

제 8원칙: 지속 가능한 개발 속도 유지

Agile 프로세스는 지속 가능한 개발을 장려합니다. 스폰서, 개발자 및 사용자는 일정하게 일정한 속도를 유지할 수 있어야합니다. Agile은 프로젝트 초반부터 결과물을 내야하므로 초반에 더 힘이 듭니다. 하지만 지속적인 성과를 내기에 효과적입니다.

 

제 9원칙: 좋은 기술, 설계에 관심

우수한 기술과 우수한 디자인에 대한 지속적인 관심은 민첩성(agility)을 향상시킵니다. 바빠서 기술적 개선을 하지 못한다면, 항상 바쁘기 때문에 영원히 뒤처집니다. “나에게 나무 베는 6시간이 주어진다면, 4시간을 도끼 가는데 사용할 것이다” – 링컨 대통령 팀원의 성장도 프로젝트 성공에 필수 사항입니다.

 

제 10원칙: 단순성

단순성(수행되지 않은 작업량을 최대화하는 기술)은 필수적입니다. 단순할 수록, 불량을 줄일 수록, 미사용 기능을 구현 안 할 수록 효과적입니다. 중간에서 추가 Value를 주지 않는 Task는 단순 취합이고 낭비이며 허들이 될 수 있습니다.

 

제 11원칙: 자기 조직화 팀

최고의 아키텍처, 요구 사항 및 디자인은 자기 조직화 팀(Self-Organization Team)에서 나옵니다. 의사결정권자가 팀의 밖에 있다면 팀원들은 효과적으로 빠른 의사결정 할 수 없습니다. 예를 들면, 의사결정권자 없이 실무자끼리 회의를 해봐야 결정할 수 있는 것은 없습니다. 그분이 만족할까? 이런 결정 내리면 혼나지 않을까? 우리팀에서는 좋아할까? 그팀에서 허락해줄까?로 고민만 합니다.

 

제 12원칙: 정기적으로 효율성 제고

팀은 정기적으로보다 효과적인 방법을 적용해보고, 그에 따라 행동을 조조율하고 조정합니다. Scrum에서는 Sprint가 끝나는날마다 회고(Retrospective)를 수행합니다.

 

프로젝트 페이지 기능에서 미팅노트를 작성하거나 회고록을 작성하는 것을 통해서 효율성을 찾아낼 수 있다고 생각한다. 또한 Jira라는 협업툴을 사용하는 것이 팀의 효율성을 높이기 위한 행동 중 하나라는 생각이 들었다.