📝 사전 팀 미팅 일지 (작성일 : 2024 10 24)
- 분류: 정규 회의
- 생성 일시: 2024년 10월 24일 오후 9:21
- 선택: 회의록
👀 사전 팀 미팅 일정 정하기 및 사전 준비 (작성일 : 2024 10 24)
우리를 소개해봅시당!
- 우리팀 짱짱맨
- 첫 회의 사진입니다.
회의 안건에 대해서 자유롭게 적어주세요! 회의 전에 정리해서 같이 논해봐요!
@Zen :: 이거 좋네요. 개인적으로는 이모지대신 답장이 좋을 듯 합니다. 만약 서로 소통이 늦어지는 게 보이면 통계를 내서, 원인 분석하면, 이 역시도 포폴에서 할말이 많을 것 같아서요!
@동율 이 :: 저도 좋은 방법인 것 같습니다. 아무래도 온라인이다 보니 소통이 더욱 활발하면 좋을 것 같아요!
⇒ 개발자적 표현 쓰면 :: 데이터베이스 쌓아두기. 언젠가는 쓰이겠지. (추적가능성 고려)
-
서로에 대한 이야기
-
각자의 목표
그라운드 룰에 앞서서 여러분들의 이번 미션에서의 목표는 무엇인지 적어주실 수 있나요?
이름 목표 상세 J210 @Zen 🚀 1. 내가 쓸 수 있는, 내가 겪은 문제를 해결하는 프로그램을 만들고 싶다. 🚀 2. 작은 기능이어도 좋으니까, 이후 확장 및
유지보수가 가능하게 제대로 완성도 있게 구현이 되었으면 좋겠다.🚀 3. 모든 과정이 깃허브에 기록되어 아카이빙 되었으면 좋겠다. ⇒
포폴에 쓰고 싶다.🚀 4. 거창한 기술을 사용하기 보다는 React 등의 기본 기술을 이용해서 UX에 기반한 기술적인 완성도를 높이고 싶다.
🚀 5. 분업이 아닌 협업을 겪어보고 싶다. | 🤔 제가 가진 개발에 대한 가치는 가치는 작은 문제라도 괄시하지 않고 기술적으로 해결해보자! 입니다.
또한, 어제 강연에서 연사님들이 “현실적인 문제를 해결한 프로젝트에 눈길이 갔다. 그 외는 자기가 쓰지도 않을거면서 그냥 있어보이게 만들어서 정말 실망했다.”라는 뉘양스의 피드백을 주셨습니다.
이에 따라서, 진짜 현실의 문제를 해결할 수 있고, 일단 우리부터 매일 쓸만한 프로그램을 만들고 싶었습니다.
🤔 ”기술을 학습하는 데 어려운건 진짜 큰 의미가 없다고 생각한다. 작은 기술이어도, 그 기술로 어떤 문제를 해결하기 위해 고군분투할 때 그것이야말로 가치가 있다.” 라는 테오님의 말씀이 있었고, 제가 가진 철학과 합치하는 부분이 있었습니다.
프로젝트를 하다보면 기술에 매몰되어서, 정작 중요한 “본질”을 보지 못하는 경우가 많았습니다. 그리고, 보통 이럴 때 스스로도 납득이 안되어서 쉽게 흥미를 잃거나 결과적으로 완성도가 떨어지는 것 같습니다.
프론트앤드 4명이 모였기 때문에, 많은 시도를 할 수 있겠지만, 반대로 4명이 모였기 때문에 리액트만 쓰더라도, 완성도를 극도로 끌어올릴 수 있는 프로젝트를 만들어 볼 수 있겠다는 생각이 듭니다.
그렇기에, 이런 관점에서 한번 시도해봤으면 하는 마음이 있습니다.
🤔 포트폴리오에 쓰고 싶다는 생각이 있습니다.
백이 없다는 것은 반대로 말하면, 프론트앤드 입장에서 백이 완성이 안되었을 때 저희가 서비스를 어떻게 개발해 나갈 수 있는지, 어떻게 데모를 구축할 수 있는지를 잘 보여줄 수 있는 기회라고도 생각합니다.
여러 모킹 방법도 있고.. 무엇이 되었든 프론트 4명이라서 생기는 여러가지 고민이 있을 것이고, 그걸 정말 좋은 팀원분들과 함께 해결해나가는 게 일상이 되리라고 생각합니다.
포트폴리오를 만들다보면 기록이 부족해서 어려움과 극복 사례가 잘 드러나지 않는 경우가 있는데.. 이번에는 그걸 제대로 기록해서 확실하게 이거 하나만으로도 내세울 수 있는 프로젝트로 만들고 싶습니다.
🤔 즐겁게 하하호호 웃으면서 하고 싶다.
사이드프로젝트를 하다보면, 너무 비즈니스적으로 가는 경우가 있습니다. 그렇게 했을 때, 장기적으로 보면 많이 힘들어지는 것 같습니다.
저희가 고생하면서 달려온 여정의 종지부를 찍는 그룹프로젝트인 만큼, 모두 다 같이 웃으면서 하고 싶습니다. ㅎㅎ.
오프라인이었으면 술 한잔 하면서 대화하면 좋았겠지만.. 온라인인만큼 다른 방면으로 하하호호 하면서 즐겁게 해보고 싶습니다. ㅎㅎ.
🤔 내가 사용할 프로그램을 만들기 위해 온전히 몰입해보고 싶다.
좋은 분을 만나서, 그것도 프론트앤드의 길을 걷는 분들과 만나서 하나의 목표로 달려갈 수 있는 기회는 좀처럼 없다고 생각합니다.
이런 좋은 기회에 반해, 제 능력이 많이 부족하네요.. 여러분들께 누가 되지 않을까 싶습니다. 한편으로는 진짜 제대로 프로젝트를 통해서 실무적으로 성장하고 싶다는 생각도 있습니다.
그래서 온전히 프로젝트에 몰입하는 기간으로 보내고자 합니다. 할 수 있는 역량을 제대로 파악하고, 맡은 역할을 책임지고 수행하면서 점차적으로 스스로 성장을 이루고 싶습니다. 그래서, 저 개인적으로는 6주간 한번 모든 시간을 투자해보고 싶습니다. (순수하게 저 개인에 대한 이야기입니다 ㅎㅎ.) | | J060 김주원 | - 처음부터 끝까지 만들어보며 전반에 관한 이해를 높이고 싶다
-
포트폴리오에 쓸 수 있는 프로젝트를 만들고 싶다 | | | J174 이동율 | - 저도포트폴리오에 쓸 수 있는 프로젝트를 만들고 싶습니다. (실 사용자가 있는) - 서비스를
유지 보수하는 경험도 해보고 싶습니다. - 기능이 거창하지 않더라도 완성도가 있는 프로젝트였으면 좋겠습니다. | |
| J234 정혜인 | - 계속해서
포트폴리오로 사용할 수 있는 프로젝트 -
적어도 1년 정도는 계속 배포되어있는 지속 가능한 프로젝트 | |
-
-
아이디어 노트
자유롭게 아이디어를 적어주세요!
제안자 아이디어 예상 사용 기술 이유 @주원 김 🗺️ 네이버 지도 개선 - 오늘의 장소 리스트에 오늘 갈 장소들을 담아둔다
- 단톡에 이를 공유하면 약속 일정 공유와 함께 장소를 이동할때 바로 해당 링크에서 길안내를 시작할 수 있다
- 좋았던 여행경로 등을 기록해두고 공유할 수 있다
🤔 확장 (1,2월 기간을 활용해서 더 추가해볼만한 사항)
- 경로추천 - 경로 설정(A,B,C) 3가지 목적지가 있을 경우 A→B→C가 빠른지 B→A→C가 빠른지 등 빠른 경유지 탐색
- 3D를 사용 - 실내(롯데타워 같은 곳에서는 실내 길안내)
- AI 사용 - 여행의 경우에 추가할만한 방문지 추천
- 재도님 프로젝트와의 결합? - 링크에 접속한 사람들의 실시간 위치를 표시(옵션 추가) → 위치의 정확성 높이기 → 어르신 픽업, 흩어져서 놀다가 모이기 등등 | | 이전의 지도는 단톡방에 공유되어있는 장소 정보나 인터넷 검색을 통해 1명이 길찾기를 진행하는 방식으로 진행되어왔다. 따라서 단톡방에 일정을 공유할때 장소 각각에 대한 링크들을 공유하는 것이 아니라 장소들의 목록을 공유하여 번거로움을 줄이고자 한다. | | @Zen | 🚀 약속 정하기 위해 사용하는 프로그램
[핵심] :: 실시간 위치 추적
- 지도에 실시간으로 각 사용자의 위치를 표시한다.
- 이를 보면서 사용자 간의 서로 현재 어느 위치에 있는 지 파악한다
[추가 기능]
- 실시간 위치 표시를 넘어서 장소에 댓글을 남겨봐도 괜찮을 것 같다. 일종의 추억저장이라해야하나…?
-
-
WhenToMeet처럼 시간을 타임테이블 형식으로 정할 수 있었으면 좋겠다.
-
-
- 약속 장소를 리스트업하고, 이를 바탕으로 주변 사람들의 위치를 파악할 수 있었으면 좋겠다.
-
- 중간지점이 되는 장소를 자동으로 찾고, 경로를 알려줬으면 좋겠다. (예상시간까지.)
-
- 버스타는 지점이나 대중교통 타는 지점 등을 알려줬으면 좋겠다.
-
- 막차에 대한 정보를 정확하게 제공했으면 좋겠다. 혹은 현재 버스가 어디에 있는지도. | - Geolocation API
- 네이버 지도 API
- React
- React Native | 1. 약속을 정하기 위해서 항상 어려운 것은 다음과 같습니다.
- ㄱ) 공통된 시간을 정하는 문제
- ㄴ) 중간 지점을 찾는 문제
이에 대해서 뭔가 하나로 합쳐진 서비스가 있었으면 했습니다. (당장 저희만 해도 관련해서 정하는데 꽤 오래 걸렸잖아요? ㅎㅎ)
- 막차를 제대로 알려주는 서비스가 있었으면 했습니다.
얼마전 집 근처 지하철역에서 집까지 막차를 타는데, 버스가 16분후로 찍혀있는 겁니다. 7정거장 전이었구요. 그래서 그런갑다 했는데 10분 딴짓하다 다시 보니 14분입니다… 그래서 아 뭔가 막히는갑다 했는데.. 20분 더 기다려서 보니 버스가 사라져있습니다… 아놔.. 이러면서 다른 버스 기다리는데 20분 후 그 버스가 다시 나타나고 6분후가 되었더군요.. 3정거장 전…
심지어 기다리던 다른 버스에서도 비슷한 문제가 발생했습니다.
결국 밖에서 1시간 10분을 기다린 끝에 탔습니다.
이런 경우 다른건 모르겠고 실시간 버스 위치만 추적이 되어도 괜찮지 않을까 했습니다.
그리고, 이런 기능은 약속 정할때 실시간 위치 추적과도 크게 기능상 다르지 않을 것 같아서.. 이정도만 있어도
약속 정하기 위한 프로그램이 아니라버스의 위치 추적만 제공을 해주고, 도메인을버스 추적기라고 해서 개발해도..전 이 프로그램을 사용할 거라고 생각했습니다.- 저희 조부모님의 동네에는 1시간에 버스가 1대옵니다. 그리고, 정해진 시각에 도착하는 경우가 거의 없습니다. 현재 위치가 어딘지 몰라서.. 조부모님께서는 항상 덥든 춥든 힘든 몸을 이끌고 최소 20분은 대기하십니다..
버스의 위치만을 알아도 이런 문제가 덜하지 않을까 생각했습니다.
- 조부모님께서 열차로 올라오실 때 서울지리가 익숙치 않아서 길을 자주 헤메십니다.. 저희가 마중가도 위치파악이 안되어서 헤메는 경우가 많습니다.
이 경우 실시간 위치만 제대로 보여줘도, 그 위치로 저희가 가면 되니까 얼마나 좋을까? 하는 생각이 있었습니다.
-
약속때에도 항상 길이 엇갈리는 경우가 생깁니다. 그런 경우에도 이런 서비스가 있었으면 어떗을까 합니다.
-
위치서비스를 쓰면 차는 몰라도 도보는 현재 내 위치가 제대로 파악이 안되는 경우가 많습니다. 이걸 프론트앤드의 기술을 써서 해결해보면 어떨까 했습니다. | | @혜인 정 | 🚗 초보자를 위한 운전 연수 웹
네이버 지도의 네비게이션처럼 길을 알려주지만, 현재 위치를 기반으로 해서 유턴을 해야할때는 핸들을 꺾는 각도를 함께 보여준다거나, 구간단속이나 비보호 좌회전, 유턴 신호 등 간단하지만 처음에는 헷갈릴 수 있는 규범이 나왔을 때 어떤 용도(?)인지를 목소리로 알려주는 웹앱 | | 부모님이 멀리 계시거나 연수는 비싸서 많이 할 수 없는 경우에는 면허증이 있어도 운전을 시작할 엄두가 안 나는 초보자들을 위해… | | @혜인 정 | 🧭 위치 기반 날씨 시각화 웹 (백엔드 필요 없을 듯)
사용자의 현재 위치와 날씨 정보를 통해 구름, 비, 눈 등의 날씨 요소를 three.js를 통해 3D로 표현해주는 웹 (추가로 인구 밀도, 교통량, 미세먼지 등도 표현하면 괜찮을듯) | | 백엔드 기술이 최대한 들어가지 않는 웹을 생각해보다……. | | @혜인 정 | 🚲 여행 기록 3d animation 웹
내가 여태껏 다닌 여행지를 애니메이션 형태 (인스타 등에 자랑?할 수 있는 형태)의 영상으로 추출해주는 웹 개인적으로 ‘내트리에놀러와’ 같이 그 영상을 서로 공유하는 웹사이트로 만들어도 재밌을 듯
아래 링크 참고
https://mult.dev/studio | | 제가 여행을 정말 좋아해서 기록하고 SNS에 공유하는 것을 좋아하는 편인데, 예쁜 애니메이션 형태로 공유할 수 있는 웹사이트가 있으면 좋겠다고 생각하였습니다. (다만 급하게 생각해낸 거기도 하고 현재 실시간 위치를 반영하는 웹은 아니라서, 더 고민해봐야할듯…) | | @혜인 정 | 크리스마스 특집
이건 진짜 아이디어가 아니고 브레인 스토밍 용인데, 12월 딱 프로젝트 마무리 할 때 쯔음 되면 크리스마스일테니, 내 트리에 놀러와 같은 크리스마스 용 웹사이트를 만들어도 재밌을 듯 | | | | @동율 이 | 여행 도감 이미 해봤던 아이디어긴 하지만 매우 미약하고 퀄리티가 떨어져서 다시 디벨롭 해보고 싶은 생각이 있습니다! 기능은 각 도시들 마다 유명한 관광지들을 도감에 비활성화 상태로 넣어두고 실제 그 관광지에 들어간 뒤 5분이 지나면 도감에 사진과 글을 등록할 수 있도록 합니다! 그 이후 각 도시들마다 진행도를 넣고, 등록한 관광지의 수 만큼 경험치를 얻거나 크레딧을 얻는 방식입니다! 이를 three.js를 사용해서 멋지게 만들어 보거나 혜인님 아이디어와 결합해도 재밌을 것 같아요!! 추가적으로는 등록을 위한 여행 루트도 짜주는 시스템도 들어가면 좋을 것 같아요! 시간이 모자라서 구현을 못했던 기능입니다 | | 주제가 공익적이거나 전국적인 사회 문제를 해결할 수 있는 앱이었고, 현재 우리나라는 수도권 집중화가 과도하게 되어있어, 이를 해결하기 위한 앱이었습니다. 아무래도 기업을 옮기거나 인프라를 늘리는 방법은 저희가 할 수 없기 때문에, 여행을 통한 유동 인구를 늘려 지역 경제를 활성화 시키자는 아이디어로 시작했습니다 비인기 도시일수록 크레딧을 많이 주는 방식으로 하면 좋은 방향이 될 수 있을 것 같아요 | | @Zen | 현실 메세지 | | |
- 포폴에 쓰는 걸로 그치지 않고, 개선 및 사용하는 것에 대한 생각
- 실사용자가 있었으면 좋겠다.
- 적어도 1년은 썼으면 좋겠다.
@혜인 정 :: 실 사용자가 있는, 내가 쓸 것 같은 프로그램을 만들 꺼면 단순히 재미만을 위해서 만드는 것도 괜찮을 수 있다. 이미 문제를 해결하기 위한 것은 이미 다 있다. 그렇다고 하면, 써보면 좋을 것 같다는 생각이 들어왔다. 내트리를 들어와 라는 것을 보면서 사이드프로젝트이면서 정말 많은 사용자가 들어올 수 있는 서비스라는 생각이 들더라.
@동율 이 :: 대회를 2번 나갔다. 그 대회가 다 똑같은 대회인데, 사회적 문제를 해결하는 대회였다. 사회적인 문제나 공익적인 문제를 생각하면 애초에 사용을 하기가 쉽지 않다. 서비스를 한다고 하면 수익성이 없는 것도 있지만, 문제를 해결하면서 수익을 얻기도 굉장히 까다롭다. 어떤 문제를 해결한다는 것은 당연히 좋지만, 엄청난 아이디어가 있지 않는 이상은 쉽지 않을 수 있다. 그래서 혜인님과 비슷한 생각이다.
@주원 김 :: 문제를 해결하려고 해결방안에 볼두하는 할 게 없을 수 있다. 이미 다 필요하다고 생각했던 것이고, 누구나 다 생각할 수 있는 것이니까. 우리가 생각하는 범위 내에서 불편한 점이 있을 수 있기 때문에 거기에서 한번 주제를 던져보고, 안되면 재미를 위해서 기술에만 집중할 수 있는 것을 다음으로 선택해보면 어떨까 생각해보고 있다.
- 어느정도 기술적 역량이 있는가
- 어떤 경력이 있는가
@Zen :: 서로의 기술적 역량을 미리 공유했으면 좋겠습니다.
- 팀원의 목표에 대한 이야기
@주원 김 리액트를 이용하여 개발하는 법을 알고 해당 프로젝트를 왜 이렇게 만들었고 어떤 개선점들이 있었는지 설명할 수 있게 되는 성장을 하고 싶습니다 → 단순히 만드는 것이 아니라 꾸준히 개선이 필요하다고 생각합니다
@주원 김 우선은 취업이 목적이다 보니, 포폴에 들어갈 수 있는 프로젝트를 만드는게 목표인거 같습니다. 특히 제가 로봇관련 전공이다 보니 위치기반에 대해 관심을 많이 가지고 있는데 정말 이 방향이 맞는지 점검하고 기반이 되는 프로젝트를 만들기 그리고 단순 구현이 아니라 왜?를 알고 개발하기 입니다.
-
완성도 있는 프로젝트란 무엇인가에 대한 논의
@혜인 정 :: 코드적으로 완성이 있는지, 코드는 좀 더럽더라도 서비스적으로 완성이 되었는지… → 사용자가 보기에 제대로 돌아가는 게 먼저이다., 코드적으로 완성도를 높이는게 목표이다.
@주원 김 :: 6주는 프로젝트 완성이라는 기간, 완벽한 기능을 하게 만들어놓고, 이후 기간에 리펙토링을 했으면 좋겠다. 스스로 불만족하는 그런 코드를 개선하는 시간을 갖는 방향이 좋지 않을까 생각중
@동율 이 :: 실사용자가 있어야하고, 유지보수를 1년이 있어야 한다. → 서비스 완성이 되어야 한다. 기간도 짧고.
-
공통의 목표에 대한 논의
-
팀원 개개인의 목표에서 공통의 목표 추리기
- 공통의 목표는 각자 작성해온 목표에 도움이 되어야 한다.
- 공통의 목표는 팀의 의사결정에 기반이 되어야 한다.
-
공통의 목표를 바탕으로 행동 규칙에 대해 논의하기
@Zen :: 이에 대해서는 팀의 문화에 대한 이야기에서 논의해봐도 좋을 것 같습니다.
-
우리는 어떤 팀이 될 것인가?
@Zen :: 온라인이지만, 의사소통이 원활하고 활발하게 이루어졌으면 좋겠습니다. 코어 시간에라도 서로가 무언가를 물어보면 빠른 피드백이 올 수 있었으면 좋겠습니다.
슬랙의 경우 작업하다보면 슬랙 스스로 알림을 끄는 경우가 있어서,
Zep,게더타운등으로 각자 일하더라도 캐릭터가 찾아가서 말걸 수 있는 그런 환경이었으면 좋겠습니다. 그리고 코어시간 외나, 하루에 주어진 할당을 빨리 끝냈더라도.. 팀에 서로서로 무언가 더 기여하고자 하는 팀이었으면 좋겠습니다.@혜인 정 서로 친하고 편한 분위기면 좋겠습니다! 그리고 효율적인 팀이었으면 해요! 완전 노는 목적(?)이면 상관 없는데, 불필요하게 회의를 길게 하고.. 그런건 정말 비효율적이라고 생각합니다 ….. 개인적으로 회의 길게 하는 팀은 다 산으로 가고 작업률은 떨어지고 팀에 대한 집중은 깨지게 되더라고요 ….. 놀땐 놀고, 할 땐 하는 팀이었으면 좋겠습니다!!
@주원 김 우선 분위기는 최대한 좋게 가져가기 위해서 스몰톡도 하는 팀이었으면 좋겠습니다. 네부캠 마지막 코스인만큼 마지막까지 불태울 수 있도록 서로 동기 부여 할 수 있는 팀이 되고 싶습니다.
@주원 김 아직 기술이 정해진게 아니지만 그래도 위치기반이니만큼 위치 데이터를 시각화하는 것들을 다뤄보고 싶습니다.
@동율 이 제 생각에도 아무래도 친해질수록 말도 많이 하게되고 소통도 원활하게 될 것 같아서 화목한 팀이 되었으면 좋겠습니다
⇒ 베타테스트 해보고 별로면 다른걸 찾아보자. → “서로 실시간으로 편하게 소통할 수 있는 창구이자 장치를 뒀으면 좋겠다.” || “보이스로”
- 감시하는 장치를 만들자 ⇒ “감시하면 못하는 성격…”, || 화면공유 끕시다. → 킬사람
-
코어시간 활동 규칙 정하기
-
코어시간과 주어진 시간을 어떻게 활용할 것인가?
@Zen :: 개인적으로 코어 시간 내에
게더타운이나Zep을 이용해서 항상 화면공유하고 있었으면 좋겠습니다.온라인으로 비동기적 소통을 하더라도, 실제 오프라인처럼 팀원의 위치로 가서 대화를 할 수 있고, 자유롭게 소통이 되었으면 합니다.
@혜인 정 저는 개인적으로 휴식과 일/공부 등이 제대로 분리 되어야 더 빠르고 확실하게 작업을 할 수 있는 편이라, 최대한 코어타임 내에 모든 걸 효율적으로 진행하고 코어타임 외에는 작업을 진행하지 않았으면 좋겠습니다..!! 물론 본인이 맡은 작업이나 정말 필요한 경우는 당연히 해야겠지만, 장기적으로 달리는 프로젝트이기 때문에 과하게 하는 것보다는 멀리 보고 마라톤 경주를 할 수 있으면 좋겠어요! (부캠하면서 건강 해치시는 분들 너무 많이 봐서 .. 항상 모두의 건강과 컨디션이 우선이라 생각합니다….!!!)
@주원 김 제가 부족함이 좀 큰거 같아서 이번 기간에 좀 빠짝 해보고 싶어요ㅎㅎ 코어타임에는 줌이나 허들에 접속해있고 코어타임 외에는 자유롭게 개발을 하거나 쉬거나 하는 식으로 활용해도 좋을거 같습니다.
@동율 이 그룹 프로젝트이기도 하고 마무리 프로젝트인 만큼 코어 타임을 지키는게 좋을 것 같습니다! 개인적으로는 캠보다는 허들이 더 좋을 것 같네요! 재도님 말처럼 게더타운이나 Zep을 활용하는 방법도 좋을 것 같습니다.
-
-
기록은 어떻게 할 지 정하기
@Zen :: 노션은 지금처럼 실시간으로 함께 정리하는 용도로 쓰고, 이에 대한 요소도 이후 깃허브에 모두 올렸으면 좋겠습니다.
회의록 항목 따로, 이슈가 발생하면 깃허브 이슈로 작성하고, 항상 어떤 제안을 하기 전에 깃허브 이슈 문서로 정리하고 이야기를 하면 좀 더 효율적인 커뮤니케이션이 되지 않을까 싶었습니다.
트러블 슈팅도 그렇고, 발견한 문제, 배운 기술 등등 모두 깃허브의 기능을 제대로 활용해봤으면 합니다. ⇒ 포폴때 노션 링크에 들어가는 것 조차 비용이라는 말을 들었고 깃허브를 굉장히 잘 쓴게 보이면 그것 자체로도 이미 +일것 같기 때문입니다.
-
의사결정 방식 정하기
@Zen :: 의사결정을 어떻게 할 지도 굉장히 중요한 문제 같습니다.
개인적인 제안 사항은, 깃허브 이슈에 문제를 먼저 정리하고 그에 대한 근거를 마련해옵니다. 그리고, 그에 대한 논의를 이해관계자가 하는 것이 아닌 팀 전체가 매번 나누었으면 좋겠습니다.
4FE인 만큼, 모든 이슈와 기술 내용이 공유되어도 좋다고 생각하기 때문입니다. (저희가 같은 도메인인 만큼 언젠가는 만날 문제일 테니까요!)
@동율 이 모르는 부분이 생기면 바로 바로 이야기 하면 좋을 것 같아요! (제가 모르는게 굉장히 많아서 ㅎㅎ) @주원 김 매일 아침 데일리 스크럼에 토의가 필요하지 않을까 생각합니다
→ 깃허브 Issue에 자유롭게 남기기. ⇒ 좋은거, 나쁜거, 트러블 슈팅 등등 전부
→ 데일리 스크럼때 길게 잡아서 자유롭게 이야기
→ 급하면 젭에서 사람을 불러서 하기.
-
코드리뷰 및 PR 규칙 정하기
@Zen :: 4FE인 만큼 저희 모두가 서로의 기술을 자세히 알면 좋지 않을까하는 생각이 있습니다. 동료의 코드를 리뷰해주는 것과 더불어서, 이런 기술에 이렇게 쓰이구 있구나 하는 걸 이해하면 좋을 것 같다는 생각입니다.
이런 맥락에서 코드리뷰를 매일해도 좋지 않을까 하는 생각이 있습니다. 모두 FE인 만큼, 서로의 코드에 담긴 기술적인 내용에 대한 백그라운드가 같으므로, 매일 하는 코드리뷰는 서로에게 큰 도움이 될 거라고 생각하기 때문입니다.
진행상황 파악도 그렇고, 맥락에 대한 파악도 그렇고, 문서화도 그렇고 여러가지로 온라인이기에 발생할 수 있는 여러 커뮤니케이션 문제를 해결할 수 있는 장치가 될 수 있지 않을까 했습니다.
@Zen :: PR에 대해서 4명 다 Approve 해야 올라갈 수 있게 하면 어떨까 하는 생각을 해보았습니다.
PR도 지금까지와 달리 작은 기능 단위로 올라올텐데, 4FE인 만큼, 이를 제대로 파악만 해둬도, 서로에 대한 기술적인 이해에 대한 갭이 줄어들거라고 생각하기 때문입니다. (품이 많이든다를 제외하면, 제 개인적인 생각에서는 단점이 크게 보이지 않는 것 같다는 생각이 있는데… 언제나 그렇듯 그 품이 많이 드는게 문제이지만요 하하!)
@주원 김 : 비슷한 작업을 하고 있는 페어를 정해서 리뷰어를 정해봐도 좋을거 같습니다 → 코드리뷰 보다는 PR 리뷰면 좋을 것 같다. 코드하나하나 보지말고 이렇게 하는 게 어떨까. 방향성만 한번씩 보는. 코드 설명을 간략하게 하는 시간도…
@혜인 정 :: 데일리 스크럼에서 활용해보면 어떨까? 이 코드가 괜찮아야…
@Zen :: 공통된 규칙을 잡아갈 것. → 코드 슽아리 가이드, TS ⇒ 타입 정할 것. 그리고 몇가지 코드 쓸때 공통적으로 통일해야 하는 부분 || 어긋나는지 안어긋나는지. ⇒ 코드 리뷰하고, 데일리스크럼에서… 어느정도에서 스크럼
- 슥보자~
-
서로에 대한 작업 공유
@Zen :: 저는 매일 코드리뷰와 4명 모두 PR Approve가 어느정도 작업 공유에 대한 장치가 된다고 생각합니다. 이에 더해서, 하루에 작업 상황에 대한 요소를 기록하는 부분을 따로 빼서, 모았으면 합니다. (하루마다 스스로 평가해서 올리는 것이죠. 무엇을 했다, 무엇을 하고 있다, 어디서 문제가 발생했다 등…) ⇒ 개발자로서 탐구하는 자세도 중요하지만, 마감을 지키는 게 더욱 중요하다고 생각합니다. 6주간 프로젝트이고, 4FE인 만큼 매일마다 공유하고 서로가 한 일을 서로가 매일 상세히 이해하는게 나쁠게 있나…? 하는 생각이 있습니다.
@혜인 정 노션 등과 같은 툴을 이용해서 일감 관리를 하면 어떨까 싶습니다! 인턴할 때는 먼데이라는 일감 관리 앱을 써본 적이 있는데, 팀 단위 작업을 할 때 일감 관리 플랫폼을 이용해서 관리하면 정말 편하고 서로 좋더라고요!
@주원 김 7시에 끝나기 전에 허들로 간략히 얘기 나눠봐도 좋을거 같습니다. 그리고 노션에도 간략히 기록해둔다면 쉽게 찾아볼 수 있을거 같아요
@Zen :: 매일마다 코어시간 전에 하루에 대한 상황을 아주 짧게 요약해서 말해보는 것도 좋은 것 같아요. 실제로 지난 스터디그룹때 해봤는데, 비용은 적게드는 반면 얻는 효과는 굉장히 컸던 기억이 있어요! 단, 이게 PR리뷰와 코드리뷰라는 측면에서 겹칠수가 있어서 이것도 논의해보면 좋을 것 같아요!
-
회고 방식에 대한 생각
@Zen :: 현업에 있는 친구들과 회고를 하고 있는데, 생각보다 피그마를 활용한 회고가 좋은 것 같더라구요. 수료생 분이 하신 이야기와도 같은 방식인데, 이에 대해서는 이따 회의때 이야기드리겠습니다.
@주원 김 회고는 아직 잘 모르겠네요… 생각한거는 각자 작성하는것과 금요일에 회고 시간을 갖자 정도인거 같습니다
→ KPT ⇒ 쁘띠쁘띠…
→ F4
- 깃허브 파야함. 리포지토리.
- 네부캠에서 파주나요…? 거기 아래에서 우리끼리 하는것…?
- 팀명은 생각해보는걸로….
- 휴식! 카드
- 나 힘들다 카드 → 😴🥱 → 무제한
- 나 말좀 하게 해줘 카드 → ✋ → 무제한
- 스탑! 거기까지만… 너무깊게 가지마.. 카드 → 각자 PR에 남기기…
- 2장씩 → 내 말 무조건 들어줘 || 의사결정할때.
- 조건! 2:2 갈릴 경우만..
- 기본적으로는 다수결…
- 모두가 납득은 했을 떄
- 상식적인 선에서
- 2장씩 → 반차 (건강 때문에)
- 최소한의 할일은 끝내자.
- 마지막 바쁠땐 안됨.
-
포트폴리오 → 할말이 있어야 한다.
- 4FE :: 서로가 한 개발 내용은 자기가 개발하진 않더라도 다 이해했으면 좋겠다.
-
실사용자가 있었으면 좋겠다.
-
적어도 1년은 썼으면 좋겠다.
-
단순히 자기만족 프로젝트라기 보다는 프로젝트 그 자체가 가치가 있었으면 좋겠다. 그게 재미든, 뭔가 사회적 문제 해결이든, 우리가 장난식으로 쓰든(재미), 그냥 사용할만한 확실한 이유가 있었으면 좋겠다.
-
@혜인 정 :: 서비스는 사용자 기준으로 맞춰서 완성이 되어야 한다.
-
@동율 이 :: UX를 신경써서 서비스를 해보면 좋을 것 같다.
-
@주원 김 :: 가이드 → 만들어도 좋을 것 같다.
-
@Zen :: UI/UX 사용자 중심으로
-
UI/UX 사용자 중심으로 생각한다.
- 코드리뷰 경우도, 코드 자체의 품질이런것도 좋지만, 사용자경험에서의 코드리뷰
- 지금 한 내용 정리하기
- 멘토님 발표나면 바로 초대
- Zep이든 게더타운이든 하나 파서 공유
- 찜질방 넣기
- 월요일 :: 아이디어 생각해보기 → 아이디어 :: 만약에 올리시면 슬랙에 올렸다고 이야기…
- 멘토님께 누가 될 수 있으니까, 우리끼리 소통할 수 있는 창구를 만들어볼까요?
- 그냥 있는곳 쓰죠.
- 10시 7시 코어타임만큼은 집중하고 그 이외에는 자율 → 마지막이나 스프린트 다가오면 그때 결정하고, 일단은…
- 점심도 알아서 먹되, 쉬겠다는 룸으로 가면 적당히.. 눈치껏 ^^
- 아이디어 가져올때, 어느정도 좀 구현가능한 기술같은거 근거를 확실히 마련해옵시다.