Offcanvas

���������

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

ERP같은 대규모 프로젝트에 애자일을 도입하기 위해서는 넘어야 할 난관들이 있다.  오랫동안 애자일은 IT 업계의 표준 개발 방법론이었으며 많은 기업에 도입돼 성공적으로 활용된 바 있다. 애자일을 통해 기업들이 덕을 보게 되면서, 점점 더 큰 작업에도 애자일을 도입하려는 경향이 나타났다. 심지어 (상당한 분량의 통합 작업 때문에 복잡하기로 악명높은) ERP 구축 프로젝트에 애자일을 응용하려는 시도도 나타나고 있다. 그러나 프로젝트의 규모가 커지면 애자일의 혜택이 소규모 프로젝트만큼 쉽게 나타나지 않는 것도 사실이다.    그간의 경험과 연구를 통해, 필자는 ERP 구축에 애자일을 효과적으로 활용하기 위해 넘어서야 할 6가지 난관과 그에 대한 조치를 아래와 같이 정리했다.  1. 주요 결정 거버넌스  애자일 프로젝트의 성공을 좌우하는 중요한 요인은 팀이다. 정예화되고 헌신적인 팀이 필요하며 팀 구성원은 고도로 숙련되고 연결돼 있어야 한다. 또 이들 구성원들에게 프로젝트 전반에 걸쳐 핵심 의사결정을 내릴 수 있는 권한이 주어져야 한다. 대규모 프로젝트에서는  각 팀이 내려야 할 의사 결정의 개수가 증가하며, 이로 인해 잘못된 결정을 내리는 경우도 늘어난다. 조직별 유불리에 따라 각 결정의 복잡성이 높아지기도 한다. 프로젝트에 참여한 팀과 결과물이 많을수록 모든 팀을 정렬시키는 작업은 어렵고 시간도 많이 소요된다.  또한 이해당사자 스코프도 증가하기 때문에 합의하는 데 더 많은 시간이 들 수 있다. 의사결정이 복잡해지고 교차기능적으로 이뤄지면 애자일 사고방식은 어울리지 않는 경향이 있다. 때문에 프로젝트의 규모가 클수록 애자일 방법론은 적용하기가 까다로워진다. 이 문제를 해결하려면 릴리즈 트레인 엔지니어(Release Train Engineers)가 주요 책임과 권한을 갖고 있어야 한다. 즉, 그가 핵심 의사결정 사안을 파악하고, 조기에 팀원에게 공유하며, 핵심 의사결정이 적시에 이루어질 수 ...

애자일 워터폴 ERP 백로그 스크럼 프로젝트 관리

2020.10.06

ERP같은 대규모 프로젝트에 애자일을 도입하기 위해서는 넘어야 할 난관들이 있다.  오랫동안 애자일은 IT 업계의 표준 개발 방법론이었으며 많은 기업에 도입돼 성공적으로 활용된 바 있다. 애자일을 통해 기업들이 덕을 보게 되면서, 점점 더 큰 작업에도 애자일을 도입하려는 경향이 나타났다. 심지어 (상당한 분량의 통합 작업 때문에 복잡하기로 악명높은) ERP 구축 프로젝트에 애자일을 응용하려는 시도도 나타나고 있다. 그러나 프로젝트의 규모가 커지면 애자일의 혜택이 소규모 프로젝트만큼 쉽게 나타나지 않는 것도 사실이다.    그간의 경험과 연구를 통해, 필자는 ERP 구축에 애자일을 효과적으로 활용하기 위해 넘어서야 할 6가지 난관과 그에 대한 조치를 아래와 같이 정리했다.  1. 주요 결정 거버넌스  애자일 프로젝트의 성공을 좌우하는 중요한 요인은 팀이다. 정예화되고 헌신적인 팀이 필요하며 팀 구성원은 고도로 숙련되고 연결돼 있어야 한다. 또 이들 구성원들에게 프로젝트 전반에 걸쳐 핵심 의사결정을 내릴 수 있는 권한이 주어져야 한다. 대규모 프로젝트에서는  각 팀이 내려야 할 의사 결정의 개수가 증가하며, 이로 인해 잘못된 결정을 내리는 경우도 늘어난다. 조직별 유불리에 따라 각 결정의 복잡성이 높아지기도 한다. 프로젝트에 참여한 팀과 결과물이 많을수록 모든 팀을 정렬시키는 작업은 어렵고 시간도 많이 소요된다.  또한 이해당사자 스코프도 증가하기 때문에 합의하는 데 더 많은 시간이 들 수 있다. 의사결정이 복잡해지고 교차기능적으로 이뤄지면 애자일 사고방식은 어울리지 않는 경향이 있다. 때문에 프로젝트의 규모가 클수록 애자일 방법론은 적용하기가 까다로워진다. 이 문제를 해결하려면 릴리즈 트레인 엔지니어(Release Train Engineers)가 주요 책임과 권한을 갖고 있어야 한다. 즉, 그가 핵심 의사결정 사안을 파악하고, 조기에 팀원에게 공유하며, 핵심 의사결정이 적시에 이루어질 수 ...

