애자일 방법 이전의 전통적인 소프트웨어 개발 방법들이 좋은 결과를 보이지 못하는 가장 근본적인 원인은 프로젝트를 수행하는 동안에 발생하는 변화에 능동적으로 대처하지 못하기 때문입니다. 

아니 어쩌면, 변화가 발생한다는 것을 인정하지 않기 때문인지도 모르겠습니다. 

우선 폭포수 모델에서는 이전 단계가 끝이 나서 다음 과정으로 넘어가면 절대 이전 단계로 되돌아가지 않습니다. 

즉, 초반부에서의 설계나 프로젝트의 마일스톤이 결정되면, 프로젝트가 끝날때까지 처음 결정한 계획에 묶여있게 되지요. 

하지만, 실제 상황에서는 프로젝트를 하면서, 고객의 요구가 변경되기도 하고, 개발자의 입장에서도 처음 생각했던 것보다 쉽게 문제를 해결할 수 있는 방법을 발견하거나 추가적인 제약조건에 의해서 처음 설계했던 부분에 수정을 가할 수도 있습니다. 

이 프로젝트 진행 과정에서 발생하는 불확실성을 애자일 방법에서는 적극적으로 수용하고, 이것이 애자일 모델의 장점의 근원이 되지요. 

불확실성을 수용하기 위한 첫 단계는 바로, "우리는 알지 못한다" 라는 개발팀의 무지를 인정하는 것에서 시작합니다. 

고객의 요구를 완벽하게 아는 것도 아니고, 도출된 요구사항을 해결하기 위한 완벽한 방법을 아는 것도 아니고, 시스템 디자인을 완벽하게 만들 수 있는 것도 아니라는 것을 인정하고 들어가는 것이지요.

그렇다고, 애자일에서는 시스템의 설계도 없이 일단 코딩부터 시작하는 것은 아닙니다. 

개괄적인 구조만 잡고서, 각 부분에 대한 설계는 그 부분을 구현할 단계, 즉 그 스토리의 이터레이션 과정에서 설계를 하고, 코딩을 하게 됩니다. 

"6개월 뒤에 날씨를 예측할 수는 없어. 하지만, 내일의 날씨라면, 거의 확실하게 예측할 수 있지" 라는 것과 유사하지요. 

그래서, 일을 쪼개고, 쪼갠 부분에 대해서 확인하고 개발하는 작업을 반복하면서 프로젝트를 달성해가게 됩니다. 

이 책은, 이런 애자일 모델 중에서, 추정과 계획하는 부분에 초점을 맞춘 책입니다. 즉 애자일 개발 방법론을 다 설명하는 것은 아니고, 또 애자일 방법이 400여 페이지를 겨우 넘는 이 책한권으로 잘 설명될 수 있는 것도 아닙니다. 

각설하고, 이 책은 불확실한 프로젝트 개발 과정안에서, 프로젝트 초기에 어떻게 프로젝트의 전체 그림을 그릴 것인가에 대한 주제만을 다루고 있습니다. 

저자는 주장하지요. 계획을 세운다는 것은, 프로젝트 초기에 한번 세워놓고 끝까지 지키는 것이 아니라고 말입니다. 

계획은 상황에 따라 달라지고, 프로젝트 진행 중에, 프로젝트의 상황은 끊임없이 변화하기 때문에, 계획 역시 그렇게 변화한 상황에 따라 그 변화를 잘 포용할 수 있도록 계속해서 멈추지 않고 계획을 세워야 한다고 주장합니다. 

그렇다고 프로젝트가 계획만 세우다가 끝이 나서는 안되겠지요. 

이 모순을 해결하기 위해서 애자일 모델은 이런 방법을 제시합니다. 

우선, 스토리를 정리합니다. (기존 요구사항 분석과 비슷한 작업이지만, 유즈케이스를 만드는 것처럼 정해진 문서 형식에 맞춰 작업하는 것이 아니라, 그냥 해야 할 일에 대한 목록을 몇 줄로 기술하는 정도이지요)

