[실행하기-팀빌딩] 액션#2: 스크럼(Scrum)문화

요즘들어 백엔드팀의 면접진행과 다양한 업무 피드백, 평가로 인해 블로그 작성이 뜸해졌던 부분 개인적으로 반성합니다.

1. 스크럼이란?

아마 IT업계에서 일하시는 분들이라면 모두가 많이 들어보기도 했고 알고 있겠지만 용어 정의부터 하겠습니다. 스크럼을 말하기에 앞서, 애자일(Agile)에 대해서 먼저 이야기를 하자면

하나의 프로덕트를 조립식 로봇을 만들듯이 짧은 기간의 목표를 수행해나가며 완성해나가는 개발 방식입니다.
예를 들면, 첫 주의 목표는 로봇의 머리형태를 만들고 / 두번째 주의 목표는 로봇의 눈 코 입을 만들고 / … / 여섯번째 주의 목표는 다리를 만들고 / 일곱번째 주의 목표는 조립되어있는 머리와 몸통 다리를 합치는 작업을 하는 것과 같습니다.

이러한 애자일 철학에 맞게 일을 하게 된다면 중간중간에 마무리 되는 회고를 통해 피드백은 더욱 빨라지고 우리가 만들고 있는 프로덕트가 과연 정상적으로 흘러가고있는 것인지, 개선해야할 부분이나 이슈가 있는지 빠르게 인지하여 유연하게 요구사항들을 변경해서 개발할 수가 있습니다.

애자일 철학에 맞게 생겨난 방법론이 바로 ‘스크럼’, ‘칸반’, ‘XP’ 등등이 있습니다. 현재 잡플래닛 백엔드팀은 ‘스크럼’기반으로 일을 하고 있습니다.

‘스크럼’은 육상 단거리달리기에서 전력질주를 한다는 뜻의 스프린트(sprint) 용어를 IT업무에 접목시켜, 위에서 언급한 ‘프로젝트의 형태를 단기작업을 통해 빠르게 각각의 모듈을 만들어나가는 과정’을 수행합니다.
스프린트의 과정은 아래와 같은 사이클을 가집니다.

저의 첫 스크럼 개발방법 경험은 ‘와이즈넛 검색엔진연구소’에서 겪어봤으며, 솔루션 회사에서 겪었던 경험을 토대로 서비스 회사에 맞게 접목시키려는 노력을 했습니다.

2. 주요 용어 설명

위의 스프린트사이클 그림에 나오는 각각의 용어에 대한 의미를 정리합니다.

백로그(Backlog)

• 제품을 개발하는데에 필요한 기능들을 정리한 요구사항 내용들입니다.
• 크게 프로덕트 백로그와 스프린트 백로그로 이루어집니다.
  • 프로덕트 백로그(Product Backlog)
    • ‘대기중인 TASK’입니다. 보통은 PO(Product Owner)가 원하는 기능들을 단위별로 기입을 하는 것이 정석이지만, 백엔드팀만의 스크럼문화안에서 실행하고 있기 때문에 현재 레거시코드에서 기술부채로 자리잡고있는 테스크들을 관리하고 있습니다.
    • 상황에 따라 수정 또는 삭제가 가능한 레벨이며, 작업의 우선순위를 관리합니다.
  • 스프린트 백로그(Sprint Backlog)
    • ‘현재 진행중인 TASK + 단기간 목표안에 있는 TASK’입니다.
    • 진행중인 테스크이므로 더이상의 수정과 삭제는 불가능한 레벨이며, 작업을 하면서 이슈가 있어서 딜레이가 되는 부분은 회고를 통해 논의하며 새로운 Sprint Backlog로 이동하여 다음작업으로 이어지도록 합니다.

스프린트(Sprint)

• 목표 작업 기간을 의미합니다.
• 보통 스프린트는 각 회사/각 부서마다 다르게 지정하며 짧게는 1주일~ 길게는 1달 기간으로 지정을 합니다. 잡플래닛 백엔드팀은 2주간격으로 본인의 목표(Sprint Planning)를 세워서 업무를 수행합니다.
• 스프린트가 진행되는 동안에는, 데일리스크럼(Daily Scrum)을 통해 본인이 어제 마무리 지은 업무와 오늘 진행해야할 업무가 무엇인지 공유합니다.
• 스프린트가 종료되는 날에는, 회고(Retrospective)를 통해 계획했던 업무들이 정상적으로 처리되었는지 체크와 함께 중간에 어떤 이슈들이 있었는지 논의를 하는 것과 동시에 현재 겪고 있는 개발고충에 대해 허심탄회하게 이야기를 합니다.
  
  

