현재 회사에서는, 애자일과 스크럼에 맞추어 월요일에 이슈와 백로그들 만들고 이걸로 주단위 스프린트를 시작하는데, 여기서는 이슈에 초점을 맞추어서 별의별 기능들을 모두 소개해 주며진행을 하는듯 하다.
하긴 개발이 급해서 그렇지, Jira 자체에 기능이 뭔가 많기는 했었따...(근데 그걸 다 쓸 여유가 있는 팀이 있나?)
그래도 전반적으로 커스텀 필드로 해당 이슈를 상세하게 묘사하는 부분은 참고할 만 했다.
스크럼 소프트웨어 개발의 이름과 키를 설정하고 프로젝트를 만들어서, 백로그와 이슈를 쳐 나가고, 주단위로 이슈그래프가 천천히 하강하는 모양새를 이상적으로 삼는데... 과연?
--------- 이후부터는 강의내용 위주
이슈(Issues) 란?
이슈의 정의
- 오류, 버그 및 '새로운 기능', 작업요청, 사소한 질문이나 의견등 제품에 관해 회사에서 대화의 대상이 되는 거의 모든 것.
- 이슈 종류에 따라 개발자의 구현이 필요없는 경우도 상당수 있음
- "글로벌 소프트웨어를 꿈꾸다." 김익환. p.48
- Issue Tracking System(Ex: Trac) 의 종류에 따라 ticket 이라고 하기도 합니다.
- Problem 과 Issue를 혼동하는 경우가 많으나 Issue 가 더 포괄적인 개념임.
이슈 화면
JIRA 에서 이슈는 다음 화면과 같이 보여집니다.
필드별 의미는 다음과 같습니다.
- Project — 현재 이슈가 속한 프로젝트명.
- Key — 현재 이슈의 유일한 식별키(hyphen 왼쪽의 문자는 프로젝트명)
- Summary — a brief one-line summary of the issue.
- Type(종류) — 이슈의 종류
- Status(상태) — workflow 에 따른 이슈의 현재 상태.
- Priority(우선순위)--- 이슈의 우선 순위
- Resolution(처리상태)--- 이슈가 Resolved나 Closed 일 경우 처리상태
- Affects Version(s)(관련버전) (if applicable) — 이슈가 발생하는 프로젝트 버전.
- Fix Version(s)(수정버전) (if applicable) — 해당 이슈가 수정된 프로젝트 버전.
- Component(s)(컴포넌트) (if applicable) — 이 이슈가 관련된 프로젝트 컴포넌트
- Labels(s) (if applicable) — 이슈와 관련된 label
- Description(상세내역) — a detailed description of the issue.
- Assignee(담당자) — 해당 이슈가 할당된 담당자.
- Reporter(보고자) — 해당 이슈를 등록한 사람.
- Created(생성일자) — 이슈 생성일
- Updated(갱신일자) — 이슈가 마지막으로 갱신된 날자.
- Resolved(해결일자) — 이슈가 해결된 날자
- Attachments(첨부 파일) — 현재 이슈 해결에 필요한 첨부 파일(스크린샷, 로그 파일등)
- Issue Links(이슈 링크) — 현재 이슈와 관련된 이슈 링크
위의 여러 항목 가운데 가장 중요한 필드들은 'Type', 'Priority', 'Status' and 'Resolution' 입니다. 하단에 기술합니다.
Issue Type
Issue 는 type 으로 구분되어 질 수 있으며 JIRA에서 제공되는 기본 이슈는 다음과 같습니다.
관리자는 새로운 이슈 유형을 추가할 수 있습니다.
이슈 타입설명
BUG (문제점) | 제품 혹은 소프트웨어의 기능을 방해하는 문제 | |
Improvement (개선사항) | 기존의 기능을 향상시키는 것. | |
New Feature (새 기능} | 아직 개발되지 않은 새로운 기능 | |
Task (업무) | 실행해야 하는 업무. | |
Story | User Story |
Priority Levels (우선순위 레벨)
우선순위는 상대적인 우선순위를 나타내는 필드입니다. 기본적으로 다음과 같은 우선 순위가 설정되어 있으며 관리자는 임의의 우선순위를 추가할 수 있습니다.
긴급도(Serverity)와 중요도(Importance)
긴급도와 중요도는 다른 등급이며 고객의 관점에서 보면 다 긴급하고 중요하지만 회사의 관점은 다르게 봐야 한다. 전략성없는 긴급성 최우선주의로 업무를 추진하는 것은 응급실만 있는 병원과 같다.
급하고 중요한 것
- 제품에 심각한 문제가 일어나 많은 고객의 불평이 쇄도하여 당장 해결해야 하는 문제.
급하지만 중요하지 않은 것
- 특정 고객이 자기 회사에는 급하다고 새로운 기능을 빨리 추가해 달라고 요청하는 경우
중요하지만 급하지 않은 것
- 개발초기에 분석을 충실히 하고 스펙 문서를 잘 적는 것
- 설계를 잘 해서 구현에 들어가기 전에 컴포넌트와 인터페이스를 잘 정해놓는 것
- 동료 검토를 적절히 하는 것
- 제품 품질 테스트를 잘하는 것
- "글로벌 소프트웨어를 꿈꾸다." 김익환. p.142
우선순위 레벨설명
Blocker (긴급) | 전체 프로젝트의 진행을 막고 있는 가장 우선적으로 처리해야 할 이슈의 우선순위 레벨 | |
Critical (심각) | 데이터 손실, 심각한 메모리 결함과 같은 치명적인 문제를 발생시키는 이슈의 우선순위 레벨 | |
Major (높음) | 기능 수행 자체에 영향을 주는 이슈 우선순위 레벨 | |
Minor (보통) | 기능의 최소한의 손실이나 간단한 문제점을 발생시키는 이슈의 우선순위 레벨 | |
Trivial (낮음) | 철자오류나 텍스트의 조정 불량과 같은 표면적이며 기능자체와 직접적인 연관은 없는 사소한 문제를 발생시키는 이슈의 우선순위 레벨 |
JIRA에는 importance 항목이 없으나 다음과 같은 방법으로 중요도를 나타낼 수 있습니다.
|
Status(이슈 상태)
각 이슈는 상태를 가지고 있으며 lifecycle('workflow') 내의 어떤 상태에 있는지를 나타냅니다.
일반적으로 이슈들은 open함으로써 시작되고 진행되고 종결됩니다.
관리자 설정에 따라서 그것은 다른 상태로 진행될 수도 있습니다.
이슈 상태설명
Open (개설) | 이슈는 초기에 "Open"상태 |
In Progress (진행중) | 현재 담당자에 의해 작업이 검토 혹은 수정이 이루어지고 있습니다. |
Resolved (해결) | 해결이 되고 보고자로부터의 확인을 기다리고 있습니다. 여기에서 이슈는 보고자가 확인 후 재수정이 필요한 경우는 재오픈 되어지고만약 바람직한 상태로 해결된 것이 확인되면 이슈는 종결되고 종결됨이 표시됩니다. |
Reopened (재오픈) | 이슈가 일단 해결되었지만 그 해결이 부정확하다고 판단되었을 경우 사용합니다. 예를 들어 더 자세한 정보가 발견되어 추가 확인이 필요한 경우나 혹은 문제가 재현이 되는 경우 사용되며, 재오픈된 이슈들은 다시 In Progress(진행중), Resolved(해결) 또는 Closed (종료)의 상태로 진행이 되게 됩니다. |
Closed (종료) | 이슈가 충분히 숙고하여 해결되었고 그 해결이 정확할 경우 사용됩니다. 이슈는 완전히 종료되거나 혹은 다시 작업해야 할 경우 Reopened (재오픈) 되어 다시 처리되어져야 합니다. |
Resolution (이슈처리 상태)
An issue can be resolved in many ways, only one of them being 'Fixed'. The default resolutions are listed below; note that your JIRA administrator may have customised these to suit your organisation.
이슈 처리 상태설명
Fixed (수정) | 해당 이슈가 처리됨. |
Won't Fix (수정 불가) | 해결할 수 없는 이슈 |
Duplicate (중복) | 이 문제는 기존이슈와 중복된 것입니다. 이 해결책을 처리하기 위해서 중복된 이슈에 link(링크)할 것을 권장합니다. |
Incomplete (정보부족) | 이슈에서 작업할 정보가 충분치 않습니다 |
Cannot reproduce (재현 불가능) | 이슈의 재현을 위한 모든 시도들이 효과가 없었거나 이슈를 재현하기 위한 정보가 충분치 않았습니다. 차후에 더 자세한 정보가 나타날 경우 이슈를 재오픈하시기 바랍니다. |
ETC. 관련사진들 긁어오기 by 인터넷
본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.