스크럼, 입고팀이 애자일하게 일하는 법 1부

1. 글을 시작하며: 다양한 사람들은 어떻게 함께 일할까

안녕하세요. 입고팀 입사 6개월차인 병아리 개발자입니다.

최근 MZ 세대를 중심으로 핫하게 떠오른 키워드는 뭘까요?

바로 MBTI입니다.

사람들과 친해지는 과정에서 한번쯤 꼭 물어보곤 합니다.

"컬리님, MBTI 뭐에요?"

평화로운 월요일, 입고팀 slack에서 우리는 흥미로운 결과를 발견했습니다. 파국 대잔치 바로 MBTI가 천차만별이라는 사실인데요. 그래서인지 각자가 선호하는 업무 방식, 커뮤니케이션 방식은 너무나도 달랐습니다. 이렇게 다른 우리 팀, 어떻게 함께 일하고 있을까요?

저희는 **'스크럼'**을 기반으로 애자일하게 일하고 있습니다.💪

2. 스크럼 도입 계기

기존에는 과제 하나당 각 사람이 만들 기능을 분배하여 개발을 진행했습니다. 각종 운영 이슈에 대응하며 촉박해지는 일정. 개발자들은 코드 리뷰를 하더라도 다른 사람이 만든 코드를 설계 레벨부터 완전히 이해하긴 어려웠습니다. 개발팀 전체의 도메인 이해도 증진과 개발 일정의 효율화에 대해 고민하던 끝에, 우리는 단 시간에 목표에 집중할 수 있는 스크럼을 도입했습니다.

3. Working agreement: 스크럼 운영을 위해 우리가 함께 정한 운영 방식

팀을 운영시 서로가 선호하는 방법은 다를 수 밖에 없습니다. 예를 들어 각자가 선호하는 배포요일이 다르고, 보고 방식도 다릅니다. 많은 팀에서 시니어의 의견이 우선이 되고, 그에 따라 팀 내부 업무룰이 정해집니다. 하지만 스크럼 팀 내에는 하부 팀이나 수직구조가 없습니다. 모두가 전문성을 갖고 업무에 주도적으로 임하기 위해 우리는 working agreement를 정리했습니다. 티켓 작성법, 각자의 역할, 회의 방식등 팀의 모든 업무 방식을 이 때 정한 덕분에 갈등이나 업무룰에 대한 혼란 없이 협업할 수 있습니다.

4 .애자일(Agile)과 스크럼(Scrum)의 정의

4.1 애자일이란

고객의 요구사항은 빈번하게 변경됩니다. 이에 민첩하게 대응하도록 프로젝트를 일정 단위로 쪼개어, 매 단위마다 결과물을 도출하는 프로세스입니다. 서비스의 요구사항 변경이 잦은 IT 업계에서 자주 쓰입니다. 이 때 주의할 사항은, 애자일은 단순히 빠르게 결과물을 도출하는 것이 아니라는 점입니다. "좋은 제품을 낭비 없이 빠르게 만들기" 위해 제품의 핵심 기능만 구현하며 우선순위가 낮은 기능들은 고려 대상에서 배제하거나 별도의 일정에서 개발합니다.

4.2 스크럼이란

프로젝트를 애자일하게 운영하기 위한 방법론 중 하나입니다. 참고로, 애자일 개발 프로세스는 다양한 방법론 전체를 일컬으며, 스크럼(Scrum) 외에도 칸반 프로세스(Kanban), 익스트림 프로그래밍(XP) 등이 있습니다. 출처: https://agileforall.com/resources/introduction-to-agile/

5. 스크럼팀 멤버 구성

스크럼팀은 작지만, 과제를 충분히 처리할 수 있을 만큼 커야 합니다. 적정 인원수는 보통 7명 내외입니다. 팀 구성원은 아래 3가지로 나뉩니다. 팀에 따라 한 사람이 PO와 스크럼 마스터를 겸하거나, 스크럼마스터와 개발자를 동시에 맡습니다.

5.1 PO(=Project Owner)

제품의 책임자이며, 백로그를 주로 작성합니다. 제품에 대한 비즈니스 요구 사항을 정의 할 수 있는 사람입니다.

5.2 스크럼 마스터(=Scrum Master)

스크럼이 잘 진행될 수 있도록 돕습니다. 각 Sprint 별로 처리할 Story Point를 산정하고, 팀원들이 스크럼중 이슈를 겪을 경우, 이를 해결하기 위한 중개자 역할을 합니다. 특히 외부 팀과 협업이 필요할 경우 소통 채널의 역할을 주로 맡습니다.

