피드로 돌아가기
Dev.toBackend
원문 읽기
Task 중심 설계에서 User Story 기반 Feature 정의로의 전환을 통한 Definition of Done 확립
Writing Features Not Tasks
AI 요약
Context
단순 구현 중심의 Task 단위 티켓팅으로 인한 주니어 개발자의 혼선 및 모호한 작업 범위 발생. 단순 DB 컬럼 추가와 같은 구현체 위주 서술로 인해 실제 사용자 가치 전달 여부를 검증할 수 없는 구조적 한계 노출.
Technical Solution
- 구현 상세(Implementation Details)를 배제하고 사용자 관점의 행동 중심인 User Story 포맷 도입
- Actor, Action, Goal의 3단계 구조를 통한 기능의 존재 이유와 목적성 명시
- 테스트 가능한 구체적 조건인 Acceptance Criteria를 정의하여 주관적 판단을 배제한 Definition of Done 구축
- Actor별 스토리 그룹화를 통한 시스템 전체 Surface Area의 구조적 가시화
- 기능 상태(State)에 따른 제어권 및 접근 권한(Read-only, Visibility)을 Acceptance Criteria에 명시하여 엣지 케이스 사전 방지
실천 포인트
- 티켓 작성 시 '무엇을(What)' 구축하는지가 아닌 '왜(Why)' 필요한지에 집중하고 있는가? - Acceptance Criteria가 제3의 엔지니어가 읽어도 동일한 결과물을 도출할 만큼 구체적인가? - 구현 방법(예: DB Query)이 아닌 사용자 경험(예: Status 확인) 관점으로 서술되었는가? - Actor별로 권한과 상태 변화에 따른 제약 사항이 명확히 정의되었는가?