[코드스테이츠 PMB14] 애자일과 스크럼 그리고 스프린트... 도대체 그게 뭔데

사람들과 일하는 방식은 다양합니다. 그 중에서 워터폴과 애자일 프로젝트 방법론을 비교하는 글을 많이 볼 수 있습니다. 지금은 아니지만 애자일이 막 떠오르는 그 당시, 워터폴은 구식이고 꼰대 기업에서 하는 방식이니 별로다, 애자일이 트렌디하고 젊은 기업에서 차용하는 방식이니 좋다 등의 기조가 있었던 것 같아요. 하지만 그 방식의 옳고 그름을 떠나 일의 범위, 리소스, 시간 등 다양한 요인을 고려하여 프로젝트 방법론을 결정하는 것이 적절합니다.

출처: 위키피디아

 

워터폴(Waterfall) 방법은 ‘요구사항 ➡️ 분석 ➡️ 디자인 ➡️ 개발 ➡️ 테스트 ➡️ 운영’ 순으로 step by step 방식으로 진행됩니다. 단계별로 업무가 순서에따라 완성되면 다음 단계로 넘어가는 형식이 폭포수처럼 내려가는 것과 같아서 워터폴 방법이라 부릅니다.

애자일(Agile) 방법은 ‘우리는 진짜 고객을 모른다’라는 생각으로 시작해 진짜 고객을 찾기 위해서 시장에 제품을 빠르게 내놓고 고객이 만족할 때까지 수정하며 앞으로 나아가는 방법입니다. 애자일한 조직 운영을 위해 칸반, 스크럼, 스프린트 등 다양한 방법론, 프레임워크가 개발되었습니다.

이번 포스팅에서는 애자일 조직에 대하여, 그리고 애자일한 조직을 실현시켜줄 수 있는 ‘스크럼’ 프레임워크에 대하여 중점적으로 다루려 합니다.

애자일: “우리는 진짜 고객을 모른다” 진짜 고객을 만나기 위해 빠르게 제품을 내놓고 빠르게 실패하고, 빠르게 수정한다. 스크럼: 조직이 빠르게 제품을 내놓고 빠르게 실패하고 빠르게 수정할 수 있도록 도와주는 일하는 방식 스프린트: 스크럼 프레임워크가 작동하도록 짜는 반복적인 개발 주기(회사에서 정하는 이터레이션이 개발 주기가 된다. 계획 회의부터 제품 리뷰가 진행되는 날짜 까지의 기간이 1스프린트 이다)

1. 프로덕트 매니저로서 스크럼을 관리하는 과정에 필요한 업무 요소

역할 1: 프로덕트 가치 극대화

- 핵심가치

그 일의 핵심이 무엇인지 파악하고 거기에 집중해서 일해야합니다. 예를들어 매주 퍼널별 전환율을 트래킹하는 것이 업무라고 해요. 전환율을 왜 분석하는 건지, 분석에서 어떤 인사이트를 뽑을 건지, 인사이트로 어떻게 반영할 것인지 등 뾰족함을 만들어주는 것이 핵심가치입니다. 그 핵심은 고객가치와 기업가치를 중심으로 MVP를 만들고 수정해가는 일이고요. 프로덕트 매니저는 팀원들에게 우리의 핵심가치는 무엇인지 상기시켜주고 모두가 같은 방향을 보고 나아갈 수 있도록 지원해야합니다.

- 투명성

종이접기를 하는데 혼자 끙끙대서 종이 비행기를 접어오는 게 아닌 색종이 색깔, 종이 접는 과정을 함께 공유하면서 종이 비행기를 만들어나가는 거에요. 날개를 접는 데 어렵다면 옆에 팀원이 도와줄 수도 있지요. 프로덕트 매니저는 질문을 하면서 팀원이 날개를 더 잘 접을 수 있도록 유도합니다. 혹은 색깔을 고르기 어려워하는 팀원에게 먼저 다가가 어떤 것이 문제인지 상황을 체크할 수 있습니다.

- 높은 적응성

스크럼 프레임워크는 빠른 MVP를 통해 제품이 시장의 수요에 알맞게 적응할 수 있습니다. 시장의 트렌드에 따라서 MVP에 반영을 할 수 있는데요. 프로덕트 매니저는 프로덕트가 잘 살아남을 수 있도록(이왕이면 사랑받을 수 있도록) 시장 트렌드를 파악해야합니다.

 

