최종 프로젝트 회고 (1) - 일정 관리

프로그래머스 데브코스에 참여한지 이제 거의 6개월이 다 되어간다. 현재는 최종 프로젝트 기간 중 QA 기간이라 포스팅을 쓸 시간이 생긴 것 같아 하루에 겪었던 이슈들을 하나씩 정리해보려고 한다. 그 중에서는 일정 관리 부분이 가장 중요했던 것 같다고 생각하여 이를 얘기해보고자 한다.

서론

프로젝트를 진행하기 전에 프로그래머스에서 '일하는 우리'의 지윤정님의 강의를 통해 협업에 임하기 전에 배워야 할 태도와 애자일 방식의 프로젝트 관리를 방법을 간단하게 배우게 되었다. 

 

저번 1차 클론 코딩 프로젝트에서는 제대로 진행이 되지 않았지만, 최종 프로젝트에서는 애자일한 협업을 한 번 해보고자 마음을 먹었다.

 

팀원분들이 대부분 내향적인 성격을 가지신 MBTI I로 구성이 되어있었다. 스크럼을 이끌어가는 것은 그래도 주도적인 사람이 끌고 가는 것이 나을 것 같다는 의견이 나왔고 자연스럽게 MBTI가 E인 내가 스크럼 마스터가 되었다. 또한, 스크럼 마스터가 되어서 졸업 프로젝트에서는 제대로 하지 못했던 일정 관리를 이번에는 더 발전 된 모습으로 해보고자 스크럼 마스터라는 역할을 맡는 것도 좋다고 생각했다.

스프린트 관리 방식

우리 팀은 1주일을 단위로 스프린트를 계획했다. 그리고 쏘카의 CTO 분께서 강연에서 해주신 말씀을 따르기로 했다.

스프린트 막바지에 꼭 팀끼리 데모데이를 가져보세요.
MVP를 산출하고, MVP에 대해서 데모데이를 가져서 서로가 피드백해나가는 과정이 정말 중요합니다.

애자일한 프로젝트 진행방식을 통해 모두가 MVP를 구현하기 위해서 최선을 다하고, MVP가 구현이 되면 프론트, 백이 합쳐서 지금까지 구현 된 MVP가 얼마만큼 잘 완성이 되었는지, 그리고 우리가 시간 산정에서는 잘 못한 부분은 없었는지, 또 더 나아가 개선 할 수 있는 부분은 없는지 확인하고 싶었다.

 

이러한 생각을 팀원분에게 전하였을 때 다들 너무 좋은 생각인 것 같다고 말씀을 해주셨다. 벌써 기분이 좋았다. 열정있고 잘 따라주는 팀원들! 어쩌면 프로젝트가 기획했던 것보다 더 일찍 끝나서 고도화를 오래 할 수도 있지 않을까? 란 생각을 했었다.

 

프로젝트 시작 첫 1주차 어떤 것을 개발 할 지, MVP는 무엇으로 잡는게 좋을지, 프론트, 백엔드 팀 간의 코드 컨벤션은 어떻게 가져갈지 팀 문화는 어떻게 가져가는 것이 좋을지에 대한 얘기는 신속하고 변경 가능한 부분은 빠르게 변경하면서 PO를 정함으로써 결정하기 힘든 상황에서는 PO가 결정 할 수 있도록 하여 빠른 속도로 기획이 끝내게 되었다.

 

해당 기획서를 멘토 및 매니저님에게 전달 드렸을 때 어렵지 않게 컨펌을 받을 수 있었다. 기획서가 컨펌이 되지 않을 것을 우려해 3개를 만든 것이 잘 한 선택 이었던 것 같다. 팀원들이 다들 자신의 의견을 주저없이 피력하며 커뮤니케이션이 원할하게 이루어졌기에 만들 수 있는 결과였다.

 

첫 단추는 이렇게 잘 꿰어졌지만 이후부터는 일정 관리에서 부족한 부분들이 하나씩 드러나기 시작했다.

 

스프린트 이슈

매주 스프린트마다 MVP를 정하고 해당 기능을 팀원끼리 데모데이를 하자는 목표를 이루지 못했다. 먼저, MVP를 백엔드 팀이 구현하기 이전에 Front 팀에서 초기에 세팅해야 될 부분이 많아서 오래 걸린다는 얘기를 전해듣게 되었다.

 

멘토님들과 식사를 가지면서 들었던 말씀 중에 "원래 프론트보다 백엔드가 MVP를 구현하는데 더 적은 시간이 든다"고 말씀을 해주셨다. 따라서, 팀원들하고 MVP를 빨리 구현을 하고 남은 시간에는 인프라를 건드리거나, 추가로 다음 MVP를 구현하기 위해서 미리 팀원들을 위한 다른 기능들을 만드는 것도 좋을 것이라고 판단하여 우선 데모데이는 그 다음주로 미루게 되었다. 

 

