Jira에서 찾아보는 애자일의 12원칙
[코드스테이츠 PMB 10기] 애자일의 12가지 원칙
Jira 속에는
어떤 원칙이 숨어있을까?
1. 애자일의 12원칙
Agile은 변화하는 고객과 시장의 니즈에 빠르게 대처하기 위한 방법으로 단순히 빠르게 일한다고 해서 '애자일하게 일하고 있다.'라고 말할 수 없다. 그렇다면 애자일하게 일하기 위해서는 어떤 원칙을 지켜야 하는 것일까?
제 1원칙: 초기부터 지속적으로 고객 만족
"our highest priority is to satisfy the customer through early and continuous delivery of valuable software".
우리의 최우선 순위는 가치(value) 있는 소프트웨어를 초기부터 지속적으로 제공함으로써 고객을 만족시키는 것이다. 초기부터 개발물을 제공해야 리스크를 감소시키면서 가치를 증가시킬 수 있는 방법이다.
제 2원칙: 요구사항 변경 수용
"welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage"
개발 후반부에 변화하는 요구 사항의 수용을 환영한다. Agile 프로세스는 변화를 수용하며 고객의 경쟁력을 돕는다. 목표한 바를 달성하는 것은 중요하지만, 지속적으로 변화하는 고객 또는 사물에 맞추기 위해서는 변화에 대응할 수 있어야 함을 의미한다.
제 3원칙: 짧은 배포 간격
"deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale"
소프트웨어를 짧은 주기(2주에서 2달까지)로 동작하는 소프트웨어를 배포하되 더 짧은 주기를 선호합니다. 프로젝트 초반에 비하여 팀원들의 지식은 지속적으로 성장하고 그 사이에 고객과 시장의 욕구도 높아져간다. 짧은 주기를 설정하면 지속적으로 변화하는 고객과 시장의 요구에 맞출 수 있다.
제 4원칙: 함께 일하기
"business people and developers must work together daily throughout the project"
비즈니스 담당자와 개발자는 프로젝트 전체 기간 동안 매일 함께 일해야 한다. 비즈니스 가치가 있는 소프트웨어를 개발하기 위해서는 비즈니스 담당자가 원하는 소프트웨어를 함께 개발해야 함을 의미한다.
제 5원칙: 동기 부여된 팀원들로 프로젝트팀 만들기
"build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done"
동기가 부여된 개인들 중심으로 프로젝트를 구축한다. 그들에게 필요한 환경과 지원을 제공하고 업무를 완수할 것을 믿는다. 만일, 구성된 팀의 목표나 동기가 서로 다르다면 동상이몽과 다름없기 때문에 성공적인 결과를 내기 어렵다.
제 6원칙: 얼굴 보고 대화하기
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
개발 팀에 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화이다.
제 7원칙: 동작되는 소프트웨어로 진도 측정
Working Software is the Primary Measure of Progress
작동하는 소프트웨어가 진척의 주요 척도이다. 전체 100%의 모든 기능을 80% 수준으로 완성해도 진척률은 80%이고, 80%의 기능이 100% 완성되어도 진척률은 80%이다. 실행해보고 배우고 개선하기 위해서 Agile은 후자를 선호한다.
제 8원칙: 지속 가능한 개발 속도 유지
"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
Agile 프로세스는 지속 가능한 개발을 장려한다. 스폰서, 개발자 및 사용자는 일정하게 일정한 속도를 유지할 수 있어야 한다. Agile은 프로젝트 초반부터 결과물을 내야 하므로 초반에 더 힘이 들지만 지속적인 성과를 내기에 효과적이다.
제 9원칙: 좋은 기술, 설계에 관심
"continuous attention to technical excellence and good design enhances agility"
우수한 기술과 우수한 디자인에 대한 지속적인 관심은 민첩성(agility)을 향상한다. 바빠서 기술적 개선을 하지 못한다면, 항상 바쁘기 때문에 영원히 뒤처질 것이다.
제 10원칙: 단순성
"Simplicity–the art of maximizing the amount of work not done–is essential"
단순성(수행되지 않은 작업량을 최대화하는 기술)은 필수적이다. 즉, 단순할수록, 불량을 줄일수록, 미사용 기능을 구현 안 할수록 효과적이란 뜻이다. 중간에서 추가 Value를 주지 않는 Task는 단순 취합이고 낭비이며 허들이 될 수 있다.
제 11원칙: 자기 조직화 팀
"the best architectures, requirements, and designs emerge from self-organizing teams"
최고의 아키텍처, 요구 사항 및 디자인은 자기 조직화 팀(Self-Organization Team)에서 나옵니다. 의사결정권자가 팀의 밖에 있다면 팀원들은 효과적으로 빠른 의사결정할 수 없다. 만일 의사결정권자 없이 실무자들로만 회의를 하게 된다면 '과연 그분이 만족할까?'의 질문에 사로잡힐 뿐이다.
제 12원칙: 정기적으로 효율성 제고
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly"
팀은 정기적으로 보다 효과적인 방법을 적용해보고, 그에 따라 행동을 조율하고 조정한다. Scrum에서는 Sprint가 끝나는 날마다 회고(Retrospective)를 수행합니다.
2. 애자일 툴 (Agile Tools)
Week8에서는 지속적으로 애자일에 대해서 학습해왔다. 하지만 애자일의 방법에는 스크럼도 있고, 칸반도 있는 마당에 어떻게 하면 프로젝트를 효율적으로 관리할 수 있을까?
아마 이 질문은 모든 사람들이 지속적으로 고민을 해왔던 것일테다. 왜냐하면 애자일은 명실상부 인기있는 프로젝트 관리방법이기 때문이다. 그리고 애자일 프로세스를 채택한 많은 팀들은 자신들의 프로젝트 진행을 최대화하기 위해 올바른 애자일 도구를 사용하고자 한다.
그 도구들에는 수많은 것들이 있지만, 이번 포스팅에서는 대표적으로 아틀라시안 지라(Atlassian Jira)에 대해 알아보고자 한다.
Hi, Jira
'최고의 애자일 툴' 이라고 구글에 검색했을 때 Jira가 포함되지 않은 포스팅은 매우 드물다. 그 정도로 Jira는 애자일 툴 중 가장 대표적으로 쓰이는 도구이다.
실제로 많은 JD를 확인해봤을 때도, 애자일하게 일하는 조직이라면 대부분 Jira의 사용 경험을 묻는다. 일례로, 네오플의 던파모바일 기술/개발 PM의 JD를 가져와봤다.
그렇다면 Jira는 도대체 어떤 툴이길래 이렇게 인기있는 걸까?
Jira는 본래 버그 트래킹을 위해 생성되었던 툴이지만, 현재는 강력한 작업 관리 도구가 되었다. 특히 애자일 소프트웨어 개발 팀을 대상으로 하며 커스텀이 가능한 워크플로(workflow)를 통해 모든 종류의 팀에 유용할 수 있다. Jira를 설명하는 글을 읽어보면 놀랍게도 처음에 좀 복잡할 수 있다는 점을 제외하고는 단점이 없다고 언급되었다.
오히려 애자일 및 소프트웨어 개발을 하기 위해서는 가장 잘 정립된 소프트웨어이며, Premium을 사용하면 조직 내 여러 팀의 프로젝트를 추적할 수 있다고 한다. 그에 더해 specialized된 스크럼 기능과 팀 협업 및 커뮤니케이션을 촉진하는 채팅 기능도 포함되어 있다.
쿠키런 : 오븐브레이크의
Jira 도입기
Jira에 대해 설명하는 글을 읽고서 바로 든 의문점은 '도대체 얼마나 어렵길래?'였다. 그래서 데브시스터즈에서 Jira를 도입하는 과정에서 느낀 감상을 작성한 포스팅이 있어 이를 참고해보고자 한다. (참고)
쿠키런 : 오븐브레이크의 QA팀은 이슈(Issue)를 추적하는 일이 매우 중요하다. '탄생(생성)부터 죽음(완료)까지 이슈의 생애를 각종 정보들을 통해 지켜봄으로서 이들의 처리가 원활하도록 관리해야 합니다.'라고 서술해놓으셨는데, 이는 업데이트를 할 때마다 QA가 진행이 되고 그에 따라 발생할 수 있는 여러 이슈들을 지속적으로 관리해야 원활하게 서비스를 운영할 수 있기 때문이 아닐까 추측해보았다.
그래서 이들은 좀 더 수월한 Issue Tracking을 위해 BTS(Bug Tracking System)을 도입하고자 하였는데, 그들이 이전에 사용하던 구글 스프레드시트와 트렐로(Trello)에서 불만족을 느꼈기 때문이다.
아찔하다고 적어주셨는데.. 정말 아찔하다.. (출처. DevTECH 기술블로그)구글 스프레드시트의 경우 이슈를 추적관리하는 것보다 시트의 내용을 정리하고 수동으로 최적화하는 작업에 더 시간이 쏟아졌다고 한다. 말 그대로 '일을 하기 위한 일'이 되어버린 셈. 그래서 처음에는 트렐로로 넘어가신 듯 하다.
초창기, 팀의 규모가 작았을 때에는 트렐로가 가볍게 사용할 수 있으면서도 이슈들의 상태를 잘 관리할 수 있었기 때문에 편했다고 한다. 무엇보다 무료라서 비용의 부담이 없었다는 점이 좋았던 듯 하다.
기능상 제한이 많았던 트렐로 (출처. DevTECH 기술블로그)하지만 무료였기 때문에 여러 파일들을 올릴 때는 용량 제한이 있었고, 경우에 따라 인코딩 작업을 했는데 그렇게 하니 이후 파일을 실행할 때 저화질로 보아야 하는 점이 불편했다고 한다. 거기다 이슈 검색 기능이 좋지 않아 특정 이슈 카드를 찾기 힘들었으며, 버전 단위로도 이슈를 확인하기 어려운 점이 가장 큰 불편성이라고 꼽았다.
트렐로에서까지 불편성을 느끼면서 드디어 QA팀은 Jira로 옮겨가게 되었다. 앞서 Jira에 관해 설명할 때도 말했지만, 여러 기능들이 있었기 때문에 효율적으로 사용할 수 있었다고 한다. 무엇보다도 '편리하고 정확한 검색(추적)'과 '버전별 이슈 관리(관리)'의 니즈를 충족시켜 준 점이 가장 큰 포인트라 서술되었다.
하지만 Jira를 사용하면서 불편한 점도 있었는데, 이는 앞서 이야기한 것처럼 '복잡하다'였다. Jira는 사용자의 숙련도에 따라서 효율성이 천차만별이라며 초기 환경 설정이 매우 중요하다고 한다. 만일 초기 설정이 어렵다면 오히려 간단하게 사용할 수 있는 다른 서비스를 이용하는 것이 더 효과적일지도 모른다고 작성되었다.
도대체 초기 설정을 하는 게 얼마나 어렵길래 이렇게 작성한 것일까?(..) 그래서 이번에는 실제로 Jira를 사용해보면서 어떤 원리가 숨어있는지 살펴보고자 한다.
3. Jira 속 12원칙 찾기
사실 나는 Jira를 사용해보는 것이 처음이 아닌데, 그 이유는 부트캠프를 수강하기 전 개발PM으로 지원을 해보고 싶어 프로젝트를 Jira로 관리해본 적이 있기 때문이다. 비록 Jira의 기능이 어려워서 거의 공모전 막바지에 칸반 보드와 이슈 트래킹밖에 이용하지 못했지만 그래도 이를 기반으로 오늘 포스팅을 작성해볼까 한다.
제 4원칙:
함께 일하기
Jira에는 로드맵 기능이 있어 모든 업무의 진척도가 투명하게 공유되며, 특히 비즈니스 담당자는 스마트 필터를 통해 모든 개발자들의 로드맵을 구체적으로 확인할 수 있다. 이는 곧 비즈니스 담당자가 매 스프린트 회의마다 참석하지 않는다 하더라도 지속적으로 개발 현황을 공유해줄 수 있을 것이다.
제 3원칙:
짧은 배포 간격
처음 스프린트를 설정할 때, 기간을 1주에서 4주 사이로 지정할 수 있다. 해당 백로그는 공모전이 시작된지 한 중간쯤되었을 때 main page/success page/fail page에 동적인 요소를 추가하고자 설정한 task들이다. 이를 Jira로 다시 한번 설정해보았다.
Jira를 사용했을 때 어떤 task들이 완료되었는지 바로 확인할 수가 있고, 거기다 스프린트 각 기간에 맞춰 소프트웨어를 배포할 수 있었기 때문에 교수님께 피드백 받기 좋았던 기억이 난다.
제 5원칙:
동기 부여된 팀원들로 프로젝트팀 만들기
백로그를 살펴보면 이번 프로젝트에 함께 참여할 여러 팀원들을 초대할 수가 있다. 그에 따라 백로그를 할당할 수도 있는데, 내 아이콘을 클릭하면 나의 이슈들만 나오고 아닐 때는 모두의 이슈를 확인할 수 있다.
해당 프로젝트를 진행할 당시, 나는 front-end를 주로 맡고 친구는 object detection 부분을 수정했기 때문에 위와 같이 백로그를 나눌 수 있다.
제 7원칙:
동작되는 소프트웨어로 진도 측정
Jira에는 다양한 대시보드를 활용하여 개발 진척도를 확인할 수 있다. 총 15개의 대시보드 가젯이 있으며 각각 무엇을 추적하고 싶은지에 따라 다르게 선택해야 한다. 해당 기능은 사용할 당시에는 쓰지 않았던 기능이라 내 프로젝트오 관련해서는 정보가 없지만, 개발 진척도를 추적하는데에 매우 유용할 것이라 생각이 든다.
Jira guide에 따르면 스크럼 팀에게는 총 4가지를 추천하고 칸반 팀에게는 2가지를 추천하고 있는데, 이에 대해 조금 알아보고자 한다.
For. Scurm team
Jira에는 위의 4가지 추적 데이터로 스프린트의 회고를 잘할 수 있도록 돕는다.
스프린트 리포트 (Sprint report) : 각 스프린트에서 완료된 작업 또는 백로그의 작업을 확인하여 팀의 작업 할당량이 적절한 지를 파악할 수 있다.
번다운 차트 (Burndown chart) : 남아있는 총 작업량을 트래킹하고 스프린트 목표가 달성 가능한지 예상할 수 있다. 해당 차트를 이용하여 진행 상황을 관리할 수 있다.
릴리즈 번다운 (Release Burndown) : 특정 버전의 예상 릴리즈 날짜를 트래킹하여 작업이 지체되는 경우 조치를 취할 수 있다.
속도 차트 (Velocity chart) : 스프린트 간에 완료된 작업량의 속도를 측정할 수 있다. 해당 차트를 이용하여 팀의 작업 속도를 파악하고 이후 팀이 현실적으로 처리할 수 있을 정도의 작업량을 추정할 수 있다.
For. Kanban Team
칸반 팀은 위의 두 대시보드를 활용하여 향후 성과를 더 효과적으로 예측하고 병목현상을 파악할 수 있도록 돕는다.
누적 흐름 다이어그램 (Cumulative flow diagram) : 지정된 상태별로 증가한 이슈 개수를 확인하여 병목 요인을 쉽게 찾아낼 수 있다.
컨트롤 차트 (Control chart) : 프로덕트, 버전 또는 스프린트에 대한 주기 및 리드 타임을 확인하여 향수 성능을 파악할 수 있다.
이상으로 Jira의 feature을 기반으로 하여 어떤 애자일 원칙을 찾을 수 있을지 알아보았다. 그리고 이번 포스팅을 하면서 느낀 점은 당시 한창 프로젝트를 하던 당시 Jira를 사용해보겠다고 혼자 고군분투했었는데, 그럼에도 Jira의 기능들 중 0.1%도 못 썼다는 사실을 새삼 깨달았다.(..;)
만일 당시에 정말 쿠키런 오븐브레이크 팀처럼 팀원들과 초기환경을 설정하고 함께 사용해보고자 노력했으면 좀 다른 결과가 나왔을까하는 아쉬움도 좀 생긴다. 그래도 이번 포스팅을 통해 Jira가 어떤 기능을 서비스하고 있는지에 대해서는 좀 더 확실히 알 수 있었다.
이후 개발/기술 PM으로도 꿈을 가지고 있는 만큼, Jira와 Confluence에 한해서는 무엇이든 바로 답할 수 있도록 여기저기 기능들을 많이 건들여봐야겠다!
참고자료.