그리고, 각 스토리의 작업량을 결정합니다. (이 부분이 핵심인데, 이전에 비슷한 작업을 했었다면, 그것을 토대로 정하고, 그렇지 않다면, 팀원들이 모두 모여서 투표를 통해 정하게 됩니다)

그렇게 스토리 (구현해야 할 기능들에 대한 목록) 과 그 스토리의 작업량이 결정되면, 어느 스토리를 먼저 개발할지를 정하게 됩니다. 

그리고, 짧은 이터레이션 기간 동안, 그 결정된 스토리를 구현합니다. (이 때, 그 스토리에 대한 설계가 들어가는 것이지요)

그렇게 첫 이터레이션이 지나면, 처음 결정한 스토리별 작업량은 적당한지 결정되고, 혹시 그 와중에 변경된 스토리(고객이 요청에 의해)가 있다면, 추가해서 다음 이터레이션 계획을 세우게 됩니다. 

그러나, 무턱대고 스토리를 계속 늘릴 수는 없기 때문에, 매 이터레이션이 들어가기 전에, 우선순위 (리스크는 크지만 중요한 기능, 리스크는 크지만 안중요한 기능, 리스크는 작지만 중요한 기능, 리스크도 작고 중요하지도 않은 기능) 에 따라서 먼저 개발할 것, 나중에 개발할 것을 정하게 됩니다. 

물론 이 과정에서 먼저 개발된 스토리에 따라 다음 이터레이션에서 작업할 스토리에 영향을 미치게 되는 것들이 존재하는데, (즉 패러럴한 관계로 연결되지 않은 스토리의 경우) 그런 스토리들은 전후 관계에 맞춰 적절히 우선순위를 조절합니다. 

또 이 과정에서의 실수가 나오지 않도록 하기 위해, 애자일 모델은 스토리의 개발이 끝나면, 또는 그 과정중에서도 계속해서 전체 빌딩을 수행해서, 나중에 수정된 코드가 기존 코드를 잡아먹는 일이 발생하지 않도록 끊임없이 테스트를 합니다. 

그리고, 이터레이션 과정에서 스토리의 개발 일정에 맞추지 못하게 된 경우, 그 원인을 분석하고 그 대안을 찾습니다. 그리고, 이로 인해 발생하는 전체 프로젝트의 일정 변경이 발생하면, 덜 중요한 스토리를 제거하게 되지요. 

이 책은, 이렇게 동적으로 변화하는 프로젝트 진행 과정에서, 능동적으로 변화를 수용하기 위한 방법으로써, 짦은 단위로 작은 기능을 구현하고 빌드하며, 그 과정에서 발생하는 문제를 쉽게 해결하기 (가령 2주짜리 이터레이션이라면, 혹시 이터레이션이 망처도 2주를 손해본 것으로 끝나기 때문에, 실패에 대한 부담을 줄일 수 있지요)위한 방법으로써, 스토리와 이터레이션의 방법을 제안하고 있습니다. 

모르는 것을 모른다고 하고, 그 무지의 위치에서 부터 앎으로 나아가는 소프트웨어 개발 방법이 애자일 모델의 핵심이었습니다. 

번역도 잘 되어 있고, (이 애자일 시리즈는 특히 번역의 질이 좋은 것 같습니다) 내용도 재미있게 읽을 수 있습니다. 

다만, 이 책 하나로 애자일 모델에 대해 많은 것을 알 수 있기를 기대한다면, 다소 실망할 수는 있을 것 같습니다. 

애자일에 대한 기본 개념 하나를 익힌다고 생각하고 이 책을 접하시면 절대 후회하지 않는 선택이라고 생각합니다. 

