-
Notifications
You must be signed in to change notification settings - Fork 1
김다영‐ 1주차 경험
프로젝트 기획 , 일정 수립, 디자인, 협업 전략 수립, 기술 스텍 선정
1주차에는 프로젝트 기획 및 협업 전략을 주로 세웠습니다. 1주차때 한 고민은 크게 다음과 같습니다.
- 어떤 서비스를 만들 것인가?
- 어디까지 만들 것인가?
- 백로그는 어떻게 작성하지?
- 팀원과의 의사소통
- 깃허브 협업 전략 정하기
- 1주차 개발 문서 리스트
어떤 서비스를 만들지 정하기 전에, 저희는 결정한 서비스가 아래 두가지 조건을 충족해야한다고 생각했습니다.
1. 이 서비스가 현실적인 문제를 해결하는가? (사용자의 공감을 얻어낼 수 있는가?)
2. 얻을 수 있는 기술적 도전이 존재하는가?
저희 팀은 클라우드를 주제 안에서 위 조건을 충족하는 주제에 대해 각각 생각해오고, 해당 조건에 충족하는 주제를 고르기로 결정했습니다. 그 과정에서 결정된 것이 바로 지금의 서비스(데이터베이스 실행 환경)입니다.
- 서비스가 현실적인 문제를 해결하는가?
문제의식 : Query를 연습하고 싶은데 DB 환경세팅에 너무 많은 시간이 소요된다.
데이터 베이스 쿼리를 연습하기 위해 실제로 많은 시간이 소요되며, 이 시간을 줄여 편하게 db를 사용해 볼 수 있게 하는 것이 저희 서비스의 핵심입니다. 실제로 1주차 발표때 저희 서비스의 문제의식에 많은 분이 공감해주셨고, 질문도 많이 받았기에 저희는 사용자의 공감을 얻어낸 서비스라는 확신을 가질 수 있었습니다.
- 얻을 수 있는 기술적 도전이 존재하는가?
프론트엔드인 저의 입장에서 제가 프로젝트에서 얻고 싶었던 경험은 리액트를 활용해 프로젝트를 완수하는 경험이었기에, 해당 프로젝트는 제가 원하는 기술적 도전을 충족하는 서비스였습니다. 백엔드는 데이터베이스에 대한 학습, 서버 성능 개선 경험을 원했기에 해당 프로젝트가 적합하다고 생각했습니다.
저희는 우선 1-2주차에 핵심 기능을 빠르게 만들기로 결정했고,
이후 3-5주차에 부가기능을 추가하기로 하였습니다.
핵심기능과 부가기능은 아래 기준을 바탕으로 정했습니다.
-
핵심 기능: 서비스를 유저가 사용할 수 있게 하는 최소한의 기능- 쿼리 실행 기능, 테이블 보기 기능
-
부가 기능: 없어도 서비스를 사용하는데에 지장이 없지만, 편의를 제공하는 기능- 테이블 추가/수정 기능, 랜덤 데이터 추가 기능, 예시 쿼리 추가 기능
개발자로서 프로젝트 경험이 처음이라, 백로그 작성시에도 많은 고민을 했습니다.
결국 고민 끝에 아래와 같이 결정했습니다.
-
백로그 관리: 깃허브 & 엑셀- 깃허브로만 관리하려다가, 한눈에 보기 불편해서 엑셀을 추가로 사용하였습니다.
-
마일스톤: 기능 단위 -
이슈: 2~5시간 단위로 쪼개기
이 중에 가장 어려웠던건 이슈 쪼개기였습니다. 한 기능에 대해 이슈를 쪼개다보니 이슈가 서로 얽혀있어서 나누기 애매한 경우도 많았고, 저의 경우에는 메타인지가 안되어서 작업시간 산정도 몹시 어려웠습니다.
이에 저희 팀은 플레닝 포커를 활용하였고, 이 덕분에 작업에 대한 예측 시간을 실제시간과 거의 동일하게 맞춰 갈 수 있었습니다. 이에 대한 과정은 위 링크에서 상세히 확인하실 수 있습니다.
중간에 이해가 되지 않으면 끊고 설명을 요청하자!
저희 서비스는 아무래도 DB 실행환경을 제공하는 서비스다보니, 기술적인 논의를 진행할때 해당 내용에 대해 많이 논의가 이루어졌습니다. 다만 저는 이에 대해 배경지식이 없어서 회의하다보면 종종 이해를 하지 못하는 경우가 있었습니다.
처음에는 팀원들의 대화를 끊기가 껄끄러워서 그냥 듣고만 있었는데, 그렇게 하고 나니까 오히려 팀원분들의 이해를 따라가기가 어려웠습니다. 그래서 이후에는 팀원들이 논의하는 것을 주로 들으며 최대한 기존 지식으로 이해하다가, 정말 이해하기 어려운 부분에 대해 중간에 대화를 잠깐 끊고 질문했습니다.
이렇게 대화를 끊고 나니까 팀원분들이 제 이해를 검토하고 잘못 이해한 부분은 정정해주셔서 의사소통속도가 오히려 더 빨라질 수 있었던 것 같습니다.
저희는 초반에 main, dev, dev-fe, dev-be, feature 브렌치로 총 5개의 브렌치로 협업을 진행했습니다. 다만, dev-fe / dev-be브렌치 효용에 대한 의문을 품게 되었고 main, dev, feature 3가지 브렌치로 간소화 하였습니다.
저는 깃허브로 협업한 경험이 이번에 처음이었기에 이에 적응하는데 어려움을 겪었습니다. 특히 브렌치 전략이 익숙치 않았는데요. 그러다보니 부모 브렌치의 중요성을 몰라서 피처브렌치에서 분기하고, 또 다른 피처브렌치에서 다른 피처 브렌치를 분기하면서 만들다보니. 나중에 피처브렌치의 커밋이 몇십개가 넘는 끔찍한 일이 발생했었습니다.