5.3 개발자(=Developer)

스크럼에서 칭하는 개발자는 소프트웨어 개발자만을 칭하는 것이 아닙니다. QA, 기획자, 디자이너등, 제품의 요구사항을 구현하기 위해 기여할 수 있는 모든 사람이 개발자에 포함됩니다.

6. 스크럼에서 사용되는 주요 용어

스크럼 운영 방식을 소개하기 전, 자주 등장하는 용어를 잠깐 설명하겠습니다.

6.1 스프린트(=Sprint)

말 그대로 목표를 향해 '전력 질주'하는 기간입니다. 통상적으로 2주를 잡습니다. 스프린트 기간 동안에는 다른 이슈는 우선 순위를 낮추고, Sprint에서 제시된 목표 달성만을 위해 팀원 전체가 기여합니다.

6.2 백로그(=backlog)

• 제품의 백로그 : 제품(예. 입고 서비스)에 부여되는 큰 과제들, 운영 이슈등입니다. PO는 주기적으로 backlog의 우선 순위를 조정합니다.
• 스프린트 백로그 : 해당 스프린트 내에 진행할 작업 목록입니다. 제품 백로그와 마찬가지로 우선 순위가 높은 순 ~ 낮은 순으로 나열됩니다.

7. 입고팀의 스크럼 운영 프로세스

스크럼은 스프린트(=2주)단위로 진행됩니다. 스크럼은 아래의 순서대로 진행 됩니다.

7.1 스토리 리뷰 - 주 1회 / 1시간 30분

• 용어 설명

  • 에픽(Epic) 에픽은 팀 내의 큰 목표입니다. 크게 신규 프로젝트, 기존 기능 개선 및 버그 수정 두가지로 나뉩니다. 에픽의 이름은 어떻게 정할까요? 신규 프로젝트 에픽은 주로 과제를 잘 나타내는 이름을 사용합니다. 예를 들어 물류센터간 재고를 이동하는 기능을 추가한다는 과제를 부여 받으면, 센터간 재고이동을 에픽의 이름으로 정하는 식입니다. 기존 기능 개선 및 버그 수정은 운영 및 장애 서포트라는 이름의 에픽에서 다루고 있습니다.
  • 스토리(Story) 에픽 내에는 요구사항이 여러 개 있습니다. 요구사항 하나를 스토리라 칭합니다. Jira 티켓을 기준으로 하나의 티켓은 한 개의 스토리만 포함합니다.
  • 스토리 포인트(Story Point) 작업의 난이도 입니다. 피보나치 수열을 기준으로 1,2,3,5,8,13 중 고를 수 있습니다. 한 티켓의 포인트가 너무 클 경우, 하위 과제 여러개로 나눌 수 있기 때문에 피보나치 수열을 사용합니다. 예를 들어, 5포인트의 과제는 2,3의 업무로 잘게 나눌 수 있습니다.

• 스토리 리뷰의 목적 및 주기

  개발자가 티켓을 맡아 작업을 시작할때 충분히 요구사항을 이해할 수 있도록 리뷰를 진행합니다. 입고팀은 주 1회 정기 스토리 리뷰 시간을 가집니다.

• 리뷰 대상

  신규 개발건 혹은 서비스 운영 중 보고된 이슈입니다. 리뷰 하루 전 대상 티켓들의 목록이 팀 내에서 정리되어야 합니다.

• 리뷰 진행 방법: 요구사항 이해 및 작업의 난이도 측정

  각 팀원은 리뷰할 티켓들을 전날 미리 읽어야합니다. 리뷰 당일, 팀원들은 미리 읽어온 내용을 바탕으로 티켓 작성자에게 궁금한 사항을 질문합니다. 리뷰 후 모든 개발자가 티켓의 요구사항을 이해하면 티켓에 스토리 포인트를 부여합니다.

  이 때 포인트가 너무 클 경우, 티켓을 작게 분리합니다. 참고로, 포인트는 작업 일수를 의미하지 않습니다. 팀에서 지금까지 해결한 과제에 상대적으로 점수를 계산합니다. 예를 들어, 기존에 개발된 출근체크 기능이 5포인트라고 가정하겠습니다. 이 때, 새롭게 퇴근 기능을 개발한다면, 기존의 출근체크 기능에 상대적으로 얼마나 개발 공수가 드는지 고려하여 포인트를 측정합니다. 포인트 부여시 PlanItPoker 를 사용합니다

  팀원들간 포인트 측정도가 다를 경우, 각자 왜 그렇게 생각하는지 근거를 이야기하고 최종 포인트를 산출합니다.

