애자일 (Agile)

• 애자일은 하나의 방법론이라기보다는 개발 철학에 가깝습니다.

마일스톤 (Milestone)

• 마일스톤은 여러 기능(Feature)이 모여 하나의 가치(Value)를 완성하는 배포 단위입니다. 사용자에게 어떤 경험을 제공할 것인가를 기준으로 기능들을 묶어내는 단위입니다. 보통 줄여서 MS라고 부릅니다.

FDD (Feature-Driven Development)

• FDD는 이름 그대로 기능(Feature) 중심 개발 방식입니다.

스프린트 (Sprint)

• 스프린트는 애자일에서 사용하는 반복 주기(Timebox) 개념입니다.

기능 (Feature)

디에듀팀은 기능번호(F01, F02…대신 지라 작업 티켓번호를 사용합니다.)

• FDD의 기본 단위 (사용자에게 직접적인 가치를 주는 최소 단위의 기능)
• Ex: F01 로그인, F02 과제 관리, F03 대시보드 개선
• 각 기능은 반드시 인수기준(Acceptance Criteria)과 검증기준(Validation Rule)을 가진다.

인수기준 (Acceptance Criteria)

• 기능이 완료(Close)로 간주되기 위한 명확한 조건.
• 주관적 감이 아니라 이 기준을 충족하면 완성이라고 판단 가능한 근거.
• Ex: 학생이 과제를 제출하면 강사가 즉시 확인 가능해야 한다.

검증(Validation)

• 기능이 설계 의도대로 작동하는지를 실제 환경에서 확인하는 단계.
• QA, 시연, 사용자 테스트 등이 포함된다.
• 우리 팀에서는 Claim Fix(Validate) 후 Close가 공식 완료 프로세스다.

기술 부채 (Technical Debt)

• 빠른 개발이나 임시 대응으로 인해 쌓인 품질 저하 요소.
• 초기에는 문제 없지만, 시간이 지날수록 생산성과 안정성을 떨어뜨림.

라이트 FDD (Light FDD)

• 전통적인 FDD를 사이드프로젝트 현실에 맞게 단순화한 형태.
• 고정된 스프린트 대신 기능 완성 단위로 리듬을 관리한다.
• 문서, 마일스톤, 배포 단위를 최소화하고, 실행 중심으로 운영한다.

마일스톤 킥오프 (Milestone Kick-off)

• 새 마일스톤 시작 시 진행되는 기능·목표 공유 회의.
• 이번 배포에서 사용자에게 어떤 경험을 제공할 것인가?를 팀이 함께 정의한다.

회고 (Retrospective)

• 마일스톤 종료 후 잘한 점 / 개선할 점 / 다음 목표를 정리하는 단계.
• 단순 리뷰가 아니라 프로세스 개선의 핵심 루프이다.