중간 회고

소통

• 스몰 토크

• 저희는 날선 사람이 없어서, 항상 스무스한 분위기
• 특별히 누군가의 감정이나 예민한 부분이 있는지 걱정하지 않고 이야기 할 수 있다는 점 좋다

• 화이트보드로 스크럼 시간 절약 (10분)

• 프로젝트 초기라 그런지 소통이 원할하진 않음
• 개인적인 능지 이슈가 있어 몇가지 실수가 있었음 (ㅇㅔ엥?)
• 왜 그러면 이해가 안될 때 한 번더 물어보면 되지 않나?
• 이해했다고 생각했는데, 하려고 할 때 아니였다..

• 가볍게 물어보는 것의 어려움
• 온라인의 문제일까, 시간부족의 문제일까, 말을 통한 소통이 더 빠를 텐데, 그 침묵을 뚫고 가볍게 물어보기 가 어렵다
[ Try ]
• 코어타임 마이크 on || bgm ? ㅋㅋㅋ
• 10분이내 끝낼 이슈들은 디코방 2인실 ㄱ?
• 15분 구경?
• 방해금지모드?
• 내 문제 해결을 위해 바로바로 말하는 것이 팀적으로 도움되는 것
• 가벼운 문제라도 생기면 바로 채팅을 통해 1차 알림 후 소통이어나가기

• PR리뷰 사항들이 전부 반영되지는 못하는 듯 하다
• eslint-ignore 관련
[ Try ]
• 룰등을 바꿀 필요가 있다면 PR을 통해 알리는 것보다, 먼저 말하고 하는게 옳지 않을까?
• rule을 바꾸고자 한다면, 슬랙이나 채팅에 바꿔야 하는 이유와 함께 남기자

• 우리는 같은 그림을 보고 있는가? 같은 그림을 보기 위해 얼마나 노력하는가?

• 텍스트로 전달하는게 어려움
• 문서로 소통이 가능하게 하는 것은 매번 느끼지만 어렵다
[ Try ]
• 화이트 보드 많이 활성화하기
• 변경사항 등 있으면 이야기 한 것도 반드시 적어두기

• 구두로 소통 당시에는 이해되었다고 생각하지만 나중에 각자 이해한 방식이 달라 PR 리뷰 때야 알게되는 경우가 있었다
• 지나가는 말
[ Try ]
• 소통을 좀 더 확실하게 하자

• 익명5님 처럼 작업 시간대 뒤바뀐 사람과 같이 어떻게 하는거지?
• (외국인 아니면 없는 특수경우라고 생각하고 맞춰가는 ..)
[ Try ]
• 두 번 이야기 보다 빠르게 가성비 있는 문서를 작성(핵심만 위주로 작성)하는 방법이 최선이지 않나..
• 익명5님은 핵심을 파악한 상태에서 담당자에게 디테일한 부분을 따로 문의하는 방법

개발 진행 관련

• 미해님이 디자인에 투자한 시간에 대한 감사와 respect

• 개발환경 세팅들 솔선수범하여 미리 해주신것에 대한 감사

• 인터페이스 미리 구현해준 것에 감사

• 깔끔한 코드를 보고 많이 배울 수 있어 감사

• 개발 진행속도는 느리다고 생각해용
• 이유는 기획 단계가 부실해서..
• 2주에 맞는 기획을 생각해야 했으나 adv를 고려하면서 복잡도가 높아졌다 (4주 정도의 욕심)
• adv 고려하면서 basic의 구체적 기획이 부족했다
[ Try ]
• 데드라인에 맞는 기획을 하자

• 팀 개발이 익숙하지 않아서 팀 RULE 익히는게 오래 걸렸음
• 동의 동의2

• 2주에서는 도전을 하면 안될 듯? → 인간은 도전하는 동물이에요!! (re:ㅋㅋㅋㅋㅋ)
• 공통 기술 스택 관련
• 새로운 개발 스택 적응에 오래 걸렸음
[ Try ]
• 학습과 프로젝트를 구분하자
• 가장 잘하는 걸로 하자
• 오류는 채팅으로 빠르게 물어보자
• 다른 사람이 경험했을 확률 높다

• 코드리뷰를 어느 정도로 해야 하는지 고민이었고, 리뷰하는데 보다 많은 시간 소요
[ Try ]
• 첫 페이지를 구현한 다음에는 PR단위를 줄이자 + 가독성 좋은 PR 메시지를 쓰자

• 개인 < 프로젝트 < 서비스단 에서의 우리 코드 기준은 어디인가
[ Try ]
• “basic First, advance Later Due to TimeLimit“
• “Do First, Refactor Later” 12345 vs 13579

• 어렵지 않다고 느끼는데, 빠르다고 느끼진 않음 → 쉬운데 오래걸림 .. → 저도 동감

• container 폴더의 역할? 의미?
• 소통문제도 있는 것으로 → 일단은 ㄱㄱ
[ Try ]
• 각자 리뷰 올린 후 폴더구조 결정

• api 처리하느라 시간이 많이 소요되었다
• 백엔드와의 소통과정 체험이랄까

• 선협님이 짜놓은 컴포넌트, hooks 그냥 가져다 사용할 수 있는 부분들 있는데, 바람직한가?

기타 (어려운점 , … )

• 음..

• zenHub 도입 의미 있었나?
• 에픽 단위로 이슈를 관리한다는 측면에서 어느 정도 장점은 확실히 있다고 생각
• 지금은 하나의 에픽을 한 사람이 관리해서 + github 자체 칸반이 있어서 효용성이 적다
[ Try ]
• issue + PR 연결, epic등록만 같이 잘해주기

• 라이브러리 도입(formik)
• 익히는데 하루 꼬박 걸림

• 페이지 구현 기본 로직들이 바로바로 생각나지 않아 시간을 많이 썼다
• 시간에 쪼들린다고 생각해서 생각날 것도 잘 안난다
• 로직 분리에 대한 고민들을 했는데 생각만큼 잘 되진 않아서 일단 어거지로 쓰는 중
• hook과 분리된 완전한 로직을 작성(클래스 형식으로)하고 싶었는데, 해당 부분이 쉽지 않다

• 제어/비제어 컴포넌트 선택과, 비제어 컴포넌트로 할 수 있는 구조를 짜다가 포기하고 되돌아 온 것

• 로직을 분리하는 것에 있어 어느 정도로 분리할지 / 어떤 폴더에 넣어야 할지 고민이 많았다

• 구현 시 확장성에 대한 고민을 하다 많은 시간을 보냈다
[ Try ]
• 확장성 관련은 PR과 develop에 올린 것만 참고하자!