시작하며
내가 Jira를 처음 만난건 약 5년 전 이었다. 당시 어느 GUI 디자인 에이젼시의 막내급 디자이너였던 나는, 모 자동차 그룹의 AVN 화면의 GUI 프로젝트에 참여하게 되었는데, 당시의 클라이언트의 그룹사에서 내부 간 또는 내부와 협력사 간의 프로젝트 협업과 일정 관리 등을 위해서 MCOLS라는 Jira 기반의 이슈 트레커와 AEM(Adobe Experience Manager)이라는 프로그램을 사용하고 있었다.
당시만 해도 Jira라는 이슈 트레커가 업계를 대표하는 프로그램인줄 몰랐고, 심지어는 클라이언트 그룹사 내부에서 자체적으로 제작한 내부 프로그램이라고 생각했다. 하지만 이후 퇴사를 하고 UIUX 디자이너를 준비하면서 Jira가 이슈 트레커 프로그램의 대표적인 케이스이고 매우 영향력이 큰 툴이라는걸 알게 되었다.
그때 만난 Jira와의 인연은 계속 이어져 다음 회사인 모 플랫폼 스타트업에서도 사용하게 되었고, PM/기획자가 된 미래에도 계속 이어질 것이라 예상한다.
(여기서 궁금한점, 모 자동차 그룹과 함께 사용했었던 MCOLS는 그 그룹에서 Jira 또는 Confluence를 커스터마이징해서 만든것인지 궁금하다. MCOLS를 검색했을 때 나오는 결과는 해당 그룹사의 채용 공고 등 그 그룹과 관련된 내용만 나오기 때문이다. Jira에 프로그램을 커스터마이징하는 기능이 있어 프로그램 이름도 바꾸고, 기능도 입맛에 바꿔서 사용할 수 있는지 궁금해졌다.)
오늘의 포스팅에서는 애자일의 12가지 원칙과 연결하여 협업과 이슈 트레커인 Jira의 주요 기능에 대해서 알아보도록 하겠다.
애자일의 12가지 원칙
먼저 애자일하게 일하는데에 12가지 원칙이 있다. 만약에 자신의 팀과 기업에 애자일 기법을 도입하고 싶다면, 다음의 원칙을 참고하여 기틀을 갖투는 것도 좋은 방법이다.
제1원칙: 초기부터 지속해서 고객 만족
우리의 최우선 순위는 가치(value) 있는 프로덕트를 초기부터 지속해서 제공(배포)함으로써 고객을 만족시키는 것입니다. 초기부터 프로덕트를 제공하는 것이 리스크(risk)도 감소하고 가치(value)가 증가합니다.
제2원칙: 요구사항 변경 수용
개발 후반부에 변화하는 요구사항의 수용을 환영합니다. 애자일(agile) 프로세스는 변화를 수용하며 고객의 경쟁력을 돕습니다. 쏜 곳으로 정확히 날아가는 것도 중요하지만, 움직이는 사물(고객/시장)을 맞추기 위해서는 변화에 대응할 수 있어야 합니다.
제3원칙: 짧은 배포 간격
프로덕트를 짧은 주기(2주에서 2달까지)로 동작하는 프로덕트를 배포하되 더 짧은 주기를 선호합니다.
여러 개발자가 개발한 프로덕트를 초기부터 조금씩 통합/검증하는 것이 한 번에 통합/검증보다 낫습니다. 예측한 요구사항(계약)을 따르기보다는, 변화하는 고객/시장에 따라 요구사항도 변해야 합니다. 만약 상호 검수를 위해 요구사항만 중시한다면 Output은 만족시키겠지만 Outcome은 만족시킬 수 없습니다. 프로젝트 초반 보다 팀원의 지식은 증가하고 그사이에 고객/시장의 눈높이도 증가합니다.
제4원칙: 함께 일하기
비즈니스 담당자와 개발자는 프로덕트 전체 기간 매일 함께 일해야 합니다. 비즈니스 가치가 있는 프로덕트를 개발하기 위해서는 비즈니스 담당자가 원하는 프로덕트를 함께 개발해야 합니다.
제5원칙: 동기 부여된 팀원들로 프로덕트팀 만들기
동기가 부여된 개인을 중심으로 프로덕트를 구축합니다. 그들에게 필요한 환경과 지원을 제공하고 업무를 완수할 것을 믿습니다. 구성된 팀의 목표나 동기가 서로 다르다면 성공적인 결과를 내기 어렵습니다.
제6원칙: 얼굴 보고 대화하기
개발팀에 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다. 얼굴 보고 대화하는 것이 가장 효과적이고 효율적인 커뮤니케이션입니다. 그냥 얼굴 보고 이야기하면 될 것을 서로 등지고 문서로 전달하려고 하지 않나요?
제7원칙: 동작하는 프로덕트로 진도 측정
작동하는 프로덕트가 진척의 주요 척도입니다. 전체 100%의 모든 기능을 80% 수준으로 완성해도 진척도은 80%이고, 80%의 기능이 100% 완성되어도 진척도는 80%입니다. 실행해보고 배우고 개선하기 위해서 애자일은 후자를 선호합니다.
제8원칙: 지속 가능한 개발 속도 유지
애자일 프로세스는 지속 가능한 개발을 장려합니다. 스폰서, 개발자 및 사용자는 일정하게 일정한 속도를 유지할 수 있어야 합니다. 애자일은 프로젝트 초반부터 결과물을 내야 하므로 초반에 더 힘이 듭니다. 하지만 지속적인 성과를 내기에 효과적입니다.
제9원칙: 좋은 기술, 설계에 관심
우수한 기술과 우수한 디자인에 대한 지속적인 관심은 민첩성(agility)을 향상합니다. 바빠서 기술적 개선을 하지 못한다면, 항상 바쁘기 때문에 영원히 뒤처집니다.
제10원칙: 단순성
단순성(수행되지 않은 작업량을 최대화하는 기술)은 필수적입니다. 단순할수록, 불량을 줄일수록, 미사용 기능을 구현 안 할수록 효과적입니다. 중간에서 추가 가치(value)를 주지 않는 태스크(task)는 단순 취합이고 낭비이며 허들이 될 수 있습니다.
제11원칙: 자기 조직화 팀
최고의 아키텍처, 요구 사항 및 디자인은 자기 조직화 팀(Self-Organization Team)에서 나옵니다. 의사결정권자가 팀의 밖에 있다면 팀원들은 효과적으로 빠른 의사결정 할 수 없습니다. 예를 들면, 의사결정권자 없이 실무자끼리 회의를 해봐야 결정할 수 있는 것은 없습니다. ‘그분이 만족할까?’, ‘이런 결정 내리면 혼나지 않을까?’, ‘우리 팀에서는 좋아할까?’, ‘그 팀에서 허락해줄까?’로 고민만 합니다.
제12원칙: 정기적으로 효율성 재고
팀은 정기적으로보다 효과적인 방법을 적용해보고, 그에 따라 행동을 조율하고 조정합니다. 스크럼(scrum)에서는 스프린트(sprint)가 끝나는 날마다 회고(retrospective)를 수행합니다.
나는 축구 팀과 IT 기업은 같은 문화, 개념이라고 생각한다. 특히 작년, 아마존 프라임에서 공개한 아스날 다큐멘터리 ‘All or Nothing’를 보고 나서 확실하게 느꼈다. 이 부분은 PMB가 끝난 뒤, 따로 포스팅 할 예정이다.
애자일 원칙으로 알아보는 Jira
지라(Jira)는 아틀라시안(Atlassian)이 개발한 사유 이슈 추적 제품이다. 버그 추적, 이슈 추적, 프로젝트 관리 기능을 제공하는 소프트웨어이며, 다음 링크를 통해 계정을 생성하고 서비스를 이용할 수 있다. 링크
이후 지라에서 알려주는 매뉴얼대로 움직이다 보면, 간편하게 협업 환경을 만들 수 있다.
제 2원칙 : 요구사항 변경 수용
Jira는 상황에 따라 Task를 유연하게 대처할 수 있다. 업무의 진척도에 따라 할 일/진행 중/완료 단계로 변경 할 수 있으며, 이슈에 따라 다시 변경하거나, 우선 순위를 바꿔 설정 할 수 있다.
제 3원칙 : 짧은 배포 간격
Jira는 1주, 2주, 4주 등 스프린트 기간을 구체적으로 설정할 수 있다. 업무의 중요도와 일정에 따라 스프린트 기간을 설정할 수 있으며, 스프린트 종료 후 미완성인 부분은 그대로 다시 시작해 볼 수 있다.
제 4원칙 : 함께 일하기
Jira의 최대 강점이라 생각하는 부분, 바로 협업에 극대화 되어 있다는 점이다. 실시간으로 이해 관계자들을 초대하여 함께 작업의 진행도와 이슈 현황을 살펴볼 수 있으며, 각 종 다양한 툴과의 연계로 협업의 범위를 넓혀 사용할 수 있다.
마무리하며
이렇듯 Jira는 최상의 애자일 환경을 구축하여 일할 수 있도록 도와주는 최적의 협업 툴&이슈 트레커이다. 나 역시도 Jira로 일은 많이 해보았지만, 초기 환경 세팅과 구축까지는 직접 해보지 않았기 때문에 앞으로 PM과 기획자를 준비하면서 틈틈히 배워 둘 필요성을 느꼈다.
이지훈 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
