애자일 프로세스 적용 고려
애자일 프로세스의 장점을 프로젝트로 가져오자.
애자일 프로세스를 적용하여 시스템을 개발 시 여러 가지 장점이 있다. 나는 이 글에서 애자일 프로세스에 대한 상세한 내용은 다루지 않고자 한다. 어차피 이 글은 실무자 입장에서 경험상 느낀 점을 적은 것이므로, 애자일에 대한 더 상세한 내용은 개별로 찾아보시길 바란다.
애자일 프로세스 적용 시 내가 느낀 장점은 다음과 같다.
첫째, 프로젝트 초반부터 실제 구현된 결과물을 가지고 고객 요구사항을 받을 수 있기 때문에 상당히 구체적인 요구사항을 수집할 수 있다.
둘째, 이터레이션 과정에서 실제 구현상 문제가 되는 부분들을 도출해내고, 대안을 찾아내거나 방향을 바꿀 수 있기 때문에 잘못된 분석/설계로 인한 실패 위험이 줄어든다.
하지만, 애자일 프로세스는 구축해야 할 목표시스템이 명확하고, 납기가 정해져 있는 프로젝트에 적용하기 어렵다. 각 이터레이션 별로 개발대상 기능들에 대한 개별적인 계획만 세울 뿐, 최종적으로 완성된 모습을 알 수 없다. 또한, 애자일 프로세스는 개발 진행 과정상의 산출물들이 남지 않기 때문에 프로젝트팀이 철수하고 난 이후 별도의 운영조직이 시스템을 운영할 때 문제가 발생한다.
위와 같은 문제점 때문에 수주를 통해 시작되는 대부분의 프로젝트의 경우, 개발 프로세스는 폭포수 기반의 방법론을 사용하게 되고, 반면 전담 개발팀이 있어서 지속적으로 기능을 개선해나가는 제품이나 서비스의 경우에는 애자일 프로세스가 보다 효율적이다.
그러나, 나는 애자일 프로세스의 장점을 프로젝트에 가져와야 한다고 생각하는 편이다. 그 방법은 프로젝트의 전체 범위를 애자일 프로세스로 진행하는 것이 아니라, 일부만 적용하는 것이다. 그 방법은 아래와 같다.
- 전체 개발범위 중 가장 핵심적인 업무 프로세스 하나를 선정하여 능력이 뛰어난 개발자 1명을 배치하고, 그 핵심 업무는 애자일 프로세스를 적용하여 프로젝트 착수시점부터 이터레이션 계획을 세워서 진행한다. 이때 이런 역할을 진행할 개발자는 이것저것 고민해서 차근차근 만들어내는 스타일보다는 조금 덤벙댈 때도 있지만, 빨리빨리 결과물을 만들어내는 스타일이 나은 것 같다. 만일 두 명의 실력 좋은 개발자가 있는데 개발 스타일이 그와 같이 다를 경우에 역할을 나눈다면 나 같으면 차근차근 만들어내는 스타일의 개발자는 전체 프로젝트의 Key-man으로 나머지 전체 개발자들의 품질을 관리하고 역량을 향상시키는 사수 역할을 맡길 것 같다. 어쨌든 애자일스럽게 일할 개발자는 혼자서라도 빨리빨리 결과물을 만들어내야 하기 때문이다.
- 나머지 전체 개발범위에 대해서는 원래의 계획대로 폭포수 방법론을 사용하여 분석-설계-구현 순으로 진행한다.
- 애자일 프로세스로 먼저 개발한 핵심 업무는 구현 단계에서 통합하며, 그 이후로는 별도의 애자일 프로세스는 진행하지 않는다.
이와 같이 핵심 업무 프로세스 한 개를 떼내어 애자일스럽게 먼저 구현부터 시작할 경우, 애자일 프로세스 적용 시의 장점을 프로젝트에 그대로 취할 수 있다. 현업 담당자가 핵심업무의 기능을 화면으로 먼저 확인했기 때문에 설계단계 진행 시 그와 같은 스타일로 전체 화면의 설계를 진행하면 큰 무리가 없다. (예를 들어, 화면 설계 시 검색창이나 검색 결과창의 배치, 각종 버튼의 배치, 상세보기 시 팝업창으로 할지 등)
실제로 그와 같이 진행해보면 패키지 SW 도입 프로젝트(일부 커스터마이징 포함된)나, 프로토타입 방법론과 유사하다고 느낄 수 있을 것이다. 그와 같은 프로세스를 적용하는 것에 대해 어떤 이름을 붙이건 상관없다고 생각한다. 어쨌든 이와 같은 방법을 사용하는 것은 기능 구현상의 불확실성을 사전에 제거하는 것이 목적이기 때문이다.
