[algo-with-me] 프로젝트 규칙 설정, 주간 백로그 작성 (5)

원래 목표는 2주차에 1주차 글을 쓰고, 3주차에 2주차 글을 쓰고.. 하는 것을 목표로 했는데 정신없이 보내다보니 어느새 프로젝트가 끝나버렸어요! 그래도 이제는 시간이 많아져서 차근차근 복기하면서 글을 써보려고 합니다. 근데 기억이 잘 안나네요..? 내가.... 뭘 했더라????

 

이번 포스트에서는 프로젝트 규칙 설정과 본격 개발에 앞서 주간 백로그를 작성한 내용을 담았습니다.

 

프론트 - 무지, 콘, 네오

백 - 저(제이지), 프로도

 

혼자 개발할거면 룰이고 뭐고 그냥 내 생각대로 짜도 크게 상관없지만, 협업을 하기 위해서는 공통으로 지켜야하는 룰이 필요합니다. 우리 코드 사피엔스 팀이 공통으로 설정한 규칙들을 알려드릴게요!

 

그라운드 룰

그라운드 룰을 말 그대로 모두가 지켜야 할 가장 기본이 되는 규칙입니다.

• 코어 타임은 10시부터 19시까지이다.
• 코어 타임 사이에는 연락이 원활해야 한다.
• 점심시간은 12시부터 13시까지이다.
• 주말에는 업무를 진행하지 않는 것을 권장한다.
• 코어 타임에 피치못할 사정이 생기면 연락이 불가능한 시간을 미리 고지한다.
• 프로젝트 관련 이야기는 반드시 슬랙을 사용한다.
• FE는 PR 머지를 위해 다른 두명, BE는 PR 머지를 위해 다른 한명의 approve를 받아야 한다.
• 문서화는 notion을 사용한다.

뭔가 있어보이지만 사실 별거 없습니다. 최소한 이 시간에는 프로젝트에 집중하고 소통이 필요할 경우 바로바로 슬랙 허들이나 줌 회의가 가능하도록 하기위해 이런 규칙을 정했습니다. 프로젝트 후반으로 갈수록 저녁 7시넘어 까지 하게 되는 경우는 많아졌지만 다 성장과 취업을 위해서니까 열심히 했습니다 하하.

 

 

추가로, 저희는 미니 개발 세미나 라는 것을 진행해 보기로 했습니다! 매주 개발 관련 자유주제로 5분 내외의 발표를 하고 질의응답을 진행합니다.

• 공유 문화 형성
• 발표 연습

여러 장점을 기대하고 진행해보기로 했습니다. 단, 프로젝트 진행에 지장을 주면 안되기 때문에 ppt 퀄리티 같은건 크게 신경쓰지 않기로 했습니다.

 

코드 컨벤션

코드 컨벤션을 처음에는 구글 스타일 가이드, 에어비엔비 스타일 가이드, 이런걸 사용해보려고 했었습니다. 그런데 be의 경우 nestJs를 사용하는데 이 프레임워크 포멧과는 맞지 않다고 생각해서 따로 스타일 가이드를 추가하지 않았습니다. nestJs를 설치하면 생기는 기본 ESlint, prettier에 import sort 정도만 추가해서 사용하였습니다.

 

 

브랜치 전략

git flow, github flow 등등 여러가지 브랜치 전략에 대해 알아보았습니다. 저희는 6주간의 짧은 개발기간이 정해져 있고, 개발서버 같은것도 없으므로 브랜치를 많이 나눌 필요가 없다고 생각했습니다.

fe, be 브랜치만 각각 하나 따로 파서 여기에서 각자 브랜치를 따와서 개발하는 방법, 즉 github flow 느낌의 브랜치 전략을 사용하기로 결정했습니다.

 

pr 컨벤션

pr 올릴때 어떤 방식으로 올릴지 결정하였습니다.