하지만, 이후에도 스프린트가 생각한 대로 진행되지 않았다.

스프린트를 계획할 때 스토리 포인트를 작성하여 유저 스토리를 구현하는데 필요한 예상 시간을 산출하고 이를 통해, 목표한 시간까지 구현이 되었는지를 확인하는 검토 과정이 필요했다. 그러나 이를 예측하고 구현하는 것은 미래를 예측하는 것과 유사하지 않을까? 라는 생각이 들었기에 이를 하지 않았는데 이것이 큰 착오였던 것 같다.

 

3주가 지난 중간 발표 이후에도 계속해서 MVP 기능이 완성되면 데모데이를 해보자고 하였는데도, 아직 안 되어있는 부분이 많다는 얘기가 돌아왔다. 

 

하지만, 이미 벌어진 일은 어쩔 수 없는 부분이기에 직접 프론트분들의 스케줄 관리를 하기 시작했다. 그리고 이는 프론트 팀원들에게 힘들었을 수 있지만, 팀적으로는 좋은 결과였던 것 같다.

 

내가 도와드린 부분은 크지 않다.

1. 먼저 MVP 에서 구현이 덜 된 부분이 무엇이 있는지 정리.

2. 이 중에서 가장 빠르게 할 수 있다고 생각되는 부분들을 체크

3. 그리고 본인의 예상시간을 정리하고, 스프린트에 맞게 끝낼 수 있도록 매일 체크

 

팀 전체를 관리를 하게 되면서 스크럼 시간이 15분을 초과하게 되었지만, 그 효과는 굉장히 좋았던 것 같다.

프론트 팀원분들의 능률 또한 올라가게 되었고 나 또한 스토리 포인트를 만드는 것이 얼마나 중요한지를 깨닫게 되었다. 

 

결과적으로 이 글을 작성하고 있는 지금 원래 계획은 QA를 2주 정도를 가져갈 계획이었지만 QA를 하기 위한 시간은 약 5일 정도의 시간이 주어지게 되었다.

 

하지만, 그 전에 쿼리 성능 테스트와 인프라 및 모니터링을 미리 준비해두고 QA를 위한 시나리오를 짜두었기에 매일마다 진행되는 QA는 원할하게 진행되고 있다. 무엇을 하던 앞으로 일어날 상황에 대해서 미리 준비를 하고 대비해두면 안 좋은 상황에서도 돌파구를 찾을 수 있다는 것을 다시 한 번 깨달았다.

 

회고

결과적으로, 이번 프로젝트를 하면서 앞으로 내가 프로젝트를 임할 때 가져가야 될 행동에 대해서 어떤 것이 가장 중요 할지에 대해서 정리를 해봤다.

 

1. 구현하는데 오래 걸릴 것 같은 것, 익숙한 것, 배워야 하는 것이 있는지를 구별한다. 먼저, 익숙한 것에 대한 구현 시간을 먼저 잡는다. 실제로 이번 프로젝트에서는 구현을 하기 위해서 배워야 하는 것들이 너무나도 많았는데, 이를 구현하기 위한 시간을 제대로 산정하지 못했기 때문이다. 욕심보다는 우선 순위가 더 중요하다.

 

2. 서로 간의 믿음으로 알아서 잘 흘러가겠지 라는 생각을 버리기! 팀원들을 서로 믿는 것도 중요하지만 때로는 원할하게 흘러가지 않을 수 있다. 그리고 스크럼은 이를 파악하기 위한 가장 중요한 시간이라고 생각한다. 비즈니스적인 관계에서 무한한 신뢰를 가지지 않기.

 

3. MVP를 빠르게 구현하는 능력을 기르기. 종종 MVP를 구현하다가 보면 엣지 케이스들을 많이 마주치게 된다. 이러한 엣지 케이스를 잘 관리하는 것이 개발자의 덕목이지만 가끔 보면 기획적인 부분들을 고민을 하게 된다.

ex) 범죄가 일어날 가능성이 있는데 이걸 어떻게 해결하지?

이런 고민들을 멘토님에게 말씀을 드렸을 때, 사업을 한다면 고려해야하지만 저런 부분들은 기획적으로도 법적으로도 통제 하기 어려운 부분들이 있다는 말을 전해들었다. 이러한 것들을 고민하는 시간보다 MVP를 위한 API를 하나 더 작성하자.

 

대략적으로 이렇게 3가지를 뽑아낼 수 있었다. 짧다면 짧고 길면 길었던 프로젝트 기간동안 앞으로 내가 어느 회사의 팀원으로서 가져야 할 자세에 대해서도 많은 부분을 상기 할 수 있는 좋은 시간이었다.