애자일과 PM
Sunday, June 14th, 2009인사이트에서 보내주신 ‘스크럼과 XP‘를 읽었습니다.이 책의 원래 제목인, ‘Scrum and XP from the Trenches’에서 알 수 있듯이, 현장에서 스크럼을 적용하면서 경험담을 정리한 책이죠. 스크럼의 기본 내용에서 크게 벗어나지 않지만, 아직 스크럼을 업무에 적용해 보지 못한 분에게 스크럼을 적용한다면 이런 점을 신경써야 한다는 것을 알려주고, 스크럼을 현업에 적용했지만 그렇게 성공적이지 않으셨던 분들에게 개선책의 힌트를 줍니다.
분량도 그렇게 많지 않고, 번역도 잘되어서 읽는 데 큰 부담이 없었습니다. 다만 경험담 위주로 이야기를 전개하기 때문에, 애자일의 기본원리나 실천방법을 접해 보지 못한 분들은 조금 어럽게 느끼실 수도 있죠(스크럼을 처음 접하시는 분들은, 부록으로 수록된 스크럼 입문을 먼저 읽어보시는 게 좋습니다).
이 책을 읽으면서 이런 생각이 들었습니다. 스크럼이 좋은 방법인데, SI 프로젝트에서도 적용하면 좋습니다. 그런데 현실을 둘러 보면, 아직도 연속적인 생애주기, 즉 폭포수 방법을 많이들 사용하십니다. 왜 그럴까요?
사실, 이 질문에 해답으로서 몇 가지가 있지만, 전 프로젝트 관리자에게 가장 많은 책임이 있다고 생각합니다. 프로젝트 관리자가 애자일 방법의 효과를 잘 알고, 프로젝트에 적용하려고 노력해도, 설계-개발-테스트의 연속적인 생애주기에 익숙한 팀원을 설득하기란 어려우며. 깔끔한 간트 차트를 제공하지도 않고 완벽한 프로젝트 계획도 세우지 않은 채 프로젝트를 진행하는 것을 고객에게 이해시키기란 끔찍하게 지난하죠.
그래도, 뒤늦게 고객이 요구사항을 바꿔서 연속되는 철야행진을 몇 번씩 경험했거나, 프로젝트 막판에 통합하느라 생고생을 한 프로젝트 관리자라면, 무언가 바꿔야 하고. 이런 문제에 대한 해결책을 찾거나 궁리하다 보면… 애자일 방법이 하나의 대안이 될 수 있습니다. 물론 다른 방식도 있겠지만, 기존 방법에서 발생한 문제를 해결하려는 노력이 흔히 애자일 방법으로 표현되기 때문에, 애자일 방법이 하나의 대안인 셈이죠.
그동안 제가 수행했던 프로젝트를 뒤돌아 보면, 팀원이 프로젝트의 진행방향을 바꾸기보다, 확실히 프로젝트 관리자가 무언가를 바꾸기가 훨씬 쉬웠습니다. 프로젝트 관리자가 하는 관리방식이 문제를 해결하지 못한다면, 당장 프로젝트 현실이 바뀌지 않겠지만, 그런 PM 밑에서 기존 방식을 답습하는 방법을 배우기보다, 먼 미래 PM이 되었을 때 개선할 수 있는 힘을 기르는 게 더 낫겠죠.

