[QA] SW검토와 인스펙션

 오늘은 구디역이 아닌 가디역 근처로 출근을 하였습니다. 수강생들을 보아하니 역시 관리자급으로 보이는(사람의 겉모습으로 그 사람을 판단하는 것은 좋지 않습니다만...) 분들이 대부분이셨습니다.

 사전테스트를 풀고, 강의를 진행하셨습니다. 진짜로 수강 중에 사전테스트를 본 것은 처음입니다. 강사님께서는 김영온 강사님으로 SI를 기반으로 발전한 한국의 IT, SW 개발 분야에서 일을 하셨다고 했습니다. 

========================================  1  ========================================

[ 09 : 00 ~ 10 : 14 ] 

강의 사전 평가 문제를 먼저 풀었습니다. 그리고 간단하게 강의 개요를 훑어주셨습니다. 각 방법에 대해 간단하게 의견을 붙여서 설명을 해 주셨습니다. 동료검토와 인스펙션을 비교 해 주셨습니다. 

5시 40분에 마지막 페이지를 넘기는 것을 목표로 강의를 준지 해 오셨다고 했습니다.

소프트웨어 프로젝트 검토를 도자기를 만드는 것에 비교하여 검토를 설명 해 주셨습니다. SW를 제외한 거의 모든 제조업은 제조 공정 중간에도 체크를 해서 제품을 점검합니다. 예로 도자기를 굽는 사람은 자기를 빚을 때 부터 모양을 잘못 잡으면 다시 잡고, 구웠을 때 문제가 있으면 깨버립니다.

하지만 SW는 개발이 다 끝나고 나서야 종이 한장 달랑달랑 들고와서 검토한다고 하셨습니다. (조금 극단적인 비유지만 이해는 갑니다.) 즉, 이 과정을 도자기 제작 과정에 비유하면 도자기 몇백개를 다 만들어 납품할 때 문제 있다고 다 만들어진 도자기를 망치로 깨는 일이라고 하셨습니다.

강의자료를 보고 강의 개요 및 책 추천을 해 주셨습니다. 그 후 강의자료로 강의를 이어가셨습니다.

SW품질 현황이라는 주제로 강의를 해 주셨는데, 충격적인 내용이 프로젝트 재작업 비용이 40~50%이며, 우리나라는 더 할 것이라고 이야기하셨습니다.

우선 검토의 목적을 잘 생각 해 보면 근본원인을 없애는 것 이라고 하셨습니다.

========================================  2  ========================================

[ 10 : 24 ~ 11 : 14 ] 

강의자료 16페이지의 동료검토 효과에 대해서 강의를 계속 하셨습니다. 

한국 SW 업체들에서 살아남기 위해서는 폭탄돌리기를 잘 하라고 하셨습니다. 그 이유는 관리자, 윗사람들이 아는것이 많지만 제대로 하는것은 없고, 뭔가를 배우려고 하지도 않고 가르치려 하면 기분부터 나빠한다는 이야기를 하셨습니다.

프로젝트의 막바지에 바빠지고 하는것은 프로젝트 관리가 잘 안된 것이고, 공학 체계가 없어서 그렇다고 하셨습니다. 

계획! SW를 설계하기 위해서는 알아야 할 것들이 있습니다.

개발하고자 하는 SW는 무엇인가?

SW의 기능, 동작과정, 목적은 무엇인가?

SW개발자의 개발 실력, 능력은 어느정도인가?

...

와 같은 질문의 답을 알아야 하는데 한국은 SI를 하면서도 위와 같은 질문도 하지 않은체 Project를 바로 시작한다고 하셨습니다. 위와 같은 질문의 답은 프로젝트를 시작하면서 바로, 혹은 시작하기 전에 미리 알고있어야 하는 것들입니다. 

한국의 SW업계를 미국과 비교하기에는 지금 너무 격차가 크다는 이야기를 또한 하셨습니다. 