역할 2: 프로덕트 백로그 관리

프로덕트 백로그란 본격적으로 프로덕트 개발 프로세스가 시작되기 전 프로덕트가 정식 출시되기까지 해야할 일 목록입니다. 쉽게 말하면 To-Do List 입니다. 할일을 유저스토리로 작성해 할 일이 누구를 위한 일인지, 고객의 어떤 니즈, 어떤 JTBD 을 위한 일인지 파악하면 사용자관점으로 생각할 수 있습니다.

- 우선순위 정하기

프로덕트 출시를 위해서 여러가지 할일 들이 있고, 그 큰 할일들 밑에 또 세부적으로 해야할 일들이 있을텐데요. 그렇게 많은 할일 목록이 산더미처럼 쌓여있다면 어떤 것부터 해야할지 막막하기만 합니다. 그 막막함을 잠시 뒤로 미뤄두고 당장 해야할 일을 순서대로 차곡차곡 정리하는 것, 바로 우선순위 정하기입니다.

 

이때 프로덕트 매니저는 구성원이 업무를 할 때 잘 집중할 수 있는 환경을 만들어줘야 합니다. 다시 말하자면, 멀티태스킹을 최소화할 수 있도록 업무의 캐파(capacity)를 잘 파악해 분배해야 하는데요. 사실 현업에서 일대다는 기본이죠. 하나만 할 수 없습니다. 항상 문어발처럼 이 프로젝트, 저 프로젝트 다 담아두고 있죠… 그렇기 때문에 구성원들이 함께 일하며 단시간 내에 하나의 문제점을 해결하기 위한 프레임워크인 스크럼을 잘 활용하는 거죠. 앞서 언급한 투명성, 즉 과정을 함께 공유하면서 나아가는 겁니다.

 

사실 동시에 처리해야 할 업무가 두세개 있더라도 내 안에서 우선순위를 다시 정하면 됩니다. 멀티태스킹처럼 보이는 것도 중요도(마감기한) 순서대로 다시 나열하면 되니깐요.

- 시간관리: 플래닝 포커와 마감기한

우선순위 정하는 데에 가장 많은 영향을 미치는 요인은 바로 ‘시간’입니다. 실제로 일을 하게 되면 ‘이 일 얼마정도 걸릴 거 같아요?’라는 말을 종종 듣습니다. 내가 자주 했던 업무라면 대략 마감기한을 제시하고 서로 조율을 할 수 있죠. 하지만 한번도 해본 적 없던 업무에 대한 마감기한은 어떻게 정해야할까요? 그럴 때 사용하는 방법 중 하나가 바로 ‘플래닝 포커’입니다.

 

예를 들어 비슷한 과거 프로젝트의 기한을 기준으로 8년차 상사는 1일 이라고 말하고 2년차 사수는 3일, 나는 5일이라고 얘기했을 때 협업하는 구성원의 역량과 시간을 고려해 신규 프로젝트 일정을 잡을 때 유용합니다.

 

효과적인 시간관리를 위해서 선택과 집중이 필요합니다. 빨리 처리할 수 있는 일, 마감기한이 촉박한 일 등 일을 마무리하기 위해 시간을 고려해 할 일을 관리합니다. 프로덕트 매니저는 팀이 지치지 않고 계속해서 나아갈 수 있도록 명확한 의사결정으로 우선순위를 정하고 시간을 적절히 계획해야합니다.

 

---

 

2. 실제 스프린트가 진행되는 과정에서 중요하게 생각해야 하는 점

스프린트란 최소 1주일 최대 한달 가량 팀이 집중해서 일하는 기간을 입니다. 보편적으로는 2주 기간으로 설정해 진행합니다. 기간이 너무 길면 스프린트 목표가 흐지부지해질 수 있는 반면, 기간이 너무 짧다면 잦은 플래닝 미팅, 리뷰, 회고는 팀원에게 피로도를 불러올 수 있기 때문에 적정한 선의 기간을 고려해야합니다. (스프린트 기간에는 정답은 없으니 조직, 팀의 상황에 맞게 적용하면 됩니다.)

 

