2020.10.06

기고|대규모 ERP 프로젝트에 애자일 활용하려면?··· 6가지 과제와 해법

John Belden | CIO
ERP같은 대규모 프로젝트에 애자일을 도입하기 위해서는 넘어야 할 난관들이 있다. 

오랫동안 애자일은 IT 업계의 표준 개발 방법론이었으며 많은 기업에 도입돼 성공적으로 활용된 바 있다. 애자일을 통해 기업들이 덕을 보게 되면서, 점점 더 큰 작업에도 애자일을 도입하려는 경향이 나타났다. 심지어 (상당한 분량의 통합 작업 때문에 복잡하기로 악명높은) ERP 구축 프로젝트에 애자일을 응용하려는 시도도 나타나고 있다. 그러나 프로젝트의 규모가 커지면 애자일의 혜택이 소규모 프로젝트만큼 쉽게 나타나지 않는 것도 사실이다. 
 
ⓒGetty Images Bank

그간의 경험과 연구를 통해, 필자는 ERP 구축에 애자일을 효과적으로 활용하기 위해 넘어서야 할 6가지 난관과 그에 대한 조치를 아래와 같이 정리했다. 

1. 주요 결정 거버넌스 
애자일 프로젝트의 성공을 좌우하는 중요한 요인은 팀이다. 정예화되고 헌신적인 팀이 필요하며 팀 구성원은 고도로 숙련되고 연결돼 있어야 한다. 또 이들 구성원들에게 프로젝트 전반에 걸쳐 핵심 의사결정을 내릴 수 있는 권한이 주어져야 한다. 대규모 프로젝트에서는  각 팀이 내려야 할 의사 결정의 개수가 증가하며, 이로 인해 잘못된 결정을 내리는 경우도 늘어난다. 조직별 유불리에 따라 각 결정의 복잡성이 높아지기도 한다. 프로젝트에 참여한 팀과 결과물이 많을수록 모든 팀을 정렬시키는 작업은 어렵고 시간도 많이 소요된다. 

또한 이해당사자 스코프도 증가하기 때문에 합의하는 데 더 많은 시간이 들 수 있다. 의사결정이 복잡해지고 교차기능적으로 이뤄지면 애자일 사고방식은 어울리지 않는 경향이 있다. 때문에 프로젝트의 규모가 클수록 애자일 방법론은 적용하기가 까다로워진다.

이 문제를 해결하려면 릴리즈 트레인 엔지니어(Release Train Engineers)가 주요 책임과 권한을 갖고 있어야 한다. 즉, 그가 핵심 의사결정 사안을 파악하고, 조기에 팀원에게 공유하며, 핵심 의사결정이 적시에 이루어질 수 있도록 의사결정 전략을 수립해야 한다. 

2. 백로그(Backlog) 관리 
대규모 프로젝트에 애자일을 활용할 경우, 소규모 개발 프로젝트보다 백로그를 관리하기가 어렵다. 왜냐하면 백로그에는 소프트웨어 개발과 직접 관련이 없는 활동(즉, 데이터팀 지원, 교육 지원, 배포 활동 등)들도 다수 포함돼 있기 때문이다. 

통합된 테스트를 관리하는 작업도 만만치 않다. ERP 테스팅에는 여러 팀이 참여해야 하기 때문이다. 또한 (특히 ERP의 경우) 백로그에 있는 여러 항목들을 한 사람이 혼자서 결정하기 어려우며, 다른 팀들의 직접적인 요구 사항을 반영해야 한다는 점에서 관리하기가 번거롭다. 이 두 가지 애로사항 때문에 프로덕트 오너는 프로그램의 전체 스코프를 이해한 상태에서 백로그를 조율 및 관리해 백로그가 다른 팀과 동기화될 수 있도록 해야 한다. 

이를 위해서 프로젝트 초기에 엔드투엔드 테스트 전략을 마련해야 한다. 이 전략을 수립함으로써, 프로덕트 오너는 백로그의 우선 순위를 정하는 과정에 얽힌 종속성과 관행을 더 잘 이해할 수 있다. 

3. 스크럼 팀 동기화 및 최적화
애자일 프로젝트에서는 스크럼 팀 전체의 진행 속도를 맞추는 것이 중요하다. 스크럼 팀 전체의 커뮤니케이션 및 퍼포먼스와 합이 맞지 않는 팀은 최적의 생산성을 발휘하지 못한다. 따라서 각 팀의 작업물은 반드시 동일한 시기에 동일한 완성도를 갖춰야 한다. 

