Skip to content

11.11 금 회의록

HG.Seo edited this page Nov 11, 2022 · 11 revisions

회의 내용

주차별 발표자 정하기

1주차 2주차 3주차 4주차 5주차 6주차(동영상)
서하경 최민혁 최지윤 한도현 가위바위보 함께

설계공유 준비

0. 설계공유에서 다룰 내용

  • 저희는 Web25조 얼리버드 팀입니다.
  • 저희의 프로젝트 명은 SCOPA이고 차후에 이 이름이 과연 어떤 뜻인지 차차 말씀드리겠습니다.
  • 일단, 설계공유는 우리가 기획 및 설계를 하면서 어려웠던 점과 이를 해결한 경험을 공유하는 자리이기 때문에, 저희가 겪었던 어려운 점과 해결했던 과정에 대해서 다루고자 합니다.

1. 제품기획

  • 잘 맞는 사람끼리 팀을 구성했음에도 기술스텍이나 코드스타일 등을 맞춰가는 과정에서 많은 시간을 들였던 것 같습니다. 이 과정에서 자연스럽게 처음부터 나와 꼭 맞는 팀원들과 프로젝트를 할 수 있다면 얼마나 좋을까?라는 생각을 하게 되었고 자연스럽게 저희의 프로젝트는 나와 꼭 맞는 팀원을 구할 수 있는 프로젝트 파트너 찾기가 되었습니다.
  • 아까 말씀드리겠다던 저희 프로젝트 명의 풀네임은 Searching for Code Partner입니다.
  • 이러한 제품 아이디어는 있었지만, 기획경험이 없어서 기획을 어떻게 시작할지가 굉장히 막막했기에 저희가 당장 할 수 있는 컨벤션 등을 먼저 정하고 있었습니다.
  • 기획 특강을 듣게 되었고 그때 들었던 기획 흐름대로 진행을 해보니, 저희 팀의 생각을 훨씬 수월하게 전개할 수 있었습니다.
  • 아이디어를 구체화하는 과정에서 저희는 저희의 필요성에서 이러한 아이디어를 도출해냈기 때문에 프로젝트 팀원을 구하는 모집자와 본인을 프로젝트 인력 풀에 등록하고 싶은 등록자의 입장에 대해 너무도 잘 알고 있었기 때문에, 구체적인 생각을 전개해나가는 과정은 그렇게 어렵지 않았던 것 같습니다.
  • 또한, 벤치마킹 사이트들을 찾아보면서 저희 아이디어의 차별성에 대해서도 구체화시킬 수 있었습니다.

2. 디자인 및 기능상세

  • 저희는 디자인과 기능 구체화를 위해서 피그마를 사용하였습니다.
  • 실무에서도 피그마가 활발히 사용되고 있고 여태 저희가 멤버십 과제를 해오면서도 피그마의 편의성을 잘 인지할 수 있었기에 피그마를 선택했습니다.
  • 피그마를 작성하다 보니 기능이나 각 요소별 이벤트에 대해서도 구체화할 수 있어서 좋았습니다.
  • 구체화하는 과정에서 개개인별로 어떻게 기능을 동작시킬지에 대해서도 의견이 달랐는데, 각 동작방식이 가지는 장단점에 대해 토론을 하며 의견을 일치시켰습니다.
  • 이러한 토론 과정에서 난관에 부딪히면 멘토님에게 도움을 요청하여 훨씬 수월하게 의견을 합칠 수 있었습니다.
  • 그리고 피그마 레이아웃을 완성한 다음에, 피그마의 요소들을 컴포넌트화 시키는 작업을 했습니다.
  • 이 작업은 생각보다 많은 시간이 소요되었지만, 미리 FE 컴포넌트 구조나 명칭을 정의함으로써 차후 프로젝트 진행 과정에서 불필요한 시간소모를 줄여줄 수 있을 것입니다.

3. 기술기획

  • 기술스텍을 선정할 때, 왜 이 기술스텍을 사용해야하는 지 그 근거에 대해 많은 토론을 했습니다.

  • 또한, 이 과정에서 팀원 간 의견이 일치하지 않을 때 서로가 서로를 설득하고 논의하는 과정이 쉽지는 않았습니다.

  • 정해진 프로젝트 기간 내 저희가 활용할 수 있는 기술을 최대한 선정하였고 각 기술별로 장단점을 논의해보며 저희만의 기술스택 선정에 대한 근거를 정할 수 있었습니다.

  • 그러한 과정을 통해서 이런 기술스텍을 최종적으로 선정하였습니다.

  • 기술 선정한 뒤에 API명세와 각 API에 대하여 어떤 데이터를 주고받을지에 대해서도 미리 논의하였습니다.

  • 초반에 이러한 것들을 모두 정하고 시작한다는 것이 시간이 꽤 걸리는 작업이었지만, 차후 작업 진행 시에는 이미 기준이 정해져있기 때문에, 불필요한 고민 시간을 줄이고 작업진행 속도를 더 높일 수 있다고 생각합니다.

  • 이 과정에서 어떠한 데이터를 어떤 형태로 백엔드와 프론트엔드가 주고받아야할지 결정하는 것이 쉽지 않았고 또 하나의 기능에 대해 프론트엔드와 백엔드의 책임 범위를 설정하는 과정이 까다로웠습니다.

  • 이러한 과정에서는 데이터 수용능력 등 프론트엔드와 백엔드가 할 수 있는 선을 먼저 정의하고, 어느 분야에서 하는 것이 더 합리적이고 타당할지에 대해서 의견을 최대한 많이 나누며 해결하였습니다.

얼리버드

프로젝트

개발일지

스프린트 계획

멘토링

데일리 스크럼

데일리 개인 회고

위클리 그룹 회고

스터디

Clone this wiki locally