
완료의 정의 템플릿
안심하고 배포해 모호함을 제거하세요. 완료의 정의 템플릿을 사용해 공통 품질 기준을 설정하고, 모든 기능이 사용자에게 전달되기 전에 진정으로 '완료'되었는지 확인하세요.
4 팀의 템플릿
- 127 좋아요1.2천 사용

- 83 좋아요676 사용
- 37 좋아요321 사용
- 4 좋아요40 사용
Definition of Done(DoD) 템플릿이란?
Definition of Done(DoD) 템플릿은 사용자 스토리나 작업이 "완료"로 간주되기 전에 충족해야 하는 기술적·기능적 기준을 포괄적으로 정리한 체크리스트입니다. "Acceptance Criteria"(각 스토리마다 고유한)와 달리 DoD는 모든 작업에 적용되는 전사적 표준입니다. 테스트, 문서화, 규정 준수를 속도를 이유로 생략하지 않도록 해 "기술 부채"를 방지합니다.
품질 점검: 출시 가능 기준을 적용하는 3가지 방법
DoD는 팀의 규율에 따라 효과가 달라집니다. 템플릿을 확정하기 전에 다음 세 가지 전문가용 "건강 점검"을 적용하세요:
1. "완료되지 않은 작업" 점검
점검: 스토리를 “완료”로 이동시키면서 문서화나 통합 테스트는 “다음 스프린트”로 미루고 있나요? 해결책:미뤄진 품질을 점검하세요. 전문적인 DoD에는 회귀 테스트와 문서 업데이트가 포함되어야 합니다. 시스템 전체에 대해 문서화되고 테스트되지 않았다면 “완료”가 아니라 단지 “개발됨”에 불과합니다. 템플릿에는 “새로운 기술 부채 없음”을 요구사항으로 명시해야 합니다.
2. “자동화된 진실” 테스트
감사: DoD가 "사람의 약속"(예: "내가 코드를 확인했다")에 의존하고 있나요? 해결책:이진 검증. 가능한 한 수동 검사를 자동화된 검사로 대체하세요. "코드가 검토되었다" 대신 "동료 2명이 승인한 Pull Request."를 사용하세요. "단위 테스트를 통과했다" 대신 "단위 테스트 커버리지 > 80%."를 사용하세요. 이렇게 하면 주관성이 사라지고 "완료" 상태가 측정 가능하며 논쟁의 여지가 없게 됩니다.
3. "글로벌 vs. 로컬" 충돌
검증: DoD가 너무 길어 팀이 스프린트 목표를 맞추기 위해 그 절반을 무시하나요? 해결책:현실을 검증하세요. "최소 실행 가능 DoD"부터 시작해 팀이 성숙해질수록 확장하세요. 팀이 현실적으로 매 스프린트마다 전체 보안 감사를 수행할 수 없다면, 이를 스토리 수준 DoD에 포함하지 마세요. 대신 "출시 정의"로 옮기세요. 이렇게 하면 일일 DoD가 실현 가능하고 지켜집니다.
전략적 프레임워크: '완료'의 세 수준
전문 조직에서는 완료 단계를 관리하기 위해 보통 세 가지 별도 템플릿을 사용합니다:
레벨 1: 사용자 스토리 DoD (스프린트 수준)
중점: 코드 품질, 동료 검토, 특정 수용 기준 충족.
예: "단위 테스트 통과", "PO 승인", "기능 테스트 통과."
레벨 2: 스프린트/기능 DoD (통합 수준)
중점: 기능이 앱의 다른 부분과 상호작용하는 방식.
예: "회귀 버그 없음", "성능 지표 안정적", "스테이징 환경 업데이트됨."
레벨 3: 릴리스 DoD (시장 수준)
중점: 법적, 마케팅 및 보안 규정 준수.
예: "보안 침투 테스트 통과", "번역 완료", "사용자 설명서 업데이트 완료."
완료 정의 템플릿의 핵심 구성 요소
고성능 DoD에는 다음 다섯 가지 핵심 항목이 필요합니다:
개발 표준: 코드는 주석이 달려 있고 리팩터링되어 메인 브랜치에 병합되어야 합니다.
테스트 및 품질: 단위 테스트, 통합 테스트, 수동 스모크 테스트가 완료되어 통과되어야 합니다.
환경 및 DevOps: 코드는 스테이징 환경에 배포되고 빌드 파이프라인을 통과해야 합니다.
검토 및 승인: 동료 검토가 완료되고 제품 책임자(PO)가 기능을 승인해야 합니다.
비기능 요구사항: 기능이 특정 성능, 접근성 및 보안 기준을 충족해야 합니다.


