[꼬까의 책읽기 1+1]예측가능한 프로젝트를 갈구한다

VS

개발자에게 애자일 방법론은 복음이다. 
쓰지도 않을 바보같은 문서는 만들지도 말지어다 열마디 뜬구름잡는 설계보다 동작하는 코드가 백번낫다 동작하는 코드가 멋이 없다거나 심지어 에러가 나도 상관없다. 빠르게 릴리즈가 되기만 하면 된다
사람들은 듣고싶은 내용만 듣는(기억하는) 경향이 있다. 애자일이 딱 그 경우다. 스크럼을 읽어보자. 애자일은 아주 긴장감높은 방법론이라는 것을 알게될것이다. 스크럼은 애자일의 한가지 방법론이다. 팀원들의 상하관계없는 동등한 입장에서의 협력을 나타나기 위해 스크럼이라는 단어를 사용했으리라 본다.
먼저, 요구사항 리스트에 해당하는 백로그를 만든다. 프로덕트 매니저가 백로그에 우선순위를 매긴다 두번째, 개발팀(스크럼)이 30일에 릴리즈 가능할만큼의 백로그를 가져와서 스프린트 계획을 짠다(sprint라는 영어단어를 찾아보면 전력질주로 나온다) 세번째, 팀원들은 매일매일 스크럼회의라는 것을 한다. 어제한일/오늘할일/장애요소 이렇게 3가지를 말하는데, 이메일이나 팩스등의 간접적인 방식은 거부된다. 원격이라도 전화의 스피커폰으로 스크럼회의를 한다.
왜 이렇게할까? 그건 팀이건 팀외부건, ceo건 cto건 그 누구도 이 프로젝트를 관리할 수 없기 때문에 프로젝트의 완성도를 유보하고 빠른 릴리즈를 선택했기 때문이다. 이 릴리즈는 스프린트라는 이름으로 30일인것으로 나오지만 팀원들이 스프린트에 익숙해지면 더 짧아지게 된다. 팀이 어디까지 할수 있나를 보는것이다. 게다가 모든 팀원은 매일 1일보고를 하게된다. 이것 또한 결국 프로젝트의 위험관리를 매일한다는 의미이다. 스크럼회의의 목적은 스크럼의 장애요소를 매일 즉각 제거하는 것이 목적인것이다. 
따라서 애자일이 개발자들이 믿고 싶은대로 개발자들의 천국은 아닌것이다. 결국 프로젝트 관리의 한 형태이다. 하지만 개발자들이 고통받고 있는 지점이 바로 잘못된(관료적) 프로젝트의 관리 때문이기에 개발자들은 애자일을 환영해야 한다. 애자일을 제대로 보자는 것이다.
여기서 애자일에 접근할때 주의해야 할 한가지 큰 특징을 알아야 한다. 그건 고수들의 세계에 가깝다는 것이다. 쓰맛단맛 육해공에서 다 싸워본 배테랑들에게 더 친화적인 방법론이다. 애자일에서 쓰는 용어만 보더라도 이들의 내공을 알수 있을것이다. 
우리나라의 보통의 개발자들에게 어울리는 프로젝트 관리책은 [아키텍트 이야기]일 것이다. 물론 이책은 프로젝트 관리론을 전면에 내세우는 책은 아니다. 아키텍트의 책임과 역할에 포커스가 맞춰져 있다. 하지만 아키텍트가 프로젝트를 리딩하는 역할을 할 수 밖에 없기 때문에 자연스럽게 프로젝트 방법론과 연결되어 있다. 게다가 이책은 우리날의 대부분의 개발자들이 친숙하게 알고 있는 (또는 그동안 경험한) 폭포수 방법론에 입각해서 쓰여져 있다. 
폭포수 방법론이 낡았다고? 물론 제조업에서 쓰이는 방법론을 소프트웨어에 이식했다는 태생의 한계와 비판은 있을 수 있다. 하지만 프로젝트를 완료하기 위해서 해야할 대부분의 내용을 알고 있을때 쓸수 있는 가장 효율적인 방법이다. 예를 들자면 한번이라도 비슷한 프로젝트를 해봐서 프로젝트의 각 단계별로 어떤 일을 해야 할지 알고 있다면 폭포수 모델을 사용해서 프로젝트를 단번에 끝내야 한다. 그렇치 않다면 프로젝트의 완료까지 몇개의 거점을 미리 계획한다음에 각 거점을 1달의 한번씩 거치면서 프로젝트의 현재위치와 방향을 그때 그때 조정하는 애자일 방법론을 써야 한다.