한국의 PM을 일도 모르고 사람도 모르는데 프로젝트를 진행 해 내는 미국에서 보면 기적을 만들어내는 사람일거다 라는 이야기로 현황을 비유해서 이야기 해주셨습니다.

동료검토를 하면 각 업무 담당자 별 장점이 아래와 같습니다.

(강의자료 25~26페이지)

개발자 - 재작업 감소

개발관리자 - 유지보수 감소, 팀웍 증가, 프로젝트 상황판단력 증가

프로젝트관리자 - 이슈 가시성 증가, 일정 관리 용이, 팀원 상호 트레이닝 효과

품질관리자 - 

요구사항 분석가- 빠진 요구사항을 빨리 칮을 수 있음. 위험관리 확인

테스트 엔지니어 - 결함 감소, 테스트케이스 설계가 용이해짐

SW업종만 유독 관리자들이 내부적인것을 잘 모르기 때문에 조직에서 투명한 관리가 안된다고 하셨습니다.

========================================  3  ========================================

[ 11 : 09 ~ 11 : 52 ]

혹시 검토를 하고있는 수강생이 있는지 확인을 시작으로 이번시간 수업을 하셨습니다. 

상식적으로 살아가면서 짬을 채워가는 것의 차이를 알려주셨습니다. 세월이 지나고 보면 책의 내용이나 표준등이 자기와 맞아가면 짬이 잘 차는 것이라고 하셨습니다.

어떤 조직에서의 예를 들어가면서 하나 이야기를 해 주셨습니다. 개발자 개개인은 굉장히 예의있게 검토를 했었는데, 공식석상에서 여러 개발자들이 모이자 욕이 나오면서 공개석상에서의 대화와 검토가 되지 않는 경우를 예를 들며 이런 경우에는 프로젝트가 잘 되지 않았다는 이야기를 해 주셨습니다.

 리뷰를 하면서 기분좋게 들어와 기분좋게 나가는 것이 기본인데 이러한 리뷰를 하는것이 현실적으로 쉽지 않다고 하셨습니다. 또한 성과평가와 검토활동을 연관시켜서는 안된다고 하셨습니다. 

 

 기본적으로 관리도 못하는데 성과평가만 하려는 관리자들에 대한 비판을 하시면서 그러한 현실이 잘못되었음을 알려주셨습니다. 

========================================  4  ========================================

[ 13 : 02 ~ 13 : 55 ]

동료 검토 (Peer Review)

동료검토가 원활하게 진행되기 위해서는 기술적인 실력도 필요하지만 대인관계, 상대방의 기분이 나쁘지 않도록 하는것이 중요하다고 하셨습니다. 특히 우리나라에서는 그러한 문화가 있지않아, 한가지 사례를 들어주셨습니다.

품질 관리자가 지적을 하면서 자기들의 잘못을 지적하자 "입에 개거품 물고 달려든다."고 하실정도로 공격적인 피드백이 돌아왔다고 하셨습니다. 이것은 저 사례 뿐 아니라 주변에서도 많이 겪었던 기억이 났습니다.

일반회사와 Apple을 비교하며 Apple은 더 SW에서 뺄 기능이 없을 때 출시하고, 보통 회사는 더 넣을 기능이 없을 때 출시한다고 하였습니다. 뭔가 너무나 이해가 잘 되는 사례들입니다. 

그리고 리뷰를 하는 태도와 말투로 하나의 사례를 또 이야기 해 주셨는데

  

 어디에 변수 초기화 했는지 모르겠네 vs 너 이 변수 초기화 안했네

위의 두가지 말에 느낌차이, 받아들일 사람에 대한 배려등에 대해 이야기를 해 보았습니다.

NAH증후군에 관한 이야기도 해 주셨습니다.

NAH증후군은 Not Applicable Here 즉, 여기는 적용할 수 없다는 말로, 지금은 바빠서 안된다. 상황이 이래서 안된다는 등의 이야기를 하는 것을 말합니다. 

