티스토리 뷰

HMR 스타트업 플레이팅의 개발자로 입사한 뒤 JIRA를 도입하면서 JIRA의 활용 방안을 연구해서 개인적으로 작성한 6개월 전의 글입니다.

이제 개발팀 내부적으로 이 문서를 갱신할 때가 되었고, 아직 부족한 점이 많은 가이드지만 JIRA를 사용하려하는 많은 팀에게 도움이 될 수도 있겠다는 생각에 공유합니다.

Contributor: Plating Development Team (Yowu, Journey, Alex, Jude)

Agile Scrum와 JIRA에 대한 연구 문서

  • 우리는 쓴다. 무엇을. 지라를. 왜?. 늘어나는 개발 업무. 제한된 시간과 인원. 개발 업무 효율화

현 상황

  • 개발팀 업무 진행
    1. 스프린트 회의 때 백로그에서 각자 할 일을 골라 포커쳐서 스토리 포인트를 결정하고 그 주의 스프린트를 만든다.
      • 이 때 스토리 포인트 단위는 1시간이며, 1일 8시간 근무 기준으로 단위 스프린트의 포인트 총 합이 40을 넘지 않도록 한다.
    2. 각자의 스프린트 테스크를 열심히 작업(하려고 한다.)
    3. 예정에 없던 갑자기 밀려드는 업무 처리. 으앙
      • 예) 프로세스를 거치지 않은 타 팀의 업무/개발요청,
    4. 다음주 스프린트 때 확인해보면 본래 계획의 반 정도 밖에 하지 못했다.
    5. 딜레이. 고통. 눈물

JIRA와 함께 우리가 나아가야할 방향

JIRA의 참트루 목적

  • 팀의 테스크를 좀 더 효율적으로 관리하고, 트래킹한다.
  • 좀 더 효율적인 스프린트 리포팅 도구를 사용하여 스크럼 마스터와 리더는 팀원의 부하와 스프린트를 체크하며 점진적으로 프로세스를 개선하여 생산성을 높인다.

스프린트

  1. 스크럼 마스터나 마케팅, 운영, 개발 등 각 팀원이 필요한 기능을 User Story 형식으로 JIRA Backlog에 기록한다. 이 때, 상세한 기술이나 개발 내용, 기획이 반드시 나올 필요는 없으며 차후에 Comment로 기록하거나 Sub-task로 만든다.
    • 예-1 : 사용자로서, 새로운 하이브리드앱 어플리케이션이 필요하다고 생각합니다
    • 예-2 : 운영팀으로서, 조건에 맞는 여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템이 필요합니다.
    • 예-3 : 개발자로서, 개발 프로세스 효율화의 필요성을 강하게 느낍니다.
    • 예-4 : 사용자로서, 안드로이드 어플리케이션을 사용하다보면 자꾸 튕깁니다.
    • 예-5 : 마케팅팀으로서, 까먹은 급한 쿠폰 발급건 건이 생각났습니다. 내일까지 해야되요 ㅜㅜ
    • 이 경우 예-1큰틀(Epic), 예-2예-3는 이슈 타입 스토리(Story)이며, 예-4버그(Bug), 예-5긴급(Hotfix)이다.
    • Scrum User Story에 따라, Backlog에 이슈 등록시 ...으로서 를 반드시 기재하도록 한다. 해당 이슈의 출처와 목적을 확인하기 위함이다.
  2. 스프린트 회의 시 기존 스프린트에 대한 리뷰를 하고 스프린트를 완료시킨다. 이 때 완료하지 못한 이슈가 있다면 다시 Backlog로 돌아가게 된다.
    • 스프린트 리뷰 시 Keep, Problem, Actions는 Confluence 회고록에 기록한다.
  3. 새로운 스프린트를 시작하면서, 먼저 토의를 통해 이슈의 백로그의 우선순위(Priority)를 결정한다. 그 후 각자 백로그에서 할 일을 선택해 스프린트에 넣는다. 이 때, 담당자를 지정하며 포커쳐서 결정된 Story Point에 설정한다.
    • 현재 Story Point는 해당 이슈를 해결하는데 걸리는 예상 시간을 사용한다.
      • 1 Point = 1 Hour / 1 Day = 8 Hours / 1 Week = 5 Days / Story Point Max = 40
    • 만약 해당 이슈가 Sub Task가 발생할 것으로 추측되는 이슈라면 원본 이슈에는 예상 작업 시간(Estimated time)을 기재하지 않는다. 이유는 시간 예측시 Sub Task의 시간까지 모두 합산되기 때문.
    • Sub Task가 발생하지 않을 것으로 추측되는 이슈라면 예상 작업 시간Story Point와 같게 설정해준다. 만약 예상과 달리 차후에 Sub Task가 발생하더라도 변경할 수 있다.
  4. 예-5와 같은 긴급(Hotfix) 이슈 발생 시, 해당 이슈의 타당성을 팀원, 스크럼 마스터와 토의 후 담당자를 정하고 진행 여부를 결정한다. 진행할 시 해당 이슈를 스프린트에 올리고 다음 스프린트 회의 때 리뷰하도록 한다.
    • 물론 담당자의 재량이 충분히 발휘될 수 있는 이슈 타입이므로, 담당자 판단하에 간단하게 끝나는 일의 경우 이슈 등록 후 토의 없이 즉시 처리할 수도 있고, 펜딩할 수도 있다.
  5. 스프린트 회의가 성공적으로 끝나고, 스프린트가 생성되었다면 이제 스크럼 보드에 해당 스프린트의 이슈들이 나타난다. 일해라 담당자.

