Jira 티켓은 일반적으로 회사의 기획 & 디자인 → 개발 → 검증 → 릴리즈 과정에 맞춰 구성하는 것이 좋습니다.
또한 티켓의 사용법 뿐만 아니라 각 티켓의 워크플로까지 고민하여 티켓을 구성해야 티켓 설정이 완료되었다 할 수 있습니다.
티켓 구성을 쉽게 설명하기 위해 아래와 같은 프로젝트가 있다 가정하겠습니다.
[모니터링 시스템 구축]
* 배경 및 문제점
- 가나라다라마바사
* 해결방안 및 가치
- 가나라다라마바사
* concept
- 가나라다라마바사
* 상세 기능
- 가나라다라마바사
* 구현 범위 및 Task
- 가나라다라마바사
* 세부 일정
- 가나라다라마바사
1. Epic
Epic은 여러 Story/Subtask들의 집합으로 하나의 버전 혹은 프로젝트 단위입니다. Epic 티켓의 이름은 모니터링시스템으로, 요약은 모니터링 시스템 v1.0, 세부 내용으로는 배경 및 문제점, 해결방안, 일정 정도가 기록되는 것이 좋습니다. Epic 티켓의 이름은 하위 항목들을 이어주는 Epic Link로 동작하기 때문에 회사에서 어떻게 프로젝트를 구분해서 관리하느냐에 따라 티켓의 이름과 요약이 정해질 것 입니다.
세부 내용 중 일정의 경우 앞서 말했듯 모든 구성원들이 한 눈에 보기 쉽도록 기획 & 디자인 → 개발 → 검증 → 릴리즈의 과정이 모두 담기도록 작성되는 것이 좋습니다. Epic은 큰 그림에서의 내용을 집약적으로 담고 있기 때문에 Epic 티켓의 하단에 프로젝트에 참여하는 모든 구성원들을 cc로 추가하는 것이 좋습니다. 일정이 변경되거나, 기능이 변경되는 등의 경우 반드시 Epic 티켓도 수정되어야 하며, 이 항목들은 참여자 모두에게 알려져야 하기 때문입니다.
샘플 양식
Key features
Minor features
Bugs
세부 일정
- kick-off :
- 요구사항 정리 :
- 기능 기획 :
- UI/UX :
- figma :
- DEV
- BE :
- FE :
- Dev Exit :
- QA
- Internal :
- Field :
- Demo :
- Release :
cc.
2. Story / Subtask
Story를 하나의 기능 정의서로, Subtask를 기능에 따른 구현 단위로 작성할 있기도 하며, Subtask에 하나로 합쳐서 작성할 수도 있습니다. 그렇기 때문에 Story 및 Subtask의 경우 회사마다 정의가 다를 것 같습니다. 다만 Story든 Subtask든 에픽의 하위 작업으로 생각하고 작성해주시면 됩니다.
Story / Subtask의 작성 및 관리는 전체 일정을 관리하는 Project Manager가 관리하는 것이 아니라 각 기능의 담당자들이 하는 것이 협업 차원에서 합리적입니다. 그렇기 때문에 일반적으로 Story / Subtask에 모든 구현의 내용을 담기보다는 큰 기능들 위주로 담아 관리의 효율성을 높이는 것이 좋습니다.
샘플 양식
현황 및 배경
요구사항
cc.
3. Bug
Bug 티켓의 경우 릴리즈 되기 전의 검증용과 릴리즈 후 발생한 이슈용으로 나눠서 생성하는 것이 일반적입니다. 이러한 구분은 레이블을 추가하여 쉽게 관리할 수 있으며, 만약 릴리즈 전과 후를 나눠서 이슈 관리하는 것에 대해 리소스가 많이 들거나 버그가 거의 리포팅 되지 않는다면 레이블없이 하나로 관리되어도 무방합니다.
다만, Bug의 경우 언제 해결될지가 제일 중요한 항목이기 때문에 레이블에 우선 순위, 원인이 되는 component 혹은 제품, 발생한 버전, 해결될 버전은 추가하는 운영 측면에서 좋습니다.
샘플 양식
테스트 환경
재현 시나리오
현재 동작
기대 동작
참고 영상 및 이미지
일반적으로 티켓의 구성을 설명드렸지만 제일 처음 작성하였듯
각 회사마다 구현 및 관리하는 방식의 차이가 있기 때문에 회사에 맞춰서 티켓을 활용하는 것이 제일 중요합니다.