Jira로 애자일하게 일하기 [코드스테이츠 PMB 10기]

우리는 애자일하게 개발을 적용하고, 스프린트를 진행하는 동안 예상치 못한 문제에 마주치곤 한다. 의사소통에 문제가 생기기도 하고, 개발팀과 협업에 문제가 생기기도 하고, 외부 요인 또한 발생하게 된다. 스프린트 과정에서 발생할 수 있는 문제 상황과 이를 방지할 수 있는 방법은 무엇이 있을까? 우리는 이러한 문제를 해결하고, 예방하기 위해서 애자일의 12가지 원칙을 알아야 한다.

---

애자일의 12가지 원칙

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

우리의 최우선 순위는 가치(value) 있는 소프트웨어를 초기부터 지속적으로 제공(배포)함으로써 고객을 만족시키는 것이다.

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

개발 후반부에 변화하는 요구 사항의 수용을 환영한다. Agile 프로세스는 변화를 수용하며 고객의 경쟁력을 돕는다.

제3원칙: 짧은 배포 간격

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

제4원칙: 함께 일하기

비즈니스 담당자와 개발자는 프로젝트 전체 기간 동안 매일 함께 일해야 한다.

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

동기가 부여된 개인들 중심으로 프로젝트를 구축한다. 그들에게 필요한 환경과 지원을 제공하고 업무를 완수할 것을 믿는다.

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

개발 팀에 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화이다.

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

작동하는 소프트웨어가 진척의 주요 척도이다.

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

Agile 프로세스는 지속 가능한 개발을 장려한다. 스폰서, 개발자 및 사용자는 일정하게 일정한 속도를 유지할 수 있어야 한다.

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

우수한 기술과 우수한 디자인에 대한 지속적인 관심은 민첩성(agility)을 향상한다.

제10원칙: 단순성

단순성(수행되지 않은 작업량을 최대화하는 기술)은 필수적이다. 단순할수록, 불량을 줄일수록, 미사용 기능을 구현 안 할수록 효과적이다.

제11원칙: 자기 조직화 팀

최고의 아키텍처, 요구 사항 및 디자인은 자기 조직화 팀(Self-Organization Team)에서 나온다. 의사결정권자가 팀의 밖에 있다면 팀원들은 효과적으로 빠른 의사 결정할 수 없다.

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

팀은 정기 적으로보다 효과적인 방법을 적용해보고, 그에 따라 행동을 조율하고 조정한다.


그렇다면 PM은 애자일 프로세스를 관리하기 위해 어떤 도구들을 사용할까? 대표적으로 Jira, Trello, asana 등은 애자일 프로세스를 도와주는 협업 툴이다.

오늘은 그중 하나인 Jira를 살펴보려고 한다.

---

Jira의 기능과 애자일의 원칙

Jira의 주요 기능 중 애자일의 원칙을 수행하는 데 도움이 되는 기능을 살펴보자.

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

지라는 초기부터 지속적으로 고객 만족을 시키기 위한 애자일 프레임 워크로 스크럼과 칸반 보드를 사용한다. 스크럼 보드는 스프린트에서 스토리, 작업 및 버그를 관리한다. 그리고 정기적인 일정으로 작업을 제공하는 팀에 적합하다. 한편, 간판 보드는 지속적인 흐름에서 스토리, 작업 및 버그 관리를 한다. 그리고 백로그에서 작업량을 제어하는 팀에 적합하다.

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

제품 백로그는 제품 로드맵 및 해당 요구 사항에서 비롯된 개발 팀이 수행할 작업의 우선순위 목록이다. 개발 팀은 각 스프린트에 대한 제품 백로그에서 작업을 가져온다.

백로그를 정리하고 유지 관리하면 팀의 장기 능력과 변화하는 비즈니스 목표에 따라 항목을 지속적으로 추가 및 제거하여 팀이 장기 목표를 달성하는 데 도움이 된다. Jira Software를 사용하면 팀에서 다중 선택 순위를 사용하여 거대한 백로그를 정리하고 문제를 끌어다 놓아 사용자 스토리와 버그를 주문할 수 있다. Jira Software의 유연한 검색으로 필터링하여 특정 사용자 스토리나 버그를 찾을 수도 있다.

제3원칙: 짧은 배포 간격

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

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

리포트는 스프린트를 시작할 때 무엇을 할 수 있는지 결정하는 데 도움이 되지만 초기 추정치가 마지막에 얼마나 정확했는지도 보여준다. 번다운 차트와 같은 애자일 보고서는 스프린트 동안 완료되는 "스토리 포인트" 수를 보여준다. Jira Software는 팀의 성과에 대한 실행 가능한 실시간 인사이트와 함께 즉시 사용 가능한 수십 개의 보고서를 제공한다.

제10원칙: 단순성

우리에게 병목현상을 최소화하기 위한 단순성은 필수적이다. 따라서 보드 구성의 열 섹션으로 이동하여 보드의 열 제약 조건을 구성할 수 있는데, 각 열에 대한 최소 및 최대 제약 조건을 설정할 수 있다. 만약 최대 칼럼을 10개로 설정할 경우, 개발을 위해 선택됨 또는 진행 중 열이 10개 이상일 때마다 상단이 빨간색으로 표시된다.

---

참고자료

How to Use Jira Software | Official Buyer & User Guide