Portfolio

시간 00 : 00 ~ 01 : 00

히히 : 서버 관리, 회의 시간이 생각보다 길다. 스펙 협의 등등의 문서화, 리소스 분배를 어디까지 해야할지?
에일린 : 회의 시작 시간 뿐만 아니라 회의 끝나는 시간도 같이 정하면 좋을 것 같다. 비동기적 커뮤니케이션을 활용해봤으면 좋겠다( 지라에 댓글 활용)
윤: 오류 잡기에 시간이 너무 들어가서 진도가 늦어졌다, 1차 스프린트 때 만든 기능을 너무 급하게 만들어서 리팩토링에 시간이 많이 걸린다
송 : 기능이 점점 많아지면서 삐적대는 부분이 늘어났다, 정책과 세부 구현 사항 사이를 구분하기 어려워 커뮤니케이션 비용이 많이 발생한다.
에이다: 오류를 잡는 부분에 있어서 프론트 문제인지, 백 문제인지 파악하고, 그 뒤에 문제가 된 부분이 정확이 어디인지 찾는게 쉽지 않았던 것 같다. 그리고 리팩토링 하는 게 생각보다 오래걸리고 어려웠던 것 같다.
마레 : API를 만드는 것에만 치중한 나머지 안정적인 개발을 하지 못한 점, 문서화 작업(지라 관리, 노션 문서화, 이슈 관리 등)

히히 : 서버 문제 터질때마다 개인 티켓 뒤로 미뤘음. 문서화에 시간 많이 씀. 오류 생겼을 때 원인점 찾기 어려웠음
에일린 : 기능 구현 뿐만 아니라 리팩토링, 오류 잡는 거에서 시간을 많이 썼음.
윤: 1차 스프린트 때 만든 기능을 너무 급하게 만들어서 리팩토링에 시간이 많이 걸린다 전체적인 폴더구조나, 라우터 등등 리팩토링 할 것들이 너무 많아서 진도를 못나갔다
송 : 1차 스프린트 기능에 대한 확인 작업이 늦어졌고, 협업을 하면서 연관된 부분이 있으니 전체적으로 딜레이 된 것같다.
에이다: 오류의 이유를 찾아서 서칭하는 시간도 길었고, 기능 구현이 처음 생각과 달리 어려웠다는 점에서 점점 밀리기 시작 한 것 같다.
마레 : 기능 구현을 우선적으로 해서 다른 오류나 리팩토링 작업들도 많아지게 되어서 일정에 지장이 생겼다.

히히 : 코드를 어떻게 하면 확장시켜나갈 수 있는지, 근본이 무엇인지 무엇이 핵심인지 망각하지 말자는 점, 프론트 기술을 알고 이해하는 백엔드 개발자가 되자
에일린 : CORS 설정 , 스트림 활용
윤: 함수 실행과 렌더링 과정의 순서? 에 대해 좀 더 잘 알게되어서 1차 스프린트 때 해결하지 못한 기능을 구현하거나 오류를 해결할 수 있었다
송 : useEffect data fetching, CORS 원인과 해결법
에이다: 쉽지 않다. CORS 에러에 관해 서칭할 때는 시큐리티에 대한 부분은 보질 못했었는데 그 부분에서 문제가 발생했다는 점(CORS에도 여러 이유가 있을 수 있구나 하는 걸 깨달음.), 넷틀리파이로 배포하면 자동으로 https로 배포가 된다, 버셀 배포는 간단하고 빠르다, 컴포넌트를 만들 때는 처음부터 재활용을 생각하고 좀 더 추상화하자.
마레 : 기본적인 개발에 조금 더 힘을 쓰자, CORS에러에 관한 문제

히히 : 팀 개선 사항 적극적으로 고민하기. 팀 회의하면 내 일이라고 생각하기. 본인 일에만 우선하지 말자. 지라 적응기는 지났다고 생각하고 이제는 지라를 협업툴로써 잘 써야하는 시점이라고 생각.
에일린 : 기능이 끝나면 바로 branch 삭제 하기! 문서화 하기! 현실성 있는 스프린트 작업 분배
윤: 시간에 쫒겨서 되는대로 구현하지 말고 기간을 못지키더라도 어느 정도는 차근차근 수시로 리팩토링 해가며 코드 짜기
송 : 시간 효율적으로 쓰기, 기능 하나하나 제대로 만들기, 팀 개선 사항을 빠르게 적용하기
에이다: 현실적으로 나중에 리팩토링 하기가 쉽지 않다. 스프린트 기간에 소화할 일을 리팩토링까지 고려해서 설정하는 게 좋지않을까?
마레 : 문제가 생기거나 논의할게 있으면 팀원들과 얘기하기. 개발을 효율적으로 하기

2차 스프린트 회고