[#이슈번호] 이슈 한줄 요약

위와 같은 제목을 설정하고, 내용을 자율적으로 하기로 했습니다. 간략하게 이 pr에서 한 일 정도를 적도록 이야기를 나누었습니다. 또 fe, be 라벨을 다는 것 정도로 간단하게 규칙을 정했습니다.

pr 머지 방법은 그라운드 룰에 적힌 방법을 그대로 사용합니다.

 

 

커밋 컨벤션

커밋 컨벤션도 정했습니다.

# feat : 기능 (새로운 기능)
# fix : 버그 (버그 수정)
# update : 기존의 기능이 변경됨
# refactor : 기능 변경 없이 코드만 수정 (리팩토링)
# chore : 기타 변경사항 (빌드 스크립트 수정 등)

 

예를 들어 다음과 같이 사용했습니다.

feat: 게시판 CRUD 구현

 

이렇게 협업을 원활하게 하기 위한 여러가지 규칙들을 정했습니다. 뒤로 갈수록 조금 안지켜지고 있다 라는 생각도 들긴했지만요.. 그래도 모두 필요한 규칙이라고 생각합니다.

 

주간 백로그 작성

진짜 진짜 개발하기에 앞서, 주마다 개발해야 하는 기능의 목표를 정했습니다. 주간 작업 계획을 세우는 것이 정말 어려웠는데, 아무래도 경험이 적다보니 이 업무가 몇시간이 걸릴지 감이 잘 오지 않았습니다.

어떻게 산정해야 하나 이런 저런 고민을 하다가, 우선 기준을 정했습니다. 업무의 소요시간은 PR이 머지될 때 까지 걸리는 시간으로 한다. 라는 것이었습니다.

그리고 항상 예상 시간보다 1.5~2배정도 넉넉하게 잡으라고 멘토님이 말씀해주셔서 넉넉하게 잡아보았습니다.

초록색은 유저 관점의 스토리를 작성해 본 것이고, 분홍색이 백엔드의 업무입니다. 이 업무를 어떤 단위로 잘라서 작성해야 하는지도 어려워서 보시다시피 굉장히 뭉텅뭉텅으로 잘라두었습니다.

이렇게 2주차에 개발할 기능들을 가져다 놓고, 업무 분담을 시작했습니다. 백엔드는 두명이기 때문에 이정도로 잡아 보았습니다. 그리고 ERD 설계는 무조건 같이하기로 했습니다!

간단하게 2주차에서 실현할 유저의 가치도 적어보았습니다. (실패 했다는 것은 안비밀)

 

저희의 핵심 목표는 "채점"기능의 구현이었습니다. 이를 위해 프론트도 비슷한 작업을 배정했구요! 사실 진짜 개발 시작하기 전까지만 해도 이게 될거라는 확신이 없었습니다. 뭐 부딪혀보면 어떻게든 구현해 낼 수 있지 않을까? 라는 막연한 생각 이었던것 같네요.

 

이제 진짜 개발을 시작하려 했지만,, ERD 설계가 필요해서 프로도님과 후다닥 설계했습니다.

이미지가 최종본 밖에 남아있지 않아서 모두 가져왔지만 대시보드는 없는 상태였습니다. 안에 들어가는 값들도 처음과 달리 많이 수정되었구요. 이제보니 soft delete 같은건 생각도 안하고 있었네요.

어쨋든! 2주차 개발 계획에서 제가 담당한 부분은 문제 API를 구현하는 것과, 채점 API 구현 그리고 redis message queue를 사용하고, websocket을 사용하는 것 까지 구현하는 것이었습니다.

사실 처음에 이렇게 많진 않았는데 하다보니 생각보다 일찍 끝나서 3주차 업무를 땡겨왔어요. 공부해야 할 내용은 많았는데 추상화가 워낙 잘되어 있어 그냥 가져다 쓰면 되는 경우가 많았어서 그런것 같네요. (websocket, redis)

 

업무를 분담하고 보니 저는 클라이언트와 가까운 쪽, 프로도님은 진짜 백(?) 쪽 업무를 분담하게 되었습니다. (docker, 실제 채점 로직 구현)

 

다음편부터 저희 프로젝트 한번 정리하는 설명을 한 뒤 진짜 개발 과정을 이해하기 쉽게 설명해 볼게요! 봐주셔서 감사합니다~!