S/W 개발자, 기획자 또는 관련 종사자들을 위한 책이다. 특히 책 뒷부분은 S/W coding에 대한 세부적인 상황이 나온다. 나도 어려서 GW Basic을 써본 이후로 프로그래밍이란 글씨와 여백과 같은 그림이상의 의미를 갖지 않는다. 다만 사용할 뿐이다.

그런데 영업쟁이가 이런 책을 읽는 이유는 한가지는 재미있다는 것이다. 두번째는 개발조직과 업무를 할때 그들을 이해하는 것이 중요하다고 생각하기 때문이다. 최근 UX(사용자 경험)에 대한 책을 읽은 이유도 보다 효과적으로 협력을 하기 위한 이유이다.

현업에서 느끼는 의사소통을 보면서 우리나라의 교육이 얼마나 편향되었는지 생각하게 된다. 사상과 관련한 과거의 트라우무로 인한 편향을 차치하고, 이과와 문과라는 말도 안되는 편향된 주입식 교육이 고학력 무능력을 양산할 가능성이 높다고 생각하기 때문이다.  이공계 사람들과 이야기하면 논리란 이성이 주류가 된다. 하지만 이들과 술을 한잔 기울이면 이들의 필요는 이성적 논리가 아니라 인간적 교감이다. 주위에 많이 있는 영업쟁이들을 보면 창의적이고 사람을 잘 이해하는 직종이란 편견과 달리 똘끼 충만에 고집불통이 한두가지가 아니다. 그들에게 필요한건 일관성과 논리라는 생각을 하게된다.  최종 사용자인 사람을 고려하지 않은 논리적이고 뛰어난 기계, 경제학과 경영학에서 수요와 공급, 필요를 배우고 나서도 계속 가격이 싸면 다된다는 영업이 그렇다. 갈증이 나야 가게 가서 마실것을 산다. 싸다고 사는 것도 아니고, 물만 담아서 판다고 팔리는 것이 아니다. 일반 사람이 먹기에 충분하고 적정한 양과 주머니 사정에 따라 고른다. 자기가 행동할땐 이런 기준으로 하고, 자기가 제공할때에는 사용자가 아닌 자기 맘데로 상상의 나래를 펴고, 확인도 안하는 환경이 문제인 것이다. 누군가 성공을 하고, 누군가 불필요한 제품을 만드는 낭비를 하는 이유라고 생각한다.

S/W개발과 관련하여서도 동일한 일이 빈번하게 발생한다. H/W는 단계적으로 개발이 진행되고, 물리적인 제작시간이후에 확인이 가능하다. 하지만 S/W는 특성상 관리하는 방식이 조금 다르다. 레고와 같이 모듈라방식으로 제작되어 합체와 분리를 할 수도 있고(이렇게 잘 만들수록 좋고), 다양한 정보를 indexing하는 기술이 발달될 수록 효과적으로 동작한다. 이런 동작을 수행하기 이전에 사용자이자 고객이 정말로 필요한 것을 재빠르고 효과적으로 찾아가는 방법중 하나가 Agile process다. 기존에 본 UX 기획 전략과 유사하게 접근하는 분석배경을 갖고 있고, 한가지 차이라면 전체의 과정을 운영해봐야 알기 때문에 그 과정속에서 어떻게 판단하고, 대응할 것인지에 대한 관리기법을 설명하고 있다.

S/W라 할지라도 시간, 품질, 비용, 범위라는 전설의 4총사..가 지속적으로 문제를 일으키긴한다. 여기서 조정가능한 것은 범위이다. 계획은 수정이 가능하지만 목표는 유지하는 것이 원칙에 가깝다. 물론 목표가 잘못되었다면 수정이 필요하지만 S/W개발에서 이 정도라면 기획능력이 부족하다고 봐야한다. 변화는 항상 존재하고, 이를 얼마나 창의적으로 인식하고 대응하는 것이 문제이지, 일관성없이 매일 바꾸는 것은 Agile process를 운영하는 팀에게는 부적합하다. 다른 일에도 그렇다.

책의 말미에 Agile팀이 되었는지 안되었는지보다 목표 즉 고객의 가치가 제대로 실현되고 있는지에 대해서 바라보라고 한다. 현업에서 가장 간과되는 일이고, 정책이 나오면 대책을 세우고, 상황이 바뀌면 목표를 접근하기 위한 판단이 바뀌어야 하는데, 약삭빠르게 목표를 바꾸는 일이 비일비재하기 때문이다. 

