시간 00 : 00 ~ 01 : 00
사각사각팀의 회고의 목적
- 다음 스프린트를 개선할 수 있다.
- 현 스프린트 문제점, 아쉬웠던 점을 파악한다.
- 우리팀 잘한점 & 보완할 점을 파악한다.
- 배운점을 정리할 수 있다.
사각사각 회고 질문
-
힘들었던 점(개발, 협업, 문서화)
- 히히 : 서버 관리, 회의 시간이 생각보다 길다. 스펙 협의 등등의 문서화, 리소스 분배를 어디까지 해야할지?
- 에일린 : 회의 시작 시간 뿐만 아니라 회의 끝나는 시간도 같이 정하면 좋을 것 같다. 비동기적 커뮤니케이션을 활용해봤으면 좋겠다( 지라에 댓글 활용)
- 윤: 오류 잡기에 시간이 너무 들어가서 진도가 늦어졌다,
1차 스프린트 때 만든 기능을 너무 급하게 만들어서 리팩토링에 시간이 많이 걸린다
- 송 : 기능이 점점 많아지면서 삐적대는 부분이 늘어났다, 정책과 세부 구현 사항 사이를 구분하기 어려워 커뮤니케이션 비용이 많이 발생한다.
- 에이다: 오류를 잡는 부분에 있어서 프론트 문제인지, 백 문제인지 파악하고, 그 뒤에 문제가 된 부분이 정확이 어디인지 찾는게 쉽지 않았던 것 같다. 그리고 리팩토링 하는 게 생각보다 오래걸리고 어려웠던 것 같다.
- 마레 : API를 만드는 것에만 치중한 나머지 안정적인 개발을 하지 못한 점, 문서화 작업(지라 관리, 노션 문서화, 이슈 관리 등)
-
일정이 딜레이 된 이유
- 히히 : 서버 문제 터질때마다 개인 티켓 뒤로 미뤘음. 문서화에 시간 많이 씀. 오류 생겼을 때 원인점 찾기 어려웠음
- 에일린 : 기능 구현 뿐만 아니라 리팩토링, 오류 잡는 거에서 시간을 많이 썼음.
- 윤: 1차 스프린트 때 만든 기능을 너무 급하게 만들어서 리팩토링에 시간이 많이 걸린다
전체적인 폴더구조나, 라우터 등등 리팩토링 할 것들이 너무 많아서 진도를 못나갔다
- 송 : 1차 스프린트 기능에 대한 확인 작업이 늦어졌고, 협업을 하면서 연관된 부분이 있으니 전체적으로 딜레이 된 것같다.
- 에이다: 오류의 이유를 찾아서 서칭하는 시간도 길었고, 기능 구현이 처음 생각과 달리 어려웠다는 점에서 점점 밀리기 시작 한 것 같다.
- 마레 : 기능 구현을 우선적으로 해서 다른 오류나 리팩토링 작업들도 많아지게 되어서 일정에 지장이 생겼다.
-
우리팀 이거 안지켜진다.
- 히히 : 지라 관리, 깃 브랜치 관리, 팀 전체적으로 확인해야하는 문제가 생겼을 때 누군가는 개인 작업을 진행함.
- 에일린 : 코드리뷰 (급하다보니 빠르게 머지하게 된다. 혹은 실시간)
- 윤 : 브런치 관리
- 송 : 브런치, 코드 컨벤션, 일관성, 코드리뷰
- 에이다: 깃 브랜치(저222)
- 마레 : 브랜치 관리(저), 코드 리뷰
-
깨달은 점
- 히히 : 코드를 어떻게 하면 확장시켜나갈 수 있는지, 근본이 무엇인지 무엇이 핵심인지 망각하지 말자는 점, 프론트 기술을 알고 이해하는 백엔드 개발자가 되자
- 에일린 : CORS 설정 , 스트림 활용
- 윤: 함수 실행과 렌더링 과정의 순서? 에 대해 좀 더 잘 알게되어서 1차 스프린트 때 해결하지 못한 기능을 구현하거나 오류를 해결할 수 있었다
- 송 : useEffect data fetching, CORS 원인과 해결법
- 에이다: 쉽지 않다. CORS 에러에 관해 서칭할 때는 시큐리티에 대한 부분은 보질 못했었는데 그 부분에서 문제가 발생했다는 점(CORS에도 여러 이유가 있을 수 있구나 하는 걸 깨달음.), 넷틀리파이로 배포하면 자동으로 https로 배포가 된다, 버셀 배포는 간단하고 빠르다, 컴포넌트를 만들 때는 처음부터 재활용을 생각하고 좀 더 추상화하자.
- 마레 : 기본적인 개발에 조금 더 힘을 쓰자, CORS에러에 관한 문제
-
개선사항
- 히히 : 팀 개선 사항 적극적으로 고민하기. 팀 회의하면 내 일이라고 생각하기. 본인 일에만 우선하지 말자. 지라 적응기는 지났다고 생각하고 이제는 지라를 협업툴로써 잘 써야하는 시점이라고 생각.
- 에일린 : 기능이 끝나면 바로 branch 삭제 하기! 문서화 하기! 현실성 있는 스프린트 작업 분배
- 윤: 시간에 쫒겨서 되는대로 구현하지 말고 기간을 못지키더라도 어느 정도는 차근차근 수시로 리팩토링 해가며 코드 짜기
- 송 : 시간 효율적으로 쓰기, 기능 하나하나 제대로 만들기, 팀 개선 사항을 빠르게 적용하기
- 에이다: 현실적으로 나중에 리팩토링 하기가 쉽지 않다. 스프린트 기간에 소화할 일을 리팩토링까지 고려해서 설정하는 게 좋지않을까?
- 마레 : 문제가 생기거나 논의할게 있으면 팀원들과 얘기하기. 개발을 효율적으로 하기
- 회고를 바탕으로 3차 스프린트부터 이런 규칙을 세워봅시다!
- 회의 시간을 정해서 진행해봐요.
- 회의 안건 미리 정하기.
- 회의에 필요한 내용 미리 생각하고 각자 정리하고 작성까지 하기
- 회의 시간에는 오로지 의견 공유 및 결정만 한다.
- 스프린트 공수 산정을 잘해보자.
- 스프린트에 사용할 스토리 포인트를 정해보세요. (8시간)
- 하루에 사용할 스토리 포인트를 정하세요
- (모든 시간을 포함하세요, 회의도 티켓을 만들어도 좋습니다.)
- 히히 : 10시간
- 윤: 10~12시간
- 에이다: 12시간
- 에일린 : 8시간
마레 : 담주 (수)까지 5시간 , 이후 24시간- 송 : 8시간
- 스프린트 종료 전, 종종 번다운 차트로 중간 과정을 확인하세요.
- 중간에 잘 진행 되고 있는지 확인을해야 합니다.
- api 연동 끝나면 지라 댓글 남기고 담당자들끼리 확인하기.
- 브랜치 정리 잘하기