완료의 정의 (DoD)는 애자일 스프린트에서 제품 증분(product increment)이 "완료"로 선언되기 전에 충족해야 하는 모든 조건을 명시하는 공유되고 명확한 팀 합의입니다. 엄격한 DoD는 숨겨진 기술 부채(technical debt)가 쌓이는 것을 방지하고, 미완성 작업의 조기 마감을 막으며, 모든 증분이 팀의 품질 기준을 충족하도록 보장합니다.
?
소프트웨어 팀의 완료의 정의에는 일반적으로 어떤 조건이 포함되나요?
SaaS 제품 팀의 포괄적인 DoD는 일반적으로 다음을 포함합니다: 풀 리퀘스트(pull request)를 통해 작성 및 제출된 코드; 최소 한 명 이상의 다른 엔지니어에 의해 동료 검토(peer-reviewed)된 코드; 작성 및 통과된 자동화된 테스트(단위 테스트, 통합 테스트 및 관련 종단 간 시나리오); 테스트 스위트(test suite)에서 회귀 실패 없음; PM 또는 QA에 의해 검증된 인수 기준(acceptance criteria); 성능 벤치마크 확인(중요 경로에 대한 목표 지연 시간 충족); 변경 사항이 인증, 데이터 접근 또는 외부 데이터 입력을 포함하는 경우 완료된 보안 검토; 업데이트된 내부 문서(해당하는 경우 API 문서, 중요한 설계 결정이 내려진 경우 아키텍처 결정 기록); 고객에게 보이는 기능에 영향을 미치는 경우 업데이트되거나 생성된 도움말 센터 문서; 단계적 출시(staged rollout)가 계획된 경우 구성된 기능 플래그(feature flag).
?
완료의 정의는 팀 수준에서 설정되어야 할까요, 아니면 조직 수준에서 설정되어야 할까요?
조직은 모든 팀에 적용되는 협상 불가능한 품질 표준(자동화된 테스트, 민감한 변경에 대한 보안 검토, 문서화)을 설정하는 최소한의 조직 수준 DoD로부터 이점을 얻습니다. 개별 팀은 특정 도메인과 관련된 추가 기준으로 조직 DoD를 확장할 수 있습니다(예: 데이터 팀은 "data migration scripts tested and rolled back successfully in staging"을 추가할 수 있고, 모바일 팀은 "tested on minimum supported OS versions"을 추가할 수 있습니다). Product Ops는 엔지니어링 리더십과 협력하여 조직 수준 DoD를 정의하고, 이를 공식 표준으로 문서화하며, 신규 엔지니어 및 PM을 위한 온보딩 자료에 참조되도록 합니다.
?
완료의 정의는 관료적인 부담이 되지 않으면서 어떻게 강제될 수 있나요?
강제는 수동 체크리스트에 의존하기보다는 자동화되거나 워크플로우에 내장될 때 가장 효과적입니다. 자동화된 강제: 테스트 실패 또는 린팅(linting) 위반 시 병합을 차단하는 CI/CD 파이프라인; 병합 전에 PR 승인을 요구하는 저장소 브랜치 보호 규칙; CI 검사로 취약점을 표시하는 자동화된 보안 스캐닝 도구. 인적 강제: 스프린트 검토(sprint review) 의제에 DoD를 체크리스트로 포함 (스프린트 검토 자체가 게이트입니다 — DoD 기준이 충족되지 않으면 작업은 수락되지 않고 다음 스프린트로 이월됩니다); 보드에서 스토리가 "검토(Review)"에서 "완료(Done)"로 이동하기 전의 간략한 QA 검증 단계. Product Ops는 스프린트 속도(sprint velocity)의 등급 인플레이션을 방지하기 위해 주기적인 DoD 감사(완료된 스토리를 샘플링하고 DoD 기준이 실제로 충족되었는지 확인)를 수행합니다.
지식 챌린지
완료의 정의 (DoD)을(를) 마스터하셨나요? 이제 관련된 5글자 단어를 맞춰보세요!
입력하거나 키보드를 사용하세요