publish: true
스프린트 히스토리
스프린트 구조
2주 단위 사이클로 운영. 사이드 프로젝트지만 실제 스타트업 방식으로 진행.
| 단계 | 기간 | 상세 내용 |
|---|---|---|
| 기획 | 2일 | 전체 목표 공유, 필요한 기능·수정 사항 기획 |
| 개발 | 9일 | 정해진 기능·이슈 개발, 병목·장애 요인 조율 |
| QA | 2일 | 기능 테스트, 버그 수정, 사용자 흐름 점검 (Google Sheet 활용) |
| 회고 | 1일 | KPT 회고 + 구현 기능 시연 |
회고 방식
KPT (Keep / Problem / Try) — 스프린트 마지막 날 전원 참여.
| 항목 | 내용 |
|---|---|
| Keep | 이번 스프린트에서 잘 작동했던 점, 계속 유지하고 싶은 방식 |
| Problem | 어려웠던 점, 예상보다 오래 걸리거나 비효율적이었던 부분 |
| Try | 다음 스프린트에서 개선하거나 새롭게 시도할 아이디어 |
- 회고 결과는 Notion에 기록하여 히스토리로 보관
- 반복적 문제·병목은 팀 차원 해결 방안 논의 후 프로세스 개선
- 시연: 개발된 기능을 화면 공유 또는 APK 설치로 직접 시연, QA·피드백 수행
이슈 관리 방식
- GitHub 이슈 생성 → n8n으로 Notion 이슈 트래커 자동 동기화
- 이슈 속성: 우선순위(Priority), 예상 소요 시간(Estimate), 담당자
- 데일리 스크럼: 매일 오전 11시 n8n이 진행 중 이슈 목록 + 진행률 Discord 전송 → 어제 한 일/오늘 할 일/현재 문제 공유
스프린트 이슈 트래커 구조
Notion “스프린트 이슈 트래커” 페이지에는 3개의 이슈 DB + KPT 리뷰 DB로 구성됨:
| 섹션 | 설명 |
|---|---|
| Plan Issue | 기획 이슈 — 현재 스프린트 기간에 다음 스프린트 내용을 미리 기획하는 것이 원칙 |
| Development Issue | 개발 이슈 — 현재 스프린트 내에 이슈를 마무리하는 것이 원칙 |
| Sprint Plan | 한 스프린트 내에 개발 가능한 범위로 이슈를 생성하고 계획 |
| KPT Review | 스프린트 회고 — Keep/Problem/Try 기록 + Review Gallery(대표 이미지) |
스프린트 목록
| 스프린트 | 기간 | 주요 내용 | Keep | Problem | Try |
|---|---|---|---|---|---|
| MVP 준비 | ~2026-04 | 초기 앱 구축 및 MVP 런칭 | ⚠️ 미확인 | ⚠️ 미확인 | ⚠️ 미확인 |
| (이후 스프린트) | 미팅 후 INGEST로 추가 |