2016.07.12

기고 | 애자일과 워터폴을 공존시키는 4가지 방법

David Taber | CIO
이론적으로 이들 두 기법은 서로 섞일만한 것들이 아니다. 하지만 현실적으로는 대개 공존해야만 한다. 여기 애자일과 워터폴이라는 상반되는 기법이 함께 존재할 수 있도록 하는 4가지 방법을 정리한다.


Image Credit : Getty Images Bank

IT 부서는 애자일(Agile) 프로젝트의 민첩성과 생산성을 으레 선호한다. 하지만 경영진과 재무 조직에 프로젝트를 소개할 때는 워터폴(Waterfall) 개념을 거의 항상 필수요건으로 소개하게 된다. 사실 따져보면 애자일과 워터폴은 반대에 가까운 개념들이며, 특히 많은 소프트웨어 프로젝트에서 두 기법을 두고 꽤나 불편한 상황이 연출되기도 한다. 폴라 압둘의 노래와는 달리 상반되는 성격이 그리 매력적으로 다가오지 않는 것이다. 그렇다면 이 둘을 어떻게 함께 활용할 수 있을까?

대응 전략 #1: 적극적 계정 관리
워터폴에는 고정된 사양뿐만이 아니라 고정된 예산과 일정이 수반된다. 따라서 유연하거나 모호하게 정의된 스프린트(Sprint) 성과물과 조합하려면 꽤나 고민을 해야 한다. 하지만 워터폴의 ‘사양’이 불분명하거나 (고객은 무엇이 필요한지 정확하게 모르기 때문) 신축성이 있는 경우 (임원이 우선적으로 결정하기 때문) 의외로 효과가 있을 수 있다

하지만 이 전략은 조심스럽게 적용될 필요가 있다는 점에 주의해야 한다. 프로젝트 범위 확대 및 우선순위 충돌 문제로 비화되서는 안 된다.

베스트 프랙티스: 매 스프린트 시작과 끝에 서면으로 기대치를 명시적으로 관리한다. 또한 스프린트 중 제공되는 각 기능에 대해 고객의 승인을 받는다.

워스트 프랙티스: 문제 자체가 알아서 해결되기를 바라면서 현실을 외면하는 태도.

대응 전략 #2: 주문 변경 공식화
워터폴 프로젝트에서 고객은 걸핏하면 주문을 변경한다 (계약서가 그렇게 조장하는 측면도 있다). 그렇다면 이런 메커니즘을 조기에 자주 활용하자. 예전에 참여한 70만달러짜리 프로젝트에서 50건의 주문 변경이 발생했다 (다행히 시간이 그리 많이 초과되지는 않았다). 주문 변경은 SOW(Statement Of Work)에 공식적인 항목으로 포함시켜야 하며 고객 서명을 받아 계약상의 효과를 갖도록 해야 한다.

베스트 프랙티스: 모호하게 지정된 모든 항목에 대한 주문 변경서를 발행해 모호함을 없앤다. 주문 변경에는 일정과 비용 영향뿐만이 아니라 기능 상세도 포함되어야 한다.

워스트 프랙티스: 주문 변경서 발행 지연 또는 누락으로 ‘구두상으로만 합의’했다가 쉽게 잊어버림.

대응 전략 #3: 발견 작업을 중단
일반적인 소프트웨어 프로젝트에서 초기 고정 비용 단계(총 프로젝트 노력의 10-25% 차지)가 요건 발견 과정에 할당된다. 이 과정의 결과물로 프로젝트 기능 요건 명세서를 얻게 된다. 대개 첫 번째 단계 이후에도 많은 세부사항을 발견되지만 이런 새로운 항목은 프로젝트 이행자의 문제가 아니며, 소비 또는 고객 기관의 문제다. 주문 변경서 없이 구속력이 있는 요건으로 수용해서는 안 된다. 안타깝게도 배치 후에도 여전히 발견 작업을 진행 중인 프로젝트가 적지 않다.

베스트 프랙티스: 발견 단계에서 작성된 프로젝트 요건 문서는 그 내용인 계약을 위한 구속력 있는 요건의 총체임을 알리는 문장이 포함되고 소비 또는 고객 부서의 각 주요 부처의 VP 서명이 포함되어야 한다.

