애자일의 12가지 원칙과 애자일 협업 툴, Jira
[코드스테이츠 PMB 11] Ep31. 애자일의 12가지 원칙
Agile(애자일)은 일을 빠르게 하기 위해서가 아니라, 고객과 시장의 변화에 빠르게 대처하기 위한 방법으로 기술 기반 상품 개발 프로세스이다. 애자일은 코드 기반(code-oriented) 개발 모형으로 워터폴 모델 등 계획 기반(document oriented) 모델과 대비되는 방법이다.
2001년, 소프트웨어 업계를 주도하는 리더들이 '애자일 소프트웨어 개발을 위한 선언문'을 만들어 공표하였다. 애자일 선언문과 애자일 선언을 뒷받침하는 12가지 원칙에는 고객 만족, 빠르고 반복적인 개발, 경영과 개발의 면대면 협업, 자기조직화 등 린 사고가 강하게 담겨 있다.
애자일 소프트웨어 개발 선언문은 다음과 같다.
애자일 소프트웨어 개발 선언
"우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다.
왼쪽에 있는 것들도 가치가 있지만, 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다."
그렇다면 애자일 선언문을 잘 따르기 위한 애자일의 12가지 원칙을 살펴보자.
1. 애자일의 12가지 원칙
제1원칙: 초기부터 지속적으로 고객 만족
우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
제2원칙: 요구사항 변경 수용
비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
제3원칙: 짧은 배포 간격
작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
제4원칙: 함께 일하기
비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
제5원칙: 동기부여된 팀원들로 프로젝트팀 만들기
동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라 신뢰하라.
제6원칙: 얼굴 보고 대화하기
개발팀으로 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
제7원칙: 동작되는 소프트웨어로 진도 측정
작동하는 소프트웨어가 진척의 주된 척도이다.
제8원칙: 지속 가능한 개발 속도 유지
애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
제9원칙: 좋은 기술, 설계에 관심
기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
제10원칙: 단순성
단순성이 - 안 하는 일의 양을 최대화하는 기술이 - 필수적이다.
제11원칙: 자기 조직화 팀
최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발 한다.
제12원칙: 정기적으로 효율성 제고
팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
위 12가지 원칙 중 1~3 원칙은 소프트웨어를 일찍 그리고 지속적으로 전달하며, 요구사항 변경을 적극적으로 받아들이고, 짧은 주기마다 작동하는 소프트웨어를 제공하는 것이다. 이렇게 하기 위해서 반복(iteration)과 백로그(backlog)와 같은 방법을 사용하여 관리한다.
반복 주기: 모든 프로젝트 활동을 반복적으로 수행하여 작동하는 소프트웨어를 지속적으로 제공한다. 반복 주기는 정해진 시간(Timedboxed)이 있기에 이 시기에 수행할 수 있는 일을 매 반복 주기에 우선순위를 두어 할당하고 조율하게 된다. 이를 통해 가장 중요한 요청사항에 집중해서 작업할 수 있는 환경을 만들 수 있다.
백로그: 변하는 요구사항을 관리하는 아주 좋은 방법으로 반복 주기에 포함되어 있지 않지만 개발 예정된 피처 목록(할 일 목록)이다.
애자일의 12가지 원칙의 핵심을 정리해 보면 소프트웨어는 사용자, 고객, 또는 이해관계자가 원하는 일을 할 때 가치가 있다. 이 가치를 달성하기 위해 효율적으로 '협력'과 '피드백'을 하자로 정리할 수 있다.
2. 애자일을 위한 협업 툴, Jira
Jira는 스크럼, 칸반 등 애자일 방법론의 관리를 도와주는 프로젝트 관리 도구로 애자일 보드, 백로그, 로드맵, 보고서 작성 등의 기능을 통해 애자일 소프트웨어 개발 프로젝트를 계획, 추적 및 관리하도록 도와준다.
특히, Jira는 이슈 관리에 특화된 프로젝트 관리 툴이다. 애자일 팀에게 적합한 스크럼 보드와 칸반 보드를 제공하고 필요한 기능을 사용자에 맞게 최적화할 수 있어 프로젝트 진행 상황을 효율적으로 관리하는 것이 가능하다.
짧은 스프린트 주기로 고객의 요구사항을 빠르게 수용하여 지속적으로 고객에게 가치를 전달해야 하는 애자일 환경에서는 구성원들 간의 긴밀한 협업이 무엇보다 중요하다. 구성원 간의 소통의 단절이 발생하거나, 진행 상황이 전혀 공유가 되지 않는다면 개발 과정과 결과물에 크게 차질이 생길 수 있다.
Jira는 이러한 문제 상황을 사전에 차단하고, 팀원들이 작업 상황을 함께 공유하며 효율적으로 협업할 수 있도록 다양한 기능을 지원한다. 이러한 기능 덕분에 Jira는 애자일 소프트웨어 개발 및 고객지원부터 스타트업과 엔터프라이즈를 포괄하는 관리 도구로 널리 쓰이고 있다.
Jira는 위와 같이 모바일 앱으로도 이용할 수 있다. Jira 앱을 사용하면 푸시 알림을 받아보고, 팀 내 이슈에 즉각적으로 대응하고, 대시보드 및 백로그를 즉시 업데이트하는 등 각종 상황에 기민하게 대처할 수 있다.
Jira의 자사 홈페이지에서 사용 방법을 안내하고 있으니, 아래 링크를 참고해 보자.
Jira에서 꼭 알아야 하는 용어들
Issue
Issue(이슈)는 생성에서 완료까지 추적되는 모든 유형 또는 크기의 단일 작업 항목을 나타낸다. 쉽게 말해 이슈는 개발 중인 기능, 할 일 항목 또는 계약이다. 이슈는 티켓(ticket) 또는 작업(task)이라는 용어와도 혼용하여 쓰인다.
Jira에서 관리할 수 있는 이슈 타입은 크게 아래와 같이 나누어 볼 수 있으며, 필요에 따라 프로젝트 관리에서 이슈 유형을 추가, 변경할 수도 있다.
애자일에서는 일을 단위로 쪼개어서 진행하는데, 최상위 목표인 테마(Theme)부터 태스크(Task)까지로 나누어진다. * Theme > Epic > Stories > Tasks
- 스토리(Story) : 애자일에서 가장 핵심이 되는 단위. 스토리는 PM/PO가 작성하며, 스토리는 사용자에게 어떤 가치(경험)를 줄 수 있는지, 누구나 쉽게 이해할 수 있는 문장으로 작성한다.
- 에픽(Epic) : 에픽은 여러 개의 스토리가 모여 이루는 집합이다. 이 역시 PM/PO가 작성하며, 애초에 단 한 번의 스프린트로는 달성할 수 없기에 이를 스토리로 세분화하게 된다. 사실상 제품의 주요 기능에 가깝고, 프로젝트의 마일스톤이 된다.
- 버그(Bug) : 제품이나 소프트웨어에서 발생하는 문제점을 일컫는다.
- 서브 태스크(Sub-Task) : 스토리를 만족시키기 위한 실제 개발 작업 단위를 말한다. 가장 작은 단위의 작업이라 볼 수 있다. 서브 태스크의 작성 주체는 주로 개발자인데, 팀바팀. 부바부일 수 있다.
Projects
프로젝트는 팀의 목적이나 맥락에 따라 공통적으로 보유하는 문제의 모음이다. 프로젝트는 팀, 사업부, 제품 또는 작업 흐름별로 문제를 그룹화할 수 있는 유연한 작업 공간이다. 예를 들어, 문제를 팀별로 그룹화한다면 마케팅 프로젝트, 개발 프로젝트 및 법률 프로젝트가 있을 수 있다. 이들은 모두 해당 팀의 진행 중인 작업을 추적한다.
Boards
보드는 팀이 진행 중인 작업을 수행하고 관리하고 문제를 표시하는 프로젝트의 일부이다. 즉, 보드는 프로젝트 내에서 팀의 워크플로를 시각적으로 표현한 것이다.
Workflows
워크플로는 문제의 생성에서 완료까지 순차적인 경로를 나타낸다. 기본적으로 워크플로의 형태는 다음과 같다.
3. Jira에서 애자일의 12원칙 찾아보기
1) 백로그 작성
제2원칙: 요구사항 변경 수용
애자일한 환경에서는 고객의 요구사항을 빠르게 캐치하고 반영하는 것이 중요하다. 그러기 위해서는 고객의 피드백을 수용할수록 지속적으로 쌓이는 백로그를 효율적으로 관리하고, 우선순위에 따라 해결할 수 있어야 한다.
Jira에서 프로젝트 템플릿을 '스크럼'으로 선택하고 프로젝트를 생성하면 백로그를 작성할 수 있다. "무엇을 해야 합니까?" 란에 팀이 수행해야 할 업무 목록인 백로그를 입력하여 추가하면 자동으로 DAND-1, DAND-2 형식으로 번호가 매겨진다. 해당 백로그는 스프린트 진행 중에도 필요하면 언제든지 고객과 이해관계자의 요구사항을 수용하여 변경할 수 있다. 1차적으로 진행할 우선순위 백로그를 모두 작성했다면 우측 상단의 '스프린트 시작'을 선택한 후 팀의 스프린트 기간과 목표를 설정한다.
2) 스프린트 기간 설정
제3원칙: 짧은 배포 간격
Jira는 애자일의 짧은 배포 간격의 프로덕트를 위해 스프린트 기능을 제공한다. 최소 이 주에서 최대 두 달이라는 스프린트 기간 동안 Jira를 활용하면 유저 스토리를 추가하고, 백로그를 관리하고, 스프린트 보고서로 모니터링을 하는 등 다양한 이점을 얻을 수 있다.
'스프린트 시작'을 선택하면 위와 같은 팝업이 뜨고 스프린트 이름, 기간, 시작/종료 날짜, 스프린트 목표를 설정할 수 있다. 기간은 2주에서 2달까지 선택하여 설정할 수 있으며 시작 날짜를 설정하면 종료 날짜가 자동으로 계산되어 표기된다. 기간은 사용자가 임의로 지정하는 것도 가능하다.
프로덕트를 출시한 이후에도 주변 상황의 변화에 따라 프로덕트를 지속적으로 발전시키기 위해서는, 적절히 타이트한 스프린트 주기를 설정하고 개발한 기능을 초기부터 조금씩 통합하고 검증하여 고객과 시장의 요구에 적시 대응할 수 있어야 한다.
3) 백로그 담당자와 백로그 설정
제4원칙: 함께 일하기, 제5원칙: 동기 부여된 팀원들로 프로젝트팀 만들기
Jira는 애자일 환경의 팀원들이 서로 투명한 소통을 주고받을 수 있도록 애자일의 대표적인 대표 관리 Practice인 스크럼과 칸반을 제공한다. 스크럼과 칸반 보드는 작업 관리 허브로, 각 작업 항목의 상태를 한눈에 파악할 수 있다. 이밖에도 시간 추적 기능과 실시간 성능 보고서를 통해 시간 경과에 따른 생산성을 모니터링할 수 있다.
좌측 메뉴에서 '보드' 탭을 누르면 백로그들을 칸반 보드로 보여준다. 여러 백로그들을 할 일, 진행 중, 완료 이슈로 구분하여 스프린트의 진행 상황을 파악할 수 있다. 백로그의 담당자를 배정할 때는 스프린트 회의를 통해 R&R을 명확히 설정하고 팀원들이 자신의 책임과 권한을 인지할 수 있도록 한다. 스프린트 진행과정에서 팀원들과 함께 달성해야 할 스프린트 목표를 다시 한번 상기하며 동기 부여시키는 것도 중요하다.
각 백로그를 선택하면 해당 백로그에 대한 설명과 하위 이슈를 설정할 수 있다. 오른쪽 세부 정보에서는 담당자 지정, 'Bare minimum'과 같은 우선순위 레이블을 달아서 백로그의 기능과 완료 기한 등 상세 정보를 기입한다. 하단에는 댓글 기능이 있어서 팀원 간에 진행 상황에 대한 논의가 필요할 때 언제든지 소통이 가능하다.
4) 스크럼 점검
제7원칙: 동작되는 소프트웨어로 진도 측정
Jira에는 다양한 차트와 보고서를 활용하여 개발 진척도를 확인할 수 있다. 총 15개의 대시보드 가젯이 있으며 사용자의 필요에 맞게 개인화할 수 있으며, 각각 무엇을 추적하고 싶은지에 따라 여러 개의 대시보드를 만들 수도 있다.
Jira guide에 따르면 스크럼 팀에게는 총 4가지를 추천하고 칸반 팀에게는 2가지를 추천하고 있는데, 이에 대해 조금 알아보고자 한다.
For. 스크럼 팀
스크럼 팀에게는 위의 4가지 추적 데이터로 스프린트의 회고를 잘할 수 있도록 돕는다.
스프린트 리포트 (Sprint report) : 각 스프린트에서 완료된 작업 또는 백로그의 작업을 확인하여 팀의 작업 할당량이 적절한 지를 파악할 수 있다.
번다운 차트 (Burndown chart) : 남아있는 총작업량을 트래킹하고 스프린트 목표가 달성 가능한지 예상할 수 있다. 해당 차트를 이용하여 진행 상황을 관리할 수 있다.
릴리즈 번다운 (Release Burndown) : 특정 버전의 예상 릴리즈 날짜를 트래킹하여 작업이 지체되는 경우 조치를 취할 수 있다.
속도 차트 (Velocity chart) : 스프린트 간에 완료된 작업량의 속도를 측정할 수 있다. 해당 차트를 이용하여 팀의 작업 속도를 파악하고 이후 팀이 현실적으로 처리할 수 있을 정도의 작업량을 추정할 수 있다.
For. 칸반 팀
칸반 팀은 위의 두 대시보드를 활용하여 향후 성과를 더 효과적으로 예측하고 병목현상을 파악할 수 있도록 돕는다.
누적 흐름 다이어그램 (Cumulative flow diagram) : 지정된 상태별로 증가한 이슈 개수를 확인하여 병목 요인을 쉽게 찾아낼 수 있다.
컨트롤 차트 (Control chart) : 프로덕트, 버전 또는 스프린트에 대한 주기 및 리드 타임을 확인하여 통제되는 상한 및 하한 제한치 내에서 관리할 수 있다.
5) 스프린트 리뷰/회고
제12원칙: 정기적으로 효율성 제고
애자일 팀에서 회고는 대개 하나의 스프린트가 끝날 때 이루어지는데, Jira의 회고 템플릿을 이용하면 회고의 결과를 일목요연하게 정리할 수 있다. 회고 템플릿을 이용하면 프로덕트에서 조치를 취해야 할 부분과 방법을 팀원들과 함께 고민할 수 있다.
회고를 진행하면서 담당자와 업무 진척률을 확인하고 남은 이슈들을 점검한다. PM은 이때 스프린트 주기 동안 받은 고객 피드백, 팀원들의 의견을 취합하여 지난 스프린트를 검토하고 다음 스프린트에 대한 계획을 세운다.
애자일 관리 도구인 Jira의 기능을 처음 사용해봤는데 업무의 진척상황을 다수가 공유하고 빠르게 협업할 수 있다는 점에서 유용한 도구라는 생각이 든다. 이번에 사용해 본 몇몇 기능들은 맛보기에 불과했기에 이후에 직접 업무에서 활용하며 익숙해지고 싶다.
제품을 시장에 내놓고 피드백을 받는 것을 빠른 주기로 반복하는 애자일 프로세스는 시장의 변화 속도에 따라가야 하는 소프트웨어 제품 개발에 이점이 많은 방식이라는 건 충분히 공감하지만, 그만큼 제품의 지속적인 운영과 개선을 위해서는 시간, 인력과 백로그를 적절히 관리하는 것 또한 필수적이다. (제품팀과 PM은 항상 많이 바쁠 것 같다는 얘기다..ㅎㅎ)
현실적으로 실무에서는 애자일의 장점만을 끌어모아 안정적으로 일하기란 쉽지 않을 것 같다. 언제나 이상과 현실은 차이가 있는 법이고, 모든 것은 사람이 하는 일이기에 완벽하기는 더더욱 어렵다. 그럼에도 애자일이 효율적인 협업을 위한 툴인만큼 공동의 목표가 잘 Align 되어 있는지, 바람직한 방향으로 일하고 있는지, 스크럼과 회고는 팀에 무슨 의미를 가지는지 등의 질문을 던지며 원점에서 다시 바라보는 시간이 꼭 필요할 것이다.
무엇보다 가장 중요한 것은 서로 신뢰하는 동료와의 팀워크와 커뮤니케이션이다. 이를 바탕으로 애자일이라는 '툴'을 효율적으로 이용했을 때, 우리 프로덕트에 한층 더 가치를 더할 수 있지 않을까:)
참고자료
http://agilemanifesto.org/iso/ko/manifesto.html
https://pmnagile.tistory.com/27
https://pmnagile.tistory.com/27
https://brunch.co.kr/@sunshl0203/4
https://brunch.co.kr/@otter-jieon/42
https://brunch.co.kr/@aykim13/94
