우리 사이드 프로젝트 할래요?

이번주에 첫 배포가 끝났다. 스프린트 기간을 2주로 잡고 우리는 어떤식으로 개발을 했고 현재 어떤 결과물을 만들고 성장했는지 공유하려고 한다. 그리고 이 글은 시리즈 글로 이전 스프린트를 기획해보자와 이어진다.

1 . 우리팀은요!

간단한 소개를 하자면 우선 우리팀은 FE-3, BE-3, Desginer-2, PM-2로 이루어졌고 각 포지션별로 결정권자가 있으면서 직군을 리딩했다.
팀빌딩부터 첫 기획의 아이디에이션까지는 처음부터 내가 전담했고, 이후 매니징은 PM이 진행했으며 나는 프론트엔드팀 리딩과 전체적인 팀의 소통을 전담했다.
그리고 프로젝트는 100퍼센트 온라인으로 진행했으며 온라인으로 진행하기 위해 사용한 툴들 Figjam, GatherTown, Slack, Notion을 적극 사용해서 회의를 갖고 회고를 진행하면서 최근에 팀 회식을 한번 가졌다.
이 과정이 궁금하다면 내가 현재 시리즈로 작성한 첫번째 글인 스프린트를 기획해보자를 참고 바란다.

2 . 이런식으로 개발했어요.

원래는 애자일 스프린트 방식으로 진행하면서 MVP를 정하고 빠르게 기능을 만들어서 배포하는 방식으로 가려고 했으나 서로 코드리뷰를 가지고 백엔드는 TDD를 통한 개발을 통해서 얻어가는것이 더 많다는 판단하에 우리는 기간을 2주로 Fix하고 서로의 성장에 집중했다.
또한 첫주가 끝날때쯤 간단하게 회고를 가졌고 최근 1차배포후 전체적인 회고를 가졌다.

Jira

우선 PM이 Jira를 통해 상위이슈를 등록하고 각 직군별로 하위이슈를 등록해서 해당이슈를 연결하고 깃허브와 연동해서 이슈를 자동화했다.
이는 기존에 프로젝트에서 Jira를 적극 사용해보고 잘 아는 워터와 라이언이 수고해줬고 덕분에 팀에 적용이 잘 됐다.

깃 플로우

우선 깃 플로우는 아래 사진처럼 가져갔다.

그래서 우리가 Jira에 올린 이슈 번호로 브랜치명을 따고 ex)FE-49 해당 브랜치에서 컨벤션을 준수해서 커밋 후해당 원격 브랜치로 Push했다.
그리고 PullRequest를 열어서 해당 작업에 대한 설명과 첨부 이미지나 gif로 시각적 설명을 더하고 어떤부분을 리뷰받고 싶은지 작성했고 이런 템플릿은 깃허브 자동화를 통해 작성했다.

예시 사진

그리고 해당 풀리퀘스트는 PR올린 사람 제외 2명의 Approve가 있어야 Merge가 가능하고 자세한건 링크를 남기겠다.

커밋 컨벤션

컨벤션 얘기 나온김에 깃 컨벤션도 집고 넘어가겠다.
아래 사진을 준수해서 커밋을 했다.

//예시
 [FE-50]feat: recoil 관련설정
    -리코일 타입 추가
    -관련 atom 추가

코드 리뷰

우아한 테크코스 프리과정을 거치면서 코드 리뷰를 통해 정말 많은 성장을 했다고 장담할 수 있다.

그때 왜 코드리뷰가 좋았는지 남겼던 글

그래서 이번에 적극적인 코드 리뷰를 통한 성장을 무조건 해야겠다 생각했고 적극적으로 진행했다. 우선 위에서 말했던것처럼 최소 2명의 approve가 있어야 Merge가 가능한데 그걸 하면서 코드 리뷰를 남겼다.
그리고 해당 리뷰를 남겼던걸 반영한 후에 Merge하도록 했다.

예시 코드리뷰
워터

세인트

그리고 처음에는 실무에서 리뷰를 받아보거나 Pull Request 단위를 나눈적이 없어서 페이지 하나를 통으로 한적이 있었는데 이후에는 서로의 리뷰의 용이함을 위해, 작업 분리를 위해 Pull Request단위를 최대한 작게 가져갔다.
이때 문제가 발생했는데 예를들어 A라는 브랜치에서 작업중인 내용에 의존적인 B라는 기능이 있을때 해당작업이 불가능했고, 이를 통해 전체적인 작업속도가 딜레이 된다는것이다.
이는 아래 회고에서 다시 다룰 예정이기에 넘어가겠다.

협업