워스트 프랙티스: 관리를 소홀히 해 주문 변경서 없이 프로젝트의 모든 단계에서 새로운 요건을 수용한다.

대응 전략 #4: 각 주요 기능 영역의 초과를 차단
지금껏 이야기간 방법들은 모두 프로젝트 중 대응 메커니즘에 초점을 둔 것들이다. 현실적으로는 이미 늦어버린 경우가 많다. 이번 전략은 SOW(Statement Of Work)의 문자에 초점을 두고 하나의 애자일 원칙을 워터폴 프레임워크에 혼합하는 것이 목적이다. SOW의 제품 섹션에서 각 주요 섹션(일반적 5-10 범위)은 다음의 어구를 말단에 포함해야 한다.

앞서 언급한 내용에도 불구하고 본 기능 영역의 이행과 배치에 관련된 총체적인 노력은 X 시간을 초과하지 않는다. 이 영역에 대한 노력이 해당 한계의 25%, 50%, 75%에 도달하는 경우 컨설턴트는 고객에 과업 검토 회의가 필요하다고 고지할 수 있다. 이 회의 중 컨설턴트는 고객에 제품을 위태롭게 하는 프로젝트 변동 또는 발견 사항을 알리고 나아갈 방향을 제시한다. 이 회의 후 고객은 요건, 일정, 예산 등에 대해 원하는 수정사항을 명시한 주문 변경 요청서를 발행한다.

베스트 프랙티스: 사소한 일을 당연한 것으로 받아 들이지만 적색 경보 상태이거나 수 주 이상 정체된 과업에 대해서는 과업 검토 회의를 요청한다. 과업의 적색 경보를 발령하지 못하는 것은 프로젝트 책임자로서 해고 사유다.

워스트 프랙티스: SOW에서 이 문장을 누락하고 프로젝트 중 UAT까지 문제 전체를 회피한다.

그러나...
위의 모든 전략이 어느 정도 효과가 있기는 하지만 모순이 되는 부분을 억지로 메우는 측면이 있다. 애자일 프로젝트를 지향한다면서도 많은 고객 기관 또는 경영진이 유연성에 대응하지 못하고 고정된 제품에 대한 확인 목록을 고집하는 경우가 많다. 그럴 경우 계약서에 서명하기 전에 이를 간파해야 한다. 차라리 그냥 순수한 워터폴 방식을 지양하면서 이에 따라 관리하는 것이 나을 수 있다. 물론, 가격을 올리고 일정을 늘려야겠지만 최소한 위험을 일관성 있게 관리하게 된다.

기저 원인
대부분의 맞춤형 소프트웨어 프로젝트에서 입찰 및 엄격한 프로젝트 관리를 위해 충분한 세부사항과 함께 사전에 요건을 명시하지 않는다. 만약 CRM 프로젝트의 경우 깔끔하게 끝나기란 사실상 불가능하다고 말하고 싶다. 왜일까? 어떤 가능성이 있을까?

- 개발측이 제대로 이해할 수 없을 정도로 엄격하고 정확하게 요건을 사용자가 명시할 수 있을까?

- 사용자가 프로젝트 과정 중 세부사항과 우선순위에 관한 생각을 바꾸지 않는 경우가 있을까?

- CRM 프로젝트가 진행되는 중 고객의 채널, 경쟁력 있는 환경, 내부적인 비즈니스 규칙이 바뀌지 않을 수 있을까?

- 고객이 자신의 데이터, 비즈니스 프로세스, 교차 시스템 통합을 너무 잘 이해해서 프로젝트 중 놀라는 일이 전혀 없을까?

- 개발 측이 준수해야 하는 모든 정부 규정, 고객 계약 조건, 진행 중인 소송, 내부 표준을 고객사가 예측할 수 있을까?

즉 프로젝트 전반에 걸쳐 일정 수준의 발견이 이뤄질 수밖에 없다. 따라서 입찰 시 제품 목록 전반에 산재하고 있는 "암흑 물질"을 처리할 수 있는 여유가 있어야 한다.

* David Taber는 'Salesforce.com Secrets of Success'의 저자이자 SalesLogistix의 CEO이다. 세일즈포스닷컴 인증 컨설턴트로, 주로 CRM을 이용한 비즈니스 프로세스 향상 관련 컨설팅을 제공한다. ciokr@idg.co.kr 



