목표

  • 작업 산출물 리뷰 프로세스 활동을 요약할 수 있다(시험 위주로, 중요도 = 0.5)
  • 공식 리뷰의 다양한 역할과 책임을 인식할 수 있다
  • 서로 다른 리뷰 유형의 차이를 설명할 수 있다
  • 작업 산출물에 리뷰 기법을 적용해 결함을 식별할 수 있다
  • 리뷰 성공 요소를 설명할 수 있다(시험 위주로, 중요도 = 0.5)

시험 위주로 설명하자면, 리뷰 유형은 크게 [1.비공식 리뷰], [2.워크쓰루], [3.기술 리뷰], [4.인스펙션] 으로 분류한다.

2,3,4는 공식 리뷰이다. 그 중 공식적인 특징이 가장 강한 것은 인스펙션이다.

 

리뷰 프로세스에는

'계획 -> 리뷰 착수 -> 개별 리뷰 -> 이슈 논의 및 분석 -> 수정 및 보고' 단계로 이루어져 있다.

이런 리뷰 프로세스를 바탕으로 한다는 것은 가장 공식적인 Inspection이 된다.


리뷰 프로세스를 원활히 이해하고자, 한 가지의 상황을 가정한다.

 

테스터와 개발자와 영업직 사원이 각각 한 명씩 있다.

관리자는 이들에게

어떤 세부 가이드가 따로 없이, 리뷰 문서의 p.11~p.20를  7일의 기한동안, 업무시간 중 리뷰활동에 2시간을 할당하여 결함을 알아오라고 한다. (계획)

이들은 각자 잠재적 결함을 5개씩 발견해온다. (리뷰 착수, 개별 리뷰)

그리고 7일째가 되어서 각자의 이슈를 논의한다. 각자가 알아온 이슈 중에서 중복되는 결함도 있고, 실질적인 결함이 아닌 것도 있다. 이를 간추려서 최종적으로 각자 2개의 결함(2+2+2, 총 6개)을 발견한 것이 된다. (이슈 논의 및 분석)

수정이 필요한 결함에 대해 보고를 하고, 리뷰한 작업 산출물에서 발견한 결함을 저자가 수정한다.

보고를 하면서 총 6개의 결함을 6시간동안 발견한 것이므로, '조직의 퍼포먼스는 1시간 당 1개의 결함을 발견할 수 있다' 는 메트릭을 수집할 수 있게 된다. (수정 및 보고)


리뷰에서의 역할과 책임(위의 상황에 대입하여 역할들을 매칭해보는 것이 이해에 도움이 된다)

  1. 저자 : 리뷰 대상 작업 산출물 작성, 결함이 발견되면 수정
  2. 관리자 : 
    • 리뷰 계획 담당, 실행 결정, 인력/예산/시간 할당, 메트릭 수집, 결과가 만족스럽지 않다면 제어 결정
    • 관리자는 리뷰 회의(이슈 논의 및 분석)에 참석하지 않는다
  3. 촉진다 : (가장 중요) 저자와 결함을 발견한 사람과의 충돌은 실무에서도 흔히 일어날 수 있다. 이를 중재하기 때문에 '중재자'라고도 한다.
    • 리뷰 회의 진행 시 효과적인 회의 진행을 보장한다
    • 필요한 경우 다양한 관점들에 대한 중재가 필요하다
    • 많은 경우 리뷰의 성공 여부에 결정적인 역할을 하는 사람
  4. 리뷰 리더 : 전반적으로 리뷰에 대한 책임을 지는 사람. 참여자를 결정하고 언제 어디서 진행할지 결정한다.
  5. 검토자 : 다양한 관점을 대표할 수 있기 때문에 일반적으로 여러 명이다. 
    • 해당 주제에 대한 전문가, 프로젝트 참여자, 작업 산출물에 관심 있는 사람 등이 참여 가능하다
    • 리뷰 대상 작업 산출물의 잠재적 결함을 식별한다
  6. 서기, 기록자 :
    • 회의가 진행되는 동안, 새로운 잠재결함/ 쟁점/ 결정 사항 등을 기록한다
    • 개별 리뷰 활동에서 발견한 잠재 결함을 수집한다

 

크게 4가지 리뷰 유형으로 나눌 수 있고, 비공식 리뷰, 워크 쓰루, 기술 리뷰, 인스펙션에 대해 설명할 수 있어야 한다.

모든 리뷰의 주요 목적은 잠재적 결함 발견이 공통적이다.

 

1. 비공식 리뷰

  • 새로운 아이디어나 해결책 도출, 소소한 문제의 빠른 해결을 목표로 한다.
  • 비공식이므로, 위에서 언급한 프로세스를 기반으로 하지 않는다.
  • 검토자에 따라 성과가 달라질 수 있다.
  • 애자일에서 매우 일반적으로 사용된다.

2. 워크 쓰루

  • 아이디어 교환, 참여자(관심 있는 사람 등) 교육, 합의 도출을 목표로 한다.
  • 필요에 따라, 선택적으로 리뷰 회의 전 개별 준비를 한다. 
  • 리뷰 회의는 일반적으로 작업 산출물의 저자가 주도한다. (원래는 촉진자가 주도하지만, 워크쓰루만 저자가 주도한다)
  • 서기 참여 필수
  • 시나리오, 드라이 런, 시뮬레이션의 형태로 수행할 수 있다. (제일 윗사람한테 보고하기 전의 예행 연습으로 간주할 수 있다)

3. 기술 리뷰(어려운 기술들에 대해서만 리뷰 활동)

  • 합의 도출, 새로운 아이디어 도출을 목표로 한다. -> 이 점에서 워크쓰루와 헷갈릴 수 있지만, 워크쓰루는 누구나 참여할 수 있게 하여 참여자를 교육할 수 있다는 점과 차이가 드러난다. (=기술리뷰는 참여자 교육이 목표가 아님)
  • 다른 리뷰들과 다르게 굉장히 기술적인 것을 리뷰함.
  • '리뷰 대상이 기술적이냐, 기술적이지 않냐'에 따라서 기술리뷰와 인스펙션으로 구분할 수 있다.
  • 검토자는 이미 기술 수준이 띄어난 전문가들만 참여가 가능하다.
  • 리뷰 회의 전 개별 준비가 필요
  • 이상적으로 훈련된 촉진자가 주도한다.(그러나 워크쓰루는 저자가 주도한다)

4. 인스펙션(가장 공식적, 일반적)

  • 규칙 및 체크리스트를 기반으로 공식 문서 산출물을 작성하는 정의된 프로세스를 수행
  • 명확하게 정의된 역할 참여 (낭독자, 검토자, 서기(필수), 촉진자 주도)
  • 리뷰 회의 전 개별 준비 필요 
  • 명시된 시작 및 종료 조건을 사용
  • 잠재적인 결함 로그 및 리뷰 보고서 작성
  • 전체 SW 개발 프로세스를 개선하기 위해 메트릭(측정 지표)을 수집하고 사용