2. Issue Tracking의 이해와 적용

---

2.1. Issue Tracking 개요

2.1.1. Issue Tracking 정의와 목적

• Issue :프로젝트를 진행하면서 발생하는 모든 사항의 단위
  - 기능 구현, 기능 개선, 버그 수정, 데이터 이관, 시스템 설치, 문서 작업 등
• Issue Tracking : 어떠한 시스템을 통해 이슈마다 별도의 생명 주기와 작업 흐름을 갖고 추적 및 관리하는 일
• 이슈 트래킹의 목적
  - 프로젝트 일정 관리 : 프로젝트 진행 사항 확인에 용이
  • 버그 관리 : 테스트 단계에서도 테스트 케이스 번호를 이슈와 연계시켜 별도의 버그 일람을 만들지 않아도 되고, 이전에 해결했던 이슈를 찾아 봄으로써 버그 해결에 도움
  • 유지보수시의 요청사항 관리 : 요청사항을 실시간으로 접수할 수 있고 일원화 해 관리 가능

2.1.2. Issue의 범위 : bug, realized problem

• 버그 관리는 이슈 관리의 부분 집합
• 이슈 관리 시스템은 대부분 버그 관리 시스템(BTS, Bug Tracking System)에서 출발했지만 다양한 이슈를 관리할 수 있도록 의미가 확장됨
• 이슈 관리 시스템에 따라 이슈를 버그 혹은 발현된 문제(해결해야할 문제)에 국한하기도 하지만 일반적으로는 앞서 정의했던대로 프로젝트를 진행하면서 발생하는 모든 사항들을 포함함

2.1.3. 이슈 관리 시스템의 주요 특징

• 이력 관리 시스템
• 협업/의사 소통 도구
• 작업 흐름 문서화/가시화
• 이슈 간의 관계(Association) 문서화/가시화
• 로드맵과 버전 관리
• 다양한 시스템과 연동

---

2.2. 협업 진행 방식 선정

• 협업 프로세스는 프로젝트의 규모, 참여 인원의 업무 방식과 능력을 고려해 협의해야 함
• 현재 개인적으로 진행하는 프로젝트의 경우 규모가 작기 때문에 기능이 다양한 협업툴을 새로 학습하는 것 보다 간단하고 익숙한 툴 사용이 유리

2.2.1. 사용툴

• 일정관리 : notion
• 의사 소통 도구 : slack
• 이슈 트래커 : github issue

2.2.2. 협업 진행 과정

1. 회의 개최 : 과제 파악 -> (user story 추출 ->) 구현할 기능 추출 -> 개인 일정 공유(리소스 파악) -> 파트 분배, 일정 문서화 : notion
2. 새로운 이슈 발생시 github issue 생성
3. 작업물 공유 및 피드백

---

+) 기타

• '이슈'의 범위를 잘 모르겠다. 조사 이전에 알고있었던 이슈는 계획된 프로세스에서 벗어난 해결되어야 할 무언가였다. 그런데 기능 구현과 같이 이미 계획에 있던 일들도 이슈라고 하면 일정관리와 이슈트래킹의 차이가 무엇인지 모르겠다.
• 협업 진행방식을 깊게 알아봐야할 만큼 프로젝트의 규모가 크다면 굳이 내가 협업 진행 방식을 짜야할 경우가 있을까..? 협업 경험이 적어서 필요성을 아직 크게 못느끼고 있는 것 같다.
• 깊게 배우려면 끝도 없는 것 같다..
  - WBS 소개 및 사용방법 - asana
  - CI/CD 개념, 방법, 장점, 구현과정

---

참고자료

Issue Tracking 이란 - 리눅스를 활용한 회사 인프라 구축의 모든 것