-
회의의 참가자가 자신만의 검토를 준비한 경우에도 회의 형식에 따라 검토를 수행하십시오.
-
검토할 때까지 많은 수의 결함을 숨겨진 상태로 두지 않으려면 프로세스 타스크 중에 계속 품질을 모니터하십시오. Rational Unified Process(RUP)의 각 타스크에서 아래 나열된 체크리스트를
참조하여 이 사항을 강조합니다. 일상 작업 또는 비정규 검토 회의에서 사용하십시오.
1990 표준 용어집에서 IEEE는 세 가지 종류의 검토를 정의했습니다.
-
검토
-
설명 및 승인을 위해 중간 산출물 또는 중간 산출물 세트를 사용자, 고객 또는 기타 이해 관계자에게 제시하는 정규 회의
-
검수
-
오류, 개발 표준 위반 및 기타 문제점을 발견하기 위해 작성자 이외의 개인 또는 그룹이 중간 산출물을 자세히 점검하는 정규 평가 기법
-
둘러보기
-
개발자가 자신이 작성한 중간 산출물의 세그먼트를 통해 구성원이 한 명 이상인 개발 팀을 주도하는 검토 프로세스. 이 동안 다른 구성원은 질문을 하고 기법, 스타일, 가능한 오류, 개발 표준 위반 및
기타 문제점에 대한 설명을 작성합니다.
팀에서 구현한 경우 검토는 사람들에게 다른 그룹의 디자인 및 코드를 발견할 기회를 제공하고 공통 소스 코드 발견 가능성, 재사용 기회 및 일반화 기회를 늘리기도 합니다. 또한 검토는 다양한 그룹에서 아키텍처
스타일을 조정하는 방법을 제공합니다.
RUP에서 검토는 품질을 보증하는 보조 파트이지만, 중요한 역할을 수행합니다. RUP에서 품질에 가장 많이 기여하는 요소는 피어 검수 섹션의 [ROY98]에 잘 설명되어
있습니다. 그러나 이 책에서는 전문적인 개발을 통해 검토의 중요한 추가 효과를 식별합니다. 신입에게는 전문가의 작업을 볼 기회가 제공되고 선임자가 신입의 작업을 검토합니다.
검토의 초점 및 범위를 판별하고 모든 참가자가 자신의 역할 및 검토의 목적을 이해하도록 검토를 계획합니다.
검토에 앞서, 물어 볼 질문을 판별하여 검토 범위를 정의합니다. 이때 평가할 내용 및 그 이유를 정의합니다. 물어 볼 수 있는 질문 유형에서 검토할 중간 산출물의 체크리스트를 참조합니다. 정확한 질문은 프로젝트의
단계에 따라 다릅니다. 검토 초반에서는 더 넓은 범위의 아키텍처 문제를 다루고 검토 후반에서는 더 구체적인 내용을 다룹니다.
검토 범위를 판별하면 검토 참가자, 의사 일정, 검토를 수행하는 데 필요한 정보를 정의하십시오. 참가자를 선택할 때 소프트웨어 아키텍처 전문 지식 및 도메인 전문 지식 사이에서 밸런스를 조절하십시오. 검토를 조정할
평가 리더를 명확히 지정하십시오. 필요한 경우 도메인 또는 기술 전문 지식을 제공하도록 조직의 기타 파트 또는 기타 팀을 포함하십시오.
검토자 수는 약 7명이어야 합니다. 적절히 선택하면 아키텍처에서 충분히 문제점을 식별할 수 있습니다. 실제로 검토자가 많으면 회의가 길어져 참가가 더 어려워지고 부수적인 문제와 논의를 검토에 끼워넣어 검토의 품질을
떨어뜨립니다. 검토자가 4명 미만이면 의견의 다양성이 감소하기 때문에 검토 시 통찰력을 발휘할 수 없다는 위험성이 있습니다.
검토자는 검토할 영역에 대해 경험이 있어야 합니다. 유스 케이스의 경우 검토자는 문제점 도메인에 대한 이해가 있어야 하며 소프트웨어 아키텍처의 경우 소프트웨어 디자인 기법에 대한 지식도 필요합니다. 서투른 검토자는
참가를 통해 아키텍처에 대해 무엇인가를 학습할 수는 있지만 검토에 기여하는 바는 거의 없으며 존재 자체로도 주의를 산만하게 만들 수 있습니다. 그룹 크기를 작게 유지하십시오. 3 - 7명이 적합합니다. 검토자 수가
적으면 검토 품질이 저하되고 검토자 수가 많으면 품질 결과를 달성하는 데 핵심인 대화식 논의를 할 수 없습니다.
자료에 적합한 검토자를 선택하십시오.
-
제시된 자료를 이해할 배경을 가진 사람
-
검토할 제품 또는 중간 산출물의 품질에 적극적으로 관여하는 사람
검토에 앞서 검토할 중간 산출물 및 배경 자료를 수집하고 검토 참가자에게 분배해야 합니다. 검토자가 자료를 검토하고 문제를 수집할 수 있도록 검토 회의 전에 이 작업을 충분히 완료해야 합니다. 미리 검토 자료를
충분히 분배하고 검토자에게 검토를 준비할 시간을 주면 검토 결과 품질이 개선됩니다. 또한 검토 준비를 통해 검토의 효율성 및 효과가 개선됩니다.
검토자는 문서, 양식화된 질문 및 논의할 식별된 문제를 검토 전에 조사해야 합니다. 검토자의 일반적인 워크로드를 감안하면 검토를 준비하는 데 필요한 최소 시간은 보통 몇 일이면 됩니다.
성공적인 검토 수행을 위해서는 다음 핵심 사항이 필요합니다.
아래에서는 각각을 자세히 논의합니다.
일반적으로 검토 프로세스는 다음과 같은 반복적인 주기를 따릅니다.
-
검토자가 문제를 제기함
-
문제를 논의하고 잠재적으로 확인함
-
결함을 식별함(해결해야 하는 사항으로 식별함)
-
더 이상의 문제가 식별되지 않을 때까지 계속 진행
검토가 효과적으로 수행되려면 모든 사람이 검토의 목적이 검토한 중간 산출물의 품질을 향상시키는 것이라는 점을 이해해야 합니다. 중간 산출물을 날카로운 시각으로 검토하여 문제점을 찾아야 합니다. 이러한 방법이 어려울
수도 있습니다. 따라서 모든 검토자는 식별한 문제에 초점을 맞춰야 한다는 점을 명심해야 합니다. (우리 모두 타고난 문제 해결사들이지만 검토자로서는 예외로 두어야 합니다.)
우리 모두 우리의 작업에 대해 강한 소유권을 가지고 있습니다. 그래서 건설적인 비판인 경우에도 종종 수용하기 어렵습니다. 결과적으로 우리는 검토의 목적, 즉 더 나은 작업 수행에 초점을 맞추도록 더 열심히 노력해야
합니다.
효과적인 검토를 수행하는 경우 모든 사람이 맡은 역할이 있습니다. 구체적으로 말하면 수행해야 하는 특정 역할이 있으며, 검토자는 이 역할을 쉽게 바꿀 수 없습니다. 검토와 관련된 기본 역할은 다음과 같습니다.
중개자는 검토자가 의사 일정을 준수하고 주제에 초점을 맞추도록 합니다. 중개자는 부수적인 논의를 검토에서 제외하고 모든 검토자가 동일한 수준으로 참가하도록 보장합니다.
기록자는 종종 간과되기도 하지만 검토팀에서의 핵심 부분에 해당합니다. 논의한 내용을 기록하고 수행할 조치를 문서화하는 작업은 정규 타스크입니다. 검토자 중 한 명에게 이 타스크를 지정하면 이 사람은 논의에서
제외됩니다. 결정된 내용을 문서화하지 못하면 문제를 나중으로까지 끌고 갈 수 있습니다. 기록자를 지정하고 기록자 역시 수행해야 하는 유일한 역할임을 확실히 하십시오.
발표자는 검토하는 중간 산출물의 작성자입니다. 발표자는 중간 산출물 및 이 중간 산출물을 이해하는 데 필요한 배경 정보를 설명합니다(중간 산출물이 자기 설명적이 아니어도 어느 정도의 작업이 필요할 수 있음).
검토는 '실험'이 아닙니다. 발표자가 아닌 중간 산출물에 초점을 맞춰야 합니다. 중개자의 역할은 참가자(발표자 포함)가 이 사항을 염두에 두도록 보장하는 것입니다. 발표자는 논의을 시작하고 질문에 대답하며 설명을
제공합니다.
검토자는 문제를 제기합니다. 이 문제에 초점을 맞추고 이 문제의 해결책과 같은 부수적인 논의로 벗어나지 않아야 합니다. 방법이 아닌 결과에 초점을 맞추십시오.
위에서 논의한 바와 같이, 중개자는 검토 시 초점을 유지하는 데 중요한 역할을 합니다. 중개자는 검토가 본 경로를 일탈하지 않도록 초점을 맞춰야 합니다. 중개자는 검토자의 책임을 지지 않습니다. 중개자의 역할은
논의를 유도하고 균등한 참가를 보장하며 경합을 완화시키는 것입니다. 이 작업은 정규 타스크입니다. 효과적으로 중개하지 못하면 검토가 원래 의도된 결론을 벗어나게 되고 목적을 달성하지 못하게 됩니다.
간략하고 잘 식별된 목표에 초점을 맞춘 검토가 가장 효과적입니다. 장기간 초점을 유지하기가 어렵고 검토자가 다른 작업도 해야 하기 때문에 2시간을 넘지 않도록 검토를 제한하십시오. 검토가 길어지는 경우 여러 번 더
작고 초점을 맞춘 검토로 나누십시오. 검토자가 초점을 유지할 수 있으면 결과는 더욱 개선됩니다.
이때 핵심은 잘 식별된 의사 일정과 명확히 표현된 목적입니다. 이 내용은 검토 자료를 분배할 때 커뮤니케이션해야 합니다. 중개자는 검토 회의를 시작할 때 이 내용을 강조해야 합니다. 그 다음 중개자는 회의 내내 이
목적을 계속(때때로 강력하게) 강조해야 합니다.
검토 회의에서 의도된 결과를 달성하지 못하는 주된 이유 중 한 가지는 문제점의 해결책에 대한 논의로 변질되는 경향이 있기 때문입니다. 일반적으로 문제점을 수정하려면 조사와 심사 숙고가 필요합니다. 검토 형식은
이러한 논의에 효과적인 방법이 아닙니다. 문제를 식별하면 해결해야 하는 결함이 있는지 판별한 후 누군가에게 조사 및 해결을 배정해야 합니다. 검토 회의에서는 식별에만 초점을 맞춰야 합니다.
그룹에서 문제에 대한 추가 논의가 필요한 경우 별도의 회의를 가져 해당 주제에 초점을 맞추십시오. 보통 이 회의에는 어느 정도의 조사 및 준비가 필요하고 올바른 스킬을 가진 사람이 개입해야 합니다. 검토는 다른
문제를 식별하는 데 초점을 맞춰야 합니다. 중개자는 종종 상당한 의지를 발휘하여 검토 회의에서 이 문제에 초점을 맞추도록 합니다.
검토는 해당 결과가 나오지 않는 경우 거의 소용이 없습니다. 검토 결론은 다음과 같습니다.
-
문제점 목록의 우선순위를 지정합니다.
-
문제점 및 해당 해결책을 추적하도록 결함을 작성합니다.
-
추가 조사가 필요한 경우 작은 팀을 지정하여 문제점을 조사하십시오(단, 해결하지는 않음).
-
현재 반복으로 해결할 수 있는 문제점인 경우 문제점을 수정하도록 사람 또는 팀을 지정하십시오.
-
해결되지 않은 문제점 목록을 향후 반복 계획 노력에 제공하십시오.
[MCO97]도 참조하십시오.
|