Jira로 스프린트 운영하기
지라로 스크럼과 스프린트 운영하기
BTS(그 BTS.. 아니고 버그 트래킹 시스템) 유랑기
지금까지 프로젝트를 진행하며 여러 협업 툴을 이용해 봤지만, 툴은 말 그대로 도구이기 때문에 팀의 규모나 프로젝트의 성격 그리고 제품의 종류를 고려해 선택하는 것이 가장 바람직한 방향이라 생각한다. 많은 팀들은 프로젝트의 이슈를 효율적으로 관리하고 추적하기 위해서 BTS(Bug Tracking System), ITS(Issue Tracking System)를 활용하고 있다. 첫 회사에서는 자체적으로 구축한 BTS를 활용했었고, 이후부터 조직의 규모가 상대적으로 작아지면서 외부 시스템을 활용하게 되었다..
작년까지만 하더라도 노션, 아사나, 트렐로를 사용했었지만 최근 클릭업과 지라, 컨플루언스로 넘어오면서 툴마다의 장점과 한계점을 대조해보고 있는데, 협업 툴 대조 분석글을 쓰기에는 아직 경험이 많이 부족해서(툴을 레버리지로 활용했다고 보기엔 어렵기 때문에) 오늘은 지라로 스크럼과 스프린트를 어떻게 운영하면 좋을지 간략히 공유해 보려고 한다.
JIRA
지라(JIRA)는 아틀라시안(Atlassian)에서 개발한 프로젝트 및 이슈 트래킹 시스템이다. 지라는 최대 10명까지 월 요금 무료로 사용할 수 있고, 사용자 수가 그 이상을 넘어가게 되면 스탠다드 또는 프리미엄 플랜을 구독해야 한다. 지라의 경우, 소프트웨어 관리 도구의 특성상 대규모 팀이 활용하는 경우가 대부분이다 보니 enterprise 연간 플랜을 제공하고 있다.
*지라와 연동성이 좋기로 잘 알려진 컨플루언스(Confluence)와 프로젝트 협업 도구 트렐로(Trello) 역시 아틀라시안의 제품.
https://www.atlassian.com/ko/software/jira/guides/expand-jira/jql#jql-syntax개발사 아틀라시안은 지라를 '애자일 팀이 사용하는 최고의 소프트웨어 도구'라 칭하고 있다. 물론, 이런 자부심에는 이유가 있는 듯했다. 프로덕트 팀에게 적합한 스크럼과 칸반 보드 템플릿을 제공하는 데다 다양한 플러그인을 활용할 수 있고, REST API를 제공하고 있어 외부 애플리케이션과 연동하기도 수월하다. 지라의 자체 JQL(Jira Query Language)을 활용해 복잡한 개발 환경 속에서도 세밀하게 이슈를 관리하거나 검색할 수 있다는 것 역시 하나의 이점으로 작용하고 있다.
JIRA에서 이슈 관리하기
여기서 말하는 이슈(issue)란 버그나 수정 사항, 의견 등 문제(Problem)를 아우르는 포괄적 개념을 뜻한다. 본문에서 이슈는 티켓(ticket)이라는 단어와도 혼용될 예정이다.
지라에서 관리할 수 있는 이슈 타입은 크게 아래와 같이 나누어볼 수 있다.
*필요에 따라 프로젝트 관리에서 이슈 유형을 추가, 변경할 수 있다.
흐릿한 기억을 더듬으며 n년 전, 코드스테이츠에서 배웠던 개념들을 다시금 떠올려 보았다. 애자일은 일을 단위로 쪼개어서 진행하는데, 최상위 목표인 테마부터 태스크까지로 나눠볼 수 있다. (Theme > Epic > Stories > Tasks)
스토리(Story) : 애자일에서 가장 핵심이 되는 단위. 스토리는 PM/PO가 작성하며, 스토리는 사용자에게 어떤 가치(경험)를 줄 수 있는지, 누구나 쉽게 이해할 수 있는 문장으로 작성한다. '비행기 티켓 예매 시스템'이라는 문장 속에는 수없이 많은 사용자 경험이 내포되어 있다. (이는 사실상 테마에 가깝다.) 이 문장을 쪼개어 하나의 사용자 경험 관점으로 보면, '사용자는 여행을 떠나기 위해 비행기 시간을 확인할 수 있다.'가 하나의 스토리가 될 수 있다. (WHO-WHAT-WHY)
에픽(Epic) : 에픽은 여러 개의 스토리가 모여 이루는 집합이다. 이 역시 PM/PO가 작성하며, 애초에 단 한 번의 스프린트로는 달성할 수 없기에 이를 스토리로 세분화하게 된다. 사실상 제품의 주요 기능에 가깝고, 프로젝트의 마일스톤이 된다. [사용자로서, 비행기 티켓을 조회하는 사이트가 필요하다.]
버그(Bug) : 제품이나 소프트웨어에서 발생하는 문제점을 일컫는다.
서브 태스크(Sub-Task) : 스토리를 만족시키기 위한 실제 개발 작업 단위를 말한다. 가장 작은 단위의 작업이라 볼 수 있다. 서브 태스크의 작성 주체는 주로 개발자인데, 팀바팀. 부바부일 수 있다.
이슈 필드별 의미 톺아보기
Assignee : 태스크를 수행할 실질적인 담당자를 의미한다.
Labels : 이슈를 필터링할 때 사용할 수 있는 레이블이다. 주로 파트, 팀으로 구분하지만 목적에 따라 맞춰 사용할 수 있다.
Priority : 우선순위를 설정할 때 사용한다. 우선순위는 총 4단계(Highest, Medium, Low, Lowest)로 구분한다.
Story point estimate : 제품 백로그 항목을 완전히 구현하는 데까지 필요한 개발 소요 기간 단위. 스토리 포인트를 할당할 때는 모든 팀원이 참여해야 하며, 작업 복잡성과 리스크를 고려하여 스토리 포인트를 할당한다. 스토리 포인트는 어디까지나 추정치에 불과하지만 우선순위 설정과 프로젝트 진행 상황을 추적하는데 용이하고, 진행 가능한 수준으로 업무 단위를 세분화하는 것에 도움이 된다. 단, 이를 맹신하고 개인의 업무 생산성으로 직결시키는 판단은 위험하다.
Start date & Due date : 업무의 시작 일자와 마감 일자.
프로젝트 생성
프로젝트 보드는 주로 칸반 또는 스크럼 형태를 이용한다. 칸반 보드는 백로그를 모두 보여주고, 스크럼은 스프린트에 포함되는 백로그만 노출 시켜준다. 이때 스크럼 템플릿을 선택한 뒤, 칸반 보드를 활용하고 싶으면 스프린트를 먼저 시작하고 보드 view를 실행해야하며, 스프린트 내 포함되는 백로그를 칸반 형태로 확인할 수 있다.
스프린트 백로그
스크럼 > 칸반 보드칸반 보드의 Group by를 서브 태스크 형태로 설정하면, 스토리 하위의 서브 태스크를 손쉽게 확인할 수 있다. 어사이니 형태로 설정 시, 담당자 기준으로 이슈를 필터링해서 볼 수 있다.
스프린트 플래닝
스프린트 플래닝은 이번 스프린트의 목표를 확립하고, 진행할 업무(Epic~Sub-task)에 대해 PO와 개발자가 함께 이야기하는 자리다. 태스크를 진행할 담당자를 배정하고, 해당 태스크에 소요되는 스토리 포인트를 *플래닝 포커로 추산한다.
*플래닝 포커는 스토리 포인트를 최대한 객관적으로 추산하기 위한 전략. 팀원들끼리 마치 포커를 치듯, 해당 태스크에 소요되는 예상 작업 시간을 추정하고 의논한다. 서로의 시간 추정치에 대해 의견 차이가 크다면 왜 그런 차이가 발생하는지 이야기해보고, 시간을 재추정 해본다. 이때, PO가 스토리 포인트의 상한선을 정해두는 게 좋다. 상한선을 넘을 정도로 오랜 시간이 걸리는 작업은 스프린트 내 진행 가능한 크기로 더 세분화하여 진행할 필요성이 있다.
데일리 스크럼
팀원들과 매일 오전 15~20분 내로 스크럼을 진행한다. 어제 어떤 내용을 작업했는지, 진행 중 발생한 특이사항이나 이슈가 있는지 등을 팀원 간에 공유하고 업무 간 조정이 필요할 시 빠르게 수정 반영한다. PM, PO는 데일리스크럼과 더불어 작업 진척 상황을 아래와 같이 시각화해서 확인할 수 있다.
지라는 위와 같은 번업 차트부터 시작해 번다운 차트, 속도 보고서 등 다양한 형태의 보고서를 제공하고 있다. 번업 차트는 스크럼 템플릿에만 적용되며, 하위 태스크(Sub-task)의 스토리 포인트는 차트에 반영되지 않는다. 차트 사이의 거리는 곧 앞으로 남아있는 작업 양이라 예상할 수 있다.
스프린트 리뷰(회고)
스프린트 리뷰 시간에는 해당 스프린트를 진행한 팀원 모두가 참여해 목표를 달성했는지 리뷰하고, 결과물을 확인하는 자리다. PM/PO는 스프린트 리뷰를 통해서 나온 팀원들의 의견을 취합하여, 다음 스프린트는 어떻게 진행할지 계획을 구체화하고 제품 백로그를 수정한다. 회고는 Keep, Problem, Try 형태 또는 팀 내부적으로 합의된 방향으로 진행한다.
Sprint 결과가 플 팀의 예측(추정치)를 얼마나 충족했는가?
Sprint 중간에 작업 범위가 얼마나 변동되었는가?
Sprint 기간 내에 완료되지 않은 업무가 있는가?
만일 완료되지 않은 업무(이슈 사항)가 있었다면, 어떤 이유에서였나?
마무리
오늘은 지라 프로젝트를 생성하고, 스프린트 플래닝부터 리뷰까지 운영하는 방법을 알아보았다. 앞서 언급했듯, 지라는 문서화에 특화된 컨플루언스와 뛰어난 연동성을 가지고 있는 도구이다. 두 도구를 연동해서 어떻게 더욱 효과적으로 사용할 수 있을지, 개발팀이 아닌 다른 팀과 협업하기에 용이한 플러그인은 어떤 것들이 있는지 살펴볼 예정! :)
