Agile(애자일) 조직, JIRA(지라)로 일하기
IT본부장으로 살아남기 #6
본부장(이사)라고 하면 왠지 사원들과는 무언가 달라 보이지만, 실상을 놓고 보면 회사에서 살아남기 위해 몸부림치는 한 명의 회사원이랍니다. 중견 교육업계에서 월급쟁이 중 한 명인 IT본부장으로 재직하면서 배웠던 다양한 조직 운영과 업무에 대한 지식과 경험을 공유하려고 합니다.
최근 많은 스타트업이 애자일한 개발 방법론을 도입하여 컨플루언스나 JIRA 그리고 Slack과 같은 다양한 협업 툴을 활용하여 업무를 진행하여 업무의 효율성을 높이고 있다.
lean 하게 업무성과를 만들어내고, 효율적으로 업무를 수행하기 위해서는 무엇보다 협업 툴의 적극적인 활용이 중요하며, 아래는 주요한 업무 협업(??) 툴 중에 하나인 JIRA를 가지고 어떻게 일하는지에 대해서 작성해 놓은 문서이다.
이 글을 읽고 이해하기 위해서는 JIRA와 컨플루언스를 어느 정도 사용해본 경험이 있어야 좀 더 수월할 것으로 생각된다. 나중에 기회가 되면 Atlassian 사의 주요 협업 툴인 JIRA(지라)와 Confluence (이하 컨플)에 대해 자세히 설명하도록 하겠습니다.
아래의 각 용어의 정의와 방법들이 업무의 효율성을 높이기 위해 Agile 조직에서 JIRA로 일을 하는 하나의 사례로 참고해주시면 좋을 것 같다.
Scrum(스크럼)의 멤버 별 기본 업무 R&R
스크럼을 프로젝트에 기반한 하나의 팀으로 보는 것이 가장 적절하며, 스크럼 내의 모든 인원은 수평적인 의사결정을 수행함.
스크럼 내 멤버별 업무는 어떻게 해야 한다라고 정해진 것은 없으며, 각 스크럼 내의 논의를 통해 업무에 대한 R&R 을 조정하면 좋음
PO (Product Owner)
PO는 스크럼 마스터와 엔지니어가 하지 않는 모든 일을 한다. UI 기획, 청소, 품의서 작성, 엔지니어 기분 나쁠 때 기분 풀어주기, 술 사주기, 상위 기획서 쓰기, 보고서 쓰기, 지출결의서 작성 등등
해당 스크럼의 Product에 대한 Owner (쉽게 말하면 주인장??)
업무의 우선순위를 정하며, 외부와의 커뮤니케이션을 담당, 엔지니어들이 업무를 편안하게 할 수 있는 커뮤니케이션 허브 역할을 한다. (기획 업무 중 PM 역할)
SM (Scrum Master)
개발 Lead의 역할로 Daily Scrum Meeting을 주제 하며, 서기 역할을 담당함
엔지니어들의 리소스를 조율하는 역할, 부족한 리소스를 찾아오는 역할, Tech Lead의 역할도 같이 수행함
Member
열심히 개발을 해주시면 됨
개발 외의 업무는 SM와 PO에게 모두 떠넘기면 됨.
모든 의사결정은 스크럼 내에서 최종 의사 결정되는 것을 원칙으로 해야 속도가 남, 스피드의 핵심을 빠른 의사결정! (그렇지 않으면 Waterfall과 같아요…!!)
일일 미팅 (Daily Scrum Meeting)
매일 진행하며, 미팅 진행 시 Jira 프로젝트 티켓 기준으로 진행
플래닝 하는 날(스프린트 첫날)과 회고하는 날(스프린트 마지막 날)은 진행하지 않음
미팅은 가능하면 업무를 시작하기 전인 오전에 진행하는 것을 추천함.
어제 한일 / 오늘 할 일 / 이슈를 2~3분 내외로 짧게 발표
기타 논의가 필요한 일에 대해 별도 회의 일정을 잡고 진행, 가능하면 스크럼은 15분 내외 완료할 것, 스크럼 미팅이 회의가 되지 않도록 주의할 것 (코딩할 시간도 부족해요, 회의는 가능하면 짧게)
가능하면 한자리에 모여서 서서 진행함 (상세 논의가 필요한 사항은 별도 회의를 통해 논의)
플래닝 (Planning)
플래닝은 스프린트 기간 내 해야 할 업무들의 범위와 방향을 정하는 중요한 회의로 최소 1시간 이상 모든 스크럼 멤버들이 참여하여 진행한다.
플래닝은 초기 플래닝과 중간 플래닝으로 나뉠 수 있으며 초기 플래닝은 아래와 같다.
초기 플래닝
PO는 이 프로젝트에 대한 목표 / 목적 / 방향성 / 기대효과 / 매트릭스(KPI or 지표) 등을 사전 준비하여 스크럼 멤버들에게 사전 배포하고, 스크럼 멤버들이 프로젝트의 방향성에 대해 함께 고민을 할 수 있도록 한다.
서브 프로젝트 수준으로 조금 큰 단위로 에픽을 먼저 정하고, 각 에픽(Epic)에 필요한 상세 업무(Story)들을 정하며, sub-task는 각자 별도로 정한 후 Story의 sub-task로 입력한다.
초기 플래닝의 핵심은 모든 멤버들의 프로젝트에 대한 공감이다. 내가 이 프로젝트를 왜? 해야 하는지에 대해 공감을 시키는 것은 PO의 가장 중요한 역할이며, SM과 멤버들은 프로젝트 진행에 좀 더 적극적으로 아이디어와 본인의 생각을 개진하는 것이 좋다. (시키는 일만 하는 사람은 싫어요?)
초기 플래닝의 경우 거의 워크숍 수준으로 짧으면 1시간 길면 3~4시간까지도 진행함
해당 스크럼(팀)의 1년 치 대략적인 업무를 정하는 워크숍 정도로 생각하면 좋음
중간 플래닝
중간 플래닝은 백로그 중 다음 스프린트 기간 동안에 수행 가능한 업무를 선정하는 플래닝으로 진행하게 된다. 2주 단위로 수행이 가능한 업무를 정하는 격주간 업무 회의 정도로 생각하면 좋음
플래닝과 상관없이 그때그때 생각나는 아이디어는 back log에 충실하게 작성해 놓자, back log는 우리의 아이디어 원천이 되는 공간으로 생각하자.
스프린트 (Sprint)
스프린트는 산출물을 배포하기 위한 기본 단위이며, 해당 기간 동안에는 무조건 산출물이 나와야 한다. 개발 완료된 결과물 이거나 Prototyping 된 Mockup 산출물도 괜찮음
2주 단위 또는 4주 단위를 사용하나 가장 일반적으로는 2주 단위를 사용한다.
각 스프린트의 단위는 각 스크럼 내에서 논의 후 정한다.
회고 (다른 말로 결과 리포트)와 코드 리뷰
모든 스프린트가 완료되는 날에는 반드시 회고를 진행한다.
예) 2/24(월) ~ 3/6(금) 까지가 스프린트라면 2/24(월) 에는 플래닝, 3/6(금) 에는 회고를 진행한다.
회고의 경우는 모든 참석자가 참석하며, 코드 리뷰는 개발자에 한정하여 별도 회의 일정을 잡고 진행한다.
코드 리뷰의 경우도 필요에 따라 PO와 다른 사람도 참석이 가능함. 코드 리뷰는 코드에 대한 비난(??), 지적질이 되지 않도록 해야 함 (마음에 상처 주면 안돼요!)
회고의 작성은 컨플루언스 내 별도의 공간을 생성하여 반드시 작성해야 하며, PO 가 작성함.
회고의 내용은
목표
산출물
잘한 점
아쉬운 점(잘못한 점)
개선할 점
이슈 사항
스프린트 Jira Resource data (참여인원별 리소스 현황, 황영 팔 30h, 홍길동 20h, 황 가렌 10h)
하루는 5h 기준 1개월 20 day, 100h 기준, 월 5백만 원을 비용으로 산정함
스프린트 내 Jira List는 Jira의 필터 & 커플 연동 기능을 활용하여 작성함
프로모션 등을 진행했다면, 프로모션에 대한 목표, 결과도 포함한다.
티켓(JIRA 이슈)의 기본 작성 가이드
업무를 최대한 상세하게 쪼개서 작성하기, 가장 기본 업무 단위를 sub-task
sub-task는 가능하면 반나절 또는 하루 안에 해결이 가능한 업무 단위로 상세하게 쪼개서 작성하는 것이 좋음
하루에 1~2개의 티켓을 완료하는 것을 목표로 함
예제
Epic : 학습관리 시스템 고도화 (v0.5)
Story : [기획] 학습 관리 시스템 고도화 기획
sub-task
[기획] 모의고사 화면 SB 작성
[기획] 문풀 훈련소 SB 작성
[기획] 문제은행 SB 작성
에픽 작성 기준
스크럼 내에서 진행되는 모든 프로젝트는 스크럼 전용 지라 프로젝트에 등록함, 스크럼 내 프로젝트 단위는 에픽을 기준으로 하여 생성 운영함
에픽은 한 개의 스프린트를 기준으로 해당 스프린트 기간을 초과하지 않도록 작성하지 않는 것이 좋음
어트랙션 1차 스프린트 기간을 2주라고 할 때, 2주 안에 해결이 가능하도록 에픽의 업무 단위를 산정하는 것이 좋으며, 스프린트 기간 내 해결이 불가할 경우 스프린트 기간을 조정하거나, 에픽을 두 개로 쪼개는 것이 좋음
예제
1차 스프린트
Epic : 학습 관리 서비스 고도화 (v0.5) - 기본 기능 구현
2차 스프린트
Epic : 학습 관리 서비스 고도화 (v0.7) - 문제 연동 기능 구현
Story 작성 기준
단위 업무 단위로 작성하며, 스토리의 경우 작업시간이 최대 일주일을 넘기지 않도록 작성
Sub-Task 작성 기준
Story에서 작성된 업무를 세부적으로 쪼갬 (하루 단위 또는 반나절 단위가 제일 좋음
1일 1~2 티켓 처리 목표로 업무를 진행
레이블 작성 기준
업무형태별 예) 운영 / 신규
각 업무 범위별 : 학습관리 고도화 / 모바일 웹 개편 / PC 홈페이지 개편
업무 직무별 : 상위 기획 / SB / 개발 / 디자인 / 퍼블 / QA
요청부서가 있는 경우 요청부서 : A 팀 /B 팀 / C 팀 / D 팀
Jira 티켓으로 일하는 방법
출근한 후
Jira 프로젝트 > 보드를 브라우저 내 기본 화면으로 설정함
보드 우측 상단에 그룹화 기준을 하위 작업으로 설정
Jira 보드를 보면서 내가 해야 하는 일일 업무 현황 판으로 활용하면 좋음
Jira에 없는 일은 내가 해야 하는 일이 아님
다른 말로 하면, 내가 하는 모든 업무는 Jira로 기록되고 남겨져야 함.
업무시간 중에
슬랙 / 행아웃 / 메일 등 다양한 공간에서 논의된 내용을 티켓에 잘 취합해서 작성해 놓는다. commnet 또는 설명에 해당 내용을 모두 작성함
산출물도 모두 티켓 내에 포함한다. (JPEG, UI 기획 산출물, Flow chart 등등, HTML 코드 등)
향후 Jira 티켓 (story or sub-task)만 보더라도 업무 파악과 인수인계가 될 수 있도록 하기 위함.
퇴근할 때
내가 작업했던 티켓 (Story 혹은 sub-task)에 작업 시간을 꼭 입력한다.
작업했던 업무의 Status를 알맞은 위치로 옮긴다. (해야 할 일, 진행 중, 퍼블, 디자인, 개발, QA, 배포 등)
작업시간은 꼭 입력하자. 작업시간은 향후 유사한 프로젝트 진행 시 예측을 위한 기초 자료로 활용하며, 향후 회고시 실제 프로젝트의 ROI 측정을 위한 지표로 활용하기 위함
