사내 조직개편을 하면서 팀끼리 지라 칸반보드를 따로 사용하기로 하였다. 기회가 되어서 내가 해보겠다고 나섰다.
탐색
다음과 같이 목표와 해야 할 것을 정했다.
- 지라 칸반보드 설정하기
- 다른 회사 레퍼런스 찾아보기
- 우리가 사용했던 시스템 찾아보기
- 다른 팀의 지라 설정 찾아보기
다른 회사 레퍼런스 찾아보기
구글에 jira workflow examples for software development라고 치면 워크플로 이미지가 뜬다. 화살표가 이리저리 되어있어도 전체적으로 보면 개발 전 / 중 / 후이 3가지에 어떤 것을 더 추가했느냐에 따라 형태가 달라질 뿐 큰 그림은 비슷하다.
우리가 사용했던 시스템 찾아보기
기존에 쓰고 있던 워크플로는 다음과 같다. 기획자가 디자인도 같이 했기 때문에 디자인의 영역은 따로 분리하지 않았다. 또한 개발이 완료되면 QA 대기 상태가 되기 때문에 개발 완료는 없었다. QA 중에서 QA 완료로 갈 때는 운영 배포가 끝난 후에 QA팀에서 상태를 변경하였다.
- 접수 ➡️ 할 일 ➡️ 기획 ➡️ 기획 중 ➡️ 기획 완료 ➡️ 할 일 ➡️ 작업중(수정중) ➡️ QA 대기 ➡️ QA 중 ➡️ 배포예정 ➡️ 배포완료
- 보류중
다른 팀의 지라 설정 찾아보기
다른 팀과의 차이
- 스테이징이 없을 것이다. 왜냐하면 새로 서비스를 만들기 때문에 서버와 유사한 환경이 따로 필요하지 않기 때문이다.
기존에 사용하면서 불편했던 것은?
-
기획 완료인 상태에서 기획 수정
기획자가 기획을 끝낸 후에기획 완료라고 변경을 했지만, 개발팀이나 QA 팀에서 "이거 힘든데요?"라고 의견이 나오면 기획이 수정되었다. 그런데 이런 순간이 잦아지니 기획자는기획으로 상태를 변경하지 않았다.기획 완료로 가기 전에 기획 리뷰를 했다면 잦은 변경이 일어나지 않았을 것이다. -
모두에게
할 일
기획자와 개발자에게 모두할 일이라는 상태가 있었다. '작업을 하기 전이고, 내가 해야 할 것이라는 걸 알아'라는 뜻이다. 그런데 하나의 이슈 하단에 기획, 프론트, 백엔드, 윈도우 팀 모두할 일을 갖고 있으니, 어느 단계에 있는지 한눈에 알아보기 어려웠다. -
API 수정
화면이 나오면 서버팀에서는 화면을 보고 API 설계를 하고 프론트 팀에 건네준다. 이때 서로 화면 동작을 이해하는 게 달라서 API를 수정하는 일이 있었다. 필요한 API에 대해 같이 이야기 해보지 않은 게 문제였다.
그래서 이렇게 했다
위 그래프에서 API 설계가 추가되고, 개발 배포 이후에 개발 리뷰를 하는 것으로 순서를 변경하였다.
기존에 사용하던 워크플로에서 단계를 추가하였다. 너무 세세해서 사람들이 사용할 때 불편하지 않을까 우려되는 부분도 있다. 이런 것은 사용을 하면서 차후 수정하려 한다.
적용
- 프로젝트 생성
- 프로젝트 설정
액세스권한 추가- 팀원 초대
이슈 유형추가- 기존에는
에픽,Task,하위 작업이 있다. - 여기에
버그를 추가하고, 위 3가지 중 일부 이슈의 이름을 변경하였다.
- 기존에는
`프로젝트`의 하위 이슈로 `버그` 혹은 `작업`을 적용한다.-
워크플로우 수정
테스트 이슈 하나 생성한 뒤에 워크플로우로 들어갔다.
워크플로 편집을 눌러 순서를 적용한 뒤,워크플로 업데이트를 하면 된다. 간혹 알 수 없는 이유로 저장되지 않는 경우가 있으니, 추가할 때마다 간간이 저장을 해보는 것이 좋다.
워크플로 보기
초기 설정
개발팀이 사용하는 하위 이슈 워크플로우
상태를 연결하는 걸 지라에서 `전환`이라고 하는데, 이 이름을 설정해두면 옆에 설명처럼 붙어있다.- 노출할 상태 설정
메인 화면에 어떻게 노출할 것인지 설정한다.
프로젝트 설정 > 보드 > 열 및 상태완료 🎉
내가 만든 걸 팀원들이 쓸 생각을 하니 만들면서도 재밌었다. 차후 변경되는 사항이 생기면 해당 게시글을 수정할 것이다.
