"다 됐다고 했는데, 왜 끝난 게 아니죠?" 팀의 약속, 'Definition of Done(완료의 정의)'

모호함 제거:
- “개발 완료”라는 모호한 말 대신, “단위 테스트 통과, 코드 리뷰 완료, QA 테스트 통과”와 같이 구체적인 완료 조건을 제시하여 구성원 간의 오해를 막습니다.
품질 내재화:
- QA 테스트 통과뿐만 아니라, 코드 리뷰, 문서 작성 등을 ‘Definition of Done’에 포함시킬 수 있습니다.
- 이를 통해, 개발 과정 자체에 품질 활동을 자연스럽게 녹여낼 수 있습니다. (Shift Left 실천)
예측 가능성 향상:
- ‘DoD’를 충족한 작업만 ‘완료’로 인정하므로, 프로젝트의 진행 상황을 더 정확하게 예측하고 관리할 수 있습니다.

‘DoD’는 팀과 프로젝트의 상황에 맞게 만들어야 합니다.

아래는 일반적인 ‘사용자 스토리’에 대한 ‘Definition of Done’ 예시입니다.

‘Definition of Done’ 체크리스트 예시:
- [Code] 코드가 작성되었는가?
- [Unit Test] 단위 테스트 코드가 작성되었고, 모두 통과했는가? (예: 코드 커버리지 80% 이상)
- [Code Review] 동료 개발자의 코드 리뷰를 받고, 제기된 피드백을 모두 반영했는가?
- [Integration] 코드가 메인 브랜치에 통합(Merge)되었는가?
- [Build] CI 빌드가 성공했는가?
- [QA] QA 환경에 배포되었고, 관련된 모든 테스트 케이스(기능, 회귀)를 통과했는가?
- [Bug] 해당 기능과 관련하여 심각도 높은 버그가 남아있지 않은가?
- [Documentation] 사용자 매뉴얼이나 기술 문서 등 관련 문서가 업데이트되었는가?
- [PO/PM Review] 기획자(PO/PM)가 최종적으로 기능을 확인하고 승인했는가?

QA는 ‘완료의 정의’에 ‘품질’과 관련된 기준을 명확하게 포함시키는 핵심적인 역할을 합니다.

QA가 목소리를 내지 않으면, ‘DoD’에서 테스트 관련 항목이 누락될 수 있습니다.

1. 테스트 관련 기준 제시:
- QA는 다음과 같은 구체적인 품질 기준을 ‘DoD’에 포함하도록 적극적으로 제안해야 합니다.
- “모든 인수 기준(Acceptance Criteria)을 만족하는 테스트 케이스가 통과되어야 한다.”
- “핵심 기능에 대한 자동화된 회귀 테스트가 성공해야 한다.”
- “성능 및 보안 요구사항을 만족해야 한다.”
2. 최종 검증자 (Final Verifier):
- QA는 개발이 완료된 스토리가 팀이 함께 정한 ‘Definition of Done’의 모든 항목을 정말로 충족했는지 최종적으로 검증합니다.
- 그리고 ‘완료’를 승인하여, 해당 스토리를 다음 단계로 넘기는 역할을 합니다.

‘Definition of Done’은 단순히 규칙을 나열한 문서가 아닙니다.

이는 “우리 팀은 이 정도 수준의 품질을 달성하지 않으면, 절대로 완료라고 부르지 않겠습니다”라는 팀 전체의 약속이자 품질에 대한 자부심입니다.

QA가 ‘완료의 정의’를 수립하고 지키는 과정에 적극적으로 참여할 때, 팀의 개발 문화는 한 단계 더 성숙해지고 제품의 품질은 자연스럽게 향상될 것입니다.

“다 됐다고 했는데, 왜 끝난 게 아니죠?” 팀의 약속, ‘Definition of Done(완료의 정의)’