3. 스크럼문화가 자리잡히는 과정(2022년)

2022년 3분기부터 백엔드팀은 스크럼문화를 자리잡힐수있도록 시도를 했습니다. (이 시기가 아틀라시안 JIRA를 도입한 시점이기도 합니다.)

처음에는 ‘기록하는 습관’과 ‘계획하는 습관’을 몸에 익히기 위해서 JIRA의 본인 티켓을 만들어서 2주동안의 계획대로 업무를 수행하는 루틴이 익숙해지도록 별다른 ‘간섭’ 없이 자유롭게 사용을 했습니다.
단, 스프린트가 바뀌는데 계속해서 딜레이 되고 있는 업무에 대해서는 이슈체킹을 했고 정상적으로 끝낼 수 있도록 여러가지 솔루션을 제공했습니다. 결론적으로 작년의 백엔드 스크럼문화는 ‘계획’과 ‘실행’에 대해 중점을 두었으며 별다른 회고없이 제가 팀원분들의 현 작업상황을 매니징해주는 용도로 많이 활용 되었습니다.

처음부터 정석으로 진행하지 않은 이유는, JIRA를 경험해보지 못한 팀원들도 많이 있었기 때문입니다. 개인적으로 JIRA 툴은 손에 익숙해지는데까지 꽤 진입장벽이 있는 솔루션이라고 생각을 했고(저도 첫 직장에서 JIRA를 이해하는데 꽤 오래 걸렸던 것으로 기억합니다.) 처음부터 ‘강제적으로’ 밀어붙이기보다는 숨고르기가 필요했다고 판단했기 때문입니다.

4. 스크럼문화가 자리잡히는 과정(2023년)

다들 JIRA 업무에 대해 익숙해졌을 시점인 2023년 올해부터는 조금 더 일하는방식을 세분화하기 시작했습니다.

스프린트는 2주 방식으로 유지하며,
격주 스프린트가 시작 되는 월요일마다 30분은 각자 플래닝을 알아서 진행하되,
플래닝을 하는 방식은 조금 더 세분화하여 ‘하루에 끝낼수 있을만한 계획’ 을 잡을수 있도록 규칙을 잡았습니다.

지양하는 플래닝 형태

• 게시판을 개발한다(x)

본인의 계획을 더 세분화하는 플래닝 형태

• 게시판의 글쓰기 기능을 개발한다.(o)
• 게시판의 목록 보여주기 기능을 개발한다.(o)
• 게시판의 글 수정 기능을 개발한다.(o)
• 게시판의 글 삭제 기능을 개발한다.(o)
• 게시판의 목록 페이징 기능을 개발한다.(o)

자연스럽게 계획은 더더욱 많아졌으며, 프로덕트를 개발함에 있어 개개인의 ‘모듈화’시각 또한 더 좋아졌다고 판단합니다.

스프린트가 끝나는 날에는 약 2시간동안 회고를 하는 문화도 시도했습니다.

회고에서 이루어지는 내용은

• 완료된 테스크에대한 공유 및 동료들의 피드백
• 중간에 치고 들어온 업무에 대한 부분과, 이로 인해 영향받은 계획들 공유
• 현재 겪고 있는 프로세스 및 개발고충에 대한 의견
• 번다운 차트(Burn Down Chart) 확인

의 내용이 주를 이룹니다.

여기서 ‘중간에 치고 들어온 업무’의 경우 사실 스크럼에서는 진행중인 스프린트에 절대로 넣으면 안되는 것 이 정석적인 규칙이지만(Hotfix또한 프로덕트 백로그로 쌓는 것) 잡플래닛이라는 ‘서비스 회사’의 특성상 실제 경험하는 유저들에게 크리티컬한 버그나 예상치못한 피드백을 받을 경우가 있기 때문에, 우리의 상황에 맞게 커스터마이징을 하여 일하는 정책을 세웠습니다.

회고 문화가 서서히 자리에 잡히면서 느낀점은, 여러명의 개발자 각자 하는일이 다르기 때문에 프로덕트적인 공유가 잘 안 이루어졌었는데 이 과정을 통해 더욱 더 긴밀한 공유를 할 수 있었고 더 나아가 아키텍쳐적으로도 다같이 추가 논의를 함으로써 진행중인 프로덕트가 더욱 더 단단하게 만들어진다는 장점을 느꼈습니다.

