동료검토(Peer Review) 활동

동료검토(Peer Review)는 테스트 이전 작업산출물(Work Products)의 결함을 찾는 활동입니다.

품질관리를 한다는 것을 재작업(Rework)을 줄이고 재사용(Reuse)을 늘리는 것이라고도 합니다. 이 의미는고객에게 인도(Delivery)하는 제품(Product) 결함(Defect)을 고치는 데 들어가는 비용(Cost)을 줄이고, Product를 Component, 모듈을 분할하여 표준화 시킴으로써개발에 들어가는 시간(Effort)을 절약하는 즉, 생산성을 높인다는 의미입니다.

 이 중에서 재작업을 줄인다는 의미가 결함관리가 밀접한 관계가 있습니다.
결함이라는 것은 크게 보면 이관후 결함과 이관전 결함으로 나누어집니다. 

고객에게 인도된 후의 결함은 정말 Critical 하겠죠. 시판되기 전의 소프트웨어 결함은 내부적으로발견해서 제거가 된다면, 납기문제 이외에는 큰 문제가 발생하지는 않을 수 있지만, 시판된 이후의 결함은 고객의 신뢰성을 잃게 되어 향후 매출에 막대한 영향을 줄 수도 있을 겁니다.

그래서 이관 후 결함을 강조하고 있습니다.

그리고 이관전 결함도 크게 보면 테스트 이전 결함 발견활동인 검토와 테스트를 통한 결함 발견 두가지로 나눌 수 있겠습니다.

테스트에서 결함을 찾으면 되는데 굳이 분석/설계 단계에서 시간을 내어서 결함을 찾아야 하냐고 물어보는 분이 많습니다. 하지만, 앞에서 이야기 한 재작업을 줄인다는 의미에서 보면, 테스트에서발견된 결함을 수정(fix)하는데 드는 비용(시간)이 앞단계(분석/설계)에서 발견해서 제거한 비용보다 많게는 100배 이상나올 수 있다는 것입니다.

그래서 테스트의 목적이 오류 발견이라는 목적이라면, 검토의 목적은 조기 결함 발견 및 제거라고 정의를 합니다.

일반적으로 검토 방법 의 종류는 다음과 같습니다.

이중에서 두가지 대표적인검토방법으로써 널리 알려져 있는 것은Inspeciton 과 Walkthrough 입니다.

1. Inspection :

   • 가장 구조적이고 엄격한 형태의 Peer Review임. (Ebenau & Strauss 1994; Fagan 1976; Glib & Graham 1993;Radice 2001)

   • Defect를 발견하는데 Informal Review보다 더 효과적임.(일반적인 검토 방법에 비해 ROI가 12배- SEI사례)

   • 위험성이 높은 프러덕트 등 가능한한 Defect를 Zero화 해야하는 곳에 효과적임.

   • Planning,Overview, Preparation, Meeting, Rework, Follow-up, Causal Analysis
     

2. Walkthrough :

   • 동료그룹에게 내용을 설명하고 의견을 유도하는 informal 한검토 유형임. (Hollcker 1990)

   • Defect를발견하고 내용을 공유하는 것 뿐만 아니라, 조직의 목적이나 표준 및 구현에 관한 합의점에 도달하는 것도활용 목적이 될 수 있음.

   • Producer의아이디어를 검증받거나, 솔루션 대안을 찾거나 아니면 개발 프로세스의 건전한 개선을 촉진하기 위해서도활용될 수 있음.

   • 산출물 작성한 Producer가 주도적인 역할을 수행하며, 기타 참가자의 역할은 정의되어 있지 않음.

   • Inspection의 경우에는 팀(조직)의 품질 목표를 달성하기위해 수행되고 있지만, Walkthrough는 Producer의필요에 의해서 진행되는 유형임.

   • 정의된 절차, 종료 기준,관리용 장표 및 Metrics를 따르지 않는Informal Review임.

   • Walkthrough에 참여한 인원들은 Producer가 형식적이지 않고 올바르게 했는지, Producer의 설명이 명확한지를 판단할 수 없는 단점이 있음
     
     # 어떤 조직의 개발팀에 검토활동을 어떻게 하냐고 인터뷰를 해봤더니,
     "결함을 찾아서 기록한다는 것이 시간이걸리니까, 그냥 간단한 것은 바로 수정한다."
     "100건의 검토, 테스트를 실시해 본들 결함이 1개도 기록되지 않는다. ...... "
     
     * Inspection의 효과를 제대로 발휘하기 위해서는 여러가지 조건이 있습니다
     - 적절 역할 : 동료검토를 할 수 있는 전문적인 지식 보유자, Moderator, Reader는 Producer 겸임 안됨
     - 준비활동 철저 : 개인별 준비결과서 기록 필수
     - CheckList에 의한 결함 발견
     -결함 결과 기록(투입시간, 검토Size, 결함유형, 유입단계 등)
     - Moderator육성(Inspection Champion)
     - 절차 교육 숙지, Inspection 코칭 세션 활용

     ※ Inspection 이 최고의 검토방법이라고 이야기 하지만 제 생각에는 Walkthrough 도 훌륭한 검토 방법입니다. Walkthough를 하더라도 위에 언급한 개념을잘 이해하고 결함을 발견하고 잘 기록한다면, 문제는 없습니다.

     결함을 기록한다는 것은 첫줄에 언급한 것처럼 향후 재사용, 예방 때문입니다.

     유사한 결함을 줄이고, 향후결함을 예방하기 위해 결함 유형, 유입단계등의 데이터를 수집하고 분석함으로써 효과적인 결함관리, 결함을 줄이고, 가장 높은 수준인 결함/장애 예방까지 고려하게 되는 성숙한 조직이 될 수 있습니다.

     목적과 취지를 깊이 새겨두고 검토든 테스트든 우리 모두 발견한 결함에 대해서는 반드시 기록하는 습관을 들입시다. 지금 당장은 힘들겠지만, 다음번작업시 또는 후배들에게는 정말 값어치 있는 자료가 될 수 있을 겁니다. 성의없게 입력한 데이터는 왜곡된분석으로 엉뚱한 프로세스 변경으로 이어질 수 있습니다.

     제대로 된 검토를 위해서 반드시 3자가 검토/테스트를 하도록 역할 정의가 되어야 합니다. 개발자가 본인이 하는 검토는 형식적일수 밖에 없습니다. 왜냐하면 개발자는 태생적으로 본인의 프로그램은 잘 작성되었으며, 작성되었기를 바랍니다. 즉, 정상 작동하는지에초점을 두게 마련입니다.

     
     위에서 정의했지만, 검토/테스트는 정상작동 여부 확인이 아니라, 결함 발견에 초점을 두어야합니다. 그렇기 떄문에 객관적인 3자가 검토 하고 테스트를수행하는 것이 제대로 할 수 있을 겁니다. 물론 기술적이나, 업무를모르는 무조건적인 3자는 아니기 때문에 쉽지는 않겠지요. 조직에서 가장 효과적인검토 방법을 찾기 위해서는 많은 데이터를 모으고 이를 통해 프로세스를 개선하는게 중요합니다.
     
     * 프로세스는 책꽂이에 꽂아놓은 장식품 책이 아닙니다. 지속적으로 개선되고, 최적화되는 프로세스가 살아있는 프로세스 입니다.