PS) 이 책의 제목처럼, 모든 프로젝트는 불확실성으로 점철되어 있습니다. 이 책에서 제시하는 표준 방법이 직접 운용하는 프로젝트에서 제대로 먹히지 않는다고, 애자일 방법을 비난하기 전에, 애자일의 핵심 가치가 올바르게 구현이 되고 있는지 먼저 한번 확인해 보세요. 

표준 방법은 어디까지나 "이렇게 했더니, 이 가치(변화에 대한 적극적 수용)가 잘 표출되더라" 라는 것이지, 그 방법을 따른다고 무조건 그 가치가 100% 드러난다는 보장이 있는 것은 아니니까요. 

  애자일 방법론은 요즘 소프트웨어 개발 분야의 최고 이슈이다.  아직 이슈가 되고 있다는 건 완전하게 정착되지 않았다는 의미이기도 하다.  그러다 보니 모두들 애자일 방법론을 이야기하지만 막상 경험에서 나오는 구체적인 행동 요령을 상세히 설명하는 책은 매우 드물고 있다 하더라도 주로 개발 작업 자체에 치중되어 있고  전체적인 프로세스를 어떻게 계획하여 개발을 진행할 것인가를 논의하는 책은 찾기 힘들다.  기존의 도서들이 채우지 못한 이러한 시장의 요구를 만족시킬 수 있는 책이라고 하기에 부족함이 없는 도서이다.  저자의 충고는 매우 구체적이고 소개된 각 행동요령에 대한 설명 또한 부족함이 없다.  이 책의 핵심이라 할 수 있는 '완벽한 추정이나 계획은 있을 수 없으며 프로젝트의 성공은 프로젝트 수행과정에서 습득한 지식을 해당 프로젝트 내에서 얼마나 잘 반영하는가에 달렸다'는 저자의 시각은 waterfall방식에 익숙한 많은 개발자들에게 shock를 준다.  작업량과 작업시간을 구분해야 한다는 충고는 기존의 Project Management관련 책에서 소홀히 취급되었던 부문이기에매우 유익하다.  스토리점수와 이상적 작업일, 우선순위에 따른 구현 순서 결정 등의 개념 또한 소프트웨어개발 종사자 모두가 들어야 할 충고이다.  이 책을 읽고 가장 큰 도움을 받을 사람은 애자일 개발 프로젝트의 PM일 것이며 애자일 개발에 관심있는 모든 사람이 실제 적용에 큰 도움을 받을 것이다.  과거에 애자일 개발을 직접 시도했었으나 그 실제 적용 과정에서 어려움을 느겼던 사람이라면 이 책을 읽으면서 책이 너무 늦게 나왔거나 너무 늦게 읽은 것을 후회하는 경우도 많으리라 짐작된다.

  단, 애자일 방법론하에서의 추정과 계획에 대한 내용이니만큼 애자일 방법론의 한계로 지적되는 대형프로젝트 - 철저하게 계약서에 기반하여 업체간 역할과 일정이 분담되고 각 업체 당사자들은 지독하게 정치적이며 개발팀의 규모가 너무 커 전원이 일정 회의에 참석하는 것이 불가능한 그런 프로젝트-에서의 적용의 어려움을 어떻게 극복할 것인가에 대한 대답은 들어 있지 않다.  저자가 든 예시들도 모두 상품으로서의 소프트웨어 개발 과정에서 Product Manager와 개발팀간의 의사소통 문제에 편중되어 있다.  가령 삼성전자에서 기존의 ERP를 모두 걷어내고 자체 개발하기로 한 경우 어떻게 추정하고 계획하여 불확실성을 줄일 것인가에 대한 답을 제시하려고 시도하지 않는다.  애자일 방법론을 사용하는 회사라면 이 책은 사장이 사서 직원들에게 무료로 나눠주고 세미나를 강제할 만한 가치가 있으나 애자일 방법론 자체에 대해 회의가 있다고 한다면 애자일 동네 안의 소식지정도로 간주될 것이다.