헤드퍼스트 시리즈는 무조건 좋아한다는...

편집도 재미있고 실용적이라 가끔씩 꺼내볼때는 아주 유용하답니다.

이 책은 원서로 접했었는데 번역본도 기대되네요.

이책에서 제시하는 agile방법론을 적용해보는것도 좋을거 같습니다.

번역서 기대됩니다.^^

이책을 통해 해외의 선진 aigle방법론을 간접적으로 접해볼 수 있고

책의 처음부터 끝까지의 전체 flow를 통해 진정한 agile이 무언지 다시금 생각나게 하는 책입니다.

소프트웨어 산업에 입문한 엔지니어라면 필독서로 추천드립니다^^

문제, 문제, 문제

• 대체 왜 기획자는 개발자가 필요로 하는 내용을 기획서에 담지 않는지,
• PM은 왜 툭하면 시연 등을 요청하여 개발 일정을 뒤틀어 놓는 것인지,
• 개발자는 함께 일정을 잡아놓고선 만날 야근하고도 일정을 지키질 않는지,
• 다른 조직의 개발자는 이틀이면 된다는 일을 왜 우리 팀 개발자는 일주일짜리 일이라고 하는지,
• 왜 그리도 개발자는 하드디스크가 잘 고장나서 소스 파일을 날려먹는 일이 여느 사람보다 훨씬 많은 것인지,
• 기껏 다 만들었더니 왜 요구한대로 만들지 않았냐고 사장님이 버럭 화를 내시는 것인지,
• 우리는 우리대로 손해보고, 고객은 고객대로 사기 당한 것 같은 얼굴을 보이는 일은 왜 그리도 잦은지.

해결을 하는 것이 문제

프로젝트를 진행하면서 이러한 상황을 종종 볼 수 있다. 경력이 많은 사람일수록 설화인지 전설인지 구분하기 어려운 무용담, 아니 개발담을 많이 갖고 있다. 그리고, 이런 상황을 해결할 수 있는 방법은 경력자 수만큼, 혹은 서점에 있는 책 개수만큼 많다. 예를 들면, 개발자에게 필요한 내용이 기획서에 제대로 나와있지 않다면 화술이나 대인관계론을 공부하여 기획자를 효과있게 구박하거나 기획자에게 개발 공부를 시켜서 상황을 해소하는 식이다.

이런 방법들이 틀린 것은 아니다. 그러나, 여러 톱니바퀴가 맞물려 돌아가는 상황에서 어딘가 이빨이 맞물리지 않아서 문제가 발생했다면, 각 톱니바퀴를 절대 망가지지 않는 초합금으로 만들고 금테를 두르는 것만으로는 문제를 해결하기 어렵다. 톱니바퀴 자체가 아니라 톱니바퀴가 맞물려 돌아가는 전체 흐름, 즉 개발 공정을 봐야 한다.

훌륭한 소프트웨어 개발을 위한 방법을 쉽고 재미있게 배우자

Head First Software Development 는 개발 공정을 주제로 하는 방법론을 다루고 있다. 개발 공정 중 일부에 대해서, 혹은 방법론을 깊이 다루지 않는다. 소프트웨어 개발의 전체 흐름, 그리고 개발할 소프트웨어와 관계된 이해당사자에 대해 이야기를 하고 있으며, 이러한 내용을 가상으로 프로젝트를 시작하고 완료하는 공정에 비추어 친절하게 설명한다.

책 이름이 개발자를 위한 것 같지만, 실은 기획자나 프로젝트 관리자(PM)도 함께 봐야 할 책이다. 이들이 숙지해야 할 내용이 있기 때문에 그렇기도 하지만, 다정하고 친절하게 개발 공정을 설명하는 책이기에 그렇기도 하다. 마치 이야기 구성이 잘 짜여진 소설을 읽듯이 프로젝트 시작부터 완료까지 개발 공정 이야기를 편안하고 쉽게 읽을 수 있다.

내용 구성

책은 크게 계획, 업무 정의(사용자 스토리, 태스크), 이터레이션, 버전 관리, 테스트, 버그 관리에 대해 다루고 있다.

계획 과정에서 고객의 요구사항 파악 및 우선순위 도출을 하고, 사용자 스토리를 기반으로 업무(task)를 정의한다. 이 업무는 조직의 개발 속도 등을 감안하여 이터레이션(iteration)을 나누어 진행하며 마일스톤으로 향한다. 물론, 각 이터레이션에는 협업 환경에서 필수인 버전 관리 체계 따르기, 테스트 기반 개발(TDD : Test Driven Development), 그리고 버그 추적 및 관리를 하여 품질 관리 과정이 녹아 있다.

