팀마다 '완료'가 의미하는 바에 대한 정의는 다르지만, 스토리가 받아들여지기 전에 이를 갖고 정의된 기준에 부합하는지 확인하는 것이 중요합니다.
팀에서 일반적으로 지정하는 몇 가지 기준은 다음과 같습니다.
잘 정립된 DoD가 없으면, 많은 일들이 반쯤 진행된 상황에서 끝나 진정한 완성이란 없는 일이 일어나기 쉽다.
들여쓰기 수준 및 공백과 같은 것은 중요하지 않은 것처럼 보일 수 있지만 적절한 형식의 코드를 사용하면 가독성과 유지 관리에 많은 도움이 됩니다. 규칙은 논의하고 팀으로 동의한 다음 코드에서 따라야 합니다.
프로젝트 구현의 크기가 커지면 이를 테스트하는 데 필요한 시간도 늘어납니다. 좋은 테스트 범위 없이는 테스트 팀은 확장할 수 없으며 개발자는 결국 버그에 파묻힐 것입니다.
개발자는 요구 사항을 충족하는 프로덕션 코드 전에 실패한 단위 테스트를 작성하는 TDD를 연습해야 합니다. QA는 시스템이 높은 수준에서 예상대로 작동할 수 있도록 자동화된 수락 테스트 세트를 만들어야 합니다.
Jackalope 및 Prosper와 같은 사용자 정의 프레임워크를 사용하여 JCR API를 조롱함으로써 개발자의 생산성을 보장하고 단위 테스트를 작성할 수 있습니다.
각 반복이 끝날 때 비즈니스에 데모를 통해 시스템을 사용할 수 있어야 합니다. 시스템을 데모 준비 상태로 유지하면 팀은 항상 프로덕션 준비의 반복에 놓이게 되며 기술적인 문제를 유지 관리 가능한 수준으로 유지할 수 있습니다.
지속적인 통합 환경을 구현하면 단위 테스트와 통합 테스트를 쉽고 반복적으로 실행할 수 있습니다. 또한 개발 팀에서 배포를 분리하여 팀의 다른 부분이 보다 효율적으로 작업할 수 있도록 하고 보다 안정적이고 예측 가능한 배포를 만듭니다.
단위 테스트를 실행하는 데 시간이 오래 걸리는 경우 개발자는 단위 테스트를 실행하지 않고 가치를 잃게 됩니다. 코드를 빌드하고 배포하는 데 시간이 오래 걸리는 경우 사람들이 이를 수행하는 빈도가 줄어듭니다. 짧은 빌드 시간을 우선 순위로 설정하여 테스트 범위와 CI 인프라에 투자한 시간이 계속해서 팀을 더 생산적으로 만들 수 있도록 합니다.
코드 분석 도구는 유용할 수 있지만 이로 인해 보고서가 개발 팀에서 조치를 취하는 경우에만 유용합니다. 이러한 도구에서 제공하는 분석을 미세 조정하지 않으면 생성되는 권장 사항이 관련성이 없어 가치를 잃게 됩니다.
소년 Scout은 "발견한 것보다 더 잘 내버려두라"라는 규칙을 가지고 있습니다. 개발팀 구성원 모두가 이 규칙을 준수하고 문제가 발생했을 때 무언가를 정리하는 한, 코드는 지속적으로 향상될 것입니다.
YAGNI(또는 You Are Gonna Not Gonna Be Need It) 기능은 현재 필요하지 않지만 향후 필요한 것이 있을 것으로 예상할 때 구현되는 기능입니다. 이상적으로, 우리는 오늘날 작동할 가장 간단한 것을 구현하고 시스템의 아키텍처가 시간이 지남에 따라 요구 사항을 충족하도록 지속적인 리팩터링을 사용해야 합니다. 이를 통해 중요한 사항에 집중하고 코드 오류 및 기능 소동을 방지할 수 있습니다.