• 백로그에 티켓을 우선 순위대로 나열하기

  리뷰를 마친 티켓은 개발요건이 충분히 검토되었기 때문에 ready for dev 상태로 백로그에 추가됩니다.

7.2 Sprint Planning - 30분

스토리 리뷰 때 backlog에 추가된 티켓을 우선순위에 맞게 Sprint에 추가합니다. 한 스프린트 동안 완료할 스토리 포인트 목표치를 세우는 것이 중요한데요. 팀원 각자의 휴가 일정과 이전 스프린트의 스토리 포인트 완료 수치를 근거로 본 스프린트의 목표를 설정합니다.

예를 들어 팀원 한명이 하루 휴가 일정이 있는 경우, 목표를 낮게 설정합니다. 또한 이전 스프린트에서 목표한 스토리포인트 수치가 45였는데, 일정이 남아서 50을 해결했을 경우, 이번 스프린트에서는 47 정도로 팀의 목표를 높게 잡을 수도 있습니다.

7.3 티켓 할당 - 이전 티켓 종료시

개발자는 backlog의 최상단부터 차례로 티켓을 가져갑니다. 만약 새로 온 신규 입사자나 주니어가 처리하기에 어려운 티켓일 경우 , 개발팀 내 논의 하에 다른 티켓을 할당하는 것도 가능합니다.

7.4 daily stand up - 매일 / 15분

월~금 오전 10:30~10:45 에 15분간 7명이 각자의 이슈를 리포트합니다. 회의 시간은 가능하다면 15분을 넘기지 않아야 합니다. 어제 한 일 / 오늘 할 일 / 이슈 사항을 간단히 공유합니다. 이때, 더 디테일하게 이야기해야하는 내용이 있다면, 그 부분은 당사자들만 모여 스크럼 이후에 따로 논의합니다. 회의 시간이 짧기 때문에 중요한 내용만 이야기하면서도, 팀 전체의 생산성을 저하시키는 이슈들을 빠르게 파악할 수 있어서 좋습니다. 기획 사항에 대해 질문이 있거나, 수정이 필요할 경우, 기획자-개발자 커뮤니케이션을 바로 할 수 있다는 장점이 가장 큽니다.

7.5 배포 - 주 1회

팀마다 다르지만, 입고팀은 주 1회 화요일에 정기 배포를 진행합니다. 이전에는 티켓마다 배포일을 별도로 잡았기 때문에 커뮤니케이션 비용이 컸는데요. 정기배포 제도를 도입하면서 커뮤니케이션 비용을 절감할 수 있었습니다. 단 운영상의 급박한 이슈는 별도의 배포일정을 잡습니다.

7.6 Retro(회고) - 30분

2주간의 스프린트를 돌아보며, 다음 스프린트를 위해 우리가 프로세스에 도입할 과정을 논의합니다. 2번째 스프린트 종료 후 진행한 retro 회고시, 10분간 익명으로 의견을 작성합니다. 이때 회고는 "내가 이렇게 하지 못해서 아쉬웠다" 보다는 우리 팀 전체 프로세스에 대해 논의합니다. 이후 5분간 공감 가는 내용에 👍 이모티콘을 부여하며, 한 사람당 사용할 수 있는 이모티콘은 5개 내외입니다. 스크럼 마스터는 가장 많이 공감받은 피드백부터 팀 내 공유하는데, 이때 팀원들은 각 내용에 대해 자유롭게 이야기를 나눌 수 있습니다. 회고의 카테고리는 팀마다 다르지만, 크게 좋았던 것 / 지양할 것 / 지속할 것 으로 나뉩니다. 예를 들어 2주차 회고의 카테고리는 아래와 같습니다.

• start: 다음 스프린트 시작시 도입되면 좋을 프로세스
• stop: 이번 스프린트 이후로 하지 않았으면 좋을 내용
• continue: 이번 스프린트 때 좋았던 내용. 이후에도 지속하면 좋을 것들

회고가 끝난 이후에는 다시 Sprint Planning을 시작하며, 다음 스프린트를 진행합니다.

2번의 스프린트가 끝나면 한달이 지나있는데요. 매달 마지막 금요일에는 social hour를 한 시간 진행합니다. 팀원들은 진행자가 준비한 게임을 함께 즐기며 휴식을 갖습니다.

8. 글을 마치며

1부에서는 스크럼 운영 방안에 대해 간단히 설명 드렸습니다. 2부에서는 개발자 입장에서 바라본 스크럼은 어땠는지 공유 드리겠습니다. 부족한 글 읽어주셔서 감사합니다.