Program

SI 에서 애자일은 왜 실패하는가?

Hue Kim 2017. 1. 23. 00:27

얼마전  왜 “애자일”, 특히 스크럼이 끔찍한가 - Michael O. Church 을 보고 국내 회사에서 애자일에 대한 도입 시도가 늘고 있고 

그에 대한 성공 사례보다는 실패사례가 더 자주 보게 되는 것 같다.


 실무에서 애자일을 도입해본 경험이 있는데 유통회사 SI 프로젝트를 할때 고객사에서 애자일 방식으로 프로젝트를 진행 하겠다고 한 경우가 있었다. 결론 부터 얘기하면 그 프로젝트는 애자일과 전혀 무관한 프로젝트였다. 고객사에서 애자일을 도입하려고 했던 이유는 아무때나 기획서를 수정하기 위함 이었고 그들은 애자일 선언문이 존재하는지 어떻게 해야되는지도 관심이 없었을 뿐이다. 


Michael O. Church이 지적한 사업부 주도의 애자일은 시작하는 첫 단추부터 잘못되기 아주 쉽다. 기본적으로 한국에 있는 SI 구조에서는 더더욱 성공사례를 찾기 힘들다. 그 이유는 기존에 프로젝트가 시작되는 구조를 보면서 이해할 수 있다.



- 국내 SI 프로젝트 Flow





대부분의 국내 SI 프로젝트는 이런 단계를 거쳐서 프로젝트가 진행이 되는데 Scrum과 비교해보면 



- Scrum Flow

원본 link : https://upload.wikimedia.org/wikipedia/commons/4/43/Scrum_Flow_for_one_Sprint.png


많이 다르다는 걸 알 수 있다. 


Scrum에서는 Sprint와 Backlog 를 개발자들이 정해야 한다. 그렇게 때문에 개발기간에 대한 조율과 산정에 개발자의 의견이 반영되기 쉽고 Task의 중요도에 따라서 Sprint backlog에 있던 task가 다음 Sprint 로 넘어가거나 우서순위 조정에 따라서 다시 product backlog로 갈 수도 있다.


반면에 SI 프로젝트는 RFP,요구사항 정의서를 만든 사람이 프로젝트에 투입되지 않는 경우도 있다. 심지어는 외부 프리랜서가 제안서만 통과되면 그 제안서 규모에 따라서 페이를 받는 경우도 있으니 기간안에 구현가능한지에 대한 여부보다 프로젝트를 수주하는데만 급급한 경우가 많다. 초기에 SI 회사를 다닐때 같은 회사 PL조차 "프로젝트 수주해왔으면 어떻게든 만들어야되는게 SI다" 라고 얘기할 정도니 한국 SI의 현주소를 알 수 있는 말이지 않나 싶다.


SI 프로젝트는 프로젝트의 완료 여부를 RFP에 명시된 요건들이 구현이 되는지 안되는지에 따라서 완료여부를 판단하는데 

언제나 RFP < 실제 개발된 기능이 많다. RFP에 명시되지도 않고 초기 기획단계에서 언급도 안되었던 기능이 프로젝트 종료시점에서 구현이 되어있는 경우가 부지기수다. 


일차적인 문제는 요구사항은 매우 애매할 수 밖에 없다. 완벽한 요구사항을 정리해서 완벽한 기획과 완벽한 WBS가 만들어져서 기획과 WBS 개발, Test, deploy가 되는 경우는 없다. 그리고 기대도 해선 안된다. 만약 그게 가능했다면 애자일 또한 나오지 않았을 것이다.


SI가 실패하는 / 야근이 많은 / 애자일이 성공하기 어려운 이유에 대해서 정리해보면


근본적인 문제


    1. RFP는 명확할 수 없다. 하지만 RFP대로 해야만 프로젝트가 종료된다.
    2. 요구사항은 언제나 변경되기 마련이다. 빠지는 요구사항은 없다. 늘 추가될뿐.
    3. TEST(통합테스트) 기간에도 기획서는 수정되고 수정되는 사항은 다시 개발해야되지만 그 모든건 TEST기간안에 처리되어야 한다.
    4. 발주사에서도 어떻게 해야되는지 알지 못한다.(늘 수정되고 기능구현이 되어도 맞는지 판단할 수 없음)


실제적인 문제


    1. RFP 만든 사람이 개발하지 않는다.
    2. 심지어 RFP만든 사람이 개발에 대한 이해가 없을 수도 있다.
    3. 개발자들이 기획단계에서 참여하는 곳이 드물다. 

근본적으로 Top-Down방식으로 진행되는 사업주도 개발은 애자일과 맞지 않고 성공하기 힘듭니다. 

또한 그런 분위기에서 계속 일하고 싶은 개발자도 없을 거라고 생각합니다. End Date만 있고 자유가 없는 개발팀을 좋아하는 개발자는 없을테니까요. 


한국에서 일하는 개발자의 70%가 SI업종에 종사한다는 기사를 봤을때 이런 프로세스를 경험하신 분들 또한 적지 않을 것이라고 생각합니다.


자유롭게 일할 수 있는 당당하게 Refactoring 해야하고 컨퍼런스,세미나 가겠다고 하는 개발자가 많아 지기를 기대합니다.





Next : SI 개발자와 스타트업(서비스 개발자)의 차이

저작자표시