위처럼 코드로 리뷰를 남기면서 서로의 코드에 대한 소통을 했고, 이번에 지라로 태스크를 나눴기에 우리가 어떤일을 해야할지 프론트엔드끼리 고정회의를 가졌다.
원래는 리더인 내가 진행하려했으나 생각보다 정할게 많았기에, 고정회의를 가지면서 추가적으로 얘기하고 태스크를 나눴다.
하면서 우리가 회의했던 내용들을 노션에 문서화를했고 해당 작업은 워터가 맡아줬다.
그리고 이외에도 작업하면서 크고 작은 문제가 생겼다.
예를들어 로그인 관련해서 쿠키로 값을 받는데 이를 로컬스토리지로 처리할지 등 이슈가 생겼고 이때는 번개로 모여서 서로의 의견을 공유하거나, 슬랙채널에 공유해서 프론트끼리 해결가능한건 프론트엔드채널에 여러 직군의 의견이 필요하다면의논채널에서 해결했다.

태스크 나누기

우선 태스크는 PM이 정해준 스프린트내에서 해야할 일을 정리하고 최대한 작은 단위로 끊어서 기능별로 업무를 분담했고, 이를 유사한것끼리 묶거나 잘 아는사람이 혹은 원하는 사람이 해당업무를 가져가는 방식으로 진행했다.

아래는 워터가 노션에 정리해줬고 이를 통해 지라에 등록했다.

번개회의

번개회의는 위에서 말했던것처럼 필요할떄마다 진행했고 아래 사진처럼 슬랙채널을 통해서 해결하기도 했지만 게더에서 음성회의를 통해서도 진행했다.

왜 이렇게 진행했냐가 중요하다.
위처럼 오히려 회의를 자주 갖고 슬랙에서 의논해야할 논점에 참여하다보면 본인이 일 할 시간이 줄어들 수 있다.
하지만 위처럼 소통을 진행한다면 후에 발생할 병목을 줄일 수 있고, BestPractice로 기능이 개발될 확률도 올라간다.

3 . 이런식으로 타직군과 협업했어요.

1번에서 설명했던것처럼 사이드프로젝트치고는 인원이 많고, 4개의 직군이 협업하는만큼 타직군과의 협업할일이 잦았다.
그래서 우리는 어떤식으로 협업했는지를 공유하려고 한다.

의논점이 있다면 당사자에게 즉시

우선 우리팀 Slack채널에는 직군별로 채널이 있고 의논채널이 있다.
그래서 질문이 있고 해당 내용을 한 직군에서만 의논해야할 일이라면 해당 직군의 채널에서 질문을 하고 스레드로 답장을 했으며, 만약 해당 이슈가 여러직군과 의존되어있다면 의논 채널에서 관련 사람들과 의논했다.

또한 위에서 진행했던것처럼 텍스트로만 전달이 어려울경우 게더에서 번개로 모여서 해당 문제를 해결하고 해당 내용을 슬랙 채널에 공유했다.

위는 내가 팀원들에게 회고를 통해 건의했던 내용들인데 DM으로나 1대1 번개했던 내용들이 한정적인 사람들에게만 공유돼서 불필요한 소통이 반복되는것 같아서 내용을 공유하자고 했다.

최대한 전문적인 용어는 피하기

흔히 개발자들이 타직군과의 하는 실수중 하나는 본인만 알 수 있을법한 언어들로 설명한다는 것이다.

예를 들면)
우리가 지금 session을 header에 setCookie를 통해서 담아서 주는데 이를 해결하려면 기존방식에서 body에 token을 담아주고 그걸 프론트에서 Local Storage에 담아서 줘야한다. 그래서 이거 시긴이 오래걸릴거 같아서 이번 스프린트에 힘들것같다.

라고 말하게된다면 개발자끼리도 소통이 될지 모르지만 위를 통해서 디자인이 변경되야하는 디자이너가 듣거나 위를 통해서 정책이 바껴야할 PM이 듣게된다면 공감을 하기 어려울것이다.
그래서 이런 부분이 팀 회고에서 해결해야할 문제로 나왔고, 타직군이 알아들을 수 있도록 배려해서 말하기로 됐다.

Jira나 데일리스크럼을 사용하기

데일리 스크럼

실제 현업이 아니라 모두 매일 모여서 데일리스크럼을 10~20분정도 갖기에는 무리라고 판단하여 서로 어떤 작업을할 예정인지 텍스트를 통해 슬랙에 공유하는 채널을 가졌다.
그리고 데일리 스크럼은 PM분들이 건의해줬고 이런 문제가 발생한 차주부터 적용했다.

이 또한 회고에서 나왔던 내용인데 서로 어떤 작업을 하는지 알기 힘들다는 문제가 있었다. 그래서 아래 사진처럼 서로 어떤업무를 진행할지 데일리 스크럼을 텍스트로 간단하게라도 진행했다.

Jira