이를 달성하려면 팀원 모두가 애자일 사고방식을 완벽하게 수용해야 하며 팀 간에 ‘작업 완수’가 뜻하는 바를 명확하게 합의해야 한다. 각 팀별로 작업 완수에 대한 정의가 제각각이면 엔드투엔드 테스트 기간이 늘어날 수 있다. 

이를 위해 릴리스 트레인 엔지니어는 다음의 2가지 중요한 역할을 수행해야 한다. 

1. 팀 간 종속성이 각 팀의 백로그 및 스프린트 계획의 일환으로 간주되고 기록되는지 확인
2. 예상 납품 일자에 팀의 결과물이 전달되도록 작업 속도를 모니터링하고 스프린트 팀의 업무 수용력을 조정 

4. 파트타임과 공유된 리소스의 통합
팀원들은 한 프로젝트에 풀타임 멤버로 참여하기도 하지만 다른 팀의 작업에 부분적으로 참여하기도 한다. 그런 이유로 한 팀원이 자신의 시간을 작업에 효율적으로 배분하기 위해서는 프로젝트의 다른 팀과 합을 맞추고 있어야 한다. 

스크럼 전담 인력도 감안해야 하지만 파트타임으로 참여하는 이들도 고려해야 한다. 예컨대, 애자일 프로젝트 전체 중에서 자신의 시간을 10%만 할애하는 감사 담당자가 있을 수 있다. 이 경우 프로그램 매니저는 감사가 필요할 때 감사 담당자가 프로젝트에 참여할 수 있도록 스케줄 조정을 도와줘야 한다. 

리소스 예측 (Resource forecasts) 툴은 이와 관련해 훌륭한 도구다. 릴리즈 트레인 엔지니어(Release Train Engineers)는 프로그램 전체에 필요한 리소스 수요를 예측하면서 주기적으로 모든 영역을 업데이트해야 한다. 프로덕트 오너들은 예측된 수요에 맞춰 백로그를 관리함으로써 프로젝트 외부에서 리소스를 제공해주는 이들과 좋은 관계를 유지할 수 있을 것이다. 

5. 대형 프로젝트에 필요한 '관료주의' 
프로젝트 진행 과정에서 임원진이 스테이지 게이트 검토(Stage Gate Reviews)에 참여하곤 한다. 이들은 보통 프로젝트를 검토하며 피드백을 준다. 일반적으로 대규모 프로젝트에서는 상당량의 산출물과 문서가 있어야 검토진의 전폭적인 지지를 얻을 수 있다. 

역설적이게도, 애자일 방법론은 문서작업보다는 점증식 개발에 더 많은 초점을 둔다. 이로 인해 이사회 수준의 투명성을 유지하기가 까다로워진다. 

이 문제를 해결하려면 프로덕트 오너는 경영진에게 프레젠테이션을 한 다음 각 스프린트가 종료된 후 자료를 업데이트하는 게 좋다. 이사회 및 고위 경영진에게 보고할 프레젠테이션은 요식행위가 아니라 프로젝트의 현재 상태와 향후 전망을 담고 있어야 한다. 

6. 벤더의 책임 및 성과
애자일 프로젝트에서는 회사와 벤더 간 ‘리스크 공유’를 정의하기가 훨씬 까다롭다. 대규모 프로그램 계약은 워터폴이나 인도물 기반(deliverable-based) 방식을 따르곤 한다. 즉, 가격이나 스케줄 측면의 퍼포먼스에 영향을 줄 수 있는 페널티나 인센티브를 둠으로써 벤더가 기업에게 최선을 다하도록 하는 것이다.

반면, 애자일은 스코프가 가변적일 때에도 비용과 시간이 고정된다고 가정한다. 이는 유연성이 떨어지는 ERP 스코프와 상충된다. 이로 인해 보증 지원(warranty support)의 개념을 정의하고 해결하는 일이 복잡해진다. 그런 이유로 클라이언트부터 벤더까지 프로젝트에 참여한 모든 사람들이 각 스프린트에서 정의한 ‘작업 완수’의 개념을 숙지하고 있어야 한다. 

최근 몇 년 새 이런 정의에 초점을 맞춘 새로운 계약 구조들이 등장하고 있다. 이 계약은 작업과 관련해 맺은 특정한 정의를 달성하는 데 있어 인센티브와 페널티가 적용돼 있다. ERP를 다루기 위해 규모별로 애자일 방법론을 고려하고 있는 팀이라면 새로운 계약 구조에 대해 배워야 한다. 

*John Belden은 UpperEdge의 프로젝트 실행 어드바이저리 서비스 전문가다. ciokr@idg.co.kr



