개발 프로젝트 운영과 Jira 첫 시작

7월 부터 개발 팀원들이 생겨나면서, 새로운 협업툴을 써보기로 했습니다!

이미 잘 알려진 Jira인데요.

조금 더 빨리, 효율적으로 협업하고자 시작했는데 슬랙 노션에만 익숙한 저에게는 온보딩 시간이 꽤나 필요했습니다 🥲

Jira사용하시는 다른 메이커분들은 어떻게 느끼시나요? 열심히 사용하고 계신 분들의 후기가 궁금합니다 ㅎㅎ

저와 같은 팀원들을 위해 팀내 PM 분이 만들어주신 저희 팀의 Jira 사용법을 공유해요!

원문출처 :

Middle Level Planning, Over Performing

이슈

이슈 타입은 지라(JIRA) 기반으로 소개합니다.

에픽 (Epic) : 에픽은 많은 사용자 스토리, 많은 작은 단위 업무로 나눌 수 있는 업무의 큰 틀. 하나의 Sprint에 걸쳐서 끝나지 않고, 여러 Sprint에 걸쳐서 종료되며, 여러 Story들의 집합. 주로 Major Feature들을 중심으로 정의합니다. 서비스의 마일스톤에 해당합니다.
스토리 (Story) : 서비스 고객에게 가치를 줄 수 있는 기능을 서술한 것입니다. 각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성하는 것이 좋습니다. 예) [(역할을 가진) 사용자]는 [행위 / 목표]를 수행하여 [이유]를 한다. 스토리는 대부분의 경우 서브 태스크가 있습니다.
디벨롭 (Dev): 사용자와는 직접적으로 관계되지 않는 개발과 관련한 업무
버그 (Bug): 서비스에서 발생하는 문제점 또는 리포팅된 버그
문서 (Doc): 개발과 구현에는 직접적으로 관련이 없는 문서작성 등의 문서 업무
서브 태스크 (Sub-task): 스토리의 하위 작업, 또는 Dev의 하위 작업. 스토리 또는 Dev를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업
이슈들의 가능한 상관 관계

Epic
├── Story
|     └── Subtask
├── Dev
|     └── Subtask(option)
├── Bug
└── Doc
[Epic 없음]
Story
└── Subtask
Dev
└── Subtask(option)
Bug
Doc

에픽과 스토리는 주로 PO가 작성합니다.

로드맵에는 에픽을 기록한다. 이 때, '...으로서'를 반드시 기재하도록 한다. 해당 에픽의 출처와 목적을 확인하기 위함이다.
에픽의 하위 스토리 또는 에픽 없는 스토리를 백로그에 작성할 때는 [(역할을 가진) 사용자]는 [행위 / 목표]를 수행하여 [이유]를 한다. 처럼 비즈니스 언어로 작성합니다.
Dev와 Sub-task을 작성할 때에는 개발자가 작성하는대로 작성하면 된다.

이슈 내용 작성

이슈에 작성해야하는 내용을 설명합니다.

Kanban 보드에서 GROUP BY를 Sub-task 로 보면 서브 태스크를 쉽게 드래그앤 드랍으로 관리할 수 있습니다.

그루밍 (스프린트 도중의 월요일)

다음 스프린트에 들어가기 전에 PO가 다음 스프린트에 개발할 기능에 대해서 대략적으로 리뷰하는 행위 (스프린트 진행 중에 일어남) - Epic or Story

[WHY]

[HOW]

스프린트 계획 (스프린트 시작날의 월요일)

플래닝 포커 : 팀원들은 각자 숫자가 쓰여진 카드를 골라 다른 팀원들에게 보여줌으로써, '스토리 점수'를 매길 수 있습니다.
최대 3일 이내의 작업으로 업무가 분리되어야 합니다.
고려해야할 사항
- Task 설정시 구체적인 종결 행위를 기반으로 Task 설정 하는것이 좋습니다.
- Task 설정시 분석,설계 / 구현 / 테스트 → 1:1:1 의 리소스 분배가 좋습니다.
- 주요 Task에 대해서는 어떤 형식으로든지 리뷰를 하는것이 좋습니다.
- Task 기간 설정시 20%의 버퍼를 두는것이 좋습니다.

데일리 스크럼

스프린트 리뷰 및 회고