초기 팀을 위한 JIRA(스크럼) 용어 및 사용법 정리

항상 개발 중심 조직에서 일을 하다가 완전 비개발 직군과 함께 스프린트를 꾸리면서 JIRA사용에 여러 애로사항을 겪었습니다. 그래서 이 기회에 명확한 JIRA 사용법 및 워크플로우 용어들을 정리하게 되었습니다. 

 

모든 툴이 그렇지만 각 팀의 사정과 환경에 맞게 수정해 사용해야 한다는 점을 유의해야 합니다. 그럼 제가 우리팀에서 만든 JIRA라 쓰고 스크럼이라 읽는 사용법 정리를 시작하겠습니다.

 

 스크럼에는 에픽 - 스토리 - 작업 - 버그 등 다양한 용어의 이슈(Task)들이 있습니다. 이런 용어의 혼동은 스크럼을 초기에 도입하는데 큰 방해요소중 하나입니다.

 이는 "아니, 버그면 버그, 기능이면 기능이라 쓰면되지 에픽은 뭐고 스토리는 뭐다냐?" 라는 의문점이 가장 먼저 들게 하는 요소입니다. 물론 저도 처음에는 해당 용어를 보고 이게 무슨 소리인가라는 고민을 했었습니다. 이런 용어가 붙은 철학은 여러 이유가 있겠지만 우리가 푸는 모든 문제에는 인과관계가 있고 그건 하나의 책과 같은 흐름이 존재한다는데 기인합니다. 에픽과 스토리는 실제 시나리오나 소설책에서 사용되는 용어이지요. 

 따라서 우리는 우리의 서비스를 하나의 긴 소설을 완성한다고 생각하고 접근할 필요가 있습니다. 그럼 하나씩 용어와 사용법 그리고 워크플로우를 풀어가며 진행하겠습니다.

 

1. 에픽

 에픽은 직역하면 서사시로 방대한 이야기를 의미합니다. 큰틀이라는 이름으로 번역되기도 하지만 본래 의도를 포함하기는 힘든 용어지 않나 생각됩니다. 고객한테 제공할 핵심 기능 또는 요소라고 이해해야 하며 큰 기능의 핵심을 관통하는 이야기들의 묶음입니다.

 예시를 든다면 "회원가입 및 등록절차", "재난지원금 조회", "음식 주문하기"등이 있습니다. 에픽은 현재 기준의 새로운 기능이나 경험을 제공하기 위한 카테고리라고 생각하면 될 것 같습니다. 

에픽의 워크플로우입니다.

 하나의 에픽을 처리하기 위한 워크플로우입니다. 에픽은 때로는 완전히 새로운 기능일 수도 아님 기존 기능의 변경일 수도 있습니다. 이런 에픽을 우리의 서비스에 도입하기 위해서는 시장성에 대한 검증(고객의 니즈)를 먼저 판단하고 각 팀의 기술적 검증을 거치게 됩니다. 이런 검증 절차는 해당 에픽이 고객에게 전달해주어야 할 스토리를 명확히 하는데 도움을 줍니다. 

 검증단계를 거쳐 개발하기로 결정된다면 해당 에픽을 수행하기 위한 스토리를 설계합니다. 스토리가 백로그에 추가된다면 우리는 열심히 만들어 고객에게 전달하기 위해 노력합니다.

 만약 에픽이 검증단계에서 취소가 결정된다면 삭제시키는게 아닌 취소라는 단계로 설정합니다. 우리는 모든 일을 히스토리화할 의무가 있으며 미래의 우리에게 큰 선물이 될 것입니다.

 

2. 스토리

  스토리는 에픽을 이루는 요소라고 생각할 수 있습니다. 작업자의 입장이아닌 사용자, 고객의 언어로 풀어써서 기능을 설명할 수 있어야 합니다. 예를 들면 "소셜계정을 이용하여 로그인할 수 있다.", "로그인 후 사용자의 기본 정보를 입력한다.", "개인 인증을 진행하여 사용자 정보를 불러온다.", "음식을 장바구니에 담는다."와 같이 사용자의 행동을 문장으로 완성할 수 있어야 합니다. 

 에픽과 스토리를 통해 아, 우리의 서비스는 소셜계정을 통해 회원가입하고 정보를 관리하는 구나를 파악할 수 있어야한다. 

스토리의 워크플로우입니다.

 각 스토리는 우선적으로 기획과 디자인을 수행하며 개발팀과 끊임없이 소통하게 됩니다. 이렇게 완성된 기획과 디자인을 기반으로 개발을 수행하게 됩니다. 개발이 완료된다면 각 조직의 규칙에 맞게 QA를 수행하고 해당 스토리는 완료가 됩니다.

 스토리도 에픽과 마찬가지로 문제가 있거나 수행하기 힘들 다면 취소될 수 있지만 삭제를 해서는 안됩니다.

 

3. 하위 작업(Sub Task)

 하위작업은 스토리를 실무자들이 분석하여 각각의 실무를 작성합니다. 개발자/디자이너/기획자 분들이 각각 모두의 기술적 언어를 통해 가장 편한 언어로 업무를 정리하게 됩니다.

 하위작업은 작업자들이 실시간으로 추가 및 업데이트를 수행하기 때문에 간략한 프로세스를 가지고 있습니다. (개발팀의 경우 PR이 머지될때 Done으로 이동합니다.)

 

4. 작업

 작업은 스토리로 표현할 수 없는 다양한 작업을 수행할 때 사용됩니다. 개발자의 경우 인프라 작업이나 툴 버전 업데이트등을 예로 들 수 있겠습니다.

 

 순서대로 대분류에서 소분류로 내려오며 각 이슈의 타입과 스크럼에서 어떤 형태로 업무를 수행해야 하는지에 대해 정리해보았습니다. 이런 규칙을 기반으로 팀이 움직이기 시작한다면 눈빛만 봐도 서로 어떤 일을 하는지 또 해야하는지 알 수 있는 날이 오지 않을까 기대합니다. 

 

 스크럼과 엮여서 인프라의 역할과 CI/CD를 설계하는 방법에 대해서도 풀어낼 수 있도록 하겠습니다. 해당 방법은 정답이 아니며 각 팀의 환경과 상황에 맞게 잘 변경하여 쓰시길 권장합니다!

 

 긴 글 읽어주셔서 감사합니다.