Keep

<aside> ✅

이경민

• 각자 진행도 및 개발상황 공유한 데일리 스크럼

</aside>

<aside> ✅

이승현

• 매일 아침 10시 짧게라도 진행한 데일리 스크럼
• Jira를 활용한 1차 목표 설정과 구체적인 진행 상황 공유
• AWS 배포를 통한 마이크로서비스간 원활한 통신 테스트 가능 </aside>

<aside> ✅

이다예

• 매일 같은 시간 진행한 데일리 스크럼
• 적극적인 협업 툴 사용 </aside>

<aside> ✅

정다겸

</aside>

<aside> ✅

최우탁

• 팀원 간 진행 상황을 원활히 공유
• 일정 관리 도구를 통해 일정을 효과적으로 공유 </aside>

<aside> ✅

황선영

• 공통 ApiResponse 포맷을 만들어 전 서비스에서 일관된 응답 구조를 유지함
• 서비스별 역할과 책임을 구분하여 도메인 간의 경계를 어느 정도 확보함 </aside>

Problem

<aside> 🔥

이경민

• 본인이 맡지 않은 부분에 대한 이해도 부족
• 테스트 코드 작성하지 않아 배포 상황에서 오류 발생시 확인이 지연됨 </aside>

<aside> 🔥

이승현

• PR리뷰를 진행했지만 후반으로 갈수록 일정이 빠듯해져 소홀해진 리뷰
• 서로가 사용한 기술에 대한 공유와 이해 부족 </aside>

<aside> 🔥

이다예

• 프로젝트 기간이 짧아서 아쉬움 </aside>

<aside> 🔥

정다겸

</aside>

<aside> 🔥

최우탁

• 통일감이 충분하지 않은 팀 내 코드 컨벤션
• 장애 발생 시 로깅 부족으로 인한 원인 분석과 디버깅 어려움 </aside>

<aside> 🔥

황선영

• 테스트 코드 작성을 거의 하지 않아 배포 이전 오류 확인이 어려움
• Kafka 장애 발생 시 대응 절차가 명확하지 않음
• 공연 도메인이 공연장, 출연진과 직접 연관되어 있어 코드 복잡도와 의존성이 증가함 </aside>

Try

<aside> 🛠

이경민

• 각 서비스 별로 사용한 기술 및 구조 발표
• 주요 기능 별 핵심기능 테스트 코드 작성 </aside>

<aside> 🛠

이승현

• 고정적인 PR 리뷰 시간 설정
• 스크럼 시간을 제외한 추가적인 스터디/발표 시간을 통해 본인이 사용한 기술에 대한 지식을 팀원들과 함께 공유

</aside>

<aside> 🛠

이다예

• 지금 프로젝트 연장하여 꾸준히 개선시키기 </aside>