2020.10.06

칼럼ㅣ백로그 관리부터 정렬까지··· 프론트라인 관리자가 알아야 할 것

프론트라인 관리자가 되기란 쉽지 않다. 특히 ‘엔지니어’에서 ‘프론트라인 관리자’로 승진한 경우라면 깨닫는 사실이 있다. 사실상 승진한 것이 아니라 완전히 다른 업무를 맡게 됐다는 것이다. 이 전환에서 가장 어려운 과제는 엔지니어들의 요구를 수용하면서도 기업을 대표하는 역할을 해내야 한다는 점이다.    백로그(Backlog) 조직 구성원이라면 누구나 기업의 니즈를 이해해야 한다. 프론트라인 관리자가 기업을 대표하는 역할이라고 생각할지도 모른다. 하지만 프론트라인 관리자만 ‘그런 사고방식’을 가져서는 안 된다. 엔지니어의 임무는 단순히 코드 작성이 아니다. 바로 기업의 니즈 해결이다. 2019 데브옵스 현황(State of DevOps) 보고서에 따르면 소프트웨어를 잘 전달하는 조직은 목표를 달성할 가능성이 2배 이상 높다.  즉 기업의 니즈에 부응하고자 하는 사고방식이 조직 전반에 스며들어 있어야 한다. 그러나 만약 비즈니스 요구가 많다면? 해야 할 일이 많다면? 무엇부터 먼저 해야 하는지 어떻게 알 수 있을까?  애자일 소프트웨어 개발을 하고 있는 팀이라면 그 해답은 백로그에서 찾을 수 있다. ‘백로그’란 한 팀이 일정 기간 또는 일정 시간 안에 해야 할 모든 업무를 작성한 문서이다. 이를테면 업무 개선 아이디어부터 제품 개발 관련 업무, 회고, 학습 리뷰, 사후 분석까지 모두 백로그에 들어간다. 이로 인해 백로그가 엄청나게 길어질 수 있다. 그렇다면 어떻게 해야 할까? 포기(Give up) 여기서의 ‘포기’는 두 손 들고 패배를 선언하면서 물러나라는 뜻이 아니다. 백로그 내의 모든 업무를 완수하겠다는 생각을 팀 차원에서 포기해야 한다는 뜻이다. 모든 아이디어, 모든 프로젝트가 백로그에 포함되기 마련이다. 그러나 우선순위를 비롯해 기술, 계획은 모두 변화한다. 무한한 자원과 시간이 있지 않는 한, 결코 백로그에 있는 모든 업무를 완료할 수 없다. 즉 첫 번째 단계는 모든 업무를 해내겠다는 생각을...

프론트라인 관리자 엔지니어 백로그 정렬 애자일 스프레드시트 우선순위 스크럼 OKR V2MOM 세일즈포스

2020.07.07