1) 스프린트 플래닝

스프린트 플래닝에서는 프로덕트 오너가 이번 스프린트에서 할 일을 공지하고 팀원들은 각각 맡을 업무를 어떻게 진행할지 공유하는 자리입니다. 이때 스프린트의 목표 정의가 완성되어 있어야 합니다. 플래닝 단계에서 목표를 다시금 상기시켜 스프린트 기간동안 목표를 달성할 수 있도록 이끌어야 합니다.

 

2) 데일리 스크럼

데일리 스크럼이란 매일매일 팀원들이 모여 어제 한 일, 오늘 할 일에 대해 15분간 이야기하는 시간입니다. 데일리 스크럼을 통해 팀에 원활한 소통이 가능하며 팀이 가지고 있는 고민은 무엇인지, 문제점이 발생했다면 어떻게 해결할 것인지 파악해 빠른 의사 결정을 돕습니다.

 

3) 프로덕트 백로그 다듬기

프로덕트 백로그는 프로덕트 개발 프로세스를 위해 해야할 할일 목록을 말합니다. 프로덕트 백로그는 스크럼이 시작되었다고 해서 건들이면 안되는 목록이 아니라, 상황에 맞춰 우선순위도 바뀔 수 있으며, 할일이 추가되거나 삭제될 수 있습니다. 이때 프로덕트 오너가 전면 권한을 가지고 백로그를 수정할 수도 있지만 팀원들이 백로그를 보고 의견을 제시하면서 바꿔나갈 수 있습니다. (다시 말하지만 스크럼에서 중요한 것 중 하나가 바로 투명성입니다!)

 

4) 리뷰와 회고

리뷰는 완료한 일에 대해 이야기 하는 자리이며, 회고는 일을 완료하면서 들었던 생각, 일의 방식에 대해 이야기하는 자리입니다. 왜냐하면 리뷰와 회고에 참석하는 인원부터가 다르기 때문입니다. 리뷰는 제품과 관련된 이해관계자인 고객, 의사결정자, 팀원 등이 참석해 결과물에 대해 논의하는 자리입니다. 그리고 그 의견을 바탕으로 프로덕트 백로그를 다시 다듬어 다음 스프린트에 반영하기도 합니다.

 

회고는 스프린트를 운영한 팀원만 모여 일의 방식에 대해 논의합니다. 소통에 걸림돌은 없었는지, 사용하는 툴이 일의 효율을 떨어트리는지, 완료에 대한 정의가 서로 결이 맞지 않다던지 등 팀원 간 더욱 좋은 협업을 위해 합을 맞추는 시간입니다. 회고에서 가장 중요한 키워드는 협업의 효율입니다.

 

 

---

나가며…

생각해보면 저도 실무에 있을 땐 조직 전체의 방향성을 보았을 땐 워터폴 형식으로 일하고 팀 관점으로 바라본다면 애자일하게 업무를 했습니다. 다만 그때 일하면서 “우리 팀은 애자일하게 일해야해!”라고 생각을 하지 않고 일을 효율적으로 하되 나의 최대 캐파(capacity)를 끌어올릴 수 있는 방법으로 프로젝트 로드맵을 그렸던 것 같습니다.

실제 현업에서는 “우리는 칸반 방법론을 씁니다!!!!” 라던지 “스크럼 프레임워크를 지향합니다” 등의 칼로 무를 베 듯이 정해진 애자일 방식은 없다고 생각합니다. 각 운영하는 조직, 팀, 프로젝트에 맞춰 적절하게 장단점을 버무려 활용하는 게 실무라고 생각합니다.

하지만 방법론에대한 지식이 있고 없고의 차이는 크다고 생각해요. (모르는 놈이 무섭다고 하는 것처럼… )오늘 애자일, 그 중에서도 스크럼에 대한 이론을 배우며 프로덕트 관점을 넓히는 좋은 기회였습니다. 앞으로 실무에서 어떻게 잘 버무릴지 기대됩니다!

 

 

---

참고자료

https://youtu.be/2ukuT00ubuk

https://youtu.be/6YsgggG_hdM

https://tech.kakao.com/2020/09/08/planning-poker/

https://techblog.woowahan.com/2548/