스크럼

  1. 스크럼 회의은 매일 10분~15분 가량 진행한다.
    • 스크럼 회의 시작 전 Confluence에 해당일에 대한 간단한 회의록을 남길 준비를 한다.
  2. 각자의 현재 스프린트에서의 테스크 진행 상황을 간단하게 팀원과 공유한다.
    • 스크럼 회의시 Under Review 상태의 이슈를 Resolved할 것인지 Closed 할 것인지 결정한다.
  3. 스크럼 회의에서 다음과 같은 내용을 공유하면 된다.
    • 어제 처리한 테스크
    • 현재 처리하고 있는 테스크
    • 현재 테스크 다음에 처리할 테스크
    • 테스크를 처리하는데 있어 발생한 이슈. 원인. 이유. 해결 방안
    • 발생한 긴급(Hotfix) 이슈에 대한 내용 공유
    • 등등등
  4. 서로 오늘 뭘 할지 공유가 되었고, 각자의 발언이 끝났으면 회의를 마치고 회의록을 업로드한다.
  5. 이제 자리로 돌아가 일하면 된다.

기타

이슈 할당 (Assign), 시간 추정 순서

  • 개발자에게 이슈를 할당과 시간 추정 할 때, 연결되어 있는 이슈(동일 Epic)들을 우선적으로 할당한다.
  • 연결된 이슈가 없으면 동일한 플랫폼(iOS/Android/Backend/Web)별로 나누어서 할당을 진행한다.
  • 한 Epic내의 이슈를 이어져서 할당함으로써 이슈에대한 전체적인 이해도 증가
  • 반복 설명해야하는 상황이 줄어들어 스프린트 회의시간을 절약할 수 있음.

JIRA 사용

프로젝트

프로젝트 종류

  • AWS Infrastructure (AWS)
    • 백엔드와 관련된 이슈들이 속한 프로젝트다. AWS Infrastructure 라는 이름이지만 플레이팅 주로 AWS 서비스를 백엔드로 사용하기에 붙은 이름이지 반드시 AWS와 관련된 백엔드 이슈는 아니고, 기타 백엔드 이슈도 포함한다.
  • ERP Systems (ERP)
    • 사내에서 사용하는 ERP 시스템에 관한 프로젝트다.
  • Mobile Applications (APP)
    • Android와 iOS와 같은 모바일 디바이스 어플리케이션과 관련된 이슈다.
  • Web Applications (WEB)
    • Landing Web Page 등 주로 외부에 제공되는 웹 기반 서비스과 관련된 이슈다.
  • PLATING Development (PL)
    • R&D 이슈와 위 사항에 속하지 않은 이슈들이 속한다. 어떻게 보면 나머지 프로젝트들의 상위 프로젝트라고 볼 수도 있다.
      • R&D (연구), 사원 교육, 세미나, 비즈니스 처리 (ex. 쿠폰 발급 등)
  • Toy Projects (TOY)
    • 실험적이나 여가 중 개발하게되는 개인 장난감 프로젝트
