어느 스타트업의 애자일 스크럼와 JIRA에 대한 연구 문서

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에서 각각 AWS와 ERP에 걸친 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, 실제 Story나 Bug, 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 이슈 하위에 생성되지 않아도 된다.

우선 순위 선정

• 이슈와 테스크를 진행하는 우선 순위
• 모든 이슈가 Highest나 High일 수는 없음
• High 급은 대부분 Hotfix나 Bug에 해당하고 일반적인 기능 추가나 리팩토링은 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에 잡히지는 않고, 시간이 걸린다.