SI에서 스크럼을 적용하기 어려운 이유
SI에서의 애자일 적용기 #1
6년전 애자일 스크럼을 처음 접했을 때 큰 충격을 받았다. 이 방법대로라면 당시 개발하면서 어려움을 겪었던 많은 문제들이 해소될 것 같았다. 한동안 프로젝트에 스크럼을 도입하기 위해 어떻게 해야 하는지 알기 위해 스크럼 관련 내용들을 열심히 찾아 보고 책도 읽었다. 하지만 알면 알수록 스크럼은 SI 프로젝트에 적용하기 어려운 방법론이었다. 그 이유는 다음과 같이 위키피디아에서 스크럼의 limitation이라고 설명하는 부분들 때문이었다.
파트 타임으로 일하는 사람이 많은 프로젝트는 스크럼이 덜 적합하다.
(Projects with many part-timers are less suitable for the scrum approach.)
SI 프로젝트에서는 Full-time으로 프로젝트에 참여하는 개발자가 많지 않다. 스크럼에서는 스프린트 기간 동안 모든 개발자들이 함께 집중하여 힘을 모아 목표를 달성하기 위해 노력해야 한다. 하지만 파트 타임으로 일하는 사람이 많다면 이런 힘이 분산된다. 예를 들어 스프린트 진행하는 동안 개발자들이 참여하고 있는 다른 프로젝트에서 납품을 해야 한다면 스프린트 작업보다는 납품을 위한 작업을 더 높은 우선 순위로 수행할 것이다. 개발자들이 Full-time으로 프로젝트를 참여하지 않는다면 다른 프로젝트의 상황에 영향을 받을 수 밖에 없고 스프린트를 제대로 종료하기 쉽지 않다. 그런데 SI 프로젝트 개발자들은 보통 동시에 2~3개의 프로젝트를 수행한다. SI 프로젝트는 기본적으로 프로젝트 완료 시 고객으로부터 얼마의 금액을 받을 지 결정되어 있다. 이는 개발자의 단가를 바탕으로 계산되는데 대부분의 회사에서는 개발자의 단가가 실제 급여보다 낮다. 따라서 회사에서 개발자에게 급여를 지불하기 위해서는 개발자가 여러 프로젝트에 참여할 수 밖에 없다. 이런 상황에서 스크럼을 적용하기는 쉽지 않다.
때때로 프로젝트를 짧은 스프린트들로 나누려면 신중한 계획이 필요하다. 다른 프로젝트로부터 소프트웨어를 전달받는 일과 같은 외부에 의존적인 부분이 스프린트 계획을 망칠 수 있다. 그러므로 스크럼은 외부에 크게 의존적인 프로젝트는 덜 적합하다.(Dividing a project into different short sprints sometimes requires careful planning. External dependencies, such as deliveries of software from other projects, can mess up the planning of individual sprints. Therefore the scrum approach is less suitable for projects with many external dependencies.)
그렇다. 사실 가장 큰 문제는 외부 의존성이다. SI 프로젝트가 어떤 프로젝트인가? 고객에 대한 의존성이 극대화 된 프로젝트가 아니던가? 고객이 이걸 먼저하라고 하면 그걸 먼저해야 하고 고객이 결정해줘야 하는 사항을 결정해 주지 않으면 해당 부분은 진행이 되지 않는... 이것이 바로 SI다. 스프린트를 하다가도 고객이 뭔가를 먼저 해달라는 요청을 하면 먼저 해당 작업을 진행해야 하지만 스크럼에서는 스프린트 시작할 때 스프린트 백로그를 결정하고 나면 스프린트가 끝나기 전까지 새로운 백로그를 추가하지 말 것을 권장한다. 한주에도 고객의 요청이 수십개씩 날아온다. 게다가 고객이 결정해 주어야 하는 사항들은 요청해도 묵묵부답이다. 도대체 언제 답변을 받을 수 있을지 알 수가 없어 답답하기만 하다. 새로운 작업 추가 없이 스프린트에 집중하여 끝내기엔 너무 가혹한 환경이다.
개발자들은 팀내의 다른 개발자들의 작업을 넘겨 받거나 그 작업에 대한 일을 해야 한다. 그러므로 서로 다른 전문적인 기술을 가진 개발자들로 구성된 프로젝트는 스크럼이 덜 적합하다.(Developers should be able to take over tasks and to work on tasks of other developers in the team. Therefore projects with developers with different and very specialized skills are less suitable for the scrum approach.)
필자가 수행하는 프로젝트가 조금 독특한 것일 수도 있지만 프로젝트 구성원에 전문가들이 포함되어 있다. 예를들어 프로젝트 구성원이 개발자 2명, 비행역학 전문가 1명, 영상 처리 전문가 1명 이런 식이다. 스크럼에서는 스프린트 백로그 목록에서 개발자들이 자기가 할 일을 선택하여 진행하는 방법을 권장한다. 하지만 비행역학, 영상 처리에 관련된 작업을 다른 개발자들이 가져다가 할 수는 없다. 애초에 스프린트 계획 회의에서 함께 모여 스프린트에서 진행할 백로그를 선택할 이유가 별로 없다. 비행역학 전문가는 본인에게 주어진 작업들을 스스로 선택하면 그만이다. 이런 상황에서 스크럼은 큰 의미가 없어 보인다.
필자는 이런 이유들로 SI에 스크럼을 적용할 수 없겠다는 결론을 내렸다. 한동안 누가 물어도 SI에서는 힘들다고 얘기하곤 했다. 하지만 뭔가 찜찜한 느낌은 계속 남아 있었다. 너무 좋은 도구를 앞에 두고도 쓰지 못하는 느낌이랄까? 결국 1년전 필자는 프로젝트에 스크럼을 적용해 보기로 결심했다.
