백곰술사의 IT Insight

안녕하세요.

반복적 개발 방법론으로 프로젝트를 수행하며

이 방법론이 현장에서 어떻게하면 잘 활용될 수 있는지 생각해 보았습니다.

저는 금융사에 재직 중이며 금융사 시스템은 결합도가 굉장히 강합니다.

따라서 서브시스템의 결합방식인 증분형은 실질적으로 불가능하기에 프로젝트에서 사용하지 않습니다.

보통은 진화형 반복적 개발 방법론을 사용합니다.

진화형 반복적 개발 방법론은 보통 고객의 요구사항이 불명확할 때 사용하며

운영계에 단계적으로 배포되며 고객의 요구사항을 반복적으로 수용 개발해 진화해 나갑니다.

하지만 우리가 이론적으로는 아래와 같은 개념도로 단순하게 생각할 수 있지만

이 방법론이 현장에서 성공하려면 꽤 많은 한계와 고려사항이 있습니다.

제 경험을 토대로 내용을 공유해 보겠습니다.

1. 핵심요구사항을 개발하는 1차 배포의 품질 기준

 핵심요구사항을 개발하는 1차 최초 배포의 품질 기준은 어느정도 수준일까요?

 반복적 개발 방법론이기에 1차 최초 배포의 품질 기준을 낮게 잡을 수 있을까요?

 배포라는 것은 운영계에 배포되어 실제 사용자가 사용한다는 것을 뜻합니다.

 요구사항이 빈약해 아주 낮은 수준의 품질을 운영계에 배포하는 것은 아래와 같은 문제점을 야기하게 됩니다.

  1) Data Modeling이 틀어질 가능성이 매우 높습니다.

     - 초기 품질이 매우 낮았기에 요구사항이 늘어날수록 기존 테이블들의 변경이 야기됩니다.

  2) 스파게티 코딩이 늘어납니다.

     - 로직이 지속적으로 변경되니 당연한 결과입니다.

 반복적 개발 방법론을 사용하며 효과를 내려면

 요구사항 협의가 완료된 기능(Function)기준으로 배포하거나,

 요구사항이 빈약하더라도 RFP/Reference 기준 100%의 품질을 예상 후, 그 기준에서 90%품질 이상으로 배포되어야 합니다.

 고객이 일단 개발 된 것 부터 빨리 운영계에 배포해달라고 하는 요청이 지속적으로 옵니다.

 하지만 품질확보를 하지 못한 1차 운영계 배포는 첫단추부터 잘못 꿰메는 것이라 두고두고 이후 개발이 고통스러울 것입니다.

 배포 품질 기준은 꼭 고려해야할 가장 최우선 요소입니다.

2. 수행사가 프로젝트의 환경에 익숙한가?

 반복적 개발 방법론은 폭포수 모델처럼 분석-설계-개발-테스트-배포가 순차적으로 진행되어 한번에 끝나지 않습니다.

 일정을 분할해 폭포수 모델이 반복적으로 배포됩니다.

 그런데 수행사가 수행 환경에 익숙하지 않다면?

 실질적으로 설계/개발을 주도하는 분들은 PL/개발자분들입니다.

 현 프로젝트 환경에 익숙하지 않은 분들은 요구사항이 주어지는대로 빠르게 설계/개발 및 배포할 수 없습니다.

 정직원들이 Agile을 이루어 직접 개발하는 곳은 이런 이슈가 없겠지만

 아직 금융사 뿐만 아니라 타 업종 대기업들은 거의 OS를 통해 개발하는 것이 현실입니다.

 적응기간이 필요합니다.

 따라서 반복적 개발 방법론을 사용하려 할 때는

 수행사 구성원들의 수행Reference를 확인하고 구성원을 최적화한 뒤 수행해야 합니다.

3. 일정의 터프함은 구성원들을 지치게 한다.

 반복적 개발 방법론을 활용할 때 PM들이 제일 많이하는 행동입니다.

 "1차 배포에 대한 요구사항은 전체 대비 20%수준입니다.

 따라서 전체 일정 대비 20%의 공수를 가지고 진행하겠습니다."

 이론적으로는 맞는 말입니다.

 하지만 반복적 개발 방법론의 핵심은

 일정관리 측면에서 폭포수 모델 같은 고전적 방법론 보다 더 긴 개발 일정이 필요합니다.

 많은 PM들이 이 부분을 간과하고 반복적 개발 방법론을 채택합니다.

 한 번의 SDLC 수행 간 개발자들이 얼마나 많은 피로도가 쌓이는지는 분명 아실겁니다.

 혹자들은 초기 요구사항이 빈약하지만 일정을 맞추고 고품질의 산출물을 달성하기 위해 사용하는 방법론이 아니냐? 라고 하지만

 반복적 개발 방법론을 사용해보신 분들은 아실겁니다.

 수 번의 SDLC가 반복되는 프로젝트는 개발자가 피로감에 중간에 다 나갑니다.

 결론적으로 Risk가 더 높아지는 것이 현실입니다.

 이런 부분이 이론과 현실의 차이입니다.

 다시 말씀드리면

 반복적 개발 방법론의 일정 산정은 고전적 폭포수 모델보다 더 산정되어야 합니다.

 초기 요구사항이 빈약한 만큼 배포 주기를 조금은 러프하게 가져가야 합니다.

 주어진 일정이 버퍼가 없다면 반복적 개발 방법론은 선택하지 않는 것이 좋습니다.