부록. 프로젝트간 서브 테스크 할당에 대해
  • 기본적으로 JIRA는 Sub-Task의 Cross-Project 할당이 허용되지 않는다. #
  • 하시만 실제 User Story를 기반으로 개발작업을 하다보면 하나의 프로젝트 내에서 해당 이슈를 처리할 수 없는 경우가 있다.
    • 예-2 : 운영팀으로서, 조건에 맞는 여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템이 필요합니다. (Story)
      • 예-2.1 : 서버 사이드 구조 설계, 명세화 (Sub-task, AWS)
      • 예-2.2 : 쿠폰 컨트롤러 작성(Sub-task, AWS)
      • 예-2.3 : 메인 페이지 프론트 작업(Sub-task, ERP)
  • 위 예제의 경우 하나의 User Story에서 각각 AWSERP에 걸친 Sub-task가 발생함을 알 수 있다.
  • 이러한 Cross-Project 상황을 해결하는 2가지 방법을 제안한다.
    1. 예-2의 User Story는 '여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템'에 관한 내용이으로 근본적으로는 ERP 프로젝트에 속한다. 우선 해당 Story 이슈를 ERP에 만들고, AWS에 관련 이슈를 만들면서 연결을 만든다.
      • ERP-1 : 운영팀으로서, 조건에 맞는 여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템이 필요합니다. (담당자 : 요우)
        • 연결 : causes AWS-1
      • AWS-1 : 요우(혹은 개발팀)으로서, 쿠폰 발급 시스템에 필요한 서버 사이드 작업이 필요합니다.
        • 연결 : is caused by ERP-1
    2. 예-2의 User Story는 여러 부분에 있어 개발이 필요하므로, 프로젝트를 특정 짓지 않고 PL에 위치시키고, 개발이 필요한 프로젝트에서 이슈를 생성한뒤 연결을 만든다.
      • PL-1 : 운영팀으로서, 조건에 맞는 여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템이 필요합니다. (담당자 : 요우)
        • 연결 : causes AWS-1, ERP-1
      • AWS-1 : 요우(혹은 개발팀)으로서, 쿠폰 발급 시스템에 필요한 서버 사이드 작업이 필요합니다.
        • 연결 : is caused by PL-1
      • ERP-1 : 요우(혹은 개발팀)으로서, 쿠폰 발급 시스템에 필요한 프론트 작업이 필요합니다.
        • 연결 : is caused by PL-1
  • 개인적으로는 1번의 방법이 이슈 갯수와 추적이 있어 깔끔하게 관리됨으로 추천

버저닝 (Versioning)

  • 프로젝트별 버저닝에 관한 내용. 내용 확정 후 작성함.

워크 플로우

  • 현재 JIRA Default Workflow를 따른다.
  • Open, In Progress, Under Review, Resolved, Closed, Reponed의 6단계다.
  • 최초에 이슈를 백로그에 등록할 시 Open 상태가 된다.
  • 스프린트 회의를 통해 우선순위와 담당자, Story Point, 추정 시간 등이 할당 된 뒤 담당자가 작업을 시작하면 In Progess 상태가 된다. 이 때 반드시 본인이 작업한 시간을 테스크 작업 기록에 남기도록 한다.
  • 이슈가 해결되면 Under Reivew 상태로 해당 이슈를 전이시킨다.
  • 이슈를 완전히 Resolve하거나 Close 것은 스크럼 회의를 진행하면서 진행한다.
  • 종료된 이슈를 다시 Open해야할 경우 Reopen으로 보내면 된다.

이슈

  • 3-Level 이슈 구조를 가진다.
    • 1 Level : Epic
    • 2 Level : Story, Bug, Hotfix
    • 3 Level : Sub-task
  • Story와 같은 2 Level 이슈가 반드시 Epic 이슈가 필요한 것이 아니며, 마찬가지로 2 Level 이슈 밑에 Sub-task 같은 3 Level 이슈가 있을 필요는 없다.

이슈 타입

큰틀 (Epic)
  • 1 Level, 단기간 내에 해결할 수 없는 이슈나, 거대한 테스크를 Epic 이슈로 등록한다. 이 때 위에서 언급한 것 처럼 ~으로서,를 반드시 명시한다.
    • 예-1 : 사용자로서, 새로운 플레이팅 어플리케이션이 필요하다고 생각합니다
스토리 (Story)
  • 2 Level, 기능 추가, 개선점(리팩토링)과 같은 이슈를 Story Issue로 사용한다. 이 때 위에서 언급한 것 처럼 ~으로서,를 반드시 명시한다.
    • 예-2 : 운영팀으로서, 조건에 맞는 여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템이 필요합니다.
버그 (Bug)
  • 2 Level, 현재 버전을 사용하는데 있어 문제가 되는 점들을 Bug Issue로 사용한다. 이 때 위에서 언급한 것 처럼 ~으로서,를 반드시 명시한다.
    • 예-4 : 사용자로서, 안드로이드 어플리케이션을 사용하다보면 자꾸 튕깁니다.
긴급 (Hotfix)
  • 2 Level, 현재 스프린트 계획에 없었거나 긴급하게 발생한 것들은 Hotfix Issue로 사용한다. 이 때 위에서 언급한 것 처럼 ~으로서,를 반드시 명시한다.
    • 예-5 : 마케팅팀으로서, 까먹은 급한 쿠폰 발급건 건이 생각났습니다. 내일까지 해야되요 ㅜㅜ
  • 기존 계획에 없었지만 현재 스프린트에 추가한 뒤, 해당 이슈에 대해 다음 스프린트 회고 때 얘기한다.
