Table of Contents |
---|
칸반에 대한 오해중에 하나가 운영 업무에만 적합하다는 것인데 실제 칸반은 제품을 개발할 때도 많이 사용하고 있습니다.
칸반을 제품 개발에 사용할 경우 경영진이나 비즈니스 팀은 개별 기능의 현재 상태보다는 고객에게 전달 가능한 최종 제품이 무엇인지와 언제 고객에게 딜리버리가 가능한지를 알고 싶어합니다.
이럴 경우 칸반 보드에 등록된 이슈들의 목록과 상태만 봐서는 이런 정보를 한 눈에 파악하기 어렵습니다.
이런 요구사항을 충족하려면 어떤 방법론을 사용하든 버전과 릴리스 기능을 같이 사용하면 프로젝트의 나아갈 방향에 대해 업무 가시성이 확보되므로 이해당사자들간의 격차를 좁힐 수 있습니다.
Version 이란?
먼저 버전은 프로젝트의 특정 시점의 결과물을 의미하며 여러 개선 사항이나 버그 수정등을 논리적으로 묶은 단위로 목표 릴리스 날자가 있으므로 프로젝트의 수행 일정을 파악할 수 있습니다.
Jira 에서 버전은 여러 분들이 사용하시는 소프트웨어의 버전과 동일하다고 보시면 되며 버전 이름은 여러분이 임의로 지으면 되는데 버전은 보통 숫자로 짓습니다.
예로 1.2 나 2.3.5 같이 지을 수 있으며 3.1-RC1, 3.1-Beta3 같이 의미 있는 문자열을 추가해서 지을 수 도 있으며 대신 버전 명에 대한 일관적 규칙이 있어야 합니다.
팀이 관리하는 프로젝트에서 Version 활성화
팀이 관리하는 프로젝트 유형은 기본적으로 버전 기능이 꺼져 있습니다.
활성화하려면 "프로젝트 설정" → 기능 에 들어갑니다.
아래로 내려가면 개발 그룹에 릴리스가 있는데 이걸 켜주면 됩니다.
그리고 다시 보드로 돌아가면 릴리스 메뉴가 생긴걸 볼수 있습니다.
Version 생성
이제 릴리스를 하려면 버전부터 생성해야 하는데 버전은 여러 메뉴에서 생성할 수 있습니다.
회사가 관리하는 프로젝트
좌측의 릴리스를 클릭하고 우측 상단에서 “버전 만들기” 메뉴를 클릭해서 버전을 생성할 수 있습니다.
아직 버전을 만들지 않았다면 다음과 같이 “버전 관리 시작” 화면에서 “버전 만들기” 를 클릭합니다.
버전 정보를 다음과 같이 넣어줍니다.
버전명: 1.0
시작 날자: 오늘
릴리스 날짜: 2주후
동인(Driver): 이 릴리스를 담당하는 직원으로 기본 값으로 놔둡니다.
설명: “고객에게 최초 공개”
그리고 저장을 누르면 버전이 생성됩니다.
진행 상황에 "이슈없음" 으로 표시되는 건 지정한 버전에서 처리하기로 한 이슈가 등록되어 있지 않다는 의미입니다.
이제 또 하나의 버전인 2.0 을 만들겠습니다. 먼저 이름에 2.0을 넣고 아직 1.0 도 시작 단계이므로 2.0 의 시작 일정과 릴리스 날자는 진행하면서 결정된다고 가정하고 시작 날자와 종료 날자는 빈 칸으로 두겠습니다.
그러면 2개의 버전이 생성되었습니다.
팀이 관리하는 프로젝트
릴리스에서 생성
팀이 관리하는 프로젝트도 마찬가지로 좌측의 "릴리스 " 버튼을 클릭해서 "버전"을 생성할 수 있습니다.
백로그에서 생성
백로그 기능을 활성화했다면 백로그 화면에서 버전을 생성할 수 있습니다.
백로그를 선택한 후에 상단의 "버전" 을 클릭합니다.
팝업 메뉴에서 "버전 패널"이 비활성화되어 있는데 활성화 시켜줍니다.
그러면 버전 패널이 나타나는 데 하단의 "버전 만들기" 를 클릭해서 버전을 생성할 수 있습니다.
Tip |
---|
백로그에서 만드나 릴리스에서 만드나 동일하고 접근 방법 차이입니다. |
이슈에 Version 할당
이제 버전을 만들었으니 이슈에 버전을 할당할 단계입니다.
먼저 보드를 클릭하고 칸반 보드에서 이슈를 나열합습니다.
버전을 지정할 이슈를 클릭해서 상세화면을 띄우면 여러 필드중에 "수정 버전" 필드가 표시됩니다.
클릭하면 Jira 프로젝트에 등록한 버전중 릴리스 안 된 버전들이 표시됩니다.
해당 이슈를 처리할 목표 버전을 할당하면 이슈 화면에 아래처럼 표시가 됩니다.
Tip |
---|
수정 버전은 여러 개 할당할 수 있습니다. 예로 2.0, 3.0 에서 모두 나타나는 버그일 경우입니다. |
Jira 에서 버전 관련해서 제공되는 필드는 기본적으로 2개인데 하나는 "영향을 받는 버전(affects version)” 이며 다른 하나는 "수정 버전(fixed version)” 입니다.
영향 받는 버전은 보통 이슈 타입이 버그일 때 사용하는데 해당 버그가 발생하는 버전을 기술해 줍니다. 만약 다양한 버전에서 발생하는 버그라면 위 예시처럼 여러 개의 버전을 입력해 주면 됩니다.
Note |
---|
팀이 관리하는 프로젝트에서는 "영향 받는 버전" 필드를 지원하지 않습니다. |
이제 3.0 버전에서 처리할 이슈들을 선택해서 "수정 버전" 에 3.0 을 할당해 주고 릴리스 탭을 보면 이슈가 할당되었으므로 진행 상황이 “이슈없음” 에서 변경된 것을 알수 있습니다.
그리고 몇 개의 이슈에도 수정 버전을 할당하고 상태를 처리중과 완료로 적당히 변경해 줍니다.
릴리스
좌측의 릴리스 탭을 클릭해 보면 버전 목록과 상태가 표시되는데 수정 버전에 할당한 이슈가 완료와 진행중 상태가 되었으므로 진행 상황이 다르게 표시되는 걸 볼수 있습니다.
그리고 버전 명을 클릭하면 버전의 상세 정보를 알수 있는데 전체 이슈의 상태와 개별 이슈의 상태를 개괄적으로 표시해 줍니다.
우측에서 Release 를 클릭하면 새로운 팝업 창이 뜹니다.
아직 해결 안 된 이슈가 있다는 경고창이 뜨는데 2가지 선택이 있습니다.
Tip |
---|
“이슈를 버전으로 이동합니다.” 가 표시 안 되는 것은 프로젝트에 “릴리스 안 된 버전”이 하나밖에 없어서입니다. |
첫번째는 무시하고 진행하는 것으로 이러면 해당 버전에 속한 이슈들의 상태가 완료 여부가 아니더라도 릴리스를 진행합니다.
그래서 Release 상태는 “릴리즈됨” 으로 바뀌고 이슈 상태를 그대로 있게 됩니다.
상태가 미완인 이슈들이 남게 되므로 제대로 관리가 안 될 소지가 크고 나중에 회고해 보면 이게 왜 릴리스가 되었는지 헷갈리게 되므로 이 방법을 추천하지 않습니다.
두번째는 미완인 이슈를 다른 버전으로 이동하는 것으로 미완인 이슈를 지정한 버전으로 이동하므로 혼동될 일이 적으므로 이 방법을 추천합니다.
Release 된 후에 “릴리스” 탭에 들어가서 “모든 상태” 로 변경하면 전체 버전과 릴리스 현황을 알 수 있습니다.