프론트라인 관리자가 되기란 쉽지 않다. 특히 ‘엔지니어’에서 ‘프론트라인 관리자’로 승진한 경우라면 깨닫는 사실이 있다. 사실상 승진한 것이 아니라 완전히 다른 업무를 맡게 됐다는 것이다. 이 전환에서 가장 어려운 과제는 엔지니어들의 요구를 수용하면서도 기업을 대표하는 역할을 해내야 한다는 점이다.    백로그(Backlog) 조직 구성원이라면 누구나 기업의 니즈를 이해해야 한다. 프론트라인 관리자가 기업을 대표하는 역할이라고 생각할지도 모른다. 하지만 프론트라인 관리자만 ‘그런 사고방식’을 가져서는 안 된다. 엔지니어의 임무는 단순히 코드 작성이 아니다. 바로 기업의 니즈 해결이다. 2019 데브옵스 현황(State of DevOps) 보고서에 따르면 소프트웨어를 잘 전달하는 조직은 목표를 달성할 가능성이 2배 이상 높다.  즉 기업의 니즈에 부응하고자 하는 사고방식이 조직 전반에 스며들어 있어야 한다. 그러나 만약 비즈니스 요구가 많다면? 해야 할 일이 많다면? 무엇부터 먼저 해야 하는지 어떻게 알 수 있을까?  애자일 소프트웨어 개발을 하고 있는 팀이라면 그 해답은 백로그에서 찾을 수 있다. ‘백로그’란 한 팀이 일정 기간 또는 일정 시간 안에 해야 할 모든 업무를 작성한 문서이다. 이를테면 업무 개선 아이디어부터 제품 개발 관련 업무, 회고, 학습 리뷰, 사후 분석까지 모두 백로그에 들어간다. 이로 인해 백로그가 엄청나게 길어질 수 있다. 그렇다면 어떻게 해야 할까? 포기(Give up) 여기서의 ‘포기’는 두 손 들고 패배를 선언하면서 물러나라는 뜻이 아니다. 백로그 내의 모든 업무를 완수하겠다는 생각을 팀 차원에서 포기해야 한다는 뜻이다. 모든 아이디어, 모든 프로젝트가 백로그에 포함되기 마련이다. 그러나 우선순위를 비롯해 기술, 계획은 모두 변화한다. 무한한 자원과 시간이 있지 않는 한, 결코 백로그에 있는 모든 업무를 완료할 수 없다. 즉 첫 번째 단계는 모든 업무를 해내겠다는 생각을...

2020.07.07

칼럼 | 업무를 계획하라, 계획대로 업무하라

바쁘기만 해서는 안 된다. 제대로 일하는 것이 중요하다. 해야 할 일을 신중하게 선택함으로써 보다 생산적일 수 있다.  일화 하나로 이야기를 시작해본다. 막 한 회사를 인수했고 나는 피인수 기업의 기술직 직원들에게 나를 소개하던 중이었다. 나는 그 아키텍쳐가 어떻게 설계되었는지, 그들의 작업흐름이 어떤 모습이었는지 등에 대해 온갖 질문을 하고 있었다.  당시 나는 그들의 대기 순환 근무 현황이 끔찍한 수준이라는 사실을 발견했다.  “인프라의 안정성을 향상시키는 노력을 하는 것이 어떠한가?”라고 묻자 “그러기에는 너무 바쁘다”는 반응이 나왔다. 너무 바빠서 영원히 같은 날을 반복하는 것처럼 산다는 말일까? 귀를 의심하지 않을 수가 없었다.  애석하게도 많은 조직에서 해야 할 일을 선택하는 방법은 앞에 놓인 업무를 해치우는 형태로 이뤄진다. 그렇게 함으로써 우리는 매우 바쁘게 지낼 수 있고, 결국에는 퍼진다. 그러나 성취감은 거의 없다. 왜냐하면 그런 상황에서 실제로 생산적인 경우는 거의 없기 때문이다.   생산성 2019 데브옵스 현황 보고서(State of DevOps Report)는 생산성을 “...최소한의 산만함과 방해로 시간이 소모되고 복잡한 작업을 완료할 수 있는 능력”으로 정의한다. 이 정의에 따르면, 생산적이기 위해서는 충족되어야 하는 몇몇 조건들이 있다. - 시간 블록 (우왕좌왕하는 15분이 아님) - 최소한의 산만함  - 복잡한 작업  피터 드러커는 1967년 자기경영노트(The Effective Executive)에서 “그저 바쁜 것에서 성과를 거두는 것으로 바꿀수록, 지속적인 노력(결실을 맺기 위한 꽤 많은 시간이 필요한 노력)에 집중할 수 있게 될 것이다”라고 적었다. 앞서의 인수 사례로 돌아가보자. 이들 조건 중 어느 것도 충족되지 못하는 상황이다. 그 팀은 끊임없이 호출되고 있었는데, 이는 곧 집중적으로 일할 수 있는 시간 블록이 없다는 것을 의미했다. 호출...