이 책을 보면서 많은 사람들이 google을 동경하고 자유로운 기업문화를 부러워한다. 하지만 그들이 생각하는 자유로움과 자율은 다르다고 생각한다. 기본적으로 자기통제와 절제, 목표의식, 실행력이 없는 사람들은 맹목적 자유를 동경한다. 하지만 세상이 유토피아인가? 공짜좋아하면 대머리된다..최근 본 한비자에 분조위마(힘좋은 말과 잘 달리는 말은 구유를 따로둔다)와 합조위저(게으른 돼지는 한 우리에 한 구유를 두어 경쟁하게 한다)의 말처럼 내가 가고자 하는 길이 둘중 어떤것인지도 선택의 문제이다. 그리고 Agile process & Team은 분조위마 수준의 사람에게 해당되는 말이지 합조위저의 수준에 필요한 말은 아니다.

인셉션덱이란 과정, 에자일팀원이 되기 위해서 필요한 역량, Check-in process라고된 기술적 부채(문제점)을 관리하는 방법은 매우 유익한 툴이라고 생각한다.

언제부터인가 애질리티(Agility)가 회사의 모든 일에 화두가 되면서 소프트웨어 개발 방법 중 하나인 애자일 방법론이 동네방네 퍼지기 시작했고, 결국은 경영기법의 하나로까지 확대되기에 이르렀다. 사실 애자일 방법론에 대한 많은 이야기들을 듣고, 그 중 몇 가지 방법들을 일부 실천해보기도 했지만 명확한 가치를 얻기가 힘들었다. 애자일 방법론의 고전이라 할 수 있는 이 책을 다시 집어 들어 읽은 것도 초심으로 돌아가 무엇을 해야 하는지 다시 고민하기 위해서였다. 우선 애자일의 기초, 즉, 신속하고 지속적으로 가치 있는 소프트웨어를 고객에게 전달함으로써 고객 만족을 이루는 일이 가장 중요하다는 저자의 선언에 공감한다. 또한 저자는 전형적인 애자일 프로젝트란 팀원 각각의 역할을 미리 정의하지 않는다는 것, 그래서 한 사람이 여러 가지 역할을 맡을 수 있다는 것, 분석, 코딩, 설계, 테스트 과정을 지속적으로 실행한다는 것을 강조한다. 결국 애자일 프로젝트에서 품질은 팀 모두의 책임이며, 참여하는 고객은 개발팀이 최상의 소프트웨어를 만들 수 있도록 데모에 참석하고 질문에 대답하며 피드백을 제공해야 한다는 것이다. 이 책에서 저자가 특별히 보여주고 있는 도구는 프로젝트를 시작하기 전에 꼭 물어야 하는 10가지 질문을 고민하는 인셉션 덱이다. 

그 중에서 제품의 광고를 디자인하라는 것과 무엇을 하지 말아야 하는지 NOT 리스트를 작성하라는 것이 눈길을 끌었다. 누가 왜 이 제품을 살지 스스로에게 묻는 과정은 우리 제품이 고객에게 끌릴 만한 점이 무엇인지, 이 제품만이 가진 남다른 기능은 무엇인지를 고민하라는 것이고, NOT 리스트를 작성하면서 꼭 해결해야 하는 중요한 문제들, 있으면 좋지만 무리할 필요 없는 사항들, 조금 더 생각해봐야 할 것들을 구분하라고 말한다. 한편 비용, 시간, 품질, 범위 중에서 희생해야 할 것은 범위라면서 할 것이 너무 많다면 일을 줄이라고 조언한다. 계획했던 것처럼 현실이 따라주지 않는다면 현실이 아니라 계획을 바꿔야 한다면서 말이다. 이어서 본격적으로 애자일을 어떻게 수행하는지 설명하고 있는데, 고객이 자신의 소프트웨어에 원하는 기능을 짧게 표현해 놓은 사용자 스토리부터 시작한다. 사용자 스토리를 작은 인덱스 카드에 짧게 적어 넣는 이유는 고객과 지속적으로 대화하며 거기에 적힌 기능을 언제 개발할지 모르고, 또는 나중에 아예 개발을 안 할 수도 있기 때문이라 한다. 좋은 사용자 스토리는 독립적이어야 하는데, 만약 모든 스토리가 서로 긴밀히 연결되어 의존도가 높다면 스토리를 바꾸거나 조정하기 어렵기 때문이라 한다.

