안녕하세요? FE플랫폼팀 effie 입니다!
저희 파트에서는 일정을 공유할 때 기획서를 보며 User Story[1]를 작성합니다. 작성한 User Story를 기준으로 Feature List[2]를 만들고, 이 Feature List의 MD[3]를 산정해 일정을 공유합니다.
[1] 개발해야 할 대상 제품이나 서비스의 기능을 정의하는 방식으로 사용자 입장에서의 비즈니스적인 가치를 정의하는 데 초점을 두고 요구 사항을 정리하는 실천법
[2] User Story를 충족하기 위해 개발해야 하는 기능 목록
[3] 작업량을 나타내는 개념으로 작업량은 사람 수 x 시간으로 표현함
MD는 man-day로 예를들어 1MD 이면 1명의 사람의 하루 작업량을 의미함
지난 카카오맵의 ‘사용자 장소 제보’ 프로젝트를 하며 처음으로 User Story와 Feature List를 만들고, 일정을 산정하여 협업 담당자분들에게 공유했었습니다. 프로젝트를 마친 후 아쉬운 점이 있어, 이번 신규 프로젝트 일정 산정에는 아쉬웠던 점을 최대한 보완하여 반영해 보고자 몇 가지 목표를 잡았습니다.
- 협업 담당자가 이해할 수 있어야 한다.
- 상세할수록 좋다.
- 함께 개발할 동료도 무엇을, 언제까지 할 수 있는지 이해할 수 있어야 한다.
1. 협업 담당자가 이해할 수 있어야 한다.
우리 모두는 협업하는 동료입니다. 직군은 달라도 만드는 서비스는 같기에 서비스에 대한 이해가 같아야 하며, 기능에 대한 일정도 협업 담당자가 이해할 수 있어야 합니다.
User Story 작성 시 서비스 사용자의 입장에서 무엇을 할 수 있는지를 중점으로 작성했습니다.
동일한 작업으로 보이지만 실제 구현에는 차이가 있는 A 기능과 B 기능이 있을 때, 개발 담당자는 구현에 소요되는 시간적 차이가 어디에 있는지 알 수 있지만, 다른 직군에서는 그 차이를 이해하기 어려울 수 있습니다. 이런 부분들은 메모로 설명을 추가하였습니다.
“이해를 돕기 위해 설명이 담긴 메모를 추가하였습니다”
2. 상세할수록 좋다.
카카오맵 ‘사용자 장소 제보’ 프로젝트를 할 때는 User Story를 상세하게 잡지 않았습니다. 그러다 보니 개발을 할 때 고려하지 못한 부분들이 튀어나올 때가 있었습니다.
그래서 이번에는 User Story를 작성할 때 최대한 한 가지 기능을 꼭 포함하도록 작성했습니다. 이 한 가지 User Story를 개발하는데 어떤 작업이(Feature) 필요한지 작성하고, 이것을 토대로 일정을 잡았습니다.
3. 함께 개발할 동료도 무엇을, 언제까지 할 수 있는지 이해할 수 있어야 한다.
사실 이 글을 쓰게 된 가장 큰 이유입니다.
지난 카카오맵 ‘사용자 장소 제보’ 프로젝트 일정은 저 혼자 User Story, Feature List를 작성하고 함께 개발할 동료에게 피드백을 받아 협업 담당자에게 공유했었습니다. 실제로 메인으로 개발할 사람은 제가 아니었지만 ‘나도 개발자이고 동료도 개발자이니 비슷하게 생각할 거야’ 라고 착각했습니다. 이러한 방식으로 동료에게 일정 MD까지 ‘짜잔’하고 완성본을 공유한다면, 피드백을 주기가 쉽지 않을 수 있으며, 기능에 대한 이해 없이 고려해야 할 부분에 대해 생각해보지 않고 그냥 넘어가기가 쉽습니다.
위의 ‘2. 상세할수록 좋다’ 와 이어지지만 함께 개발할 동료들도 무엇을 해야 하는지 함께 이해할 수 있어야 하기 때문에 이번 프로젝트에서는 기획서를 하나하나 꼼꼼히 살펴보고, 잘 모르는 부분은 담당 기획자에게 물어보며 약 200개 정도의 User Story를 작성하였습니다. 이로써 우리가 프로젝트에서 해야 할 ‘무엇을’ 까지는 완성되었습니다.
함께 개발할 동료들에게 작성한 User Story를 공유하고 ‘언제까지’는 어떻게 작성해보면 좋을지 의견을 나눴습니다. 성격 급한 저는 (사람은 같은 실수를 반복..) “제가 미리 작성해 볼까요?” 하고 의견을 드렸지만, 맘씨 좋은 동료들은 일정을 같이 산정해 보는 게 좋을 것 같다고 했고 어떤 방법이 좋을지 머리를 맞대고 고민했습니다.
200개가 넘는 User Story를 각자 나눠서 하는 방법은 시간은 줄일 수 있지만 자신이 작성한 부분만 이해하게 되거나 비슷한 기능인데도 작성한 사람마다 다른 일정이 산정될 수도 있고, 분명히 작년에 제가 했던 실수처럼 놓치는 부분이 생길 수도 있습니다.
Feature List에 대한 일정 산정을 한쪽 의견에 치우치지 않고 함께 논의할 수 있는 방법이 뭐가 있을까 고민하다가 한 동료가 포커처럼 동시에 각자 생각하는 일정을 오픈하는 ‘플래닝 포커(Planning Poker)’를 제안해서 이번 프로젝트 일정 산정은 플래닝 포커를 해보기로 했습니다.
플래닝 포커(Planning Poker)
그래서 플래닝 포커가 뭐야?
애자일 방법론 책을 읽다 보면 일정 산정 부분에 플래닝 포커라는 단어를 본 적이 있지만 직접 하는 건 처음이었습니다. 읽고 지나가서 잘은 모르지만 어떤 작은 기능 정도를 스토리 포인트로 정한 다음 동료들이 해당 기능에 대해 이해하고, 이 스토리를 개발하는데 시간이 얼마나 걸릴지 서로 스토리 포인트를 제시하고, 너무 크면 쪼개고 하는 것으로 이해했습니다. 우리는 스토리 포인트는 정하지 않았지만 일정의 최소 단위는 0.5MD, 최대는 2MD로 정했습니다.
플래닝 포커 (feat. 원격근무)
일정 산정은 코로나19(COVID-19)로 원격근무 중이라 Google Meet로 진행했습니다. 서로 얼굴을 보지 않고 잘 해낼 수 있을지 걱정이 되기도 했지만, 오히려 원격근무라 서로에게 집중이 더 잘 되었습니다.
만약 회사였다면 ‘잠깐 쉬고 할까요? 커피 마실래요?’ 하며 집중하지 못했을 것 같은데요,
Google Meet은 동시에 말하면 소리가 잘 들리지 않기 때문에 차례대로 말하며 서로의 목소리에 더 귀 기울이는 암묵적인 룰이 있었던 것 같습니다.
진행은 User Story를 작성한 제가 1depth는 주로 무엇을 할 수 있는 페이지인지 해당 페이지의 2,3depth에 주된 흐름을 기획서를 보며 설명한 후, 동료들이 차례대로 제 설명과 User Story를 보고 궁금한 기능에 대해 물어보고 답변하는 형태로 진행했습니다.
최소단위가 0.5MD이기 때문에 너무 작은 Feature들이나 관련이 있는 Feature은 묶어두었습니다. 그 후 Feature 뭉치에 대한 일정을 서로 이야기하고 왜 그렇게 정했는지 들어본 후, 최종적으로 일정을 정했습니다.
플래닝 포커를 도입한 일정 산정에는 세 명이서 2시간, 2시간, 1시간 반 정도 논의해서 총 5시간 30분 정도의 시간이 소요되었습니다. (User Story만 약 200개이기 때문에..)
“포커, 어디까지 쳐봤니? (feat. 원격 근무)”
비슷한 기능이지만 조금 더 상세해진 User Story와 Feature List
아래 이미지는 지난 카카오맵 ‘사용자 장소 제보’ 프로젝트 User Story와 Feature List의 일정 부분입니다.
- 카카오맵 ‘사용자 장소 제보’ 프로젝트 일정 부분
다음은 위에 언급한 세 가지 목표를 반영한 신규 프로젝트의 User Story와 Feature List입니다. 협업 담당자와 개발자 모두 이해할 수 있도록 구체적으로 작성되어 User Story와 Feature List가 개선된 것을 확인할 수 있습니다.
- 신규 프로젝트 일정 부분
함께 한 동료들과의 회고
effie.seo
- 우리가 어떤 서비스를 만들 것인지 User Story와 Feature List를 통해 협업하는 동료들 모두가 이해하는데 도움이 된 것 같습니다. 지도 서비스를 오래 했기 때문에 으레 이건 이렇게 하겠지라고 생각했던 부분들을 새로운 시각으로 한 번 더 생각할 수 있어서 좋았고, 꼼꼼하게 작성한다고 했음에도 플래닝 포커를 하며 동료들 덕분에 놓친 부분을 알 수 있었습니다.
- 방법론은 정해진 규칙이 없습니다. 이건 이렇게 해야 해서 또는 안 해봐서 시도하지 않는 것보다 우선해보고 맞는 방법을 찾으면 되는 것 같아요, 하다 보면 더 좋아질 것이고 서로를 이해하고 배운 점이 있다면 충분히 좋은 시도라고 생각합니다.
- 다만 이번 신규 프로젝트 일정 산정을 하면서 아쉬웠던 점은 생각보다 많은 리소스가 필요했습니다. 기획서를 통해 기능을 따라가며 User story를 뽑았고, 그 후 담당 기획자와 궁금한 부분에 대한 논의를 했으며, 플래닝 포커를 위해 함께 한 동료들이 프로젝트를 파악하고, 각 기능마다 플래닝 포커를 진행하는데 꽤 많은 시간이 소요 되었는데요! 짧은 시간안에 파악해서 일정을 산정하기 조금 버거운 부분이 있었습니다. 프로세스 개선이 필요한 부분도 있겠지만, 기회가 된다면 신규 서비스를 진행할때 부분 부분을 공유받고 그 부분들부터 조금씩 해나가 보는것도 좋을 것 같습니다.
jj.cho
- 기획서를 완전히 소화하는 일은 시간이 많이 소요되는 작업입니다. 사전에 effie가 기획서의 모든 기능들을 User Story로 만들어 준 덕분에 요구 사항을 이해하는 시간이 훨씬 단축되었던 것 같습니다. 또한 플래닝 포커를 하지 않고 세 사람이 각각 기획서를 이해하고 기능을 정의했다면 기능 정의나 커뮤니케이션에 소요되는 시간의 총합이 훨씬 컸을 것 같아요!
- 어떤 기능을 어떻게 개발하면 좋을지, 참고할만한 서비스 내 다른 기능이 있는지, 기능을 구현할 때 주의해야 할 점이 무엇인지 사전에 파악할 수 있었던 점이 좋았습니다. 그 과정에서 나온 의견들을 기록으로 남겨두었기 때문에 실제 구현할 때 좀 더 수월할 것으로 예상됩니다.
- 또한 원격근무였기 때문에 동료들 간 사소한 농담이나 잡담이 그리울 때가 있었는데, 플래닝 포커를 시작하기 전이나 포커를 하면서 주고받는 다양한 이야기들이 거리는 떨어져 있어도 혼자 일하고 있는 게 아니라는 점을 상기시켜주었습니다.
- 플래닝 포커에는 각자 예상한 소요 일정을 미리 이야기하지 않고 동시에 카드를 오픈함으로써, 누군가의 의견에 치우치지 않게 해야 한다는 룰이 있습니다. 이번에는 몇 가지 이유(오디오가 맞물리는 현상, 기능이 엄청 많은 프로젝트라서 일정 산정 소요시간이 꽤 길었다는 점)로 이 룰을 적용하지 않았지만 다음번에 기회가 된다면 공평한 의사결정을 위해 동시에 카드 오픈하기 룰까지 적용해보면 좋을 것 같습니다.
cayde.abdo
- 일정을 산정한다는 것은 추상적인 작업에 대해 구체적인 정량화를 한다는 것을 의미합니다. 그러나 작업자 개개인은 객관화될 수 없으며, 어떤 기준으로 판정을 하던 그것은 주관적이라고 생각합니다. 이번 플래닝 포커를 통해 개개인의 주관적인 일정을 제3자로 하여금 보다 객관화할 수 있다는 점과 작업자 간 공감할 수 있는 일정을 산정할 수 있어서 좋았습니다. (+ 추가적으로 완성된 일정이 수정되는 경우보다, 던진 의견이 즉각 수정되어 반영되는 쪽이 덜 고통스러웠습니다..)
- 대개 여러 명이 참여하는 프로젝트의 경우, 같은 기획서를 두고도 동상이몽 하는 경험을 필연적으로 겪게 되는데요, 디테일한 기획서가 아닌 초안의 경우에 특히 그렇습니다. 이는 같은 Feature를 두고도 각자 다른 일정을 산정하게 되는 결과를 만들어 내곤 합니다. 결국 프로젝트를 풀어나가기 위해서 의견 조율의 과정이 필요한데, 플래닝 포커를 통해 프로젝트에 대한 전반적인 이해도를 높이기 좋았습니다.
- 아쉬운 점은 시간과 집중이 많이 필요합니다. 플래닝 포커는 기본적으로 상호 커뮤니케이션을 지향하기 때문에 참여도가 저조하면 재미도 효과도 없습니다. (포커를 치는데 계속 다이만 하는 상황..) 혼자 산정할 때보다 과정도 많고, 개별 Feature에 대한 논의도 해야 하니 시간 소모가 큽니다. 이번 플래닝 포커의 경우에도 200여 개의 Feature를 대상으로 진행되었고(한꺼번에 작업 가능한 단위로 묶으면서 80여 개 정도로 줄어들었습니다), 개별 Feature에 대해 이해하고 해당 일정을 던져야 하기 때문에 일반적인 회의보다 많은 참여와 집중을 요구하였습니다. (feat. 원격근무)
- 간접적으로 느껴지는 진행자의 수고가 매우 큽니다. 진행자는 구체적인 Feature List를 뽑고, 정의되지 않은 기능에 대해 정리하고, 준비되지 않은 동료 개발자를 이해시키며, 담당 기획자에게 공유하며 서로의 이해를 맞추는 과정을 보면서 참석자에게 반성과 자아성찰을 불러일으켰습니다.. : )
마치며
서비스 개발을 하면서 그리고 프로젝트 협업을 하면서 느낀 것은 ‘나’ 보다는 ‘다른 사람’의 눈으로 바라보면 조금 더 좋은 결과로 이어지는 것 같습니다. 또한 실수와 피드백을 통해 한층 더 성장하는 것 같습니다. (사람은 같은 실수를 반복..)
프로젝트 진행시 User Story와 Feature List를 작성하고 일정 산정을 앞둔 개발자에게
저의 경험이 도움이 되었으면 좋겠습니다. 그리고 플래닝 포커는 신규 프로젝트 일정을 잡을 때 한번쯤 해보면 좋을 것 같습니다.
마지막으로 함께 포커를 쳐 준(?) 동료들에게 감사의 인사 전하며 글을 마치겠습니다.
감사합니다.
함께 하면 좋은 글
