첫 번째 비밀: 계획하기
정재용 | 애자일 코치 | AGIN
첫 번째 비밀: 계획하기
애자일은 기존의 방법론과 많은 차이가 있다고 막연하게 생각한다. 그러다 보니 전통적인 개발 방법론에 익숙한 사람들은 애자일에 거부감이 들게 마련이다. 특히 프로젝트를 수행하는 입장에서는 초반에 요구사항이 확정되고 그 확정된 내용을 기준으로 개발을 시작해야 한다는 생각에 요구사항을 확정하지 않고 프로젝트를 수행하는 애자일 방법은 당연히 이해가 안 될 수밖에 없다.
하지만 필자는 애자일에 성공할 수밖에 없는 첫 번째 이유로 ‘계획하기’를 꼽고 싶다. 전통적인 방법에서 요구사항을 확정하는 활동의 주체를 한번 생각해 보자. 고객 담당자와 프로젝트 PM 또는 PL 정도가 참여하여 프로젝트 요구사항을 정의하고 확정한다. 하지만 간과하고 있는 것은 누가 실행을 하는가에 있다. 요구사항을 구체화하고 구현하는 것은 개발자들이 하게 되는데, 일부 소수 정예요원이 모여서 정한 요구사항이 얼마나 명확하게 개발자에게 전달될 수 있을까?
요구사항 정의가 완료되고 분석, 설계를 하는 단계에서도 개발 조직의 스킬 셋이나 역량이 고려되지 않고 분석과 설계가 진행 된다. 적정 수준 이상의 개발팀이 구성된다면 문제가 덜 하겠지만 비용이 민감한 프로젝트의 실정을 고려할 때 현실은 불편함 투성이다. 애자일은 초기에 기존의 요구사항이라 불리는 것을 개발팀과 고객이 한자리에 모여서 분석한다. 고객의 의도가 무엇이며, 어떤 결과를 기대하는지를 함께 모여서 분석하는 것이다. 단순히 요건을 분석하는 것에서 끝나는 것이 아니라 기술적 어려움이나 문제점들이 논의되고 또는 더 좋은 방안이 제시되기도 하는 것이다.
개발자의 계획 단계 참여는 동기부여를 하는 역할도 하게 된다. 기존의 방식에서 개발자들은 대부분 시키는 일을 하고 PM이 전체 일정 및 업무 지시를 해서 작업 일정을 조절하는 역할을 했다. 하지만 애자일에서는 PM이 없다. 개발자들이 스스로 일정을 조절하고 작업을 정의한다. 시키는 일을 하는 것이 아니라 내가 할 일을 스스로 찾아서 하는 것이다. 계획 단계에 참여해서 팀이 해야 할 일과 고객이 원하는 것을 개발자 모두가 인식하고, 그 목표를 향해 함께 달리는 것이다. 그러다 보니 자연적으로 동기부여되게 되는 것이다. 개발을 하면서 지속적으로 더 좋은 방안을 찾고 고민하고 협의하는 과정도 수반되게 된다. 이런 과정들이 자연스럽게 반복되면서 더 좋은 품질의 제품이 만들어질 수 있다.
전통적인 방법을 고수하려는 사람들에게 애자일 방법에서 개발 요건을 개발자들이 참석해서 정의하는 과정(애자일에서는 백로그 정의라고 한다.)을 초반부터 많은 인력이 투입되는 것에 대해 불편하게 생각할 수도 있을 듯하다. 시간적으로 필요한 인력만 투입해서 요구사항을 정의하고, 분석과 설계를 하는 과정에 비하면 인력 낭비라는 생각을 할 수도 있을 듯하다. 틀린 이야기는 아니지만, 효과성 측면에서 본다면 개발자들이 계획 단계부터 참여하는 것이 득이 될 수도 있다. 개발자들이 정확한 고객의 요구를 이해하고, 빠르게 피드백하면서 개발하는 과정을 반복적으로 수행하는 애자일은 품질의 적정선을 유지할 수 있기 때문이고, 고객이 원하는 결과를 만들어 낼 수 있기 때문이다. 아래 그림에서 보듯이 애자일은 짧은 주기로 피드백을 통해 일정한 가시성을 확보할 수 있으며, 고객이 원하는 제품을 지속적으로 협업을 통해 리스크를 줄일 수 있고, 고객이 원하는 제품 및 서비스를 제공할 수 있게 되는 것이다.
또한 우리가 일반적으로 프로젝트 막바지에 일정 수준의 품질이 나오지 않고 변덕스러운 고객의 요구에 맞지 않는 시스템 때문에 개발자들은 날밤을 세우며 번아웃되는 일이 줄어들 것이다. 아래 그림에서 보듯이 애자일은 프로젝트 막바지에도 일정 수준의 업무 피로도를 유지할 수 있다는 장점이 있다. 프로젝트 초반에 개발자들이 참여해서 계획하는 일은 제품의 품질을 높이고, 고객의 만족을 이끌어 낼 수 있으며, 개발자의 피로도도 낮출 수 있는 비법이다.
즉, 애자일을 잘하면 프로젝트가 성공할 수밖에 없는 첫 번째 비밀은 ‘계획하기’인 것이다.
다음 회차에는 두 번째 비밀을 공개해 보도록 하겠다.