Icebreaking

이렇게 몰입하는 삶을 계속 할 수 있는지는 생각해 볼 것.
작업물을 내는 것과 함께,
- 빠르게 습득하는 능력
- 어떻게 해야 설득 / 신뢰성을 주는가 처럼, 어떤 상황에서도 적절하게 대처하는 방법이 중요하다.

Team Gathering은 어떻게 해야하나?

데일리 미팅

오늘 할일(오전) + 하루 작업물 결과 공유(오후 10시)
10시까지 목표로 하여 작업하고 나머지 4시간을 모자란 부분을 채워야 함 ✨막히는 부분 있을 때 도와줄 수 있어야 함: 도움 필요한 사람이 10시 후에도 남겠지 → 10시 부터는 도움 주어야 함(함께 해결): 답지 보는 시간! 무작정 같이 하면 자기 것을 할 시간 없고 + 자기가 해결할 능력을 기르는게 필요함.

하루 2회(스크럼) | 물어볼 시간은 10시 이후

위클리 미팅

이번 주 진행한 것들
고민한 것들
다음 주 해야할 것들

보완/추가해야 할 것들

주간 회고: 프로젝트

매주 스프린트 회고
BE + FE 가 연동된 채로 실제로 직접 테스트 해보기⇒ 연동 후 고쳐서 시연해야 함
매주 작업 진행한 것들에 대한 회고
- 다음 주에는 어떤 액션 아이템을 해야 더 잘할 수 있을까 선정
정리한 것을 토대로 토요일 일요일은 마무리 못한 것을 마무리하는 시간
개인은 매일 하는 것을 추천

금요일에 하는 한 주에 대한 평가

금주의 주간 회고

Github Project 좀 더 상세하게 작성할 것

태스크 하나하나마다 걸린 시간을 추적할 수 있도록
작업자(assignee)가 누구인지 지정하기가 누구인지
해당 작업 티켓이 몇 시간 소요될 것 같은지 예측하여 기록해두기 ✨작업량에 대한 예측이 될 수 있어야 함: 프로젝트는 정해진 시간이 있다.

작업시간 추적/측정하기

동일한 시간 대비 더 많은 아웃풋을 내놓는 것으로 결과가 나타나야 한다. → 기록을 나아가는 발판으로 한다.

작업시간 예측: 왜 예측 시간이 긴 것인가?
작업시간 실제
작업시간 오차 : 왜 예측을 못했는가?
작업시간 오차 회고: 왜 오래걸렸는가?
병목 지점: 작업하는 지점에 있어서 병목 지점이 있는가?
병목지점 해결 방법

→ 예측과 실제 작업 시간의 오차도 기록, 분석

미팅시 준비해야 하는 사항

한 주간의 회고를 공유한다.
진행하면서 막힌 점 & 궁금한 점 공유
제품 시연: 실제 작동하는 제품을 기능 위주.
남은 기능 공유: 배포 후 연동하여 진행은 연동된 프로젝트를 토대로 진행해야 한다.

개인 회고(3FS, 권고)

공유 목적의 일기 템플릿이라고 생각하자.

3FS란 Facts, Feelings, Findings 의 약자로 Three Fs 라고 읽습니다.

예를 들어, “뭐뭐뭐를 해봤다. 그래서 어떤 느낌이 들었다. 그리고 거기에서 어떤 교훈을 얻었다”의 형식을 사용합니다.

3Fs를 쓰실 때는 각 요소가 자연스럽게 연결돼야 합니다. Fact 여러 개 나열 후 Feeling 여러 개를 나열하고, Finding 여러 개를 나열하는 식으로 정리하려고 하면 실패합니다. 어떤 교훈을 얻기 위해서는 계기가 되는 강렬한 느낌이 있어야 하고, 이 느낌은 반드시 어떤 사실에 근거해야 합니다. 즉, 무언가를 경험하고, 거기서 느낀 바가 있기 때문에, 우리는 배우게 됩니다. 이렇게 하지 않으면 “공부한 걸 요약 정리”하는 형태의 글을 쓰게 되고, 이건 회고와 다르게 “실천”할 수 있는 요소가 없게 됩니다.

오늘 나는 무엇을 배웠나?

[코드숨] 3주차 주간회고

프로젝트 내용에 대하여

핵심 기능

에디터 + GPT: 나머지는 연동하기 위한 최소한의 기능을 우선으로 하여 무조건 끝낼 것. CRUD , 검색기능 같은 것은 중/하 순위로.

공부와 코딩의 우선 순위

공부하고 나아가기보다는 하면서 공부해야 기본적인 개념에 대한 공부만 하고 진입

좋은 개발자의 순환: 일단 부딪혀보고 ⇒ 찾아보고 ⇒ 적용
Gpt에는 22년, 23년 버그는 없다. ⇒ 검색하는 역량을 키워보는게
깊이있는 문제를 해결하는 것 지금에서는 불필요.
구현 들어가서 문제가 발생하면 문제를 해결해나가는게 낫다.
갖다 붙여서 해결했는데, 빈 부분에 대해서는 나중에 블로그 같은 곳에 정리해 놓았다가 공부할것.
구현한 뒤에 폴리싱 때 리팩토링, 오개념 수정할 것

편집 툴 라이브러리

npm 트랜드보다는 최근 커밋, 릴리즈된 라이브러리를 위주로 볼 것
- 어떤 라이브러리 쓸지 조사 중
구현 방법을 찾아보자.
- 유사한 서비스 확인 → 검색해서 사용된 오픈소스들을 확인 novel.sh
- 로드맵을 꾸밀 수 있는 사이트도 괜찮 visual editor

주요 기능은 “생성한 것을 로드맵으로 그리는 것”

직접 구현한 것은 거의 없을 것: 오픈소스들을 활용하여 어떻게 적용할 것인지
찾은 것으로 실제 프로젝트에 간단하게 적용해보아야 적용 시간, 난이도 등 맞는 라이브러리를 찾을 수 있다.
찾는게 일이 되면 안되고 적용까지 해 봐야 함

예: orbean

Q&A

Front

Q: 와이어 프레임을 피그마로 옮기기엔 시간이 부족할 것 같다. A: 없어도 ㄱㅊ. 대신 괜찮은 디자인 system을 골라야 함. 피그마도 이런 디자인 시스템 가져와서 사용. 일관성이 있을 수 있지만 지금은 코어 기능만 필요하니까.

antd 엔터프라이즈 디자인 컴포넌트 모임(React 지원)
mantine 등. material(MUI) 사용성과 필요로 하는 기능이 있는지만 확인.

Back

Q: 데이터 테이블 디자인 중: 실시간 편집 부분 데이터 처리는 어떻게 해야? A: 공유 부탁

기타

제품을 빠르게 내는 게 기술력보다 더 중요하다. 어느 정도 기업의 규모가 커져야 기술이 중요해진다.
프로젝트 발표 시에는: Frontend CI/CD 구성 Backend CI/CD구성, 시스템 아키텍처, AWS 솔루션도 포함시킬 것.

Categories

[Weekly Feedback] 02. 팀 미팅은 어떻게 해야 하는가