2020.10.06

기고|대규모 ERP 프로젝트에 애자일 활용하려면?··· 6가지 과제와 해법

John Belden | CIO
ERP같은 대규모 프로젝트에 애자일을 도입하기 위해서는 넘어야 할 난관들이 있다. 

오랫동안 애자일은 IT 업계의 표준 개발 방법론이었으며 많은 기업에 도입돼 성공적으로 활용된 바 있다. 애자일을 통해 기업들이 덕을 보게 되면서, 점점 더 큰 작업에도 애자일을 도입하려는 경향이 나타났다. 심지어 (상당한 분량의 통합 작업 때문에 복잡하기로 악명높은) ERP 구축 프로젝트에 애자일을 응용하려는 시도도 나타나고 있다. 그러나 프로젝트의 규모가 커지면 애자일의 혜택이 소규모 프로젝트만큼 쉽게 나타나지 않는 것도 사실이다. 
 
ⓒGetty Images Bank

그간의 경험과 연구를 통해, 필자는 ERP 구축에 애자일을 효과적으로 활용하기 위해 넘어서야 할 6가지 난관과 그에 대한 조치를 아래와 같이 정리했다. 

1. 주요 결정 거버넌스 
애자일 프로젝트의 성공을 좌우하는 중요한 요인은 팀이다. 정예화되고 헌신적인 팀이 필요하며 팀 구성원은 고도로 숙련되고 연결돼 있어야 한다. 또 이들 구성원들에게 프로젝트 전반에 걸쳐 핵심 의사결정을 내릴 수 있는 권한이 주어져야 한다. 대규모 프로젝트에서는  각 팀이 내려야 할 의사 결정의 개수가 증가하며, 이로 인해 잘못된 결정을 내리는 경우도 늘어난다. 조직별 유불리에 따라 각 결정의 복잡성이 높아지기도 한다. 프로젝트에 참여한 팀과 결과물이 많을수록 모든 팀을 정렬시키는 작업은 어렵고 시간도 많이 소요된다. 

또한 이해당사자 스코프도 증가하기 때문에 합의하는 데 더 많은 시간이 들 수 있다. 의사결정이 복잡해지고 교차기능적으로 이뤄지면 애자일 사고방식은 어울리지 않는 경향이 있다. 때문에 프로젝트의 규모가 클수록 애자일 방법론은 적용하기가 까다로워진다.

이 문제를 해결하려면 릴리즈 트레인 엔지니어(Release Train Engineers)가 주요 책임과 권한을 갖고 있어야 한다. 즉, 그가 핵심 의사결정 사안을 파악하고, 조기에 팀원에게 공유하며, 핵심 의사결정이 적시에 이루어질 수 있도록 의사결정 전략을 수립해야 한다. 

2. 백로그(Backlog) 관리 
대규모 프로젝트에 애자일을 활용할 경우, 소규모 개발 프로젝트보다 백로그를 관리하기가 어렵다. 왜냐하면 백로그에는 소프트웨어 개발과 직접 관련이 없는 활동(즉, 데이터팀 지원, 교육 지원, 배포 활동 등)들도 다수 포함돼 있기 때문이다. 

통합된 테스트를 관리하는 작업도 만만치 않다. ERP 테스팅에는 여러 팀이 참여해야 하기 때문이다. 또한 (특히 ERP의 경우) 백로그에 있는 여러 항목들을 한 사람이 혼자서 결정하기 어려우며, 다른 팀들의 직접적인 요구 사항을 반영해야 한다는 점에서 관리하기가 번거롭다. 이 두 가지 애로사항 때문에 프로덕트 오너는 프로그램의 전체 스코프를 이해한 상태에서 백로그를 조율 및 관리해 백로그가 다른 팀과 동기화될 수 있도록 해야 한다. 

이를 위해서 프로젝트 초기에 엔드투엔드 테스트 전략을 마련해야 한다. 이 전략을 수립함으로써, 프로덕트 오너는 백로그의 우선 순위를 정하는 과정에 얽힌 종속성과 관행을 더 잘 이해할 수 있다. 

3. 스크럼 팀 동기화 및 최적화
애자일 프로젝트에서는 스크럼 팀 전체의 진행 속도를 맞추는 것이 중요하다. 스크럼 팀 전체의 커뮤니케이션 및 퍼포먼스와 합이 맞지 않는 팀은 최적의 생산성을 발휘하지 못한다. 따라서 각 팀의 작업물은 반드시 동일한 시기에 동일한 완성도를 갖춰야 한다. 