한편 소프트웨어 추정의 주된 목적은 프로젝트의 결과를 예측하는 것이 아니라 프로젝트의 목표가 통제 가능할 만큼 충분히 현실적인지 알아보는 것이라고 말한다. 즉, 우리에게 주어진 시간과 자원으로 달성 가능한건지를 알아보는 것이라는 말이다. 그리고 해당 스토리의 크기를 숫자로 표현하고 다른 것들과 비교해서 스토리의 상대적인 크기를 정하면 대략 일정을 계산할 수 있다고 한다. 이 때 재미있는 것은 개발팀 팀원들이 각각 스토리의 추정치를 먼저 정한 후에 그 결과를 모두와 비교하는 게임을 해보라는 것이다. 그 추정치가 서로 많이 다르다면 팀원들은 논의를 통해 의견이 일치될 때까지 다시 추정하는 것을 반복하라고 조언한다. 또한 고객이 새로운 스토리를 추가할 때마다 오래된 스토리를 없애도록 하면서 범위를 조정해야 한다고 주장한다. 그 다음에 고객에게 가치가 있는 스토리들을 논리적으로 분류하여 묶고 우선순위를 정해서 개발을 시작해야 하는데, 이 때 고객에게 무엇을 언제 개발할지 결정할 권한이 있긴 하지만 개발팀도 아키텍처와 관련된 위험을 줄이기 위해서 어떤 스토리가 먼저 개발되면 좋을지 고객에게 추천할 의무가 있다고 말한다. 이어서 이터레이션과 테스트에 대한 내용이 전개되는데, 이 부분은 개발자 입장에서 많이 익숙해진 부분이라 할 수 있겠다.

저자는 다음 이터레이션을 준비하는 스토리 계획 회의, 지난 이터레이션에서 작업했던 스토리에 대한 피드백을 받는 쇼케이스, 다음 이터레이션에서 스토리들을 어떻게 작업할지 계획을 세우는 이터레이션 계획 회의, 향상될 부분이 있는지 지속적으로 찾아보는 미니 회고를 정기적으로 할 것을 권하고 있으며, 스토리보드, 릴리스 상황판, 번다운 차트, 인셉션 덱으로 시각적 작업환경을 조성하라고 조언한다. 그 외에도 코드가 어떻게 작동할지 조금이라도 미심쩍거나 결과가 기대하는 대로 나오는지 확인하고 싶을 때마다 단위 테스트를 쓰도록 하라고 말한다. 테스트 주도 개발에서는 새로운 코드를 쓰기 전에 먼저 새로운 코드로 성취하고자 하는 바가 무엇인지를 보여주는 실패하는 단위 테스트를 쓴다면서 말이다. 또한 코드를 리팩터링 할 때는 새로운 기능을 추가하거나 심지어 버그를 고치지도 않는다면서 이터레이션이 끝나기 전에 한 번에 몰아서 하도록 미루지 않고 매일매일 지속적으로 하는 적극적인 리펙터링을 권고하고 있다. 전반적으로 실무자 입장에서 애자일 방법론으로 소프트웨어를 개발하기 위한 핵심적인 기본 지침들이 잘 담겨 있는 책이라 하겠다.

개인적으로 애자일 입문서로는 최고의 책이다. 

애자일을 이해하는데 필요한 전반적인 개요를 이 책 한 권으로 정리할 수 있다. 

실제로, 애자일은 스크럼이나 칸반 등의 방법론으로 구현되지만, 구체적인 애자일 방법론에서 다루기 힘든 애자일의 기초 사항들인 중요한 몇 가지 개념들(인셉션 덱, 사용자 스토리 등)이 소개되고 있다. 그러나, 이 책에도 분명한 한계는 있다. 이 책의 내용만 가지고는 실제 애자일을 실무에 적용하기는 어렵다. 따라서, 이 책은 애자일의 이해를 위한 첫 번째 입문서 정도로 생각한다면, 읽고 나서 후회는 없을 것이다. 물론 좀 더 깊은 이해나 조직에 애자일 적용을 위해서는 좀 더 전문적인 내용의 책이 필요하다. 

PS) 책의 원제목은 Agile Samurai이다. 국내에서는 애자일 마스터로 책 명이 바뀌었는데.. 더 나은 것 같다.

이 책은 많은 애자일 관련 책 중에 최고의 입문서로 뽑히는 책이다. 

읽어보니 일단 무엇보다 애자일의 핵심 개념과 실천 방안에 대해 단계적으로 정확히 설명해 주고 있다. 그리고 작가 특유의 위트를 넣어 독자의 지루함을 어떻게든 줄어보려한 저자의 노력도 돋보인다. 

애자일에 관한 책을 읽어 보고 싶다면 이 책이 좋은 시작점이 될 것이다.

한가지 덧붙이자면 요즘 스타텁이 유행하면서 그로스 해킹과 린스타텁 등의 용어들이 덩달아 유행하는데 애자일도 함께 유행하는 유행어 중 하나이다. 그런데 이 개념은 그로스 해킹이나 린 개념과는 달리 완전 개발자용 개념이므로 단순히 스타텁 한다고 이 책을 개발자도 아닌 사람이 읽을 필요는 없는거 같다.