EEOS - 5월 1주차 진행 상황

서론

EEOS 프로젝트를 시작한지도, 어느덧 8개월이 지났다.

이전의 프로젝트들이 그랬던 것처럼, 과정이 사라지고 결과만이 남는 프로젝트가 되고 싶지 않았다. 그렇기에 꼭 블로그든 무엇이든지 간에, 고민의 흔적들을 남기고 싶었다.

스프린트가 끝나거나, 프로젝트가 업데이트가 될 때면, 블로그에 글을 남겨야겠다는 욕심은 들지만, 막상 블로그를 쓰려고 하면 너무 많은 것들이 쌓여 있어 시작도 전에 포기하곤 했다.

앞으로는 매주마다, 아주 짧은 글이여도 프로젝트에 대한 진행상황, 그리고 여러가지 고민들의 흔적을 남겨볼까 한다. 사실 지금의 포스팅도 PM 스터디를 위해 어쩔 수 없이(?) 작성하고 있지만, 오히려 다행이라고 생각한다. 늦었다고 생각했을 때가.. 가장 빠르지 않을까…

PM 관련 포스팅도 조금씩 올려보자 (제발..)

일정

기존의 블랙컴퍼니 1기를 떠나보내고, 새로운 팀원 FE의 Knotted와 BE Bellmin과 Dongda를 맞이하여 블랙컴퍼니 2기를 결성하였다. 3월부터 시작하여서 두 달을 함께했다. 3월에는 팀의 문화에 정착하고, 기존의 팀원들에게 인수인계를 받는 시간을 가졌고, 4월에는 2주간의 스프린트로 신기능을 출시하여 EEOS 2.2를 배포하였다.

팀원 모두가 대학생인만큼, 학사 일정에 맞추어서 프로젝트의 일정을 계획 보았다.

- WEEK 1 : 04.29(월) ~ 05.05(일)  - 회고 및 스프린트 준비
- WEEK 2 : 05.06(월) ~ 05.12(일) - Sprint 1
- WEEK 3 : 05.13(월) ~ 05.19(일) - Sprint 1
- WEEK 4 : 05.20(월) ~ 05.26(일) - 회고 및 스프린트 준비
- WEEK 5 : 05.27(월) ~ 06.02(일) - Sprint 2
- WEEK 6 : 06.03(월) ~ 06.09(일) - Sprint 2

회고 및 스프린트 준비

기존의 스프린트에 대한 회고와 다음 스프린트에 대한 준비를 팀 단위로 할 생각이다. 실질적으로 개발을 하는 과정은 아니지만, 팀에 있어서, 그리고 우리의 프로젝트에 있어서 가장 중요한 시간이 아닐까 싶다. 특히 다음 스프린트를 준비할 때에는 VOC를 면밀히 검토하여서 백로그를 추출하고, 다음 스프린트에 진짜 할 수 있는 것을 솎아내는 과정이기에 특히 내가 많이 신경써야할 부분이기도 하다.

Sprint

스프린트의 기간은 2주로 잡았다. 기존의 블랙컴퍼니 1기 팀원들과 함께할 때는 1주일이였다. 그렇게 한 이유는, 그때만하더라도 팀원들의 분야가 각자 다 달랐고, 공통된 목표를 갖고 스프린트를 진행하는 것이 현실적으로 어려웠기에, 단순히 개인의 목표를 공유하고 그에 대한 달성률을 체크하는 시간에 불과했다.
하지만 이번에는 WEB에 집중할 수 있는 팀원들이 구성되었고, 기능별로 스프린트를 진행할 수 있게 되었다. 실제로 2주동안의 스프린트 동안 기능들을 선정하여서 배포할 것하고, 이게 곧 EEOS의 업데이트가 된다.

회고의 원칙을 세우자.

팀의 회고방식은 KPT를 사용하고 있다. 여러가지 회고 방식이 있겠다만, 현재 동아리 내에 정착된 회고는 KPT이기도 하고 팀원들 모두가 익숙한 회고 방식이기에 KPT를 사용하였다.

