1장 애자일 소프트웨어 개발<br/><br/>2장 애자일 시작하기<br/>1. 결과를 위해 일하라<br/>2. 땜질은 늪을 만든다<br/>3. 사람이 아니라 생각을 비판하라<br/>4. 위험을 무릅쓰고 앞으로 나가라<br/><br/>3장 애자일 기르기<br/>5. 변화에 뒤처지지 마라<br/>6. 팀에 투자하자<br/>7. 버려야 할 때가 언제인지 알자<br/>8. 이해할 때까지 질문하라<br/>9. 리듬을 느껴라<br/><br/>4장 사용자가 원하는 내용을 제공하기<br/>10. 고객이 결정하도록 하라<br/>11. 설계가 강요하는 대신 안내하도록 하라<br/>12. 기술 사용을 정당화하라<br/>13. 코드를 출시할 수 있게 유지하라<br/>14. 일찍, 자주 통합하라<br/>15. 배치를 일찍 자동화하라<br/>16. 데모를 사용하려 자주 피드백을 받아라<br/>17. 짧은 반복을 사용하여, 점진적으로 배포하라<br/>18. 고정 가격은 깨진 약속이다<br/><br/>5장 애자일 피드백<br/>19. 수호천사를 곁에 두기<br/>20. 만들기 전에 사용하라<br/>21. 차이는 다른 결과를 만든다<br/>22. 인수 테스트를 자동화하라<br/>23. 실제 진척 상황을 측정하라<br/>24. 사용자에게 귀를 기울여라<br/><br/>6장 애자일 코딩<br/>25. 의도적이고, 의미 있게 프로그램 하라<br/>26. 코드로 대화하기<br/>27. 능동적으로 트레이드오프(Trade-off) 평가하기<br/>28. 조금씩 코딩하기<br/>29. 단순하게 유지하라<br/>30. 응집도 높은 코드를 작성하라<br/>31. 묻지 말고, 말하라<br/>32. 계약에 의해서 교체하기<br/><br/>7장 애자일 디버깅<br/>33. 해결책 로그를 기록하자<br/>34. 경고는 진짜 에러다<br/>35. 문제를 격리해서 공격하라<br/>36. 모든 예외를 보고하라<br/>37. 유용한 에러 메시지를 제공하라<br/><br/>8장 애자일 협력<br/>38. 정규 대면회의를 가져라<br/>39. 아키텍트는 코드를 작성해야 한다<br/>40. 공동 소유를 실천하라<br/>41. 멘토가 되자<br/>42. 사람들이 알게 하라<br/>43. 준비되었을 때만 코드를 공유하라<br/>44. 코드 리뷰<br/>45. 다른 사람에게 계속해서 알리기<br/><br/>9장 에필로그 : 애자일로 이동하기<br/>9.1 새로운 실천방법 하나<br/>9.2 실패하는 프로젝트 구출하기<br/>9.3 애자일 도입하기 : 관리자 지침<br/>9.4 애자일 도입하기 : 프로그래머 지침<br/>9.5 끝?<br/><br/>부록 A 자료<br/>A.1 웹 사이트<br/>A.2 참고문헌