타직군이 어떻게 일하는지 알려면 당사자에게 직접 물어보거나 데일리스크럼을 진행하는 방법밖에없다.
하지만 타직군이 현재 얼마만큼의 작업을 완료했는지 알기위해서 즉 진척도 체크를 위해 우리는 Jira를 적극 사용했다.

4 . 우리팀은 이렇게 일했어요.

우선 제일 주요했던 키워드를 묶어보면 회고, 수평적, 소통이라고 생각한다.

회고

우리팀은 한주에 한번 회고를 꼭 진행했다. 우선 오프라인으로 하는게 아니라서 회고를 통해 모두가 한번씩 만남을 갖는 시간은 최소 한번은 있어야된다고도 생각했고 우리가 잘못된 길을 가고 있다면 해당 길을 바로잡기위해, 혹은 잘하고 있는점은 더 잘하기위해 회고를 진행했다.
이는 이번 스프린트 시작전 아이디에이션을 했을때부터 했던것이고 회고 방식은 배달의민족 KPT방식으로 진행했고 이는 PM이 건의해준 방법이다.
하지만 이때까지의 회고랑은 다르게 이제 진짜 스프린트가 시작했기 때문에 기존에 했던방식으로 회고를 진행하고 다음 스프린트에 우리가 어떤걸 할지도 같이 진행했다.
아래는 회고를 가지면서 PM이 노션에 정리한 글을 정리해온 캡쳐본이다.

회고가 좋다는걸 알고는 있었지만 실제로 우리팀워크에서 좋은것들은 대부분 회고를 통해 나왔을만큼 실제 효과가 있다는걸 알아갔다.

수평적

모두가 자유롭게 의견내고 일을 더 잘하기위해 수평적으로 소통했다.
자세한 내용은 1부 스프린트를 기획해보자와도 유사하기에 어떤식으로 진행했는지 참고바란다.

소통

온라인인만큼 오프라인보다는 소통에 어려움이 있었다.
예를들면 서로가 언제 작업하는지 모르기때문에 선뜻 질문하기 부담스럽다는점, 텍스트로 전달할 일이 많기에 이를 전달하는데 어려움이 있다.
그래서 회고를 통해 나왔던말이, 코어타임을 정해서 이때 작업을 게더에서 진행하자고 했다.
그래서 게더에 있다는거는 간단하게 회의를 하거나 소통을 하는 시간이라는걸 의미하기에 서로 소통하기 더 편해진것 같다.

그리고 위에서 했던것처럼 슬랙을 적극 이용해서 온라인으로 인한 소통의 부재를 최소한으로 진행하고자 했다.

5 . 끝으로

결국 이번에 1차배포에서 수많은 버그로 인해서 스프린트의 목표를 제대로 달성하지 못했다.
프론트에서 배포를 거의 마감될때즘 했기에 다양한 버그를 마주했고, 결국 고생은 했지만 의미없는 결과물이 나와버렸다.
그래서 이번 회고에서 내가 얘기했는데 우리가 열심히 일하는것도 중요하지만 우리가 코딩하는 결과물이 어떤 가치를 가지는지 생각해보자고 했고, 다음에는 QA를 진행하고 배포는 스프린트 기간내에 좀 빨리 진행해서 프론트끼리 자체적으로 버그를 최소한 확인하는 방향으로 진행하기로 됐다.

하지만 다들 이런 문제를 해결하고자하는 의지가 있고 이번에 회고를 가지면서 회식도 가지면서 다들 더 친해진것 같다.
그리고 회식하면서 우리팀이 10명으로 많은편인데 좋은 사람들을 내가 모았다는 생각을 하니 너무 신기했다.

또한 너무 재밌었다. 원래 사람만나는걸 좋아하고 같이 성장하는걸 좋아하는데, 이번에 협업하면서 정말 많은걸 배워가고 재밌었다.
왜냐하면 이번에 처음으로 코드리뷰하면서 프로젝트를 진행했는데, 내가 많이 부족하기에 정말 많은 리뷰를 받았고 그를 통해서 정말 많이 성장했다고 생각한다.

결국 이번 첫 스프린트 결과물은 공유할만하지 않아서 불가능하고 정말 많은 문제들을 접했다.
위처럼 올바른 결과물을 얻지 못했다거나, 팀내의 소통의 불협화음 등등.
하지만 이런 문제를 겪었고 더 좋은 방안으로 발전하면서 결국은 해결가능한 문제라고 생각한다.
그리고 계속 작업해서 한두사이클만 더 돌리고 바로 사용할 수 있는 결과물을 만들고싶다.

다음 시리즈는 최종배포가 될때즘 작성할거같고 끝으로 우리팀끼리 회식했던 사진을 공유하고 마무리하겠다.

"남는건 사람이다."