[Jira] 크몽 개발팀에서 사용하는 지라 사용기
안녕하세요~ 지라 소프트웨어는 요새 개발팀 뿐 아니라 많은 스타트업에서 채택하여 사용하고 있는 대표적인 툴 중 하나입니다.
이번 글에서는 크몽 팀에서 사용하고 있는 지라 사용기에 대해 좋은 글이 있어 공유차 글을 작성하게 되었습니다.
먼저 원본 글은 아래 링크에서 참조 가능합니다.
크몽 개발팀 Jira 사용기
민첩한 조직 구조를 유연하게 유지하는 데 도움을 준 Jira 사용기
blog.kmong.com
그리고 아래의 글은 지라를 사용하면서 사용성을 더 극대화시킬 수 있는 방법에 대해 알려주고 있어서 우리 시스템에도 도입해보면 생산성이 처음에는 모르겠지만 추후에는 생산성이 향상될 수 있지 않을까 하는 기대감이 있네요 :)
크몽 개발팀 Jira 사용기 : 극대화 편
Jira를 이렇게까지 사용 가능한지 난 몰랐네?
medium.com
그럼 아래 글은 위의 두 링크에서 가져온 내용을 작성해보았으니 한 번 살펴보시면 되겠습니다. 도움 되시길 바라며 미리 크몽 개발팀에게 감사의 인사를 드립니다 :)
크몽 개발팀 지라 사용기
국내에서 가장 인기 있는 프리랜서 마켓 회사 개발팀의 민첩한 조직 구조를 유연하게 유지하는 데 도움을 준 Jira 사용기입니다.
크몽은 다양한 분야의 프리랜서 재능을 만나 볼 수 있는 서비스로 누적 회원 수 100만 명 이상, 거래건수 150만 건 이상의 국내 No.1 프리랜서 마켓 서비스입니다.
2017년부터 현재까지 급격한 성장으로 많은 기능을 빠르게 제공하기 위해서 개발팀도 30명가량으로 늘어났습니다. 개발 조직의 규모가 커지면서 효율적으로 조직이 운영될 수 있도록 많은 시도와 변화를 겪었습니다. 이 글에서는 2020년에 적용된 크몽 팀 구조와 관리를 어떻게 하고 있는지 소개하겠습니다.
크몽 개발팀 주요 요소.
Team
- 에자일 팀: 각 에자일 팀에는 주어진 Metric을 개선하기 위해 각 챕터원들이 모여 하나의 에자일 팀이 만들어지고 운영 인원들이 함께 포함되어 서비스를 개선하는 사명을 가진 팀입니다.
- 개발 팀: 인프라, 플랫폼, 데이터팀은 서비스 전반에 공통으로 필요한 업무를 진행하는 팀입니다.
Chapter
하나의 트라이브 내에서 웹 개발자, 디자이너와 같이 동일 기능을 수행하는 사람들의 조직입니다. 챕터는 정기적으로 모여 각 팀에서 발생한 문제나 지식, 산출물을 공유하고, 함께 업무 도구를 개발한다. 이를 통해 챕터는 동일 직무가 각 팀에 떨어져 있음으로써 발생되는 불필요한 업무 중복을 최소화하고, 전문성 향상, 업무 표준화 등 조직 역량을 증진시킬 수 있습니다.
보드 종류.
크몽 개발팀에서는 4개의 에자일팀과 3개의 플랫폼팀 5개 챕터는 각각 프로젝트를 생성해서 보드에 구성원들의 이슈가 나타나도록 설정되어 있습니다.
각 챕터의 인원들이 팀에 배정되어 있고 플랫폼 별로 배포를 하고 있습니다.
그리고 팀에서 진행하는 프로젝트, 챕터에서 진행하는 프로젝트, Co-work(외부 요청)에 들어오는 업무까지 각 챕터원은 다양한 업무를 하나의 스프린트에 진행하고 있습니다.
- Team
기본적으로 개발팀은 2주의 스프린트 단위로 작업을 진행하고 있습니다. 그래서 팀 보드는 스크럼 보드로 만들어 사용 중입니다. 팀 보드에는 팀원별로 진행 상황을 파악할 수 있도록 되어 있고 해당 보드뿐만 아니라 담당자로 지정된 모든 이슈를 확인할 수 있어서 팀원들이 어떤 업무를 하고 있는지 확인할 수 있습니다. - Chapter
챕터 보드는 백로그에 올라온 이슈를 처리하거나 각 에자일팀에서 진행 중인 내용을 공유할 수 있도록 칸반 보드로 이용 중입니다.
챕터에서 진행되는 업무는 챕터에서 만들어 여유가 되는 챕터원이 처리하고 있습니다. 챕터원은 맡게 된 이슈를 자신이 속한 팀의 스프린트로 등록하고 이슈가 완료되면 팀의 스프린트가 닫힐때 종료가 됩니다. - Release
각각의 개발팀에서 다른 기능들을 개발하고 있지만 배포는 각 플랫폼(챕터) 별로 이루어지기 때문에 Jira 보드에 있는 Release 기능을 사용할 수 없어서 크몽 개발팀에서는 Release 관리를 위한 Release 보드를 운영하고 있습니다. 각 챕터별로 버전별 릴리즈 티켓을 만들고 해당 버전에 나가는 이슈를 릴리즈 티켓에 링크를 걸어 관리합니다.
배포전 링크된 이슈들이 문제없이 동작하는지 확인하고 배포를 하게 되고 Confluence에 이슈를 링크걸고 자세한 내용을 기록합니다. - Co-work
운영팀에서 올라오는 버그나 요청사항을 받아 각 팀/챕터 별로 해당 이슈를 처리할 수 있는 Co-work 보드를 운영하고 있습니다.
운영팀에서 접수되어 백로그에 올라온 이슈는 관리자가 확인 후 해당되는 팀이나 챕터에 알려주면 담당자를 지정해서 이슈를 해결합니다.
이슈 통계 확인
“eazyBI” 확장 프로그램을 이용해서 각 스프린트의 SP 관리나 버그/요청사항 처리 상황을 Dashboard를 통해 관리하고 있습니다.
크몽 개발팀 지라 극대화편
크몽 마켓은 다양한 분야의 프리랜서 재능을 만나 볼 수 있는 서비스로 누적 거래 완료 건수 304만 건, 누적 회원 수 217만 명 이상의 국내 №1 프리랜서 마켓입니다.
크몽의 조직 문화는 ‘Work Happy’의 비전을 가지고 행복하고 즐겁게 일하는 것이며, 회사의 규모가 커진다고 해서 프로세스와 정책을 늘리기보다는 역량이 뛰어난 직원 스스로가 결정하는 문화를 만들어 가고 있습니다.
또한, 개발 조직의 규모가 점점 커지면서 효율적으로 조직이 운영될 수 있도록 많은 변화와 시도를 하였습니다. 그 중의 하나가 2020년 Jira를 도입한 것인데요. 이후에도 개발 조직은 더 커졌고 앞으로 더 커질 것을 예상하여 좀 더 유연하게 업무를 수행할 수 있도록 Jira의 사용성을 개선하게 되었습니다.
Jira 사용성 개선 계획
기존에도 Jira를 잘 사용하고 있었지만 좀 더 잘 사용해보고자 하는 의견이 많았습니다. 그래서 간단하게 Task를 정리하여 계획을 작성하였습니다.
- 현재 Jira 사용 분석
- 이슈 유형/워크플로우/이슈 화면 정리
- 이슈 유형/워크플로우/이슈 화면 재정의
- 보드 구성(메트릭)
- 리뷰 및 피드백 반영
- 모니터링 및 개선 활동
첫 번째, 무엇인가를 개선하기 위해서는 분석 활동이 매우 중요합니다. 무엇이 잘 되고 있는지 혹은 무엇이 부족한지를 판단하는 중요한 근거 자료를 발견할 수 있기 때문입니다.
현재 Jira를 어떻게 사용하고 있는지 Admin 권한을 받아서 살펴보았고 Jira 활용도가 높은 구성원의 인터뷰를 통해 평소 불편한 점과 좀 더 잘해보고자 하는 부분을 듣고 정리하였습니다. 이와 더불어 어떻게 구성하는 것이 좋을지 제 생각과 지식 또한 정리하고 공유하였습니다.
두 번째, 기존 Admin 페이지에는 사용하지 않는 일명 쓰레깃값들이 관리되고 있지 않았습니다. 앞으로 체계적인 관리를 위해서는 불필요한 값들을 선 정리하는 작업이 필요했습니다.
Jira의 강점 중의 하나는 삭제 시 유효성이 동작한다는 점으로 매우 논리적으로 구성되어 있기 때문에 그냥 삭제할 수 있는 데이터는 아무도 사용하지 않는다는 의미이기도 합니다.
세 번째, 인터뷰를 통해 얻은 결과물을 통해 이슈 유형/워크플로우/이슈 화면을 재정의합니다. 사용성 개선 활동의 가장 핵심적인 부분입니다.
네 번째, Jira를 사용하기 위한 속성값이 모두 정의되면 보드를 구성합니다. 보드 구성은 업무의 효율성을 극대화할 수 있도록 구성해야 합니다. Jira에서는 효율성을 최대화하기 위해 다양한 보드를 지원하는 것이 이런 연유에서입니다.
마지막으로 적용된 영역에 대해서 기존 구성원들에게 공유하고, 리뷰합니다. 그리고 피드백을 받아서 추가로 개선하거나 정해진 부분을 프리징합니다. 바로 모든 것을 포용할 수 없기 때문에 지속해서 모니터링하는 것도 개선 활동의 매우 중요한 부분입니다.
현재 Jira 사용 분석
#1 크몽팀의 조직 구성
크몽팀의 조직 구성은 이외에도 다른 부서가 있지만 현재 크몽 마켓을 개발하고 운영하는 부서의 모습입니다. 특이한 점은 목적 조직(Team)과 기능 조직(Chapter)으로 구분되어 있으면서 유연한 업무를 수행하기 위해 메트릭의 구조로 되어 있는 것인데요.
이번에 Jira 사용성을 높이고 더욱 유연하게 업무를 수행할 수 있도록 Jira 보드 구성에 크몽팀의 메트릭을 구성해 보았습니다.
#2 마인드맵 활용
Team과 Chapter 사이의 유기적인 관계를 이해하기 위해서 항상 마인드맵을 활용하였습니다. 평소 알마인드만 사용하다가 이번에 처음 검색해서 GitMind라는 걸 사용해 보았는데 테마도 많고 좋았습니다. 필요하시면 한 번 사용해 보시길 바랍니다.
가장 고민을 많이 했던 부분은 스크럼 보드와 칸반 보드의 구분입니다. 기존 사용하던 보드를 참고해서 스프린트 관리 여부를 확인 했습니다. Team은 스프린트 보드를 매우 잘 활용하고 있기 때문에 스크럼 보드로 구성하고, 좀 더 유연하게 업무를 수행하는 Chapter는 칸반 보드로 구성하기로 결정하였습니다.
마인드맵에서 추가적으로 확인 가능한 정보는 Operation Team에서 생성하는 VOC 이슈에 대한 각 Team 별, Chapter 별 업무에 대한 Co-work 노드를 확인할 수 있습니다.
#3 인터뷰
Jira 개선을 위해서 많은 분들이 다양한 의견을 주셨습니다. 이런 의견을 바탕으로 개선 방향성을 세우고, 세워진 방향성을 기준으로 Jira를 구성하게 됩니다.
이와 추가적으로 Jira의 사용성 개선을 위해 평소 알고 있던 지식과 고민하던 부분을 공유하여 인터뷰 시에 도움이 되는 정보를 정리하였습니다.
이슈 유형/워크플로우/이슈 화면 정리
기존에 Admin은 생성하고 삭제나 변경에 대한 관리가 되지 않았습니다. 새로운 이슈 유형이나 워크플로우, 그리고 이슈 화면을 생성하고 사용하기에는 매우 복잡한 상태였습니다.
대부분 Jira를 사용하는 기업의 Admin은 비슷할 거라 생각합니다. 생성과 변경만 하고 사용자 익명화와 같은 정리 작업을 하지 않기 때문입니다.
그래서 기존 사용하던 이슈 유형, 워크플로우, 이슈 화면을 Old Scheme로 구성하여 한 곳에 모아두는 작업을 하였습니다. 이렇게 작업할 때 좋은 점은 사용자들은 바뀐 것도 모르고 업무를 수행하는 데 아무런 영향이 없으면서 정리가 가능한 방법입니다.
사용하지 않거나 불필요한 항목을 삭제해야 하는 경우는 삭제 가능 여부를 판단하기 위해서 해당 이슈 유형이나 워크플로우를 직접 사용하는 구성원에게 개별 문의를 해야만 했습니다. 자칫 잘못 삭제하게 되면 현재 업무에 영향을 줄 수 있기 때문에 삭제 작업을 할 때는 꼭 현재 사용 중인지 미사용 중인지를 확인하고 삭제하시기 바랍니다.
이슈 유형/워크플로우/이슈 화면 재정의
#1 이슈 유형 재정의
이슈의 유형은 업무의 방식에 따라 직관적으로 확인할 수 있도록 재정의하였고, 이슈 유형만 보더라도 어떤 업무인지 알 수 있도록 하였습니다.
#2 워크플로우 재정의
이슈의 유형에 따라 워크플로우를 재정의하였고, 비슷한 워크플로우는 통합하여 사용할 수 있게 Scheme 작업을 하였습니다.
워크플로우 구성 시 하나 더 고민했던 점은 이슈를 Resolved 할 때(상태가 변경될 때) 필수 입력받도록 팝업을 띄우는 것이었습니다. 그래서 주요 스테이터스가 변경되는 시점에는 상태 변경에 대한 트리거(팝업)를 삽입하여 필수 입력을 받을 수 있도록 구성하였습니다.
필수 입력에 대한 선택은 내부적으로 꼭 입력되어야 하는 약속된 값이고, 향후 Jira Report나 Dashboard에서 의미 있는 데이터로 활용하기 위함입니다.
#3 이슈 화면 재정의
이슈 화면 재정의는 선택 사항입니다. 해도 좋고 안 해도 되지만 사용성을 높이기 위한 목적이라면 반드시 해야 합니다. 이슈 유형에 따라 보이는 카테고리를 조사하고 이슈 등록 시 필요한 카테고리만 보일 수 있도록 구성하는 것입니다.
그리고 입력 카테고리는 기본 입력과 옵션으로 구분하는 것이 좋습니다. 필수 입력에 대한 기본 입력만 설정하면 향후 이슈 수정 시 카테고리가 안 보일 수 있기 때문에 옵션에는 반드시 카테고리가 있어야 합니다. 이슈 등록 시에는 탭으로 보이게 구분할 수 있습니다.
보드 구성(메트릭)
‘프로젝트의 보드를 어떻게 구성해야 메트릭 형태로 구성할 수 있을까?’
이슈 유형을 재정의하고 워크플로우도 재정의하면서 보드 구성에 대한 고민을 지속해서 했습니다. 왜냐하면 크몽팀의 조직 구성이 메트릭 구조이기 때문에 프로젝트를 이동하지 않으면 나의 할 일(Backlog)이나 Co-work 티켓을 확인할 수 없기 때문인데요.
하지만 아주 간단한 방법으로 문제를 해결할 수 있었는데 그것은 바로 Jira 프로젝트 내의 보드 추가 기능을 통해서입니다.
먼저, 분석에서 확인된 보드의 유형에 따라 프로젝트를 생성합니다. 크몽팀은 스크럼 프로젝트 6개(Team), 칸반 프로젝트 6개(Chapter)를 생성하였습니다. 메트릭의 구조상 12개의 프로젝트 내에서 유연하게 업무를 수행할 수 있도록 구성할 방법이 필요했습니다.
그래서 Team 스크럼 프로젝트 내에 Chapter 칸반 보드를 추가하였습니다. 예를 들어 A Team 보드에는 6개의 Chapter 보드를 볼 수 있도록 추가하고, B Team 보드에도 6개의 Chapter 보드를 볼 수 있도록 추가한 것입니다.
이렇게 구성하기 위해서는 보드 내의 필터를 약간 수정 해야 합니다. 특히, 키 값과 같은 역할의 구분자를 사용해야 하는데 크몽팀의 경우 Team 명과 Chapter 명을 구분자로 사용하였습니다.
구분자를 해당 Team이나 Chapter의 구성원으로 해도 되지 않느냐? 는 질문을 받은 적이 있습니다. 물론 상관없습니다. 충분히 가능합니다. 하지만 사용자의 경우 들어오고 나가고의 변수가 작용하기 때문에 향후 관리에 대한 문제가 발생할 수 있는 점은 참고 바랍니다.
결과적으로 모든 Team 프로젝트에서는 Chapter 보드의 업무를 볼 수 있게 되었고, Chapter 보드에서는 Team 업무(Team의 구분 없이 자신이 해야 할 일)를 볼 수 있게 되었습니다. 별도의 프로젝트를 이동하지 않아도 유연하게 서로의 업무의 상태를 공유할 수 있게 되었습니다.
리뷰와 피드백을 받은 내용은 따로 언급하지 않겠습니다.
현재도 진행 중이고 앞으로도 많은 부분이 개선될 것이기 때문인데요. Jira를 메트릭 형태로 구성하는 것은 저에게도 큰 도전이었고, 잘 될지 안 될지 모르는 상황이었지만 믿고 적극적으로 피드백 주신 크몽팀이 있었기에 좋은 결과물이 나올 수 있던 것 같습니다.
추가로 현재 버전 관리에 대한 문제점이 발견되었습니다. 이는 Jira의 정책상 모순되는 부분이라 Admin 내에서 해결할 수 없습니다. 메트릭 구조상 Product Team에서 버전을 관리하는 것이 맞는다고 생각했는데 업무를 수행하다 보니 실질적으로 Chapter 내에서 빌드/배포를 수행하고 있었기 때문입니다.
그래서 이 부분은 현재 Jira Work Automation으로 문제를 해결한 상태이고 테스트를 진행하고 있습니다. 문제 해결에 대한 자세한 내용과 추가로 개선된 내용은 ‘응용 편’에서 찾아뵙도록 하겠습니다.
긴 글 읽어 주셔서 감사합니다.😊