5. 앞으로 더 딥하게 시도할 부분

백엔드팀의 인원수는 현재 12명이며, 2주동안의 스프린트가 가동되었을 때 할 수 있는 워킹시간은
12(인원수) * 8(하루업무시간) * 10(2주동안 휴일없이 진행할 수 있는 일수) = 총 960시간
입니다.
여기서 저는 서비스운영회사의 특성을 고려하여 하루업무시간을 6시간 으로 권장합니다. 즉, 권장 플래닝 시간은
12(인원수) * 6(권장업무시간) * 10(2주동안 휴일없이 진행할 수 있는 일수) = 총 720시간
으로 산정이 되는 것을 목표로 하고 있습니다. 나머지 시간은 중간중간 들어오는 업무들에 대한 hotfix backlog의 시간을 보장하고 있는 것입니다.

사실 이렇게 보장시간을 부여하고 있음에도 지금까지는 ‘0’으로 완료되는 번다운차트의 결말을 아직 보지는 못했습니다.

물론 이해는 합니다. 계획 된 시간동안 모든 코드가 완벽하게 짜여질 수는 없으며 중간중간 레거시로 인한 사이드이펙트로 인해 디버깅 시간또한 길어질수 있기 때문입니다. 또한 1분기 이후 잡플래닛의 조직이 점점 커짐과 동시에 큰 변화(스쿼드 체제로의 조직 구성 변화)가 이루어지고 있기 때문에 이로 인해 신경써야 하는 부분도 많아지다보니 계획대로 이루어지지 못한 부분들이 많이 있었습니다.

전사 조직의 변화가 안정화 되어가고있는 과정에서, 이제는 백엔드팀의 스프린트 결과도 조금 더 엄격하게 지켜봐야 할 시기인 것 같습니다. 계획된 목표가 ‘0’ 까지는 아니더라도 ‘80%~90%’ 수행의 결과는 나올 수 있도록 ‘개개인이 집중할 수 있는 환경’이 될 수 있도록 노력을 해보도록 하겠습니다.
번다운 차트에서 제공해주는 가이드라인에 맞춰서 계단식으로 예쁘게 내려가는 차트를 보는 것이 저의 소망(?)입니다.ㅎㅎ

참고: 백엔드팀의 스크럼을 진행하는 세부적인 규칙에 대해서는, 다음에 작성 될 블로그 글에서 더 자세하게 다루도록 하겠습니다.

(번외) 워터폴 방법론

워터폴(Waterfal) 개발방법론이란 ‘폭포수 모델’이라고도 불리우며, 흔히 SI에서 많이 진행되는 과정인
‘요구사항 분석 > 기획 > 디자인 > 개발 > 테스트 > 제품출시’
의 순차적인 순서로 개발 단계를 밟는 밥법론을 말합니다.

흔히 ‘워터폴은 안좋다’ 라는 인식이 있는데, 그 이유로는 중간 개발과정에서 요구사항이 바뀌었을 때 개발자들은 수정을 해야 하는 이슈가 발생하여 다시 기획 디자인의 과정을 기다려야 하는 딜레이현상이 이루어지기 때문이기 때문입니다. (폭포는 위로 올라갈수 없는 특징을 가지고 있죠.)

하지만 워터폴 또한 전통적인 개발 방법론의 하나로, 상황에 따라 오히려 애자일 보다 더 단단하게 개발이 될 수 있다고 보는 입장입니다.

제 관점이나 경험으로 봤을 때 워터폴은 ‘목표와 보여지는 결과가 매우 뚜렷한 사업 관련 프로젝트’ 에서는 더 큰 강점이 있다라고 생각합니다. 이미 요구사항이 제대로 잡혀있으며, 꼭 해야할 당위성에 대한 100% 공감형성이 이루어져있기 때문에 기획에서 테스트까지 자연스럽게 내려오면 되기 때문입니다.

제가 백엔드팀의 개발하는 방식을 애자일(스크럼)로 한 이유는, 비즈니스모델을 계속해서 탐색해야하고 이것을 검증하기 위한 프로토타입을 많이 보여줘야하는 역할을 해야하기 때문에 ‘기민하게 움직이며 요구사항 변화에 대해 관대한’ 애자일 문화가 맞다고 보여져서 선택을 하게 된 것입니다.