50페이지에는 11가지 동료검토잘 해 가기 위한 조건입니다.

프로젝트 마지막에 발견된 결함에 대해서 우리나라는 개발자에게 문책이 돌아오지 QA담당자를 잘못했다고 문책을 하는 경우가 거의 없다고 하셨습니다. 또한, 우리나라에서는 마지막 검토 후 문제가 나온것을 해결하면 일 잘한다고 생각하지만, 결함이 거의 없이 원활하게 프로젝트를 마무리 한 경우에는 일 잘한다는 생각을 안한다는 이야기를 해 주셨습니다.

전반적으로 강의를 계속 들으면서 나오는 사례들이 관리자들의 무지와 무관심으로 인한 것이 아닐까 하는 생각을 해 보았습니다. 

또한 계속 수업을 하시는 중에 교육을 받고 돌아가서는 동료검토와 워크스루를 꼭 근무하는 회사에 가서 활성화 하라고 하셨습니다.

========================================  5  ========================================

[ 14 : 05 ~ 14 : 55 ]

강의자료 62페이지부터 강의를 시작하셨습니다~

여러가지 동료 검토에 대해 계속 소개해주셨습니다.

ISO 12207, CMMI, Inspection, Wiegers , Walkthrough, Pair Programming, Peer Deskcheck, Passaround, Ad Hoc review

(각각 방법에대한 설명은 추후 강의자료 첨부)

쭉 들어보니 정말 다양한 방법이 있었습니다. 강사님께서 위의 방법 중 하나를 택하는 것이 아니라 모든방법을 차례로 사용하는 것이 효율적이며 상호 보완적이므로 모든 방법을 사용해야한다고 하셨습니다. 

========================================  6  ========================================

[ 15 : 18 ~ 16 : 15 ]

인스펙션이란? 새로운것이 아니라고 하셨습니다. 

 - 인스펙션 팀 크기(팀원 수)

  상황별, 프로젝트별로 다르지만 3~7명 내외 한 팀으로 구성 (3명 내외가 적합함)

 - 인스펙션 과정 단계

  1) Planning

  2) Overview

  3) Preparation

  4) Meeting

  5) Rework

  6) Follow -up

  7) Causal Analysis

 - 인스펙션의 필수 역할 소개

  1) Inspection Leader

  2) Recorder

  3) Reader

  4) Author

  5) Inspector

인스펙션이라는 것을 예로들어, 회사운영에 있어서도 본질은 지키지 않으면서 결과에 대한 기대만 크다고 현재 회사들이 90년대에 비해서 크게 발전하지 않은 이유를 이야기 해 주셨습니다. 

========================================  7  ========================================

[ 16 : 25 ~ 17 : 02 ]

왠지 마지막 시간일 것 같습니다.

124 page부터 강의를 이어가셨습니다.

인스펙션에 대해 설명하시면서 프로젝트 계획에 대충 만들어 놓았으니까 개발을 하는 그러한 경우를 설명을 하나 해 주셨는데, 이것은 누가봐도 불필요한 과정입니다. 하지만, 사용하지도, 필요도 없는 기능에 대해 이러한 기획실패로 인해 필요없는 작업과 재작업이 발생하게 되었습니다. 이러한 경우는 제가 프로젝트를 진행하는 경우에도 있었고, 정말 이해가 잘 되었습니다. 

========================================  8  ========================================

[ 17 : 07 ~ 17 : 40 ]

간단하게 5분정도 더 쉬고 Inspection에 대해 계속 수업을 하셨습니다.

144 page부터 작업을 하셨습니다. 또한 강의자료가 이번 강의가 처음이라 번역을 하지 못하시고 책 위주로 강의자료 분량상 조어정도만 생략했고 원문인 경우 단어를 바꾸지는 않으셨다고 하셨습니다. 

이 내용은 인스펙션의 미팅, 회의에 관한 내용입니다.

