팀 문화·협업 프로세스

디에듀는 마일스톤 + FDD 기반 병렬 협업을 지향한다. ("애자일을 빙자한 워터폴"에서 진짜 애자일로 복원하는 것이 목표.) 용어는 onboarding/dev-terms.

일하는 방식

• 마일스톤으로 방향, 스프린트로 리듬, FDD로 기능 단위 정의·품질 기준 확보.
• 역할 순차(디자인→FE→BE→QA)가 아니라 한 기능 내 DE/FE/BE/QA 병렬 진행.
• 속도 중심 → 가치·완성도 중심 개발.
• 주 단위 미팅 한계는 비동기 커뮤니케이션으로 보완 (Notion 진행현황 / Slack 로그 / GitHub PR / Jira Time Log).

Jira 운영 규칙

• 구조: 마일스톤(Epic) → 기능(Story) → 역할 Task(DE/FE/BE/QA). Epic 본문에 목표·범위·일정·연관 문서 링크 명시.
• 일정: Jira(상위 마일스톤 일정) + Google Calendar(세부 일정, Notion 임베드) + Notion(공용 허브).
• 소통의 종착점은 Jira — Slack/Figma/Discord 논의도 최종 결정·리소스는 Jira 코멘트/첨부로 박제.
• Workflow v2: Start → In Progress → (Need More Info / Pending) → Request Close → Claim Fix → Close (→ Reopen).

문서 문화 (FDD 중심)

• 큰 기능(로그인/스터디룸/수업노트 등)을 하나의 독립 FDD 페이지로 — 요구사항·예외처리·UI·API·테스트 기준·변경로그를 한곳에.
• 킥오프 시 프로토 수준 작성 → 각 포지션 작업 완료 시 해당 섹션 업데이트 (생성이 아닌 지속 업데이트).
• FDD는 Figma/Swagger/ERD/FE 문서를 대체하지 않고 연결 허브. 각 FDD ↔ Jira Story 1:1.
• 회의·Slack 논의가 기획서·문서 업데이트로 이어지지 않는 단절을 경계 (온보딩·인수인계 비용 직결).

회고 (Keep/Problem/Try 예시)

• Keep: 팀별 discussion, 방향성 함께 고민, FDD 상세 기획 전달.
• Problem: 기능별 담당자·진행상황 파악 어려움, 기획~작업 텀, 문서 흩어짐, Jira 관리 미흡.
• Try: 공통 문서로 담당자/진행/우선순위 가시화, 모각작·모각코 문화, 프론트-백 짧은 실시간 대화.

관련

onboarding/dev-terms · onboarding/team-structure · onboarding/collab-tools · teams/product/roadmap