애자일의 12가지 원칙과 애자일 툴(JIRA)
애자일의 12가지 원칙
애자일의 12가지 원칙
제 1원칙: 초기부터 지속적으로 고객 만족
우리의 최우선 순위는 가치(value) 있는 소프트웨어를 초기부터 지속적으로 제공(배포)함으로써
고객을 만족시키는 것입니다.
제 2원칙: 요구사항 변경 수용
개발 후반부에 변화하는 요구 사항의 수용을 환영합니다.
Agile 프로세스는 변화를 수용하며 고객의 경쟁력을 돕습니다.
쏜 곳으로 정확히 날아가는 것도 중요하지만, 움직이는 사물(고객/시장)을 맞추기 위해서는
변화에 대응할 수 있어야 합니다.
제 3원칙: 짧은 배포 간격
소프트웨어를 짧은 주기(2주에서 2달까지)로 소프트웨어를 배포하되 더 짧은 주기를 선호합니다.
여러 개발자가 개발한 SW를 초기부터 조금씩 통합/검증하는 것이 한 번에 통합/검증 보다 낫습니다.
미리 예측한 요구사항(계약)을 따르기보다는, 변화하는 고객/시장에 따라 요구사항도 변해야 합니다.
만약 상호 검수를 위해 요구사항만 중시한다면 Output은 만족시키겠지만 Outcome은 만족시킬 수
없습니다.
프로젝트 초반보다 팀원의 지식은 증가하고 그 사이에 고객/시장의 눈높이도 증가합니다.
제 4원칙: 함께 일하기
비즈니스 담당자와 개발자는 프로젝트 전체 기간 동안 매일 함께 일해야 합니다.
비즈니스 가치가 있는 소프트웨어를 개발하기 위해서는
비즈니스 담당자가 원하는 소프트웨어를 함께 개발해야 합니다.
제 5원칙: 동기 부여된 팀원들로 프로젝트팀 만들기
동기가 부여된 개인들 중심으로 프로젝트를 구축합니다.
그들에게 필요한 환경과 지원을 제공하고 업무를 완수할 것을 믿습니다.
구성된 팀의 목표나 동기가 서로 다르다면 성공적인 결과를 내기 어렵습니다.
제 6원칙: 얼굴 보고 대화하기
개발 팀에 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.
얼굴 보고 대화하는 것이 가장 효과적이고 효율적인 Communication입니다.
그냥 얼굴 보고 이야기하면 될 것을 서로 등지고 문서로 전달하려고 하지 않나요?
제 7원칙: 동작되는 소프트웨어로 진도 측정
작동하는 소프트웨어가 진척의 주요 척도입니다.
전체 100%의 모든 기능을 80% 수준으로 완성해도 진척률은 80%이고, 80%의 기능이
100% 완성되어도 진척률은 80%입니다. 실행해보고 배우고 개선하기 위해서 Agile은 후자를 선호합니다.
제 8원칙: 지속 가능한 개발 속도 유지
Agile 프로세스는 지속 가능한 개발을 장려합니다.
스폰서, 개발자 및 사용자는 일정하게 일정한 속도를 유지할 수 있어야 합니다.
Agile은 프로젝트 초반부터 결과물을 내야 하므로 초반에 더 힘이 듭니다.
하지만 지속적인 성과를 내기에 효과적입니다.
제 9원칙: 좋은 기술, 설계에 관심
우수한 기술과 우수한 디자인에 대한 지속적인 관심은 민첩성(agility)을 향상합니다.
바빠서 기술적 개선을 하지 못한다면, 항상 바쁘기 때문에 영원히 뒤처집니다.
“나에게 나무 베는 6시간이 주어진다면, 4시간을 도끼 가는데 사용할 것이다”
– 링컨 대통령 팀원의 성장도 프로젝트 성공에 필수 사항입니다.
제 10원칙: 단순성
단순성(수행되지 않은 작업량을 최대화하는 기술)은 필수적입니다.
단순할수록, 불량을 줄일수록, 미사용 기능을 구현 안 할수록 효과적입니다.
중간에서 추가 Value를 주지 않는 Task는 단순 취합이고 낭비이며 허들이 될 수 있습니다.
제 11원칙: 자기 조직화 팀
최고의 아키텍처, 요구 사항 및 디자인은 자기 조직화 팀(Self-Organization Team)에서 나옵니다.
의사결정권자가 팀의 밖에 있다면 팀원들은 효과적으로 빠른 의사 결정할 수 없습니다.
예를 들면, 의사결정권자 없이 실무자끼리 회의를 해봐야 결정할 수 있는 것은 없습니다.
그분이 만족할까? 이런 결정 내리면 혼나지 않을까? 우리 팀에서는 좋아할까? 그 팀에서 허락해줄까?로
고민만 합니다.
제 12원칙: 정기적으로 효율성 제고
팀은 정기 적으로보다 효과적인 방법을 적용해보고, 그에 따라 행동을 조율하고 조정합니다.
Scrum에서는 Sprint가 끝나는 날마다 회고(Retrospective)를 수행합니다.
애자일은 워터폴 개발 방법론에 비해 작고 빠른 릴리즈를 수행한다. 이는 고객이 원하는 것을 빠르게 파악하기 위함이고 잦은 실행을 통해 개선사항을 도출하여 발전시켜나가는 데에 목적이 있다. 고객이 원하는 요구사항을 모든 걸 한 번에 알 수 없다는 가정 하에 이루어지며, 기존의 고객에 대한 지식을 최대한 배제하고 오로지 데이터 기반으로 학습해나가며 이에 맞게 발전시켜나간다. 그리고 빠른 릴리즈가 생명이기 때문에 문서화 작업을 줄이고 잦은 대면 의사소통을 통해 진행되는 사람 중심의 개발 방법론이다.
https://clickup.com/blog/agile-tools/위에서 간단하게 설명한 애자일을 조금 더 수월하게 수행하기 위한 툴 서비스가 다양하게 출시됐다. 위 사진의 출처에선 21년도 자신의 조직이 애자일 방법론을 채택했는가에 대한 질문에 94%가 그렇다고 했다. 팀이 어떤 종류의 프로젝트를 수행하는지, 조직의 규모가 얼마나 되는지, 애자일 툴을 사용할 수 있는 예산이 얼마나 책정되어 있는지 등의 기준을 나눠 애자일 툴을 선택할 수 있다.
대표적인 애자일 15가지 툴
· 클릭업
· 지라
· 칸바니즈
· 깃허브 프로젝트 관리
· 린킷
· 플랜박스
· 액티브 콜라보레이션
· 프로지오
· 코드자이언트
· 액소소프트
· 어셈블라
· 조호 프로젝트
· 아사나
· 라이크
· 트렐로
위 15가지 툴 종류 중 오늘 알아볼 툴은 Atlassian Jira(아틀라시안 지라)다. 애자일 툴 중 가장 잘 알려졌다고 해도 무방할 정도로 다양한 기업에서 활용하고 있다. 대표적인 애자일 툴로 잘 알려진 지라를 직접 사용해보면서 어떤 기능과 특징을 가졌는지 앞서 소개된 12개의 애자일 원칙과 연관 지어 알아보고자 한다.
제 1원칙: 초기부터 지속적으로 고객 만족
https://www.oldstreetsolutions.com/scrum-vs-kanban-business-teams
지라에선 '지속적'으로 고객만족의 원칙을 위해서 사용하는, 애자일의 대표적인 프레임워크인 스크럼과 칸반을 템플릿 형태로 제공한다. 스크럼과 칸반 모두 애자일의 목적은 같지만 조직의 성격과 프로덕트에 따라 활용하는 조직이 다르다. 칸반은 작업을 시각화하여 업무의 병목 현상과 리소스 낭비를 처리할수록 돕고, 스크럼은 잘 정의된 목표를 향한 팀워크와 반복적인 진행을 강조하는 프레임워크다.
제 2원칙: 요구사항 변경 수용
https://www.atlassian.com/software/jira/guides지라의 제공하는 템플릿의 '보드'에서 각 항목별로 담당자마다 업무를 확인할 수 있다. 제2의 원칙에서 중요한 점은 개발 중 변화하는 고객의 요구 사항에 대한 수용이다. 이를 위해선 개발을 진행하는 동안 이 보드에서 각 단계별 업무를 이슈 발생 시 간단하게 추가 및 수정이 가능하다. 또한 문제 발생 시 '플래그'를 통해 협업하는 동료들에게 자신의 상태를 알릴 수 있다.
제 3원칙: 짧은 배포 간격
애자일에서 항상 강조하는 짧은 주기와 빠른 릴리즈다. 지속적으로 언급하지만, 변화하는 시장과 고객의 요구에 맞추기 위해 개발 초기부터 프로덕트를 조금씩 개선하고 검증하는 단계를 거쳐가기 때문이다. 이에 맞춰서 지라에선 스프린트를 설정할 때 기간을 설정할 수 있는데, 기본적으로 1주/2주/3주/4주를 선택할 수 있고 사용자 지정을 통해 별도로 지정할 수 있다.
제 4원칙: 함께 일하기
https://www.atlassian.com/software/jira/guides/roadmaps/basic-roadmaps#what-is-a-roadmap저번에 작성했던 스크럼 가이드 요약에서, 모든 업무는 가시적이고 투명하게 공유되어야 원활한 커뮤니케이션과 성과를 낼 수 있다고 언급되어있었다. 이를 위해 위 사진의 로드맵 차트에서 스마트 필터를 통해 모든 담당자의 로드맵을 구체적으로 확인할 수 있다. 또한, 모든 업무는 공개되어 모두가 확인할 수 있고 모든 작업은 실시간으로 동기화된다. 보드로 이동할 경우 상단에 담당자들의 아이콘이 위치해있는데 각 담당자의 아이콘을 클릭할 경우 보드에는 해당 담당자의 테스크만 남게 되어 어떤 업무를 하고 어떤 이슈를 겪고 있는지 확인할 수 있다.
제 7원칙: 동작되는 소프트웨어로 진도 측정
https://www.atlassian.com/software/jira/guides프로덕트 개발 진척도를 확인할 수 있도록 12개의 차트를 제공하고 있다. 남아있는 총작업을 트래킹 할 수 있는 [번다운 차트], 스프린트 간 완료된 작업량을 트래킹 할 수 있는 [속도 차트], 예상 릴리즈 날짜를 예상할 수 있는 [릴리즈 번다운 차트], 특정 에픽을 완료하는데 필요한 예상 스프린트 수를 트래킹 할 수 있는 [에픽 번다운 차트], 스프린트에서 완료된 작업 또는 백로그를 확인하는 [스프린트 보고서], 이슈의 개수를 확인할 수 있는 [누적 흐름도], 스프린트에 대한 사이클 타임을 확인할 수 있는 [컨트롤 차트] 등이 있다.
제 8원칙: 지속 가능한 개발 속도 유지
https://www.atlassian.com/software/jira/guides애자일 프로세스에서 초반부터 결과물을 내야 하기 때문에 지속 가능한 개발 속도를 유지하는 것은 중요하다. 마라톤으로 치면 페이스 조절을 통해 팀이 전체적으로 균형을 유지하고 체력적으로 지치지 않게 도와줄 수 있다. 이를 위해 지라의 보드에서 각 항목별로 리밋을 걸어둘 수 있다. 각 단계별로 작업할 수 있는 한계점을 설정해두어 꾸준하게 효과적인 성과를 낼 수 있도록 도움을 줄 수 있다.
어떤 아티클을 읽어도, 모든 방법론은 옳고 이상적이다. 하지만 방법론이며 원칙이며 절대적인 것은 없다는 것이다. 어떠한 방법론 속에 뛰어들더라도 조직 내 구성원들이 전부라는 것을 잊어선 안된다. 위에서 소개된 12가지의 애자일 원칙을 모두 칼같이 지킨다고, 15개의 애자일 툴과 여러 생상성 툴을 모두 사용한다고 해서 효율이 극도록 높아지는 것도 아니고, 적은 수의 툴을 활용한다고 해서 집중할 수 있는 것도 아니다. 오늘 토론에서도 동기들과 각자의 시선으로 애자일을 바라보고 많은 얘기를 해봤다.
결과적으로, 어떤 방법론을 무 자르듯이 깔끔하게 잘라서 사용하는 것이 중요한 게 아니라 테스크에 도전적이어야 한다는 것, 서로 간 지속적인 피드백을 수용할 수 있어야 한다는 것, 서로를 이해하고 존중하는 자세, 각자의 영역에서 배우고자 하고 전문성을 갖춘 팀이라면 어떤 툴을 사용하더라도 성공적으로 프로덕트를 발전시켜나갈 수 있다는 결론에 도달했다.
참고자료
