일본에서의 편지 #1

    일본에서 거의 모든 프로젝트는, 철저한 폭포수 방식입니다.

    여기에서 '철저한'이라는 것은 융통성이 조금도 용납되지 않는다는 의미입니다.

    방법론에 이 산출물을 작성하라고 되어 있으면, 그 산출물을 표준 그대로 작성합니다.

    하지만, 근본적으로 우리 프로젝트와 커다란 차이가 있죠. 충분한 기간과 충분한 인력을 줍니다. ^^;

   

    중간에 변경되는 요구사항에 대해서는 어떻게 할 것이냐? 라는 질문 자체에 대해

    이들은 이렇게 말합니다.

  

    "설계 산출물을 고객에게 검토받고, 이것을 그대로 개발기능으로 만든다. 하지만 이 내용이 변경되어야 할 경우

    우리는 추가로 금액을 받는다."

  

    참으로 부러운 IT 시장 문화입니다. 이런 상황이라면, 엔지니어의 입장에서는 폭포수 방법론을 사용해도

    전혀 문제가 없는 것처럼 보입니다. 요구사항이 변경되면, 추가로 금액을 받으니까요

    위와 같은 상황 때문에, 이곳 프로젝트에서 애자일로 접근하는 하루하루가 모험입니다.

    왜냐하면, 2년 정도 기간을 두고 수행하던 융통성을 허용하지 않는 프로젝트 방식을

    이번 단납기 프로젝트(9개월)에서도 일본 고객은 기대하기 때문입니다.

 

    산출물에 대해 융통성을 요구하면, 바로 품질을 문제 삼습니다.

    도대체 분석 산출물, 설계 산출물 없이 어떻게 개발이 가능한지 도저히 이해하지 못합니다.

   

    한국의 상황을 조금 이야기 해 본다면,

    우리는 한 개의 도메인에서 여러해 경험한 엔지니어를 '업종 전문가' 라고 부릅니다.

    이 '업종 전문가'는 ERD, 시스템 구성, 네비게이션, 화면 등등을 머릿속에 넣고 있죠.

    이들에게는 사실 아주 잘 정의된 화면 정의서가 필요 없습니다. 왜냐하면,

    대부분의 표준 및 화면 구성은 알고 있고, 그 화면 정의서를 상세히 만드는 시간에, 빨리 제품을 만들어 고객에게 보여주고, 그것을 고치는 것이

    고객 만족 및 비용소모 양쪽에서 다 좋기 때문입니다.   

    위와 같은 커다란 Gap이 양사의 협동에 어려움들을 주고 있습니다.

    이하는 단적인 예입니다.

    지지난주 금요일부터, 이번 프로젝트의 전체 Scrum들에서 본격적인 Sprint Review 가 시작되었습니다.

    Sprint Review란 Sprint 동안 개발한 내용을 Product Owner에게 시연하는 활동입니다.

    책 "Scrum and XP from the Trenches(by 헨릭 크니버그)" 에서는 Sprint Review에 대해 다음과 같이 이야기 합니다.

    - Sprint 데모 체크 리스트

       (1) 스프린트 목표를 정확하게 제시하라

       (2) 데모 준비에 너무 많은 시간을 쓰지 말라

       (3) 빠른 속도를 유지하라

       (4) 비지니스가 중심이 되도록 데모수준을 유지하라

       (5) 가능하다면 참석자들이 직접 제품을 사용해 보도록 하라

       (6) 소소한 버그 수정 내역이나 사소한 기능들을 데모하지는 말라.

    지난 4개의 Agile 로 진행했던 프로젝트에서는 위와 같은 내용들이 특별히 와 닿지 않았었습니다.

    왜냐하면 데모를 했을 때, 그 Sprint Review의 결과물, 그 절차 자체에 대해 문제삼는 고객은 현재까지 보지 못했기 때문입니다.

    하지만, 일본 고객들이 달랐습니다.

       (1) Sprint Review는 제품을 납품하기 직전 상태인 것이냐? 그렇다면, 데모만 하면 도대체 뭐가 검증이 되느냐?

       (2) Sprint Review 결과서에, 결함/변경/추가 내용만 작성하기로 되어 있는데, 그렇다면, 실제 시연한 다른 기능들을 Product Owner 가 확인했다는 근거가 없지 않느냐?

       (3) 빨리 시연을 하라는데, 화면 정의서를 보고 한 가지 한 가지씩 검증하는데, 과연 빨리 할 수 있는것이냐?

       (4) 시연을 할 때, 기능을 조작하는 흐름은 여러가지가 있다. Sprint Review에 이것을 하나하나 준비하고 검증하려면, 매우 많은 시간이 소요될 것이다.

  

    한국에서 공공 프로젝트를 할 때는 위와 같은 문제가 없었습니다. 왜냐하면, 마지막에 검수하는 절차가 따로 있기때문에 Sprint Review는 완료를 위해 거쳐가는 과정이라는 인식을 하게 됩니다.

    그래서 저는 이것을 품질 활동중에 한 개 라는 식으로 접근을 하게 되었습니다.

    프로젝트에서 수행하는 테스트 관련 전체 품질 활동을 정의하고, 현재 Sprint Review는 어떠한 단계에서 수행하는 Activity인지를 정의하였습니다.

     [표 프로젝트에서 수행하는 품질 활동]

 

    위의 내용에서 스프린트 리뷰는 설계된 내용과 실제 기능으로 구현된 내용간 Validation을 체크하는 활동이고,

    다른 질문에 대한 내용은 QA 테스트 -> 결합 테스트 ->  인수 테스트(일본에서는 수입테스트)를 통해 검증합니다. 라는 이야기를 했습니다.

    그리고 Sprint Review에 대한 명확한 룰을 만들었습니다. 

    " PO에게 검토된 화면 정의서와 기능이 함께 완료되지 않으면, Sprint Review 대상이 될 수 없다 "

    이는 Sprint #2를 수행해보니, 일부 예상되었던 문제점이 발생했습니다.

    한국 인력들 중 일부가 화면정의서를 개략적으로만 작성하고, PO에게 검토 받고, 개발기능을 완료하여,

    실제 Sprint Review시 화면 정의서가 미완료 된 상태로 고객에게 시연을 실시했습니다.

    이는 일본고객들의 가지고 있는 생각 즉, 애자일 프로세스에서든, 폭포수에서든, 설계 다음에 개발이라는 룰을 어기게 되는 것이고 

    우리가 정의한 프로세스를 우리가 지키지 않는 꼴이 되는 것이었습니다.

    위와 같은 룰을 공지하여, 일본 고객들의 눈높이에 조금 더 다가가도록 했습니다.

  

    - 계속 -