애자일 생산성 백로그 업무 계획 업무 관리

2019.11.25

바쁘기만 해서는 안 된다. 제대로 일하는 것이 중요하다. 해야 할 일을 신중하게 선택함으로써 보다 생산적일 수 있다.  일화 하나로 이야기를 시작해본다. 막 한 회사를 인수했고 나는 피인수 기업의 기술직 직원들에게 나를 소개하던 중이었다. 나는 그 아키텍쳐가 어떻게 설계되었는지, 그들의 작업흐름이 어떤 모습이었는지 등에 대해 온갖 질문을 하고 있었다.  당시 나는 그들의 대기 순환 근무 현황이 끔찍한 수준이라는 사실을 발견했다.  “인프라의 안정성을 향상시키는 노력을 하는 것이 어떠한가?”라고 묻자 “그러기에는 너무 바쁘다”는 반응이 나왔다. 너무 바빠서 영원히 같은 날을 반복하는 것처럼 산다는 말일까? 귀를 의심하지 않을 수가 없었다.  애석하게도 많은 조직에서 해야 할 일을 선택하는 방법은 앞에 놓인 업무를 해치우는 형태로 이뤄진다. 그렇게 함으로써 우리는 매우 바쁘게 지낼 수 있고, 결국에는 퍼진다. 그러나 성취감은 거의 없다. 왜냐하면 그런 상황에서 실제로 생산적인 경우는 거의 없기 때문이다.   생산성 2019 데브옵스 현황 보고서(State of DevOps Report)는 생산성을 “...최소한의 산만함과 방해로 시간이 소모되고 복잡한 작업을 완료할 수 있는 능력”으로 정의한다. 이 정의에 따르면, 생산적이기 위해서는 충족되어야 하는 몇몇 조건들이 있다. - 시간 블록 (우왕좌왕하는 15분이 아님) - 최소한의 산만함  - 복잡한 작업  피터 드러커는 1967년 자기경영노트(The Effective Executive)에서 “그저 바쁜 것에서 성과를 거두는 것으로 바꿀수록, 지속적인 노력(결실을 맺기 위한 꽤 많은 시간이 필요한 노력)에 집중할 수 있게 될 것이다”라고 적었다. 앞서의 인수 사례로 돌아가보자. 이들 조건 중 어느 것도 충족되지 못하는 상황이다. 그 팀은 끊임없이 호출되고 있었는데, 이는 곧 집중적으로 일할 수 있는 시간 블록이 없다는 것을 의미했다. 호출...

2019.11.25

쌓여가는 백로그 때문에 앱 개발 지체 <아웃시스템 조사>

