2주차 회고

백로그 상 실제 해결한 시간: 27시간

이번 주에 들인 시간: 144시간

실제 쓴 시간: 각자 11AM부터 평균 12시간씩..?

→ 하루에 모두가 일한 시간: 48시간

→ 이번 주에 들인 시간: 48 * (약 3일) = 144시간

결론: 144시간을 들여서 27시간을 해결

결론2: 533% 정도 우리를 과대평가 했다.

모노레포 관련된 이슈

빌드

한쪽만 바뀌어도 지금 둘 다 빌드해서 이게 효율적인가? 라는 생각이 조금 들었습니다.

빌드:

근데 제가 해결 방법을 모르는 걸 수도 있어요.

npm install

공통 패키지나 파일들을 루트에서 관리할 수 있다는 점이 장점인데 배포서버에 올라갈 때마다 매번 npm install을 하게되는 상황에서 패키지 공유가 장점이 아닌 것 같아요.

/cache 파일로 pull 받는게 아니라

클라이언트 / 서버 한 쪽만 수정되어도 루트의 node_modules/ 다시 install 받게돼서

🤔 클라이언트 서버 나눠져 있으면 그래도 install 하는건 똑같잖아요?

앞으로도 했으면 좋겠는 것

페어 프로그래밍을 하는게 되게 좋았어요.
- 그라운드룰에 30분이상 고민하는 부분은 팀원과 공유하기로 했었는데 같이 공유하고 해결하는 과정에서 놓치는 부분이나 몰랐던 부분을 알 수 있게 돼서 좋았어요.
- 혼자하는 프로젝트가 아니라는게 느껴졌어요. 👍
- 프로젝트에서 발생하는 이슈 공유가 잘 되어서 좋았어요.

앞으로 더 잘할 수 있는 것

진행상황 공유가 한번씩 잘 안될때가 있어요.
- 백로그의 역할인데 백로그 티켓 외 이슈들이 생기면 공동 작업을 하는 경우가 생겨요.
- 게더에서 작업을 하다가 고민이 생기면 바로 다른 분들에게 찾아가는 식으로 진행하고 있는데
- 이 과정에서 게더를 확인하고 있지 않는 분들은 다른 분들이 어떤 문제를 해결하고 있는지 모르게 돼요.
- 해결하기 위해서 슬랙에 공유하고 있는데 슬랙에 다른 메세지를 보내면 공유한게 묻혀요.
PR 메시지 없는 PR은 어떻게 생각하세요?
- follow하는데 어려움이 있어요.
- 이건 좀…
- https://github.com/boostcampwm-2022/web27-Wabinar/pull/71
- 작성자: 반성중 … 급한 이슈라서 해결하고 뭔가 다른 작업이 있었나봐요 …
아직도 스크럼하다가 딴길로 많이 새요.
approve 1명으로 바뀌어있었는데 수정하신다면 이유도 알려주시면 좋겠어요
프론트엔드 작업 테스팅이 안되고 있어요

다음주에 해보면 좋을 것

야근 금지
다음 목요일은 진짜 리팩토링 데이였으면 좋겠어요
플래닝 포커 할 때 기준을 명확하게 정해뒀으면 좋겠어요
- 현재 예측 시간의 전제: 이 티켓을 해결하면서 발생할 수 있는 학습이나 다른 작업들이 완료되었다
- 현실: 이 티켓을 해결하기 위해서 다른 이슈들이 선행되어야 하고 놓쳤던 새로운 이슈들이 가득
원래 태스크를 해결할 수 있는 시간을 제외하고 새로 생겨난 이슈들을 해결하기 위한 버퍼 시간을 정해요.
- 모든 태스크를 예측할 수 없어요.
- 태스크를 진행하다 보면 생각못한 이슈들이 생겨나요.
  - 선행되어야 하는 태스크
  - 버그가 발생
  - 리팩토링
- 이런 예측 못한 태스크들은 보통 팀원들의 도움을 받아 트러블 슈팅을 해요.