이 책은 이러한 각 과정을 12장(chapter)에 걸쳐 꼼꼼하고 친절하게 다루고 있다. 좀 더 자세히 말하자면, 책 구성과 내용이 주제보다는 독자에 기준을 두고 쓰여졌다는 생각이 들 정도이다. 이야기 전달력(스토리텔링)이 높다. 다른 기술서에선 한 두 단락으로 다룰 내용을 이 책은 내용 전달을 위해서 여러 쪽에 걸쳐 최대한 쉽게 풀어쓰고 각종 그림을 동원하기도 하고, 400장이 넘는 내용을 한 두 쪽짜리 연습문제로 내며(460쪽~463쪽) 깔끔하게 정리해서 책 이해를 돕는다.

이 정도면 불친절하고 꺼칠한 사수보다 Head First 책들이 더 낫다는 생각이 들지 않을까?

아쉬운 점

좋은 점이 참 많은 책이다. 하지만 아쉬운 점도 있다.

우선 책을 읽으면서 이러한 친절이 좀 과하다고 생각이 드는 점을 들 수 있다. 그림이나 사진 등으로 전달력을 높이는 건 좋은데, 오히려 시선을 흩뜨려서 집중을 해치는 경우도 간혹 있다. 나는 책에 줄을 긋거나 생각을 적으며 책을 읽는데, 이 책에 그러면 정돈되지 않아 산만해지는 꼴이 되어 버린다.

두 번째는 심심치 않은 오탈자이다. 다행히 뜻을 해치는 수준은 아니므로, 옥에 티가 뭍은 수준이라 할 수 있다.

서평을 마무리하며

앞서 말했듯이 난 이 책을 개발자 뿐만 아니라 기획자나 PM도 꼭 읽어야 한다고 생각한다. 책은 자바(Java)나 C#, C++ 같은 프로그래밍 언어를 알아야 한다고 하지만, 프로그래밍을 몰라도 충분히 소화할 수 있다. 그만큼 쉽게 이해하도록 쓰여져 있다.

설령 프로그래밍 언어를 몰라서 내용을 이해하기 어렵더라도 개발자에게 모르는 걸 물어보며 개발 공정을 이해하도록 노력해야 한다고 생각한다. 개발 공정이라면 마땅히 개발이 어떤 공정으로 흐르는지 알아야 하는데, 기획자나 PM은 “공정”에 자신만의 관점과 생각을 반영하여 개발 과정에서 소통 차질을 일으키곤 한다. 이런 문제는 개발 공정 중 “개발”에 지식을 쌓으면 어느 정도 해소되지만, “개발 공정”을 이해하여 개발과 공정 모두를 잡을 수도 있다. 물론, 프로그래밍이나 그래픽 디자인처럼 기획을 구현하는 “개발” 영역을 이해한다면 금상첨화이다.

이제 글을 열며 제기한 문제들을 해결하는 방법 하나를 꼽으며 글을 닫으려 한다. 이 책을 곁에 두고 읽으며 실천해보는 것이다.

애자일 방식에 기반한 소프트웨어 개발의 전반적인 리뷰 격의 책이다. 이 말은 각 챕터에서 말하는 주제에 대해 이 책만 봐서는 정확하게 알기 힘들다는 의미다. 물론, 안 보는 것 보다야 낫다는 건 확실하다. 반대로 말하면 이미 애자일 프로세스에 대해 알고 있다면 딱히 볼 필요가 있을까 하는 생각도 든다. 말 그대로 리뷰한다는 느낌으로 한 번 보는 의미는 있을 것이다. 하여튼 애매한 책이다.

이 책을 일주일 동안 지하철에서 출퇴근 시간에 보면서 이런 애매한 포지션의 책을 누가 보면 좋을까 하는 생각을 하다가 마침 생각난 것은 기획 및 QA 담당자다. 물론 기획/QA 담당자 역시 이런 프로세스에 대해 이미 알고 있는 사람(또는 경험적으로 비슷한 방식으로 프로젝트를 수행하는 사람들)도 있지만, 대부분은 개발 프로세스를 관리한다는 것에 대해 막연하게 접근한다. 이런 사람들에게 한 번쯤 읽어 보면서 간단하게 설명을 덧붙여 주면 프로젝트 진행하기 좋을 거 같다. 아, 물론 이건 내가 있는 조직의 s/w 개발 규모나 성격이 애자일에 적합하다고 생각하기 때문이다.

물론 개발자라도 프로젝트 관리에 대해 이제 막 관심을 가지기 시작했다면, 괜찮은 책이다. 개인적으로는 애자일 프랙티스를 더 추천하고 싶다. 둘 다 읽어봐도 좋고. 어차피 금방 다 읽을 수 있는 책들이다.

p.s 오타가 좀 있다.

Head First시리즈 답게 기본적인 설명에 충실하고 내용도 훌륭하지만

좀 어이 없는 오탈자와... 원서에 있는 오탈자가 수정되지 않고 그대로 나와서

읽을때 좀 거슬리기는 하다.

원서의 오류를 확인해가며 읽어야 하는 나름의 재미도 느끼게 되지만..

아무래도 출간전에 수정 되서 나왔으면 더 좋지 않을까 한다.

머 이것만 빼면 처음 개발을 접하는 사람들이나 기획자들이 읽고 도움이 될만해 보인다.