Sprint 2 회고록¶

📋 개요

회고 플레이에 대한 설명을 따라 지난 작업을 돌아보고 개선의 기회를 식별한다.

i KEEP, PROBLEM, TRY 항목을 아래 표에 정리한다. 이 항목을 바탕으로 다음 스프린트에서 개선할 Action Item을 정한다.

KEEP	PROBLEM	TRY
화면 확정 전 팀이 함께 리뷰해 피드백을 빠르게 반영하고, AI로 시안을 빠르게 뽑아 반복 주기를 줄임 스프린트 초반에 아키텍처를 먼저 공유해 트랙 간 인터페이스 이해를 맞춰 병렬 작업 충돌이 적었음 개발 환경·설계를 스프린트 내 대부분 확정해 다음 스프린트 구현 착수 장벽을 낮춤	데이터베이스 지식 부족으로 ERD 설계가 늦어져 블로커가 됨 인프라 배포가 안 돼 통일된 실행 환경을 갖추지 못함 착수 전 완료 기준을 불명확하게 잡아 시간 산정을 못 하고 스프린트 이슈를 완료하지 못함 유저 가치 검증 없이 스토리를 만들어 우선순위 낮은 기능에 공수를 소모함 각자 당일 작업 계획을 팀에 공유하지 않아 서로의 진행 방향이 보이지 않음 데일리 스크럼을 꾸준히 쓰지 않아 한 일이 공유되지 않고, 이를 뒤늦게 확인하는 중복 비용이 발생함	기획 멘토에게 유저 스토리 작성법을 물어봄 데이터베이스 정규화 예제를 풀어 지식 공백을 메움 중요한 기능은 개발 전 문제를 문서화(왜·어떻게)한 뒤 해결함 이슈를 더 작은 서브태스크로 나누고 완료 기준을 명확히 함 인프라 세팅을 먼저 끝내고 개발함 데일리 스크럼을 매 영업일 작성함

회고에서 나온 내용을 다음 스프린트에 적용하기 위한 후속 Action Item이다.

이전 Action Item

Sprint 1에서 정한 Action Item의 이행 여부를 점검한다.