이를 달성하려면 팀원 모두가 애자일 사고방식을 완벽하게 수용해야 하며 팀 간에 ‘작업 완수’가 뜻하는 바를 명확하게 합의해야 한다. 각 팀별로 작업 완수에 대한 정의가 제각각이면 엔드투엔드 테스트 기간이 늘어날 수 있다. 

이를 위해 릴리스 트레인 엔지니어는 다음의 2가지 중요한 역할을 수행해야 한다. 

1. 팀 간 종속성이 각 팀의 백로그 및 스프린트 계획의 일환으로 간주되고 기록되는지 확인
2. 예상 납품 일자에 팀의 결과물이 전달되도록 작업 속도를 모니터링하고 스프린트 팀의 업무 수용력을 조정 

4. 파트타임과 공유된 리소스의 통합
팀원들은 한 프로젝트에 풀타임 멤버로 참여하기도 하지만 다른 팀의 작업에 부분적으로 참여하기도 한다. 그런 이유로 한 팀원이 자신의 시간을 작업에 효율적으로 배분하기 위해서는 프로젝트의 다른 팀과 합을 맞추고 있어야 한다. 

스크럼 전담 인력도 감안해야 하지만 파트타임으로 참여하는 이들도 고려해야 한다. 예컨대, 애자일 프로젝트 전체 중에서 자신의 시간을 10%만 할애하는 감사 담당자가 있을 수 있다. 이 경우 프로그램 매니저는 감사가 필요할 때 감사 담당자가 프로젝트에 참여할 수 있도록 스케줄 조정을 도와줘야 한다. 

리소스 예측 (Resource forecasts) 툴은 이와 관련해 훌륭한 도구다. 릴리즈 트레인 엔지니어(Release Train Engineers)는 프로그램 전체에 필요한 리소스 수요를 예측하면서 주기적으로 모든 영역을 업데이트해야 한다. 프로덕트 오너들은 예측된 수요에 맞춰 백로그를 관리함으로써 프로젝트 외부에서 리소스를 제공해주는 이들과 좋은 관계를 유지할 수 있을 것이다. 

5. 대형 프로젝트에 필요한 '관료주의' 
프로젝트 진행 과정에서 임원진이 스테이지 게이트 검토(Stage Gate Reviews)에 참여하곤 한다. 이들은 보통 프로젝트를 검토하며 피드백을 준다. 일반적으로 대규모 프로젝트에서는 상당량의 산출물과 문서가 있어야 검토진의 전폭적인 지지를 얻을 수 있다. 

역설적이게도, 애자일 방법론은 문서작업보다는 점증식 개발에 더 많은 초점을 둔다. 이로 인해 이사회 수준의 투명성을 유지하기가 까다로워진다. 

이 문제를 해결하려면 프로덕트 오너는 경영진에게 프레젠테이션을 한 다음 각 스프린트가 종료된 후 자료를 업데이트하는 게 좋다. 이사회 및 고위 경영진에게 보고할 프레젠테이션은 요식행위가 아니라 프로젝트의 현재 상태와 향후 전망을 담고 있어야 한다. 

6. 벤더의 책임 및 성과
애자일 프로젝트에서는 회사와 벤더 간 ‘리스크 공유’를 정의하기가 훨씬 까다롭다. 대규모 프로그램 계약은 워터폴이나 인도물 기반(deliverable-based) 방식을 따르곤 한다. 즉, 가격이나 스케줄 측면의 퍼포먼스에 영향을 줄 수 있는 페널티나 인센티브를 둠으로써 벤더가 기업에게 최선을 다하도록 하는 것이다.

반면, 애자일은 스코프가 가변적일 때에도 비용과 시간이 고정된다고 가정한다. 이는 유연성이 떨어지는 ERP 스코프와 상충된다. 이로 인해 보증 지원(warranty support)의 개념을 정의하고 해결하는 일이 복잡해진다. 그런 이유로 클라이언트부터 벤더까지 프로젝트에 참여한 모든 사람들이 각 스프린트에서 정의한 ‘작업 완수’의 개념을 숙지하고 있어야 한다. 

최근 몇 년 새 이런 정의에 초점을 맞춘 새로운 계약 구조들이 등장하고 있다. 이 계약은 작업과 관련해 맺은 특정한 정의를 달성하는 데 있어 인센티브와 페널티가 적용돼 있다. ERP를 다루기 위해 규모별로 애자일 방법론을 고려하고 있는 팀이라면 새로운 계약 구조에 대해 배워야 한다. 

*John Belden은 UpperEdge의 프로젝트 실행 어드바이저리 서비스 전문가다. ciokr@idg.co.kr

X