2016.07.12

기고 | 애자일과 워터폴을 공존시키는 4가지 방법

David Taber | CIO
이론적으로 이들 두 기법은 서로 섞일만한 것들이 아니다. 하지만 현실적으로는 대개 공존해야만 한다. 여기 애자일과 워터폴이라는 상반되는 기법이 함께 존재할 수 있도록 하는 4가지 방법을 정리한다.


Image Credit : Getty Images Bank

IT 부서는 애자일(Agile) 프로젝트의 민첩성과 생산성을 으레 선호한다. 하지만 경영진과 재무 조직에 프로젝트를 소개할 때는 워터폴(Waterfall) 개념을 거의 항상 필수요건으로 소개하게 된다. 사실 따져보면 애자일과 워터폴은 반대에 가까운 개념들이며, 특히 많은 소프트웨어 프로젝트에서 두 기법을 두고 꽤나 불편한 상황이 연출되기도 한다. 폴라 압둘의 노래와는 달리 상반되는 성격이 그리 매력적으로 다가오지 않는 것이다. 그렇다면 이 둘을 어떻게 함께 활용할 수 있을까?

대응 전략 #1: 적극적 계정 관리
워터폴에는 고정된 사양뿐만이 아니라 고정된 예산과 일정이 수반된다. 따라서 유연하거나 모호하게 정의된 스프린트(Sprint) 성과물과 조합하려면 꽤나 고민을 해야 한다. 하지만 워터폴의 ‘사양’이 불분명하거나 (고객은 무엇이 필요한지 정확하게 모르기 때문) 신축성이 있는 경우 (임원이 우선적으로 결정하기 때문) 의외로 효과가 있을 수 있다

하지만 이 전략은 조심스럽게 적용될 필요가 있다는 점에 주의해야 한다. 프로젝트 범위 확대 및 우선순위 충돌 문제로 비화되서는 안 된다.

베스트 프랙티스: 매 스프린트 시작과 끝에 서면으로 기대치를 명시적으로 관리한다. 또한 스프린트 중 제공되는 각 기능에 대해 고객의 승인을 받는다.

워스트 프랙티스: 문제 자체가 알아서 해결되기를 바라면서 현실을 외면하는 태도.

대응 전략 #2: 주문 변경 공식화
워터폴 프로젝트에서 고객은 걸핏하면 주문을 변경한다 (계약서가 그렇게 조장하는 측면도 있다). 그렇다면 이런 메커니즘을 조기에 자주 활용하자. 예전에 참여한 70만달러짜리 프로젝트에서 50건의 주문 변경이 발생했다 (다행히 시간이 그리 많이 초과되지는 않았다). 주문 변경은 SOW(Statement Of Work)에 공식적인 항목으로 포함시켜야 하며 고객 서명을 받아 계약상의 효과를 갖도록 해야 한다.

베스트 프랙티스: 모호하게 지정된 모든 항목에 대한 주문 변경서를 발행해 모호함을 없앤다. 주문 변경에는 일정과 비용 영향뿐만이 아니라 기능 상세도 포함되어야 한다.

워스트 프랙티스: 주문 변경서 발행 지연 또는 누락으로 ‘구두상으로만 합의’했다가 쉽게 잊어버림.

대응 전략 #3: 발견 작업을 중단
일반적인 소프트웨어 프로젝트에서 초기 고정 비용 단계(총 프로젝트 노력의 10-25% 차지)가 요건 발견 과정에 할당된다. 이 과정의 결과물로 프로젝트 기능 요건 명세서를 얻게 된다. 대개 첫 번째 단계 이후에도 많은 세부사항을 발견되지만 이런 새로운 항목은 프로젝트 이행자의 문제가 아니며, 소비 또는 고객 기관의 문제다. 주문 변경서 없이 구속력이 있는 요건으로 수용해서는 안 된다. 안타깝게도 배치 후에도 여전히 발견 작업을 진행 중인 프로젝트가 적지 않다.

베스트 프랙티스: 발견 단계에서 작성된 프로젝트 요건 문서는 그 내용인 계약을 위한 구속력 있는 요건의 총체임을 알리는 문장이 포함되고 소비 또는 고객 부서의 각 주요 부처의 VP 서명이 포함되어야 한다.