IT부서가 디지털 변혁과 애플리케이션 개발에서 쌓여가는 백로그 때문에 오히려 개발이 지체되는 것으로 조사됐다. 미국의 아웃시스템(OutSystems)의 ‘2018 애플리케이션 개발 현황’ 보고서에 따르면 가 앱 개발 백로그 때문에 병목이 발생하며, 조사에 응한 IT임원 3,500명 가운데 2/3가 이 문제를 지적했다.   설상가상으로 2018년의 앱 개발 수요가 증가하고 있다. 응답자 42%는 올해 10개 이상의 앱을 구축할 계획이라고 말했으며, 21%는 올해 25개 이상의 앱을 구축할 계획이라고 밝혔다. 앱 개발 시간도 쟁점이 됐다. 응답자의 47%는 웹 애플리케이션이나 모바일 앱을 구축하는데 평균 5개월 이상이 걸린다고 말했다. 아웃시스템 CMO인 스티브 로터는 "우리의 2018년 연구 결과에서 명확하게 보여준 결과는 IT부서가 디지털 변혁과 애플리케이션 개발에서 위기 상황에 봉착했다는 점이다"고 설명했다. 로터는 "디지털 변혁 프로젝트의 실패율이 높고, 프로젝트 백로그가 증가하며, 개발자가 부족한 것이 가장 시급하게 해결해야 할 문제다"고 이야기했다. 한편, 이 연구는 소프트웨어를 신속하게 설계하고 개발하는 방법인 '로우 코드(low code)'가 초기 얼리 어답터를 위한 것이 아니라 주류가 되고 있음을 발견했다. --------------------------------------------------------------- 애자일 프로젝트 인기기사 ->애자일 프로젝트 관리 A to Z -> '실패다!' 애자일 프로젝트의 위험 신호 40가지 ->칼럼 | 포커에서 배우는 애자일 프로젝트 교훈 -> [기고] ‘변화 관리’에의 애자일 방법론 접목 -> 'FAQ로 알아보는' 애자일 입문 가이드 -> 애자일 실패를 초래하는 7가...

CIO 백로그 아웃시스템 얼리 어답터 디지털 변혁 웹 앱 CMO 모바일 앱 조사 로우 코드

2018.06.21

IT부서가 디지털 변혁과 애플리케이션 개발에서 쌓여가는 백로그 때문에 오히려 개발이 지체되는 것으로 조사됐다. 미국의 아웃시스템(OutSystems)의 ‘2018 애플리케이션 개발 현황’ 보고서에 따르면 가 앱 개발 백로그 때문에 병목이 발생하며, 조사에 응한 IT임원 3,500명 가운데 2/3가 이 문제를 지적했다.   설상가상으로 2018년의 앱 개발 수요가 증가하고 있다. 응답자 42%는 올해 10개 이상의 앱을 구축할 계획이라고 말했으며, 21%는 올해 25개 이상의 앱을 구축할 계획이라고 밝혔다. 앱 개발 시간도 쟁점이 됐다. 응답자의 47%는 웹 애플리케이션이나 모바일 앱을 구축하는데 평균 5개월 이상이 걸린다고 말했다. 아웃시스템 CMO인 스티브 로터는 "우리의 2018년 연구 결과에서 명확하게 보여준 결과는 IT부서가 디지털 변혁과 애플리케이션 개발에서 위기 상황에 봉착했다는 점이다"고 설명했다. 로터는 "디지털 변혁 프로젝트의 실패율이 높고, 프로젝트 백로그가 증가하며, 개발자가 부족한 것이 가장 시급하게 해결해야 할 문제다"고 이야기했다. 한편, 이 연구는 소프트웨어를 신속하게 설계하고 개발하는 방법인 '로우 코드(low code)'가 초기 얼리 어답터를 위한 것이 아니라 주류가 되고 있음을 발견했다. --------------------------------------------------------------- 애자일 프로젝트 인기기사 ->애자일 프로젝트 관리 A to Z -> '실패다!' 애자일 프로젝트의 위험 신호 40가지 ->칼럼 | 포커에서 배우는 애자일 프로젝트 교훈 -> [기고] ‘변화 관리’에의 애자일 방법론 접목 -> 'FAQ로 알아보는' 애자일 입문 가이드 -> 애자일 실패를 초래하는 7가...

2018.06.21

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.5.0.5