그런데 가끔 KPT를 하다보면, 딱히 Keep할 것은 떠오르지 않고, Problem은 쏟아지지만 Try의 결론은 열심히 하자! 가 나올때는 회고 자체에 대한 회의감이 들기도 한다.

회고의 목적은 결국 발전이다. 기존의 상황에 대해 Keep할 것들을 찾아내고, Problem들을 말하는 것들은 결국 Try를 찾기 위함이고, 이를 다음의 상황에 적용하여서 더 좋은 상황을 만들어 내기 위해 하는 것이 회고이다. 결국 회고의 핵심은 Try이다.

사실 나도 기존까지는 회고를 위한 회고를 했던 것 같았고, 이런 문제를 해결하기 위해 회고를 더욱 더 신경쓰기로 하였고 몇가지 원칙들을 생각해보았다.

1. 구체적인 Try를 작성하자.

Problem 나아가 Keep에서의 것들에 대한 구체적인 행동강령을 만들 필요가 있다. 이번 팀원들과 회고를 공유해보자 한다.

Problem

• API를 설계할 때(슬랙 알람), BE가 설계하고 FE에게 통보하는 방식으로 진행했었는데 FE의 생각이 반영이 안되는 점도 있었고, BE만의 생각으로 설계를 하다보니 구조적인 결함 문제도 발생했다.
• guest모드에서 프론트단에서 단순히 이렇게만 해도 괜찮지 않을까? 라는 생각으로 독단적으로 판단 후 적용
  • 게시글 작성한 사람이 수정 및 삭제를 하지 못하게 되는 문제 발생
  • 백엔드와 긴밀한 논의가 부족하였다.

결국 이 문제의 핵심은 프론트와 백앤드 사이에서의 의사소통이 제대로 이루어지 않았다는 것이다. 그렇다면 이에 대한 Try가 단순히 의사소통을 잘하자! 에서 그치면 안된다. 핵심은 언제, 어떻게, 소통할지 고민하는 것이 구체적인 행동강령을 만드는 것이다.

- 이전의 회고록... 구체적인 행동강령이 필요하다..! 미안해요 1기 팀원들...

Try

• API 설계할때에 FE, BE, PM이 함께한다
  • 긴급한 이슈가 발생한때에는 비대면 전체회의를 진행한다.
• 아주 작은 상황이여도, 개발 채널에 진행상황을 공유하자.

우리 팀이 세운 Try이다. API 설계, 나아가 분야별로 이슈들이 발생하였을 때 분야끼리 회의하는 경우가 많았다. (백앤드의 이슈라면 백앤드끼리), 그렇다보니 PM인 나도 그렇고 FE도 그렇고 BE의 상황을 일주일에 한번뿐인 정기회의에 공유를 받았다. 공유를 받는 것보다 짧게나마 회의에 참가하는 것이 더 적은 비용을 발생시킨다고 판단했기에 우리는 작은 이슈여도 비대면으로 전체 회의를 진행하기로 했다.

또한 Slack의 개발 채널이 최근 뜸해진 감이 있었다. 팀원들이 Slack에 추가가 되다보니 조금 부담스러웠던 것일까.. 아무튼 우리는 이제부터 최소 단위의 일이여도 개발 채널에 조금씩 공유하는 것을 목표로 하였다.

2. Try는 적용해야 의미가 있다.

그동안 이렇게나 많은 회고들을 했었는데, 이것이 잘 지켜졌는지 모르겠다.

사실 회고를 하고나면 일회성에 불과할때가 많다. 회고 시간을 잡아서 팀원들이 모이고, 열띤 토론을 거쳐 의견들을 공유하고 나서, 모두 회고 내용을 잊고 나간다.

보이는 것처럼 이제부터는 우리 팀의 노션의 가장 앞에 이렇게 회고를 정리하여 올리고자 한다. 아직 어떤 효과가 있을지는 모르겠지만, 그래도 매일 들어가는 노션의 가장 앞에 이렇게 적혀있다면 한번이라도 더 고민해보지 않을까…?