문서 리뷰는 요구사항을 정리하거나 설계하는 과정에서, 개발하고자 하는 시스템의 잠재적인 문제를 미리 발견하는 데 목적이 있다. 리뷰 단계에서 문제를 발견하면 실제 구현이나 테스트 과정에서 문제를 발견하는 것보다 훨씬 쉽게 문제를 해결할 수 있으며, 이는 곧 비용의 문제로 직결된다. 결국, 문제를 미리 발견하여 비용을 절감하는 것이 리뷰를 시행하는 가장 큰 목적이다.
_6

그렇다면 어떤 문제를 검출해야 비용 효과로 이어질까? 예를 들어, 어느 워터폴(Waterfall)형 개발 프로젝트의 설계문서 리뷰회의에서 애플리케이션 간 리소스 경합(Race Condition)에 관한 문제를 검출했다고 해보자. 설계문서의 수정과 확인에는 1인시의 공수가 들었다. 만약, 리뷰에서 이 문제를 놓쳐서 통합 테스트에서 발견했다면, 얼마만큼의 수정 공수가 필요하게 될까?
_8

문제 지적은 문제 검출만큼 중요하다. 애써 문제를 발견해도 리뷰어의 지적 방법이 올바르지 않다면 문서 작성자가 적절히 수정할 수 없거나 험악한 분위기가 되기 때문이다. 문제 지적 방법은 커뮤니케이션 기술이다. 이를 습득하는 일도 리뷰 효과를 높이는 데 빼놓을 수 없다.
_11

여럿의 리뷰어가 순서와 기준 없이 제각각 문서를 검토하는 것은 큰 효과가 없다. 성과물에 문제가 없는가를 눈으로 확인하는 작업은 리뷰의 일부에 지나지 않는다. “이번 프로젝트에서는 어떤 문제를 중점적으로 검출할 것인가?”를 생각하는 것부터 검출한 문제의 수정을 확인하는 데까지가 리뷰이다. 그러한 순서를 밟아 팀으로 공동 작업을 해야 비로소 중요한 문제를 빠짐없이 발견할 수 있다.
_41

프로젝트가 완료되었을 때, 프로젝트 다시보기를 진행하는 현장이 늘어나고 있다. 리더와 주요 리뷰어가 리뷰 다시보기도 진행한다. 다시보기의 주요 목적은 향후 유사한 프로젝트를 위해 리뷰 방법을 개선하는 것이다. 체크할 부분과 판단방법 등의 문제 검출방법을 표시한 시나리오를 바탕으로 개선한다. 또한, 문제 발생을 방지하는 것도 목적에 포함된다.
_126

애자일 개발에서는 일반적으로 문서 작성보다 동작하는 프로그램의 개발에 주력한다. 그렇다고 반드시 리뷰 대상이 적은 것을 의미하지는 않는다. 원래 문서에 적혀 있는 내용은 소스코드나 동작하는 프로그램, 팀 멤버 간의 의사소통으로 공유된다. 따라서 리뷰의 시나리오를 생각할 때는 문서 외에도 무엇을 확인해야 하는지 검토한다.
_140