워스트 프랙티스: 관리를 소홀히 해 주문 변경서 없이 프로젝트의 모든 단계에서 새로운 요건을 수용한다.

대응 전략 #4: 각 주요 기능 영역의 초과를 차단
지금껏 이야기간 방법들은 모두 프로젝트 중 대응 메커니즘에 초점을 둔 것들이다. 현실적으로는 이미 늦어버린 경우가 많다. 이번 전략은 SOW(Statement Of Work)의 문자에 초점을 두고 하나의 애자일 원칙을 워터폴 프레임워크에 혼합하는 것이 목적이다. SOW의 제품 섹션에서 각 주요 섹션(일반적 5-10 범위)은 다음의 어구를 말단에 포함해야 한다.

앞서 언급한 내용에도 불구하고 본 기능 영역의 이행과 배치에 관련된 총체적인 노력은 X 시간을 초과하지 않는다. 이 영역에 대한 노력이 해당 한계의 25%, 50%, 75%에 도달하는 경우 컨설턴트는 고객에 과업 검토 회의가 필요하다고 고지할 수 있다. 이 회의 중 컨설턴트는 고객에 제품을 위태롭게 하는 프로젝트 변동 또는 발견 사항을 알리고 나아갈 방향을 제시한다. 이 회의 후 고객은 요건, 일정, 예산 등에 대해 원하는 수정사항을 명시한 주문 변경 요청서를 발행한다.

베스트 프랙티스: 사소한 일을 당연한 것으로 받아 들이지만 적색 경보 상태이거나 수 주 이상 정체된 과업에 대해서는 과업 검토 회의를 요청한다. 과업의 적색 경보를 발령하지 못하는 것은 프로젝트 책임자로서 해고 사유다.

워스트 프랙티스: SOW에서 이 문장을 누락하고 프로젝트 중 UAT까지 문제 전체를 회피한다.

그러나...
위의 모든 전략이 어느 정도 효과가 있기는 하지만 모순이 되는 부분을 억지로 메우는 측면이 있다. 애자일 프로젝트를 지향한다면서도 많은 고객 기관 또는 경영진이 유연성에 대응하지 못하고 고정된 제품에 대한 확인 목록을 고집하는 경우가 많다. 그럴 경우 계약서에 서명하기 전에 이를 간파해야 한다. 차라리 그냥 순수한 워터폴 방식을 지양하면서 이에 따라 관리하는 것이 나을 수 있다. 물론, 가격을 올리고 일정을 늘려야겠지만 최소한 위험을 일관성 있게 관리하게 된다.

기저 원인
대부분의 맞춤형 소프트웨어 프로젝트에서 입찰 및 엄격한 프로젝트 관리를 위해 충분한 세부사항과 함께 사전에 요건을 명시하지 않는다. 만약 CRM 프로젝트의 경우 깔끔하게 끝나기란 사실상 불가능하다고 말하고 싶다. 왜일까? 어떤 가능성이 있을까?

- 개발측이 제대로 이해할 수 없을 정도로 엄격하고 정확하게 요건을 사용자가 명시할 수 있을까?

- 사용자가 프로젝트 과정 중 세부사항과 우선순위에 관한 생각을 바꾸지 않는 경우가 있을까?

- CRM 프로젝트가 진행되는 중 고객의 채널, 경쟁력 있는 환경, 내부적인 비즈니스 규칙이 바뀌지 않을 수 있을까?

- 고객이 자신의 데이터, 비즈니스 프로세스, 교차 시스템 통합을 너무 잘 이해해서 프로젝트 중 놀라는 일이 전혀 없을까?

- 개발 측이 준수해야 하는 모든 정부 규정, 고객 계약 조건, 진행 중인 소송, 내부 표준을 고객사가 예측할 수 있을까?

즉 프로젝트 전반에 걸쳐 일정 수준의 발견이 이뤄질 수밖에 없다. 따라서 입찰 시 제품 목록 전반에 산재하고 있는 "암흑 물질"을 처리할 수 있는 여유가 있어야 한다.

* David Taber는 'Salesforce.com Secrets of Success'의 저자이자 SalesLogistix의 CEO이다. 세일즈포스닷컴 인증 컨설턴트로, 주로 CRM을 이용한 비즈니스 프로세스 향상 관련 컨설팅을 제공한다. ciokr@idg.co.kr 

X