프로젝트경영협회에서 “Agile 프로젝트 관리 기법 / PMI Agile 자격증 소개”에 대한 세미나를 마쳤습니다.
최근 소프트웨어(SW) 개발 방식의 하나인 `애자일(Agile) 개발 방식’에 대한 관심이 높아지고 있으며, 2011년 하반기에는 미국 PMI에서도 애자일 자격증이 출시됩니다. 사전적으로 “민첩한, 기민한”의 의미 처럼 애자일기법은 사용자 시나리오 개발, 코딩, 품질 테스트를 단기적으로 한정된 시간 안에 진행하는 하나의 스프린트(Sprint, 단거리 경기)를 구성하여, 이를 순환반복해서 프로젝트를 완성시켜나가는 방법론입니다.
발표 자료 중 중요한 몇가지 요소만 발췌해 봅니다.
우선 범위/일정/비용/품질/인적자원에 대한 기준이 전통적인 방식에서 틀이 깨지고 있습니다.
(1) 61%가 무조건 납기를 맞추는 것이 아닌 사용하기 적합한 시점에 인도되어야 한다는 점,
(2) 87%가 최초 정의된 Spec 보다는 이해당사자의 실제적인 요구사항의 반영이 수시로 적용되어야 한다는 점,
(3) 79%가 예산내 납기가 가닌 ROI 가 도출되어야 한다는 점,
(4) 87%가 일정과 예산에 무조건 맞추는 것 보다는 고품질의 인도물을 받기 원한다는 점,
(5) 75%가 일정과 예산에 맞추는 것보다 육체적/정신적으로 일체감일 이뤄야한다는 점과, 환경이 갖추어진 상태에서 일을 해야한다는 점 이죠.
물론 EVM 기반의 전통적인 대규모 프로젝트에 애자일을 적용할 수 없습니다. 하지만 그 이외의 불확실한 기술을 도입해야하고, 상호 협의되지 않은 요구사항을 수렴해야하는 부분이 큰 복잡한 프로젝트에는 Agile 방식의 기법을 추천합니다.
Agile 경험자 642명으로 효용성을 설문조사 해보니 생산성 증대효과 82% 체험, 품질향상 77% 체험, 고객만족 78% 체험을 느꼈다고 합니다.
이를 수 밖에 없는게 하단의 애자일 흐름도 및 팀원 직접 찹여하고, PM의 서번트 리더쉽/멘토링에 의해 원활히 돌아가며, 매주/매일매일 리뷰와 회고가 이뤄지기 때문에 당연한 결과입니다. (물론 이것을 제대로 수행하기 위해서는 참여 인원들의 애자일 철학 및 방법에 대한 충분한 숙지가 되어있어야 합니다. 그냥 좋다고 도입만 한다면 100이면 100 실패합니다.)
애자일 구성 방법은 어렵지 않습니다. 정말 2-3일 정도만 체험하게 되면 바로 적용할 수 있습니다. 중요한 용어는 WBS에 해당되는 Backlog (유저스토리 혹은 FBS), 마일스톤에 해당하는 Sprint, Monitor/Control에 해당하는 Daily/Weekly 리뷰 및 회고는 프로젝트의 공감 및 리스크/품질은 기본이고, 납기까지 준수할 수 있는 정말 좋은 도구입니다.
이의 실천은 어렵지 않습니다. Spec (혹은 Product Log)가 정해지면 이를 주간 단위로 잘개 쪼개고, 다시 일간 단위로 쪼개는 작업을 한 후, 총 할일을 하나하나 수행하며 제거해 나가는 겁니다. 할일이 100개고, 10주의 시간 산정이 되었다면, 이의 수행하마 하나하나 빼는 거죠. 중요한 것은 PM이 리더쉽을 발휘해서 나홀로 프로젝트를 이끌어가는것이 아닌, 팀원이 직접 참여/발표/회고하게끔 PM이 멘토링을 해야한다는 겁니다”
PMBOK과의 관계가 헛갈릴 수 있는데, 이의 차이점은 명확합니다. PMBOK은 프로젝트 수행 기간동안 무엇을 점검해야하는지에 대해 지침을 내려준 ANSI/미국 표준 프로젝트 지침서라면, Agile/애자일은 이를 수행하기 위해 어떻게/HOWTO를 기술한 Tool & Technique 입니다.
PMI에서도 이러한 애자일 유용성 및 대중적 확대를 인지하고 2011년 3Q 내에 PMI Agile 자격증이라는 이름으로 자격제도를 출시합니다. 이는 3년 이내에 필히 PMP와 더불어 IT프로젝트의 기초 요건 자격증이 될 것이라고 확신합니다.
2시간 밖에 안되는 짧은 시간동안 애자일 철학/구성/기법/PMBOK비교/자격증설명을 하는 것이 쉽진 않았지만, 저의 지식 영역내에서 최대한 전달했다고 생각됩니다.
전 세계에서 유일하게 우리나라만 IT가 저평가 되어있습니다. 이는 남의 탓이 아닌 우리 IT 구성원들의 대충대충/ 결과지향적으로만 일하는 습성 때문인 것 같습니다. 이를 극복하기 위해서는 자신만의 (좀더 확대해서 우리 IT 산업에 맞는) 표준화된 철학과 방법론을 가지고 있어야만 하며, 아직까지는 미국의 PMBOK/AGILE 을 그대로 적용하여 각자 자신의 회사/팀에 맞는 테일러링된 철학/방법론을 내놓아야 한다고 생각합니다. 미국의 Smart Work으로 대중적으로 성공한 37signals 의 Getting Real 및 Rework 철학과 basecamp, highrise, backpack, campfire 관계 처럼요.
발표자료는 공개하고 싶지만, 저도 워낙 인용을 많이해서 부끄럽네요. 댓글로 요청하시면 바로 보내드리도록 하겠습니다.