[나만의 작은 설렘] [기술 회고] 기획/설계

[링크]
🧲 배포링크 : https://www.seollem.link/
          • 게스트 아이디 : starrypro@gmail.com
          • 게스트 비밀번호 : Abcd123!
🧲 Github : https://github.com/codestates-seb/seb39_main_035
🧲 Team Notion : https://www.notion.so/my-little-seollem/SEOLLEM-7f5ac9430c4b44f2bc103933eb0dbf90
🧲 API Doc : https://hyeongseobs-organization.gitbook.io/undefined/

 

팀 빌딩

 

팀원은 코드스테이츠 측에서 프론트엔드 2인, 백엔드 2인으로 지정해주었다. 세 분의 추천으로 내가 팀장을 맡게 되었다. 그리고 기본적인 팀 규칙을 정했다. 

 

프로젝트 일반 규칙

• 커뮤니케이션 툴 : Discord, Notion, Github Project/Wiki
• 팀 전체 공식 회의 시간 : 화/목 10 : 00
• 디스코드에 상태 정확히 표시하기(온라인 / 자리 비움 / 다른 용무 중)
  • 온라인 : 연락 가능
  • 자리비움 : 연락 받을 수 있으나 곧바로 대응은 어려움
  • 다른 용무중 : 연락 받을 수 없음

 

프로젝트 개발 관련 규칙

• 깃헙 브랜치 명
  • main
  • front-dev
    • hansunguk
    • seul
  • back-dev
    • kimhyeongseob
    • joo
• 하루 일과 종료 후, 각자의 브랜치에 commit 및 push까지 진행. 소통 필수!! (예시) 오늘은 여기까지하고 커밋할게요~ 고생하셨습니다🙂)
• pull request 및 merge는 시간 상의 후 진행. 소통 필수!! (예시) 매일 10시 정도에 만나서 merge하고 시작할까요?!?)

 

 

 

Git Commit Convention

아래와 같이 Git Commit Convetion 을 정하고 따르기로 했다.

 

git commit 문서 일부

 

 

작업 관리

Github Projects 칸반보드, 마일스톤을 이용했다.

 

Github 프로젝트 칸반

 

 

일정 관리

기술적 작업 일정 외에 회의 일정, 배포 계획 등 전반적인 일정 관리는 아래와 같이 Notion을 이용하였다.

 

 

Notion 일정 관리 캘린더 일부

 

---

아이디어 Mix & Mingle / 기획서

 

어떤 서비스를 만들지 아이디어 회의를 하고 팀과 함께 정하는 시간을 가졌다.

 

PLUS 회의

• 어떤 아이디어든 자유롭게 말한다.
• 이루고 싶은, 하고 싶은 목표를 가능한 크게 잡아본다. 

 

MINUS 회의

• 팀의 기술적 역량과 한정된 시간을 고려하여 의견을 덧붙인다.
• 해당 의견과 함께 만나게될 모든 우려사항과 해결방안까지 고려한다.
• 마이너스 의견에도 불고하고 흥미로운 이유(interest)를 작성한다.

 

Idea Mix & Mingle 문서

https://www.notion.so/my-little-seollem/Idea-Mix-Mingle-bf81a4544d5648179c0a7ec841612a89

Idea Mix & Mingle

 

 

먼저 PLUS 회의에서는 매우 다양한 시각에서 창의적인 아이디어들이 많이 나왔다. 팀 모두가 적극적이고 재밌게 의견을 제시하며 진행되었다.

• 시장성 고려(예를 들면 반려견 관련 산업의 증대)
• 타 서비스와의 차별점
• 사회적인 문제 해결
• 개인적인 경험에서 나온 원하는 기능
• 사용자 확보를 위한 커뮤니티 활성화 방안
• 재미를 위한 요소
• 수익화 방안
• etc..

 

다음으로 MINUS 회의를 통해 현실적인, 실현가능한 아이디어로 만들어나가기 시작했다.

• 기술적, 시간적 한계
• 난이도 고려
• 팀의 관심도
• 외부 기술(Open API 등) 사용가능 확인
• 타 서비스와 중복 비교, 확실한 컨셉 잡기
• 법적 문제(저작권 등)
• etc..

 

여러가지 종합적인 판단의 결과, 독서 관리 서비스로 결정되었고 조금 더 구체적으로 기획서를 작성했다.

 

 

기획서

https://www.notion.so/my-little-seollem/Main-Project-e60c87f219b249a0983d0a7d864a0a4f

Main-Project 기획서

 

 

---

설계 문서

메인 프로젝트 이전에 진행했던 프리 프로젝트에서 다음과 같은 회고가 있었다.

프리 프로젝트 회고 일부

프리 프로젝트에서 함께 회의를 거쳐 결정된 요구사항임에도 팀원들의 이해가 다른 경우가 많았다. 그래서 실제 기능을 구현하고 설명할 때, 뒤늦게 서로 다르게 이해하고 있었다는 것을 발견하곤 했다. 따라서 이번에는 설계단계에 시간을 많이 투자하고 아주 상세하게 문서를 작성하는 것을 제안했고, 팀원 모두가 공감하고 동의했다.

 

멘토님께도 설계 단계에서 궁금한 점들을 질문드렸고 몇 가지 조언을 들을 수 있었다.

• DB 설계, API 문서 도출을 우선으로 할 것. - 프론트엔드와의 협업을 위함.
• 프레임워크, 기술스택과 같은 아키텍쳐 설계도 해보면 좋다.

 

먼저 우리 팀은 화면 정의서에 공을 들였다. 텍스트보다는, 정확하게 그림이 그려져있으면 팀원들의 이해도가 높을 것으로 판단했기 때문이다. 따라서 요구사항 정의서는 서술형으로 작성하였고, 화면 정의서에서 Figma 를 이용하여 화면을 표현한 후 해당 화면에서의 기능에 따른 API 를 함께 작성했다.

 

 

요구사항 정의서

https://www.notion.so/my-little-seollem/cd0afb74ed9f4b10916d051c13a0394a

사용자 요구사항 정의서

 

 

 

화면 정의서

 

화면 정의서 일부 1

 

화면 정의서 일부 2

https://www.notion.so/my-little-seollem/c97e9eaadd0a4e1eb91fbbc1eade7db4?v=21f7f0d441b6460d9ce74c150b3e8db4 

화면정의서

 

 

 

나만의 작은 설렘 Docs

앞서 작성한 문서들을 토대로 DB ERD, DB 설계서, API 문서를 작성했다. API 문서 작성 툴로는, 코드스테이츠 교육과정에서는 Spring Rest Docs를 배웠고 프리 프로젝트에서는 Swagger를 사용했지만 이번에는 GitBook을 사용했다. 이유는 최대한 빠르게 API 문서를 도출해내기 위함이었다. 프론트엔드에서 우선적으로 정확한 API 문서를 기준으로 구현을 하고 싶다는 요청이 있었고, 코드 작성이 시작되지 않은 상태에서도 먼저 API 문서를 작성할 수 있기 때문에 선택하였다.

 

API 문서가 프론트엔드, 백엔드 간 협업의 표준이 되었다. 물론 프로젝트 진행 중에 요구사항 변경에 따라 수정되기도 하였다. 이를 Revision으로 간단하게 기록해두었다.

 

Docs 일부 1

 

Docs 일부 2

https://hyeongseobs-organization.gitbook.io/undefined/

Welcome! - 나만의 작은 설렘

 

 

 

이렇게 설계/기획 단계는 약 8일 정도 진행되었다. 문서화된 자료가 확실히 구현 단계에서 혼선을 줄여주었다.