과연 어떻게 하는 것이 애자일한 것일까?
- 권정혁(http://xguru.net/blog/)

애자일, XP, SCRUM 등을 소개하는 책이나 블로그 글 등을 통해서 정보는 많이 얻을 수 있지만 애자일한 프랙티스들이 어떻게 실무에 적용되는 것인지에 대한 설명이나 관련 자료가 부족하여 실제로 개발자가 이를 적용해 보기는 쉽지 않은 게 사실이다.
과연 어떻게 하는 것이 애자일한 것일까? 애자일한 프랙티스들은 어떻게 실천할 수 있을까?
『애자일 프랙티스』는 이렇게 XP와 Agile 개념은 알고 있지만 실행해 보기 힘들었던 사람들에게 실전에서 어떻게 애자일 프랙티스들을 적용할 수 있을지를 알려주는 좋은 가이드북이다.
간결한 문체로 흥미로운 예제 사례 및 유머들과 함께 개발자가 따라야할 45개의 실천항목들을 제시하고 있다. 또한 실천항목의 나열만이 아니라 각 실천항목을 실제 적용했을 때 우리에게 나타날 수 있는 변화와 그 변화에 있어서 어떻게 균형을 맞춰나가야 하는지를 세세하게 설명하고 있어서, 핸드북처럼 옆에 두고 종종 펼쳐 보고 싶은 생각이 들게 한다.
애자일 관련 서적들을 보면 많은 개념들이 영어권에 익숙한 사람들이 쓰는 용어로 되어있어서 번역이 쉽지 않은 게 사실이다. 이 책의 번역서에 대한 리뷰를 부탁 받았을 때 과연 어떤 식으로 번역이 되어있을까 궁금했었는데, 역자인 신승환님은 블로그를 통해 소프트웨어 공학적인 이슈들을 많이 얘기해 오셨던 분이라 그런지 아주 매끄럽게 번역이 되어있었다. 원서의 간결한 느낌을 그대로 전하려고 노력한 흔적이 많이 보인다.
이전의 Pragmatic Programmers의 책들과 마찬가지로 아마존에서도 별 4개 반 이상의 좋은 평가를 받고 있으며, 애자일을 실전에 적용해 보고 싶은 개발자 분들께는 좋은 시작점이 될 것이다. 아니, 꼭 애자일을 적용해보고 싶은 개발자가 아니더라도 이 책은 도움이 될 수 있다. 각 실천 항목에서 보이는 문제점들이 자신의 주위에서도 일어나고 있다면, 이 책에서 제시하는 대로 행동해 보라. 어느 순간 애자일한 개발자가 되어있는 당신을 발견하게 될 것이다.


일상에서의 경험과 이를 개선하기 위한 작은 변화를 통한 성장에 초점
- 김성안(http://www.pragmatic.co.kr/blog)

애자일 프랙티스는 기민한 개발자가 되기 위한 "시작점이 되는 개발자의 태도, 습성 기르기, 고객 관점에서 개발하기, 피드백 활용, 개발, 디버깅, 협력"이라는 주제에 관한 45개의 실천사항을 정리한다. 각각의 실천방법만으로는 "스탠드업 미팅"과 같이 이미 알려진 실천방법도 다수 있고, "아이디어를 비난해야지 사람을 비난해서는 안 된다"와 같은 너무나도 당연해 보이는 실천방법도 포함한다. 하지만 단순히 45개의 실천방법을 잘 정리한 것 이상의 무언가가 있다.
먼저, 45개의 실천방법 중에서 (당연한 걸 포함해서) 얼마나 적용하고 있는지 자신에게 묻자. 책 전체에 걸친 천사의 조언과 악마의 유혹은 이미 무엇이 옳은 것인지 알지만 실천하지 못하는 우리의 마음을 잘 표현하는 수단으로서 흥미로운 존재이다. 모든 예외상황은 로그를 남기고 적절히 조치해야 함을 알면서도 당장 눈에 보이는 문제가 없기 때문에 숨겨두기도 하고 (그러고는 나중에 문제가 발생하면 숨겨둔 문제를 찾느라 엄청난 노력을 들이기도 하고), 문제가 있는지 알면서도 소스코드를 버전 관리 시스템에 체크인하기도 하는 평범한 개발자를 위한 책이다.
애자일 개발과 관련된 많은 책들을 볼 때 느낌은 "좋아 보이기는 하는데 하지만 이 사람과 팀이 열정적이고 대단하기 때문이겠지, 나와 우리 팀은 힘들 거야"와 같이 나와는 상관없는 이야기로 치부하고는 한다는 점이다. 애자일 프랙티스는 "맞아! 이런 상황이 있었지. 그땐 시간에 쫓겨 어쩔 수 없었지만 나중에 더 힘들어지더라."와 같은 개인의 일상에서의 경험과 이를 개선하기 위한 작은 변화를 통한 성장에 초점을 맞춘다. 45개의 실천방법 중 필요성을 느끼고 적은 노력으로 시작할 수 있는 것부터 시작한다면 나중에는 작은 변화들이 쌓여서 큰 변화를 만들 수 있다.
하루하루 자신의 잘못을 알지만 지나치거나, 자신이 무엇을 잘못 했는지 모른 채 잘못을 저지르는 평범한 개발자에서 든든한 기초를 가진 기민한 개발자가 되고자 한다면 좋은 시작점이 될 것이다. 얇고 부담 없는 책이라 읽기 시작한 책을 몇 번이고 다시 펼쳐보는 자신을 발견할 것이다. 조직을 평가하기 위한 수단으로 인기를 얻었던 조엘 테스트와 같은 느낌으로, 자신을 평가하기 위한 수단으로 애자일 프랙티스의 항목을 점검표로 사용하면 자신의 위치를 객관적으로 바로 보는데 많은 도움이 될 거라고 생각한다. 마지막으로 요즘 번역되어 나오는 많은 책들(애자일 프랙티스를 포함해서)의 자연스러운 번역 덕분에 좋은 내용을 빠르게 습득할 수 있게 되어 좋다.


업무 효율도 좋지만 이제는 인간다운 삶을 누리고 싶다는......
- 쿵야 어드벤처 게임 프로그래머 손경욱(http://writely.tistory.com/)

요즘 많은 사람들이 애자일 개발에 새롭게 관심을 가지고 궁금해 합니다. 관심이 없다고 하면 시대에 뒤떨어질 것 같은 기분이 들 정도입니다. 업무 효율도 좋지만 이제는 인간다운 삶을 누리고 싶다는 심리의 반증이 아닐까 합니다. (그렇다고 기존의 방법론이 효율이 높을까요? 저는 부정적입니다만.)
지금까지 애자일 방법론의 대표 격인 XP나 스크럼(Scrum)은 선각자에 의해 알음알음 전해져 왔지만 애자일 자체에 대한 것은 없었습니다. 그도 그럴 것이 애자일 자체는 형체가 있는 것이 아니고 그와 같은 경량 방법론들을 통칭해 부르는 말이니까요. 여러 방법론이 하나의 이름으로 불리는 것은 그들 사이에 공통점이 많다는 것을 의미할 겁니다. 그리고 그 공통점은 의미 있고 가장 중요한 부분일 가능성이 높습니다. 우리는 어떤 방법론을 선택하기에 앞서, '그럼 애자일한 개발이라는 것은 도대체 무엇인가?'를 알 필요가 있습니다. 이 책은 바로 그런 기대를 충족시켜 줍니다.
리뷰를 위해 원고를 받아들고 출퇴근길에 한 단원씩 읽었습니다. 처음에는 정말 좋아서 흥분할 지경이었지만 점점 그렇지 않게 되더군요. 제가 운영하는 블로그에 올리려고 가 편집 상태로 놓아 둔 다양한 소재를 다루는 이미 훨씬 더 좋은 글이 이 책에 들어 있었던 겁니다. 한 장 한 장 읽어갈 때마다 좌절을 하게 됐죠. 하긴 제가 블로그에 올린 글을 누가 보겠어요? 대신 실용주의 프로그래머로 유명한 앤디와 벤캣의 책을 보십시오.
지금에 와서 애자일은 다양한 분야에서 새삼스럽게 다시 회자되고 있습니다. 여러 권의 책이 나오고 사람들의 경험담이 전해져 옵니다. 지금이 기회입니다. 보다 인간다운 개발을 통해 어렸을 때 느꼈던 열정을 되찾읍시다.


‘애자일 = 실용주의’
- 주성식(http://www.codingstar.net/tts/)
소프트웨어 프로젝트를 진행하고 있는 많은 개발자들은 한해한해 지나갈수록 어려움을 호소하고 있다. 새로운 툴, 새로운 언어, 새로운 기술들이 아무리 쏟아져 나와도 상황은 그리 나아지고 있는 것 같지 않다. 이쯤에서 마인드의 전환이 필요함을 재고(再考)해 볼 수 있음은 극히 자연스러운 일이라 할 수 있겠다. 이러한 고민을 가지고 있던 중에 이 책을 읽게 되었다.
이 책에서 이야기 하는 애자일 방법론을 위한 practice들을 따라가다 보면 ‘애자일’ 이라는 한정된 단어를 벗어나 ‘실용적’, ’합리적’, ’효율적’이라는 의미로 확장되는 것을 뚜렷하게 느낄 수 있다. 이 책은 팀 내부의 의견 조율, 고객과의 효율적인 커뮤니케이션, 코드 베이스의 안정적인 관리, 자연스럽게 실천할 수 있는 TDD 방법, 해결책 로그 작성법 등을 자세한 예를 들어 보여 주고 있다. ‘애자일 프랙티스’를 읽으면서 저자의 경험을 간접 체험할 수 있는 유익한 시간을 보냈다. 나 스스로 현재 처한 프로젝트의 상황을 대조해 볼 수 있었으며 ‘애자일’ 이라는 단어를 낯설지 않게 느낄 수 있었다.
이제 책의 내용을 팀 사람들과 함께 공유할 차례다. 책에 소개된 프랙티스들 중 마음에 드는 것을 각자 하나씩 선택하고 간략한 스탠드 업 미팅을 진행해보자. 이렇게 마음에 드는 프랙티스들을 하나씩 실천해 나가다 보면 어느 새 우리의 팀은 성취감에 하루하루를 즐겁게 마무리 할 수 있는 ‘애자일’ 팀으로 변신해 있을 것이다.

기민한 개발자의 자질을 45개로 나눠 조목조목 설명
- 최재훈(http://kaistizen.net/)

소프트웨어 개발자의 자질과 역량을 다룬 책은 곰곰이 생각해보면 얼마 되지 않는다. 신기술의 명세를 다룬 책이나 프로젝트 관리를 말하는 책은 많지만, 의외로 프로그래머 자신에 관한 책이 많지 않다는 건 안타까운 일이다. '실용주의 프로그래머'가 거의 10년이 가깝게 사랑받는 이유도 이 때문이 아닐까? 이제 다시 앤디 헌트가 '애자일 프랙티스‘로 돌아왔다. 기민한 개발자의 자질을 45개로 나눠서 조목조목 따져나간다. 여기서 그치지 않고 실천 지침까지 알려주니 더할 나위 없다. 타성에 젖은 고참이든, 현업에 막 뛰어든 신참이든 각자 느끼고 얻는 바가 있으리라 생각한다.