주변에서 애자일을 도입해서 실패한 사례를 자주 접한다.
그리고 힘들었던 사람들도 많이 봤고... 일정 부분 겪는 부분도 있다.
고객들의 잘못된 받아들임으로 인해서 고생하는 SI 프로젝트의 사람들도 봤다.
그런데.... 그게 애자일을 잘못 받아들인 문제일까? 라는 생각을 해 보았다.
방법론의 문제일까?
애자일이 애초에 시작한 배경이 무엇일까를 생각해보면 답이 나온다.
수많은 프로세스에 따른 결과물. 그 결과물을 작성하기 위한 공정. 실제 프로젝트에 필요한 것이 무엇일까에 대한 고민.
이런 것들로부터 도출된 것이 애자일 프로세스이다.
그런데 ... 이런 프로세스를 공부한 사람들조차 도입할때는 프로세스만 도입한다.
그리고 명목을 입힌다.
그렇게 되면 무엇이 문제가 될까?
당연히 ... 형식만 입히게 되겠지.
일단 애자일 프로세스는 기존의 프로세스의 문제점에서 출발한 프로세스이다. 라고 생각하고 있다.
또한, 그런 부분들을 해소하기 위해서 인간의 본성에 기초한 시도들을 한다.
그리고, 여러가지 실천법들을 강조한다.
일반적인 조직에서 , 특히 SI 조직에서 도입하는 부분은 이 실천법들만 도입한다.
실천법들을 위한 인간 본성에의 접근은 고려하지 않은채...
예전 프로젝트 프로세스 에서 관리자들은 그냥 관리만 하면 되었다.
그리고 역할 분리가 명확했다.
애자일. 이놈을 기준으로 팀이 활동하기 시작하면... 역할이 불분명해지기 일쑤이다.
그리고 그것을 더 권장을 한다.
기존의 프로세스에 익숙해 있는 우리들로써는 힘들기 마련이다.
그래서 중요해지는 사람들이 중간에서 전파하고 연결해 줄수 있는 사람들이다.
아직 더 경험해 봐야겠지만, 우리나라 개발 사회에서 애자일을 잘못 받아들여도 한참 잘못 받아들였다는 생각을 한다.
정책/전략 적인 결정에서 시작해서 bottom-up 으로 갈 수 있는 조건들이 되었어야 하는데...
그냥 top-down 으로 갔다.
그리고 이터레이션만 졸라 돌린다.
그리고 매 이터레이션 끝마다 개발자들은 기존의 개념인 '오픈' 을 경험하게 된다.
그렇게 되면...
개발자들은 '아...이 놈의 애자일이 사람 죽이네..' 라고 생각하게 되고 '고객만 좋은 일이구만' 이라고 생각한다.
아... 얼마나 ... 안타깝냐...
애초에 출발점은 이게 아닌 것을...
출발은... 개발자가 행복하기 위한 방법론이었다.... 고객에게 지속적으로 보여줌으로 인해서 의사소통 충돌 없이.. 개발자도 행복하고 고객도 행복한... 그런 프로세스였단 말이다.
그런데... 왜 이렇게 왜곡이 되었을까?
우리가 고민해야 할 부분이다.
솔루션이라고 생각되는 부분은 솔직히 없다.
아직은 공부하는 입장이라...
'개발의 즐거움' 카테고리의 다른 글
[책정리]읽기 좋은 코드가 좋은 코드다 (0) | 2012.07.14 |
---|---|
computer driven communication (?) (1) | 2012.07.10 |
전역상태와 public 메타포 - junitInAction2 에서 (0) | 2012.03.13 |
맥에서 파이썬 입문하기-3 (0) | 2011.12.10 |
프로젝트는 쉬운게 없다. (1) | 2011.12.10 |