-
Notifications
You must be signed in to change notification settings - Fork 5
W2D3 데일리 스크럼
1000 - 1100 : 공유 오피스 출석 및 개인 시간 보내기
1100 - 1130 : 데일리 스크럼
1130 - 1300 : 점심 시간
1300 - 1400 : API 명세
1400 - 1430 : 데이터 타입 확정
1430 - 1600 : 로그인 설계 전체 회의
1600 - 1730 : 로그인 구현
1730 - 1930 : 마스터클래스
1930 - 2100 : 로그인 1차 구현자 시도
2100 - 2130 : 멘토링
2130 - 2200 : 로컬 로그인 모달 1차
2200 ~ 2230 : 작업 상황 공유
!!!! 2300 마감 시간 !!!!
-
개발 환경 설정
- 커밋, Issue 및 PR 관리
- 전반적인 작업 방식
-
스키마 반영
- Prisma 관련 공유 사항
-
timezone: Zulu time으로 저장됨 → 변환할 때 date 객체 생성
-
query 확인하기: PrismaClient 생성할 때 아래와 같이 작성해주기
const prisma = new PrismaClient({ log: ['query', 'info', 'warn', 'error'], })
-
Nested query: Join을 해서 가져오는 줄 알았지만 사실 쿼리를 여러 개 날리는 방식으로 작동..
-
- Prisma 관련 공유 사항
-
API 명세서 초안 작성
- API 명세서 확정
- 로그인 설계
- 로그인 구현
- 기술공유는 각자 준비
- 작업한 내용 같이 마무리하는 시간이 필요할 듯 → 그라운드룰에 추가
- 작업 종료 시간 정하기
- 작업 시간이 예상보다 오래 걸렸으니 회고 필요
-
FE: 오래걸릴 수밖에 없었다..?
-
BE: 프레임워크를 사용하지 않다보니 구조를 정하고 이해하는 시간이 오래 걸림
→ 앞으로 설계에서 회의를 충분히 해야함
-
꼭 4명이서 같이 작업을 해야했을까? 구조를 같이 결정했다면 이후엔 분업을 했어도 효율적이었을 것 같음 → 분업 후 공유가 잘 이루어져야 함
-
구조 설계를 같이 하기로 합의되어 있었는데 ESLint와 같이 협업할 필요가 없는 작업들에 매몰되어 버림…
→ 진행하면서 협업이 필요한 작업인가?를 계속 고민해보자!
-
팀장의 역할이 중요함 → 팀장이 작업의 전체 흐름을 담당한다든지 역할 정의가 명확해야함
-
작업을 시작하기 전 각자의 역할을 나누자!
-
다음 주부터는 팀장이 팀 전체의 작업 속도를 조율하는 역할을 하게 될 듯
-
사람이 많으면 모두의 이해를 맞추는데 시간이 걸리는 게 당연한데 작업 시간을 너무 짧게 잡았다
-
어제는 작업을 하면서 이해를 동시에 해야하는 상황이었음 - 4명은 어렵고 2 & 2이 이상적
-
오늘 작업도 설계를 같이 하면 이후엔 분업해도 되지 않을까
→ 어떤 식으로 나눌지? FE/BE?
- FE/BE로 나누고, 로컬 로그인, OAuth 로그인 각각 역할 바꾸자
- 작업량 균등하게 나눠질까..? 하는 우려는 있음
- FE는 구현과정에서 컴포넌트에 대한 논의(공통 모달)를 할 수도 있을 것 같음
그라운드룰에 추가하면 좋을 사항
- 작업 시작 & 종료 시간 정하기
- 팀장은 타임테이블대로 작업이 진행될 수 있게끔 조절하는 역할