바디랭귀지에 대해 설명을 하시면서 인스펙션을 효과적으로 진행하기 위해서는 스마트폰, PC사용등을 제한하고 해당 회의 진행에 대해 회의에서 더 나은 검토를 하고 결점과 해결책을 찾는것을 해야한다고 하셨습니다. 스마트폰을 보는 것이 새로운 바디랭귀지이며 지루한 회의나 필요하지 않는 회의일 경우에는 강사님께서도 일부러 PC를 들고 간다고 하셨습니다. 저도 마찬가지였네요. 무의식적으로 그렇게 하고있었습니다.

바디랭귀지를 체크하라는 내용이 잠깐 나왔는데 그 이유는 회의의 속도에 영향을 줄 수 있기 때문입니다.

미팅에서 발생할 수 있는 문제가 몇가지 있습니다.

 - 회의시작시간을 늦추고 회의에 늦는 사람

 - 모욕적, 공격적 언어사용

 - 주의산만한 대화 및 지나친 농담

 등.... (page 155)

또한 기술적인 Peer Review의 경우에 개발자가 원하지 않는경우에는 공개하지 않는것을 원칙으로 한다고 하였습니다. 그 이유는 공개를 할 경우에 관리자들이 그것을 평가, 개인의 역량평가에 활용하게 된다는 것을 우려해서 그렇습니다. 그렇게 되면 많은 문제가 발생한다고 하셨습니다. 

강의노트에 적지는 않았지만 여러번 조직의 정상/비정상, 문제여부를 이야기를 하셨습니다. 공학적인 측면과 현실, 현업의 상황의 괴리를 정말 몸소 느낄 수 있었습니다. 또한, Apple과 Google을 비교하며, 이상적인 방식의 회사는 Google이며, 그보다는 공격적 압박적으로 하는 업체는  Apple, 그리고 Amazon은 그 중간쯤일거라고 하셨습니다. 

또한 시가총액 상위 기업은 이상적인 방식의 조직이 대부분이라고 하셨습니다.

보고자가 Data를 모아 보고한 내용으로 불이익을 받으면 그것이 관리자가 받을 마지막 Fact Data분석일 것이라는 명사의 말을 인용하여 평가와 결함 및 점검 보고 내용은 무관해야 한다는 것을 알려주셨습니다.

(수업 중간에 사전...이라고 체크된 사후 Test지를 나눠주고 나가셨습니다... ;;;;; 수업중인데....)

ㅎㅎㅎㅎ

동료검토 프로그래밍의 내재화에 대해 설명을 하던 중 흥미있는 내용이 나왔습니다.

세미나에서 가장 많이 나온 코멘트는 아래의 3개와 같다고 합니다.

 - 저의 관리자가 이 수업을 들어야 합니다.

 - 저희 관리자분 어디계시죠?

 - 저는 제 매니저가 사주지 않는다면 할 수가 없습니다.

강의자료 p.178

공식적/ 비공식적이 중요한게 아니라 검토를 최대한 빨리! 그리고 자주! 해야한다고 하셨습니다.

프로젝트의 마지막에 공식적으로 검토를 하면서 많은 결함이 발견되는 프로젝트는 문제가 많은 프로젝트로 결과도 좋지 않을것이라고 하셨습니다.

정리!

181 page부터 한번 읽어보면 검토, 인스펙션에 대해 본질을 이해하고 해결책을 찾을 수 있을 것이라고 하셨습니다. 외국도 크게 다르지 않게 겪고 있지만 변화의 여부만 차이가 있을 것이라고 하셨습니다.

성공적인 검토를 위한 제안을 몇가지 해 주셨습니다.

1) 할 수 있는것부터 시작하라

2) 동료검토의 목정에 맞는 방법을 선택

3) 교육과 Pilot부터 시작하고 데이터로 효과와 효율을 지속적으로 점검할 것

4) 개인평가를 위한것이 아니라 제품의 품질을 높이는 작업으로 할 것

5) 경쟁이 아닌 조직의 지혜를 모으는 방향으로 할 것