부작업(Sub-task)
  • 3 Level, 실제 StoryBug, Hotfix가 가질 수 있는 하위 작업(Sub-task)들 이다. 2 Level 이슈들이 추상적인 내용을 가진다면 3 Level 이슈들은 좀 더 구체적인 작업 단위가 된다.
    • 예-2 : 운영팀으로서, 조건에 맞는 여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템이 필요합니다. (Story)
      • 예-2.1 : 서버 사이드 구조 설계, 명세화 (Sub-task)
      • 예-2.2 : 쿠폰 컨트롤러 작성(Sub-task)
      • 예-2.3 : 메인 페이지 프론트 작업(Sub-task)
  • 물론 Sub-task가 필요 없는 이슈라면 2 Level 이슈 하위에 생성되지 않아도 된다.

우선 순위 선정

  • 이슈와 테스크를 진행하는 우선 순위
  • 모든 이슈가 HighestHigh일 수는 없음
  • High 급은 대부분 HotfixBug에 해당하고 일반적인 기능 추가나 리팩토링은 Midium 이하다.
  • Highest
    • 시스템이 전혀 사용 불가능한 상태
    • 해결하지 않으면 프로젝트가 진행될 수 없는 경우
      • ex. "안드로이드 어플에서 주문이 안되요 ㅜㅜ"
    • 즉시 담당자 지정 및 전사 텔레그램을 사용한 전사에 공유
  • High
    • 시스템의 주요 기능이 동작 불능
    • 프로젝트 진행은 가능하나 해결하지 않으면 정상적인 서비스 개발이 어려운 경우
      • ex. "안드로이드 어플에서 재고가 있는데 없다고 나와요 ㅜㅜ."
    • 지금 당장 개발해야하는 경우 (긴급 비즈니스 상황)
      • ex. "B2B 서비스를 시작 해야합니다."
  • Medium
    • 시스템의 일부 기능에 제약
      • ex. "안드로이드 어플에서 설명이 안나와요 ㅜㅜ"
    • 조만간 반드시 개발해야하는 경우
      • ex. "계약 업체와의 API 개발이 필요합니다."
  • Low
    • 시스템 기능은 동작하나 일부 기능 불편
      • ex. "안드로이드 어플에서 점심 탭 갔다가 저녁 탭오면 튕겨요 ㅜㅜ"
    • 개발은 해야하나 없어도 상관 없는 경우
      • ex. "플레이팅 2.0"
  • Lowest
    • 시스템 기능 동작에 영향 없음
    • 있으나 없으나 크게 상관 없음
      • ex. "텔레그램 플레이팅 봇에 기능 추가 하고 싶어요."

구성 요소(컴포넌트, Component)

  • 해당 프로젝트를 구성하는 구성 요소.
    • ex. iOS, Android, Landing Web, Database
  • 해당 이슈가 특정 컴포넌트와 관련된 이슈일 경우 추가해준다.
  • 현재 JIRA에서 사용 언어를 한국어로 설정했을 경우 컴포넌트 탭에서 목록이 뜨지 않는 버그가 있다.

레이블 (Lable)

  • SNS의 태그와 같은 기능, 가능한 많은 키워드를 넣어주자.
    • ex. Backend, AWS, EC2, React, JIRA

수정 버전

  • 해당 이슈가 특정 버전에서의 이슈일 경우 추가해준다.

Story Point

  • 스프린트 회의 때 포커친 결과를 넣어준다.

최초 예상, 남은 시간

  • 현재 플레이팅의 스토리 포인트 전략이 예상 시간과 같은 단위기 때문에 처음에는 Story Point와 같은 숫자를 넣어준다.
  • 서브 테스크가 발생할 경우 서브 테스크의 시간이 모두 합산되서 나오기 때문에 서브 테스크가 있을 경우 최초 예상을 초기화 한다.
  • 남은 시간은 사용하지 않는다.
  • 스토리 포인트와 시간 추청에 관한 부분은 아직 연구와 경험이 쌓이고 개선해야 부분

Github 연동

  • Github 커밋 메시지에 Issue Number를 붙임으로써 이슈의 개발 필드에 나타낼 수 있다.
    • Commit Message : #PL-13 #PL-24 Issue resolved.
  • Commit/Push 직후 바로 JIRA에 잡히지는 않고, 시간이 걸린다.


프로필사진

Yowu (Yu Yongwoo)

그냥 지나가는 흔한 백엔드개발자423 느낌 입니다
우분투 데스크탑 개발 환경을 선호합니다
최근에는 vscode에 vim 모드 올려서 쓰고 있습니다
개발용 키보드는 역시 해피해킹 프로2 무각입니다
락 밴드에서 드럼을 꽤나 오래 쳤었습니다